lxiol 博客

—title: 136K Stars 的 OpenCode 凭什么碾压 Claude Code SDK？TUI 界面都能被插件替换，Claude Code 一个像素都动不了
date: 2026-04-19 22:03:31
summary: title: 136K Stars 的 OpenCode 凭什么碾压 Claude Code SDK。TUI 界面都能被插件替换，Claude Code 一个像素都动不了 date: 2026-04-19 22:03:31 summary:
tags:

Claude Code
Codex
AI Agent
终端
浏览器
Git
知识库
开源
Claude Code
OpenCode
TUI
AI编程
开源项目
categories:
转载—

原文链接：https://mp.weixin.qq.com/s/OrOOJoRnHFyunD2JfaNIIA

四大 AI Coding Agent（Claude Code、OpenCode、Codex、Cursor）在配置级开放性上高度趋同，但内核可编程性分化严重。OpenCode 五层全开放，Codex 开源但 Hook 极薄，Claude Code 锁死模型和参数，Cursor 基本不可编程。选型取决于你要嵌入、定制还是直接用。

TL;DR — 2026 年的 AI Coding Agent 在”配置级”开放性上高度趋同——都有 Rules/Skills/Hooks/MCP/Plugin 的打包分发机制。真正的差异化在于内核可编程性：能不能动 agent loop、能不能替换内置工具、能不能修改发送给 LLM 的参数和消息历史。在这个维度上，四个产品分出了清晰的梯队：OpenCode 五层内核全部可编程（且开源可 fork）；Claude Code Agent SDK 在 system prompt 和工具集合上可编程，但 agent loop 和 LLM provider 不可动；Codex 的 agent loop 完全开源可 fork，但 Hook API 层极薄（目前只拦截 Bash 工具）；Cursor 基本不可编程——它的开放性服务于”在 IDE 内部用得更好”，而非”基于它构建外部产品”。

一、架构定位：四种不同的开放性哲学

四个产品对”开放性”的理解和定位完全不同。Claude Code 是 Anthropic 的”全托管 agent runtime”——SDK 帮你搞定一切，你只管调 query()。OpenCode 是”可组装的开源 agent 框架”——每个组件都有接口边界，第三方可以替换任何一层。Codex 走了一条独特的路：agent loop 完全开源（Rust），同时通过 App Server JSON-RPC 协议让任何客户端都能驱动这个 loop——JetBrains、Xcode、VS Code Extension、Desktop App 全部通过这个协议接入。Cursor 则是纯粹的闭源 IDE，它的所有”开放性”都服务于让用户在 Cursor 内部用得更好，而非让外部产品基于它构建。

维度

Claude Code

OpenCode

Codex

Cursor

核心抽象
query()
async generator

HTTP REST API + Plugin hooks

App Server JSON-RPC + fork 源码

Plugin Marketplace（配置分发）

运行时

子进程（spawn CLI）

长驻 HTTP 服务器

长驻 JSON-RPC 服务器

IDE 内嵌（不可嵌入）

语言支持

TypeScript + Python

TypeScript（插件）/ 任意语言（HTTP）

任意语言（JSON-RPC） / Rust（fork）

无 SDK

Agent loop

封闭，不可修改

Hook 注入 + 开源 fork

完全开源（Apache 2.0）

完全不可访问

模型锁定

仅 Anthropic Claude

30+ provider + 插件扩展

OpenAI 系（可换 base URL）

多模型可选，不可自定义

开源状态

闭源

MIT，136K stars

Apache 2.0，75K stars

闭源

二、Claude Code 的开放性设计

2.1 Agent SDK：把 Agent Loop 当库用

Claude Agent SDK 在 2025 年 9 月发布（最初叫 Claude Code SDK，后更名），目前 Python SDK 有 6133 stars、63 个 release，TypeScript SDK 有 1251 stars、78 个 release。它的设计哲学是”最少暴露原则”——给开发者足够的控制旋钮，但不暴露内部实现。

SDK 的核心 API 分为两个层次。query() 是一次性的 agent 调用，适合 CI/CD pipeline 场景；unstable_v2_createSession() 和 unstable_v2_resumeSession() 是有状态的 session API，适合多轮对话场景。两者都返回 async generator，每个 yield 的 message 携带 agent 的思考过程、工具调用和结果。

从源码中可以看到（ToolUseContext 类型定义），SDK 暴露的控制面相当丰富：

-
-

`// Claude Code 的 ToolUseContext 核心字段``{``options: {``commands: Command[]           // 可用的 slash commands``tools: Tools                  // 工具集合``mcpClients: MCPServerConnection[]  // MCP 服务器连接``customSystemPrompt?: string   // 替换默认 system prompt``appendSystemPrompt?: string   // 追加 system prompt``maxBudgetUsd?: number         // 费用上限``agentDefinitions: AgentDefinitionsResult  // 子 agent 定义``}``}`

