7大开源Agent源码对比解读——可扩展性

本文是「7大开源Agent源码对比解读」系列第 9 篇。评估对象：codex、gemini-cli、qwen-code、opencode、kimi-code、deepseek-harness（下称 dsh）、oh-my-pi（下称 omp）。

篇	文章	内容速览
总述	拆了七大开源 Agent 的源码，最高分竟然不是 Codex	总体结论、评估方法与评分卡
01	架构对比	四种流派与分化根源、主循环与事件机制、插件化与耦合风险
02	上下文管理	压缩触发阈值、摘要方式、token 计数口径、跨会话记忆
03	会话管理	持久化模型三层次、并发控制、崩溃恢复与 resume / fork
04	工具调用	注册与可见性、并行调度四种语义、审批门控、错误处理
05	重连与容错	重试预算、流中断处理、降级链、副作用安全
06	系统提示词与指令遵循	四种组装范式、动态注入、注入防御三层与共同敞口
07	思维链与工作流编排	思维链接入、plan 模式语义、子代理治理、工作流引擎
08	性能设计	前缀缓存三档分化、启动优化、成本核算
09	可扩展性	MCP 接入、自定义工具、多 provider、SDK 与 API
10	安全与权限控制	沙箱两种语义、审批默认姿态、企业管控、敏感数据保护

可扩展性看四个面：MCP 接入、自定义工具、多 provider 支持、SDK 与 API。先给 provider 开放性的总排序（按源码取证）：omp > opencode > qwen-code > kimi-code > gemini-cli > dsh > codex。

MCP 接入对比

项目	MCP 能力
codex	client（stdio、HTTP 传输 + OAuth），且自身可作为 MCP server
gemini-cli	client 四种传输 + OAuth + 服务账号冒充
qwen-code	client 三传输 + 连接池 + daemon 动态增删
opencode	client 三传输 + OAuth + roots + 状态机
kimi-code	client 三传输 + 进程级共享 OAuth
dsh	仅 client，无 server 侧
omp	完整 client + 能发现 5 家 IDE 已配置的 MCP server

MCP 已经是通用扩展总线，七家全部实现 client，工具命名空间统一为 mcp__server__tool。差异在两端：只有 codex 同时是 MCP server（其他客户端可以把 codex 当工具源调用）；omp 能扫描 VS Code、Cursor、Windsurf、JetBrains 等 IDE 的现有 MCP 配置直接复用，迁移用户零成本。

多 provider 支持对比

项目	provider 面
codex	仅 Responses API 兼容（chat wire 已从枚举移除）
gemini-cli	Gemini 为中心，OpenAI 兼容有限
qwen-code	4 套生成器：OpenAI 兼容、Anthropic、Gemini、Qwen OAuth
opencode	models.dev 外部模型目录 + 自定义 provider 配置
kimi-code	6 种协议（含 OpenAI Chat 与 Responses 两个变体）
dsh	DeepSeek 官方路由 + pi-ai 第三方目录 + OpenAI 兼容
omp	78 个 provider 注册文件 + owned dialect 回退

两个极端值得展开。

codex 的收紧。 WireApi 枚举只有 Responses 一个变体，Chat Completions wire 已经从协议定义里移除。接第三方模型必须自建 Responses 兼容代理。这是明确的生态绑定策略。

omp 的最后防线。 78 个 provider 注册文件之外，还有独家能力 owned dialect：给没有原生工具调用的模型伪造带内工具协议，在消息流里用标记编码工具调用与结果，加上伪造结果检测，任何能聊天的模型都能变成 agent。这是「provider 开放性」的真正底牌。

逐家特色扩展面

codex：策略语言与 marketplace

扩展面完整：extension tools、hooks、plugins、skills、connectors，外加插件市场的添加与升级工具。特别的是 execpolicy：独立的策略语言 crate，用 DSL 表达命令审批规则（PolicyParser/Policy/Evaluation）。SDK 提供 Python 和 TS 两套，包装 app-server 协议。

gemini-cli：把自己变成远程 agent

a2a-server 是独立包，把 gemini-cli 包装成 A2A 协议的 agent executor，可以被其他 A2A 客户端远程调度，执行状态推送到 A2A 事件总线（packages/a2a-server/）。这是「自身即服务」的扩展方向，配合 ACP 模式和 @google/gemini-cli-sdk，嵌入场景覆盖得比较全。

qwen-code：全端矩阵与格式兼容

扩展面是七家里最宽的：8 个 IM 渠道适配器（钉钉、飞书、企业微信、微信、Telegram、QQ、GitHub、GitLab），另有 desktop、CUA 桌面自动化、mobile-mcp、音频采集。4 套生成器之外还有 11 个命名 provider 预设加自定义模板。SDK 有 TS、Python、Java 三套。