tool() 函数允许开发者定义 in-process MCP 工具，避免了启动外部 MCP server 的开销。createSdkMcpServer() 则创建一个完整的 MCP 服务器实例，可以注入到 SDK transport 中。这两个 API 本质上是把 Claude Code 的 MCP 客户端能力暴露给了 SDK 使用者。

2.2 Hook 系统：确定性的生命周期控制

Claude Code 的 hook 系统是其开放性设计中最成熟的部分。从 coreTypes.ts 的 HOOK_EVENTS 数组可以看到，它定义了 24 个生命周期事件：

•工具相关：PreToolUse、PostToolUse、PostToolUseFailure——在工具执行前后插入逻辑•会话相关：SessionStart、SessionEnd、Stop、StopFailure——管理会话生命周期•权限相关：PermissionRequest、PermissionDenied——接管权限决策•子 agent 相关：SubagentStart、SubagentStop——监控多 agent 协作•上下文相关：PreCompact、PostCompact、InstructionsLoaded——在上下文压缩前后注入信息•工作区相关：WorktreeCreate、WorktreeRemove、CwdChanged、FileChanged——响应文件系统变化

每个 hook 支持四种处理器类型。Command hook 运行 shell 命令，是最直接的方式；HTTP hook 把事件 POST 到外部端点，适合集成 CI/CD 或监控系统；Prompt hook 发送一个 single-turn prompt 让模型做 yes/no 判断，适合模糊规则的检查（”这段代码看起来安全吗？”）；Agent hook 则 spawn 一个有工具访问权限的子 agent，可以读取文件、搜索代码后再做决策。

Hook 的配置支持精细的 matcher 语法。PreToolUse 和 PostToolUse 支持按工具名过滤（包括 MCP 工具的 mcp__server__tool 命名模式），if 字段支持类似权限规则的模式匹配——"Bash(git *)" 只对 git 命令生效，"Edit(*.ts)" 只对 TypeScript 文件生效。

从 hooks.ts 中的 syncHookResponseSchema 可以看出，hook 返回值的控制力很强：

-
-

`{``continue: boolean          // 是否继续执行``decision: 'approve' | 'block'  // 审批决策``updatedInput: Record<string, unknown>  // 修改工具输入``additionalContext: string   // 注入额外上下文``permissionDecision: 'ask' | 'deny' | 'allow'  // 权限决策``}`

一个 PreToolUse hook 不仅可以阻止工具执行，还可以修改工具的输入参数（updatedInput），或者注入额外上下文让模型在后续决策中参考（additionalContext）。但 hook 的控制力有明确的天花板——它不能修改 agent loop 的流控逻辑（比如重试策略、并发工具调用的调度、上下文窗口的裁剪算法），不能替换内置工具的实现（只能 block 后由 MCP 提供替代品），不能改变发送给 LLM 的 temperature/top_p 等推理参数。24 个事件看起来很多，但它们都是”在固定节点上的回调”，而非”对 agent 内核的编程接口”。

2.3 MCP、Skills、Plugins 的分层设计

Claude Code 的扩展点按”重量级”排列形成了清晰的层次：

CLAUDE.md / 指令文件是最轻量的扩展方式——纯文本文件，影响模型的行为偏好但不强制执行。Slash Commands（.claude/commands/*.md）是 Markdown 模板，用户通过 /command-name 触发，适合标准化重复性工作流。Skills（.claude/skills/*/SKILL.md）比 commands 更复杂，可以定义 allowedTools、model 选择和 hooks，且支持被其他 agent 自动发现。Subagents（.claude/agents/*.md）是完整的 agent 定义，包含独立的 system prompt、工具集合和模型选择。MCP 服务器通过标准协议连接外部工具，每个服务器运行在独立进程中。Plugins是最重量级的扩展，可以打包 skills、agents、hooks 和 MCP 配置为一个可分发的包。

从源码中 builtinPlugins.ts 的 BuiltinPluginDefinition 类型可以看出，plugin 是其他扩展点的超集：

-
-

`{``name: string``description: string``version: string``defaultEnabled: boolean``isAvailable?: () => boolean``skills?: BundledSkillDefinition[]  // 包含 skills``hooks?: HooksConfig                // 包含 hooks``mcpServers?: McpServerConfig       // 包含 MCP 配置``}`

2.4 权限与安全模型

Claude Code 的权限系统支持三级配置（managed > project > local），通过 allowedTools、deniedTools 和细粒度的 alwaysAllow/alwaysDeny/alwaysAsk 规则控制。在 SDK 中，开发者可以通过 PermissionRequest hook 完全接管权限决策——这对构建自动化 pipeline 至关重要，因为你需要程序化地决定哪些操作可以自动批准。

从 ToolPermissionContext 类型定义可以看到，权限系统支持”每个子 agent 独立配置”的模式：coordinator 的权限和 worker 的权限可以不同，探索型 agent 可以被锁定为只读，只有实现型 agent 才能写入。

2.5 SDK 的硬性限制：不可编程的部分

Claude Agent SDK 的”最少暴露原则”也意味着它有大量不可触碰的内核。对于想做深度二次开发的开发者来说，以下限制是硬性的：

模型锁定。SDK 强制绑定 Anthropic 的 Claude 模型。你可以选择 sonnet/opus/haiku，但不能接入 GPT、Gemini、Ollama 或任何自托管模型。这不是技术限制而是商业策略——Anthropic 通过 SDK 控制了模型调用链路。对比 OpenCode 可以通过 provider hook 注入任意 LLM provider，这是最根本的差异。

Agent Loop 不可修改。SDK 内部的模型调用 → 工具选择 → 执行 → 结果处理 → 上下文裁剪的循环逻辑完全封闭。你不能自定义重试策略、不能控制并发工具调用的调度、不能修改上下文窗口的压缩算法、不能注入自定义的 turn 结束条件（OpenCode 社区正在推进的 session.stopping hook 就解决了这个问题）。闭源意味着你也不能 fork 修改。

LLM 推理参数不可控。SDK 没有暴露任何接口让你修改 temperature、top_p、top_k、max_tokens 等推理参数。模型怎么采样、采样多少 token，完全由 SDK 内部决定。对比 OpenCode 的 chat.params hook 可以精确控制每个参数，Claude Code SDK 在这个维度上是零可编程性。

消息历史不可修改。你不能过滤、重组或注入发送给 LLM 的对话上下文。Claude Code 内部有自己的上下文管理和 compact 策略，外部不可干预。OpenCode 的 experimental.chat.messages.transform 允许对整个消息数组做任意修改——实现”选择性遗忘”、消息注入、上下文重排，这些在 Claude Code SDK 中都做不到。

内置工具不可替换。allowedTools 和 disallowedTools 控制哪些内置工具可用，但你不能修改 Bash 工具的执行逻辑、不能改变 Read 工具的文件过滤规则、不能自定义 Edit 工具的 diff 算法。如果你需要一个”受限版 Bash”（比如禁止网络请求的 Bash），唯一的做法是黑名单掉内置 Bash，然后通过 MCP 提供一个替代品——但模型不一定会优先选择 MCP 工具而非内置工具，这种替代是脆弱的。OpenCode 的同名 override 机制（自定义 tool 用 bash 这个名字就直接替换内置 bash）要干净得多。

无 HTTP API 层。SDK 通过 spawn 子进程与 Claude Code CLI 通信，不暴露 HTTP 端点。这意味着你不能用非 TypeScript/Python 语言驱动 agent（除非自己包装 CLI 的 stdin/stdout），也不能在浏览器端直接调用。对比 OpenCode 的 HTTP REST API 和 Codex 的 App Server JSON-RPC，Claude Code SDK 在跨语言集成上是最受限的。

三、OpenCode 的开放性设计

3.1 Plugin 体系：函数式的 Hook 注册

OpenCode 的插件系统基于一个简洁的函数式接口。一个 plugin 就是一个 async 函数，接收上下文对象（包含 SDK client、项目信息、Bun shell），返回一个 hooks 对象：

1	`type Plugin = (input: PluginInput, options?: PluginOptions) => Promise<Hooks>`

这个设计的优雅之处在于，Hooks 接口定义了 20+ 个可选的生命周期 hook，每个都遵循统一的 (input, output) => Promise<void> 模式——插件通过 mutation output 对象来注入逻辑，而不是返回新值。这种”input 描述上下文、output 是可修改的结果”的模式，让多个插件可以链式处理同一个事件而不会互相覆盖。

从源码中的 Hooks 接口可以看到，OpenCode 的 hook 覆盖了几乎所有关键决策点：

•**chat.params** 和 **chat.headers**——在 LLM 请求发出前修改温度、top_p、top_k、自定义 header。这是 Claude Code 完全没有暴露的能力——在 Claude Code 中，你无法修改发送给模型的参数•**chat.message**——在消息到达模型之前拦截和修改•**permission.ask**——接管权限决策•**tool.execute.before** 和 **tool.execute.after**——工具执行的前后 hook•**tool.definition**——动态修改发送给模型的工具描述和参数 schema•**shell.env**——为 shell 命令注入环境变量•**command.execute.before**——在 slash command 执行前注入 parts•**experimental.chat.system.transform**——直接修改 system prompt•**experimental.chat.messages.transform**——修改整个消息历史•**experimental.session.compacting**——自定义 compaction prompt

experimental.chat.system.transform 和 experimental.chat.messages.transform 这两个 hook 值得特别关注。它们让插件可以在消息发送给 LLM 之前，对整个对话历史和 system prompt 进行任意修改。这种级别的控制力在 Claude Code 中不存在——Claude Code 的 customSystemPrompt 和 appendSystemPrompt 只能替换或追加，不能根据运行时状态动态修改。

3.2 自定义工具：一等公民

OpenCode 的 tool() helper 提供了极简的工具定义 API：

-
-

`import { tool } from "@opencode-ai/plugin"````tool({``description: "Query the database",``args: {``query: tool.schema.string().describe("SQL query"),``},``async execute(args, context) {``// context 包含 sessionID、messageID、directory、worktree、abort signal``return `Result: ${await db.query(args.query)}```},``})`

工具的 context 对象提供了 sessionID、messageID、agent 名称、工作目录、worktree 路径、abort signal，以及两个关键方法：metadata() 用于设置工具执行的元数据（标题、自定义数据），ask() 用于触发权限请求。这意味着自定义工具可以像内置工具一样参与权限系统。

对比 Claude Code 的自定义工具方式——通过 createSdkMcpServer() 创建一个 MCP 服务器实例——OpenCode 的方式更轻量。你不需要理解 MCP 协议，直接定义一个函数和它的参数 schema 就行。

3.3 Provider 系统：真正的模型自由

OpenCode 源码中的 provider.ts import 列表直观地展示了它的 provider 生态——直接内置了 20+ 个 AI SDK provider：Anthropic、OpenAI、Google（Generative AI + Vertex）、Azure、Amazon Bedrock、XAI、Mistral、Groq、DeepInfra、Cerebras、Cohere、Together AI、Perplexity、Vercel、OpenRouter、GitHub Copilot 等。每个 provider 都通过 Vercel AI SDK 的标准 LanguageModelV3 接口抽象。

更关键的是，插件可以通过 provider hook 注入自定义 provider 和 model：

-
-

1	`{``provider: {``id: "my-custom-provider",``models: async (provider, ctx) => ({``"my-model": { /* model definition */ }``})``}``}`

这使得社区可以构建认证代理插件（如 opencode-openai-codex-auth 让 ChatGPT Plus 订阅直接用于 API 调用，opencode-gemini-auth 复用 Gemini 计划）和自定义 provider 适配器。

3.4 TUI Plugin：可编程的终端界面

OpenCode 的 TUI 插件系统是两者之间差距最大的一个维度。Claude Code 的 TUI 是完全封闭的——用 Ink（React for Terminal）渲染，不提供任何 UI 扩展点。OpenCode 则暴露了一个完整的 TUI 插件 API：

Slot 系统定义了 10+ 个 UI 插槽：app、home_logo、home_prompt、home_bottom、sidebar_title、sidebar_content、sidebar_footer 等。插件可以通过 api.slots.register() 向这些插槽注入自定义组件。每个 slot 支持不同的渲染模式——replace（替换默认内容）、single_winner（只有一个插件生效）、默认模式（所有插件叠加）。

Command 系统让插件注册自定义 slash commands：

-
-

`api.command.register(() => [``{``title: "My Command",``value: "my-command",``description: "Do something cool",``keybind: "ctrl+alt+m",``slash: { name: "mycommand", aliases: ["mc"] },``onSelect: () => { /* ... */ },``}``])`

Route 系统甚至允许插件注册完整的 TUI 页面——你可以创建一个全新的视图，用户通过导航到达。

Theme 系统支持完整的色彩定制，每个 theme 定义 50+ 个语义化色彩 token（从 primary 到 syntaxKeyword），支持 dark/light 模式切换。主题可以通过 JSON 文件定义，也可以通过插件的 api.theme.install() 动态安装。

Keybind 系统允许插件创建自己的键绑定集合，用户可以在 tui.json 中覆盖任何默认绑定。

3.5 SDK 与 HTTP API：程序化的外部控制

OpenCode 的 SDK（@opencode-ai/sdk）本质上是自动生成的 OpenAPI 客户端。因为 OpenCode server 暴露了完整的 REST API，任何语言都可以通过 HTTP 调用来控制它。SDK 同时提供了启动 OpenCode server 进程的能力：

-
-

1	`import { createOpencode } from "@opencode-ai/sdk"````const { client, server } = await createOpencode({ port: 4096 })``// client 是类型安全的 HTTP 客户端``// server.close() 停止服务器`