一个务实的细节：extensions 里带 claude、gemini、qoder 三种指令格式的转换器，别家工具的配置资产可以直接迁移。

opencode：单源生成全端

扩展面的工程化程度高：插件分 npm 与本地两种，稳定钩子约 15 个（含 event、tool、auth、chat.params、permission.ask 等，另有实验性系列），.opencode/tool/* 目录放项目级自定义工具脚本，即放即用。

模型目录从 models.opencode.ai 拉取，本地用文件锁加 hash 缓存。全端客户端从单一 HttpApi schema 生成（OpenAPI），TUI、Web、SDK 同源，不会漂移。另有 share 云服务。

kimi-code：插件分发与共享凭据

插件用 manifest 描述，支持从 GitHub 直接安装：解析仓库描述符为 codeload.github.com 的 zip 流，避开 api.github.com 每小时 60 次的匿名配额，支持 ref/tag 精确锚定（github-resolver.ts:5-74）。另有插件市场索引。

OAuth 做了进程级共享：同一机器上多个 kimi-code 进程共享一份凭据，进程内用互斥锁串行化刷新，进程间用写前后重读检测并发刷新（oauth-manager.ts:5-7）。多个 CLI 实例共存时不会互相踩 token。

服务端扩展走 kap-server（REST/WS，默认绑定回环地址，见安全篇），ACP 有 adapter 和 server 两套实现。

dsh：运行时自修改与云沙箱

扩展面最激进也最克制：defineTool 支持运行时注册工具，extensions 能修改工具注册表，但一切走 opt-in 和 fail-closed（注册变更时重新分类调度模式，未声明即独占）。模型自己可以安装、运行、卸载插件（cordis_define 工具），这是七者中唯一的运行时自修改。

外围扩展：e2b 云沙箱（含文件系统与子进程两套适配）、hooks 兼容 Claude Code 和 Codex 格式、JSON-RPC SDK（TS/Python）加 ACP server 加 API gateway。短板是 provider 侧第一方只有 DeepSeek 路由，跨生态要靠第三方目录。

omp：发现与最后防线

IDE MCP 配置发现和 owned dialect 回退（见上）。扩展分发走 marketplace（含自动更新），自定义工具是工厂模式，同一工具在不同会话（主代理、顾问、记忆后端）下可以有不同配置。SDK 入口是 createAgentSession。其他扩展面：browser-relay 浏览器控制、协作加密直播、WebRTC 实时语音。

给 Agent 开发者的借鉴清单

1. 先定模型，再选 harness。 模型生态绑定是选型的第一决定因素：codex 只认 Responses API，qwen-code 深度适配 DashScope，kimi-code 有独占的缓存亲和字段。反向选择要付出适配层成本。
2. MCP client 是标配，server 是加分项。 能让自己的工具被其他客户端消费（codex），生态位完全不同。
3. 模型目录不要自建，拉社区目录。 models.dev 这类社区维护的目录覆盖定价和能力声明，自建必然滞后（opencode 的做法）。
4. 协议无关层做统一抽象，适配层做脏活。 qwen 的 4 套生成器、omp 的多 wire 协议都说明：provider 差异不会消失，只会转移。
5. 插件分发支持多种来源。 npm、本地目录、GitHub zip、marketplace，各自的安装成本和审计强度不同，至少留两条路。
6. 多实例共存要共享凭据。 同机器多个进程各自刷 token 会互相作废（kimi 的进程级锁）。
7. 扩展的运行时修改要 fail-closed。 工具注册表能被运行时改动时，调度和审批必须重新评估（dsh）。
8. 给没有工具调用的模型留最后防线。 带内协议伪造（omp 的 dialect）让本地小模型也能当 agent，私有化场景价值很大。

---

文档地图

篇	文章	内容速览
总述	拆了七大开源 Agent 的源码，最高分竟然不是 Codex	总体结论、评估方法与评分卡
01	架构对比	四种流派与分化根源、主循环与事件机制、插件化与耦合风险
02	上下文管理	压缩触发阈值、摘要方式、token 计数口径、跨会话记忆
03	会话管理	持久化模型三层次、并发控制、崩溃恢复与 resume / fork
04	工具调用	注册与可见性、并行调度四种语义、审批门控、错误处理
05	重连与容错	重试预算、流中断处理、降级链、副作用安全
06	系统提示词与指令遵循	四种组装范式、动态注入、注入防御三层与共同敞口
07	思维链与工作流编排	思维链接入、plan 模式语义、子代理治理、工作流引擎
08	性能设计	前缀缓存三档分化、启动优化、成本核算
09	可扩展性	MCP 接入、自定义工具、多 provider、SDK 与 API
10	安全与权限控制	沙箱两种语义、审批默认姿态、企业管控、敏感数据保护