v2 API 还提供了 createOpencodeClient() 支持 workspace 和 directory 级别的资源隔离，以及 SSE event stream 用于实时订阅 agent 状态变化。

这意味着你可以用任何语言构建 OpenCode 的上层应用——Go、Rust、Python——只要能发 HTTP 请求就行。Claude Code 的 SDK 则绑定在 TypeScript 和 Python 两个语言运行时上。

四、Codex 和 Cursor：另外两种开放性路径

4.1 Codex：开源 Agent Loop + 薄 Hook 层 + 强嵌入协议

Codex（OpenAI）在内核可编程性上呈现一种独特的”两极分化”：底层 agent loop 完全开源（Apache 2.0），你可以 fork codex-rs/core 修改任何逻辑；但如果不 fork，通过 Hook/API 能做的事情远比 OpenCode 和 Claude Code 少。

Agent Loop 完全开源。codex-rs/core 是 Rust 实现的核心 crate，包含完整的 agent loop（模型调用 → 工具执行 → 结果处理 → 上下文压缩）、沙箱系统（macOS Seatbelt / Linux Landlock+seccomp）、tool dispatch、MCP 集成。OpenAI 甚至写了详细的博客《Unrolling the Codex agent loop》解释架构。如果你有 Rust 能力，fork 这个代码修改 agent/、codex_thread/、state/ 等模块是完全可行的。但 fork 意味着你需要自己维护后续更新——这是一个重要的工程决策。

Hook 层极薄。Codex 的 Hook 系统（需要在 config.toml 中启用 codex_hooks=true，仍为实验性功能）目前只支持 5 个事件：SessionStart、PreToolUse、PostToolUse、UserPromptSubmit、Stop。更关键的限制是：PreToolUse 和 PostToolUse 目前只拦截 Bash 工具——Read/Write/Edit 等其他内置工具不触发 hook。PreToolUse 可以 deny（阻止执行）或注入 systemMessage，但不能修改 tool input；PostToolUse 可以 block 后续执行，但不能修改 tool output。对比 OpenCode 的 tool.execute.before（可以修改 args）和 tool.definition（可以修改工具描述），Codex 的 hook 控制力弱很多。

System Prompt 可替换。通过 config.toml 的 model_instructions_file 或 CLI flag codex -c developer_instructions="..." 可以替换模型指令。值得注意的是，AGENTS.md 在 Codex 中不是 developer instructions 的一部分——它作为 user message 注入，这和 Claude Code 的 CLAUDE.md 逻辑不同。Codex 仓库中还包含了按模型定制的 prompt 文件（gpt_5_codex_prompt.md 等），可以直接替换。

LLM Provider 半开放。codex-core 支持配置自定义 OPENAI_BASE_URL，理论上可以指向 Ollama、LM Studio 等 OpenAI 兼容端点。但 API 格式锁定在 OpenAI 的 Responses API / Chat Completions API，不能注入一个全新的 provider 抽象。社区已经有 Ollama 支持的 PR。

App Server 是独特优势。Codex 的 App Server（codex app-server，开源 Rust 实现）是一个双向 JSON-RPC 2.0 协议，支持 stdio 和 WebSocket 传输。JetBrains IDE、Xcode、VS Code Extension、Desktop App 全部通过这个协议接入。协议涵盖了 thread/turn 生命周期管理、审批流程、配置读写、认证、流式事件推送。社区已经有 TypeScript 客户端包装库（@ratley/codex-client），Elixir SDK 也实现了 MCP 客户端。你可以用 codex app-server generate-ts 自动生成 TypeScript 类型定义，或者用 generate-json-schema 生成 JSON Schema 再用任何语言的代码生成器。这让 Codex 成为四个产品中最容易被嵌入到其他产品中的 agent——不是通过改它的内核，而是通过驱动它的接口。

4.2 Cursor：配置级开放性，非内核可编程性

Cursor 在”配置级”开放性上做得很成熟——Plugin Marketplace 有 60+ 官方审核的插件（Stripe、Figma、Linear、Datadog、GitLab、Atlassian、Shopify 等），Skills 标准（agentskills.io）实现了跨 agent 的可移植性，Hooks 支持 20+ 事件。但从”内核可编程性”角度看，Cursor 基本不可编程。

Agent Loop 完全不可访问。闭源，无 SDK，无 API 可以控制 agent 的执行逻辑。Cloud Agents API 可以程序化创建和管理 agent，但这是一个管理 API（”远程操控 Cursor”），不是 agent loop 的控制 API（”嵌入 Cursor 到你的产品”）。

内置工具不可覆盖、不可修改。Hooks（hooks.json，支持 Command 和 Prompt 两种处理器类型）可以在 preToolUse/postToolUse 等事件上运行 shell 脚本做观察或阻断，但不能修改 tool input/output。不能添加”内核级”的新工具——只能通过 MCP server 外挂。对比 OpenCode 的同名 tool override 机制（自定义 tool 用 bash 这个名字就能替换内置 bash），Cursor 没有等价能力。

System Prompt 静态可配。通过 Rules（.cursor/rules/*.mdc，支持 glob 匹配和 alwaysApply 控制）和 AGENTS.md 注入系统级指令。Team Rules 可以从 dashboard 下发（Enterprise 功能）。但没有编程接口来动态修改 system prompt——Rules 是静态文件，在 session 开始时加载。

LLM Provider 不可替换。Cursor 使用自己的 API 路由层，用户可以选择 Claude/GPT/Gemini 等模型，但不能注入自定义 provider。

消息历史完全不可访问。没有任何接口暴露或修改发送给 LLM 的对话上下文。

VS Code Extension API 只提供 registerServer（注册 MCP 服务器）和 registerPath（注册插件目录），不涉及 agent 内核控制。

Cursor 的开放性设计逻辑是明确的：它是一个商业 IDE 产品，所有扩展能力都服务于”让开发者在 Cursor 内部工作得更高效”。Plugin Marketplace 的 60+ 插件（Webflow 的 CMS 管理、Stripe 的支付集成、Datadog 的日志查询）都是”agent 在 Cursor 里使用的工具”，而非”基于 Cursor 构建的外部产品”。

五、内核可编程性矩阵

我们把”内核”定义为五层：Agent Loop（循环逻辑）、内置工具（Bash/Read/Write/Edit）、System Prompt（系统提示词）、LLM Provider（模型调用）、消息历史（对话上下文）。以下是四个产品在每一层的可编程性对比：

内核层

OpenCode

Claude Code SDK

Codex

Cursor
Agent Loop 可修改
Hook 注入 + 开源 fork

✗（封闭黑盒）

开源 fork（Rust）

✗（完全封闭）
内置工具可覆盖
✓（同名 override）

✗（只能黑名单+替代品）

✗（hook 仅拦截 Bash）

✗
工具参数可修改
✓（tool.execute.before）

✗（只能 block）

✗
工具定义可修改
✓（tool.definition hook）

✗

✗
System Prompt 可编程
✓（hook 动态注入/替换）

✓（四种方式，含完全替换）

✓（config/CLI 替换）

部分（静态 Rules 文件）
LLM Provider 可替换
✓（plugin 注入新 provider）

✗（锁定 Anthropic）

半开放（自定义 base URL）

✗（不可自定义）
LLM 参数可修改
✓（chat.params hook）

✗

✗
消息历史可修改
✓（messages.transform）

✗

✗
添加自定义工具
✓（tool() helper）

✓（MCP in-process）

✓（MCP）

✓（MCP 外挂）
嵌入其他产品
✓（HTTP API + SDK）

✓（SDK 库调用）

✓（App Server JSON-RPC）

✗

上表清晰地展示了分层：OpenCode 是唯一一个在五层内核上都提供编程接口的产品。Claude Code 在 system prompt 和自定义工具上提供了良好支持，但 agent loop、LLM provider、消息历史不可动。Codex 的源码级自由度最高（Apache 2.0 整个 agent loop 可 fork），但如果不 fork，通过 Hook API 能做的事比 OpenCode 和 Claude Code 都少。Cursor 在内核层面基本没有编程接口。

六、基于开放性构建的产品生态

6.1 Claude Code 生态

Claude Code Agent SDK（Python 6133 stars，TypeScript 1251 stars）的生态主要集中在”程序化 agent orchestration”方向。由于 SDK 把整个 agent loop 包装成了一个函数调用，它天然适合嵌入到更大的系统中。

Vercel 是 Claude Agent SDK 生态中整合最深的厂商，但它做的不是”基于 SDK 构建的独立产品”，而是三个层面的整合：(1) Vercel Plugin——一个打包了 47+ skill、3 个 subagent（AI Architect、Deployment Expert、Performance Optimizer）、5 个 slash command 的知识注入引擎，通过 PostToolUse hook 在 7 个生命周期节点实时验证代码中的废弃 API 和过期包；(2) AI Gateway——把 Claude Agent SDK 的请求路由通过 ANTHROPIC_BASE_URL 转发到 Vercel 的统一网关，实现使用量监控、provider 路由、成本追踪；(3) Sandbox——v0 的沙箱环境预装了 Claude Code CLI，agent 在隔离容器中执行文件操作和 shell 命令。这三层加在一起，Vercel 实际上把 Claude Code 变成了自己平台的”原生 AI 工程师”——但这些整合都是通过 Claude Code 的配置级接口（plugin、hooks、环境变量）实现的，不涉及 SDK 的内核修改。

Anthropic 官方 Demo 仓库（2107 stars）提供了多个参考实现：Email Agent（IMAP 邮件助手）、Research System（多 agent 协作调研）、Chat UI（React + Express + WebSocket 的完整聊天界面）、Resume Generator（Web 搜索 + 文档生成）、Excel Analyzer。

Vercel AI Gateway 和 Vercel Sandbox 提供了 Claude Agent SDK 的生产部署基础设施——前者做请求路由和可观测性，后者提供隔离的沙箱环境执行 agent。

Claude Code 生态的特点是垂直整合度高：Anthropic 提供模型 → Agent SDK 提供 runtime → Vercel 等提供部署基础设施。生态参与者倾向于在 SDK 之上构建完整的应用，而不是替换或修改 SDK 的某个组件。

6.2 OpenCode 生态

OpenCode（136K stars，超过 500 个 contributor）的生态更接近传统的开源插件市场——大量独立开发者构建小而专的插件解决具体问题。awesome-opencode 仓库（5088 stars）收录了上百个社区项目。

Token 优化类：opencode-dynamic-context-pruning（1964 stars，72 个 release）是最成熟的社区插件之一。它通过 compress tool 和自动清理减少 token 使用量，不修改会话历史，在测试中缓存命中率约 85%。opencode-snip 则通过预处理 shell 命令输出减少 60-90% 的 token 消耗。

Auth 代理类：opencode-openai-codex-auth 让 ChatGPT Plus/Pro 订阅直接用于 API 调用（相当于免费获得 agent 额度），opencode-gemini-auth 复用 Google Gemini 计划，opencode-antigravity-auth 接入免费模型。这类插件利用的是 OpenCode 的 auth hook 和 provider hook，Claude Code 不可能出现等价物，因为它锁定了 Anthropic 作为唯一 provider。

多 Agent 编排类：Oh My OpenCode（ohmyopencode.com）是一个完整的编排层，提供 Sisyphus agent（持续任务规划器）、Librarian（知识管理）等专门 agent，以及 20+ 个内置 hook。opencode-workspace 打包了 16 个组件的多 agent 编排 harness。opencode-worktree（400 stars）实现了 git worktree 自动创建和终端 spawn，每个 worktree 自动获得独立的 OpenCode 实例。

开发工具集成类：opencode-daytona 在沙箱中运行 session，opencode-helicone-session 注入 Helicone header 做请求追踪，opencode-sentry-monitor 集成 Sentry AI Monitoring，opencode-wakatime 追踪使用时间。opencode-rules（47 stars）实现了类似 Cursor Rules 的动态规则注入——它利用 experimental.chat.system.transform hook 扫描目录中的 .md / .mdc 文件并注入到 system prompt 中。

TUI 扩展类：opencode-rules 注册了 sidebar_content slot 在侧边栏展示所有已发现的规则，@plannotator/opencode 提供交互式计划审阅界面。大量社区主题（lavi、poimandres、smoke-theme 等）通过 TUI plugin 系统分发。

跨平台桥接类：ai-sdk-provider-opencode-sdk 把 OpenCode 封装为 Vercel AI SDK provider——任何使用 generateText() / streamText() 的应用可以直接调用 OpenCode 管理的模型。opencode-llm-proxy 启动本地 HTTP server 把 OpenCode 的模型暴露为 OpenAI/Anthropic/Gemini 兼容 API，让 Open WebUI、LangChain 等工具直接使用。opencode.nvim 为 Neovim 提供编辑器感知的提示。OpenChamber 是 Web/Desktop 前端和 VS Code 扩展。

OpenCode 生态的特点是去中心化和多样性：没有单一的”官方最佳实践”，社区根据自己的需求构建各种形态的插件。这种生态活力很大程度上受益于 OpenCode 的模型自由度——当用户可以用 Copilot 免费额度、Ollama 本地模型甚至 Antigravity 免费模型时，进入门槛大幅降低。

七、二次开发的上限和下限

7.1 按产品分析

OpenCode 的二次开发上限最高。experimental.chat.system.transform 和 experimental.chat.messages.transform 让你在消息到达 LLM 之前做任意修改——RAG、动态 few-shot injection、conversation steering 都可以以插件形式实现。provider hook 让你注入全新的 LLM provider。TUI 插件系统允许构建完整的上层应用（OpenChamber 就是 Web + Desktop + VS Code 三端客户端）。下限是：agent loop 本身仍由核心代码控制（hook 只在特定节点注入，不能修改流控逻辑）；experimental 前缀的 hook 可能在未来版本变更；极端情况需要 fork 整个 repo。

Claude Code SDK 的甜蜜区是”把 Claude agent 嵌入到你的系统中”。session API 支持多轮对话、forkSession() 分叉、connectRemoteControl() 远程控制、watchScheduledTasks() 定时触发。Hook 系统成熟（24 个事件，4 种处理器类型），自定义工具通过 in-process MCP 零开销注入。但它是一个黑盒——你控制输入输出，不能改内部逻辑。锁定 Anthropic 模型，不能改 LLM 参数，不能动态修改 system prompt（只能初始化时设置），无 HTTP API 层。

Codex 的独特价值在于两端：源码端，Apache 2.0 的 codex-rs/core 让你可以 fork 修改任何内部逻辑；协议端，App Server JSON-RPC 让你可以用任何语言驱动 Codex agent。两者之间的 Hook API 层很薄——5 个事件、仅拦截 Bash、不能修改 tool input。如果你的需求是”嵌入 Codex 到自己的 IDE/产品”，App Server 是目前最成熟的方案；如果你的需求是”深度定制 agent 行为”，要么 fork Rust 代码，要么等 Hook 系统成熟。

Cursor 不提供内核级的二次开发能力。它的 60+ 官方插件、Skills 标准、Cloud Agents API 都服务于一个目标：”让 Cursor IDE 内的 agent 用得更好”。你不能把 Cursor 的 agent 嵌入到你的产品中，不能修改它的工具实现，不能替换它的模型路由。如果你的需求是”基于 AI coding agent 构建自己的产品”，Cursor 不在候选名单上。

7.2 按需求选型

二次开发目标

推荐产品

原因

构建自定义 IDE/编辑器中的 AI agent

Codex App Server

成熟的 JSON-RPC 协议，JetBrains/Xcode 已验证

构建 CI/CD 中的自动化 agent

Claude Code SDK 或 Codex SDK

黑盒调用最省事；Codex exec 模式为 CI 优化

深度定制 agent 行为（改 prompt、改工具、改参数）

OpenCode

唯一在五层内核都提供编程接口的产品

接入非主流 LLM provider

OpenCode

唯一支持通过插件注入新 provider 的产品

在 Cursor IDE 内增强 agent 体验

Cursor Plugin

但这不是”二次开发”，是”配置增强”

Fork 后完全重写 agent 逻辑

Codex > OpenCode

Codex（Rust，Apache 2.0）和 OpenCode（TypeScript，MIT）都可 fork

八、设计哲学的根本差异

四个产品的开放性设计差异，反映了四种不同的商业和技术策略。

Anthropic 通过 Claude Code 控制了从模型到 runtime 的完整 stack。Agent SDK 刻意限制了”可替换性”——你可以在 agent 之上构建任何应用，但不能绕过 Anthropic 的模型或修改 agent 的核心行为。好处是体验一致性高、Anthropic 可以持续优化整个链路；代价是用户被锁定在 Anthropic 生态中。

OpenCode（SST/Anomaly 团队维护）选择了 WordPress 式的开放平台策略——核心引擎开源，通过插件生态创造网络效应。任何 LLM provider 都可以接入，任何人都可以构建插件，TUI 界面可以被完全替换。好处是生态多样性高、用户迁移成本低；代价是集成度和一致性不如 Claude Code。

Codex（OpenAI）走了”开源 harness + 闭源模型”的路线。agent loop 完全开源让社区可以审计和改进代码，App Server 协议让 Codex 成为可嵌入的基础设施。但 OpenAI 的商业模型仍然通过模型调用收费——你可以 fork 整个 harness，但仍然需要调用 OpenAI 的 API 才能获得最佳体验（虽然 Ollama 等替代方案可用）。

Cursor 是四个产品中唯一走纯闭源商业 IDE 路线的。它的开放性完全服务于 IDE 内体验——Plugin Marketplace 做生态黏性，Cloud Agents API 做远程管理，Team Rules 做组织治理。这个策略在商业上可能是最成功的（Cursor 的付费用户增长一直很快），但在”二次开发”维度上它不参与竞争。

从实际效果看，Claude Code 足以支撑 Vercel 构建 Plugin + AI Gateway + Sandbox 的三层整合（但这些整合都是配置级的，不涉及 SDK 内核修改）；OpenCode 催生了上百个社区插件的长尾生态；Codex 的 App Server 已被 JetBrains、Xcode、VS Code 等多个大型客户端验证；Cursor 则通过 60+ 官方审核插件构建了围绕 IDE 的生态护城河。四种策略各有优势，选择取决于你是要”嵌入 agent 到自己的产品”、”深度定制 agent 行为”、还是”在现成 IDE 中用得更好”。

References

本文转载自微信公众号，如有侵权请联系删除。