7大开源Agent源码对比解读——思维链与工作流编排

尘中远

119人浏览 · 2026-08-29 12:22:53

尘中远 · 2026-08-29 12:22:53 发布

7大开源Agent源码对比解读——思维链与工作流编排

本文是「7大开源Agent源码对比解读」系列第 7 篇。评估对象：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	安全与权限控制	沙箱两种语义、审批默认姿态、企业管控、敏感数据保护

这一篇覆盖四件事：让模型怎么想（思维链）、怎么计划（plan 模式）、怎么分工（子代理）、怎么编排（工作流引擎）。七家在这四件事上的分化都很清晰。

思维链的三种接入范式

范式一：服务端加密，客户端续接。 codex 关掉了服务端会话存储，把上一轮的加密思维块原样回传给下一个请求（include: ["reasoning.encrypted_content"]，client.rs:919）。加密块对客户端是不透明黑盒，不可读只透传，但模型能跨请求捡回推理上下文。这是关掉服务端存储后维持长链思维连续性的办法。

范式二：协议字段加事件流。 gemini-cli 按模型代际用不同形态的 thinkingConfig（includeThoughts、thinkingBudget、thinkingLevel），思维以独立 Thought 事件流式吐给前端，thoughtSignature 用于续接。qwen-code 要处理各家 wire 字段不统一的脏活：同一个「关闭思维」的意图，DashScope 档位模型发 reasoning_effort: 'none'，布尔模型发 enable_thinking: false，vLLM/SGLang 塞进 chat_template_kwargs，DeepSeek 发 thinking: { type: 'disabled' }，四条路径分别处理（openaiContentGenerator/pipeline.ts:1131-1212）。kimi 的 thinking.keep 走 extra_body 透传，优先级 env > config > 默认 all。

范式三：统一档位加快捷词。 qwen 定义了 5 档统一 effort（low/medium/high/xhigh/max），每家 provider adapter 再映回自己的 wire 字段，钳制到模型支持的最近档（reasoning-effort.ts:19-110）。omp 定义了 8 个 ThinkingLevel（Inherit 和 Off 是元档，其余 6 个是 effort 档），再靠 ultrathink 这类魔法关键字让用户一句话顶到最高档。分类器自动判断最高只到 xhigh，只有显式写 ultrathink 才到 max。

plan 模式的三种语义

项目	plan 语义	约束强度
dsh	log-only 状态 + 注入 guidance 提示词	软引导
gemini-cli	写工具描述改写为「只准写 plans 目录」	prompt 层软约束
qwen-code	enter/exit_plan + 批准后计划打码	软引导 + 省 token
opencode	edit 工具全 deny，只放行 plans/*.md	工具层硬隔离
kimi-code	写路径必须等于当前 plan 文件路径	七者最严
codex	展示型 TODO，与 Plan mode 是两个概念	不参与执行约束
omp	plan 模式 + 独立 plan 模型	模型分层

软引导和硬隔离的区别很实在：

dsh 的 plan 模式只是协作状态。 激活时往每轮请求注入一段 guidance 提示词，计划本身不强制执行，沙箱和审批策略独立运作、不读 plan 状态（plan-mode/src/index.ts:1-7）。状态是 log-only 的，从会话日志折叠而来，resume 和 fork 自动恢复。

opencode 和 kimi 在权限层动手。 opencode 的 plan 模式对 edit 工具 * 全 deny，只放行 .opencode/plans/*.md 和数据目录下的 plans（agent.ts:160-176）。kimi 更精确：writesOnlyPlanFile 检查所有写路径必须等于当前 plan 文件路径（plan-mode-guard-deny.ts:51-57），比「目录级」又细一层。

qwen 的计划打码值得单独说：计划批准后，全历史改写，把 exit_plan_mode 调用里的计划正文替换成一句指针（「计划已批准并保存到某路径，需要时去读文件」，geminiChat.ts:217-289）。既省 token，又防止后续轮次重复审改计划。

codex 的教训：update_plan 这个 TODO 工具和 Plan mode 是两个概念，注释里专门写明（plan_tool.rs:25），而且 Plan mode 下禁用 update_plan。两个相近概念并存时，文档和代码都要主动划清边界。

omp 的做法是模型分层：plan 可以用独立模型（PI_PLAN_MODEL 或 --plan 参数），规划用便宜或擅长规划的模型，执行用主力模型。

子代理的四种治理形态

继承型。 codex multi_agents v2 的子代理全盘继承父 turn 的模型、provider、effort、审批策略、沙箱、cwd（multi_agents_common.rs:194-233）。注释解释得很直白：不继承会让子代理和父代理在审批策略上产生分歧。

协议型。 gemini-cli 的 A2A 客户端可以调用远程 A2A agent（30 分钟超时）。dsh 有 6 个子代理后端接缝，包括把 codex 和 claude-code 当子代理调，子代理有独立的 report 回传通道和深度预算。深度预算是 durable 的，跨持久化和重启存活，防止 fork 链逃逸（child-agent.ts:116）。

隔离型。 omp 的 task 工具让子代理在工作区的 CoW 副本上干活（pi-iso，支持 APFS、overlayfs、btrfs、zfs、ProjFS 等 8 种后端），产物 diff 回主区，子代理的输出还要过 JSON Schema 校验。kimi 的 AgentSwarm 走数量路线：一个占位符模板填值数组，每项启一个子代理，单批上限 128（超过直接报错），启动策略是爬坡并发：先起 5 个，之后每 700ms 加 1 个，首次遭遇限流就停止爬坡，容量递减，3 分钟无限流则容量自愈加 1（subagent-batch.ts:16-26）。AgentSwarm 必须单独成批，不允许和其他工具同轮调用。

监督型。 omp 的 advisor 是七家中唯一的独立上下文监督设计：第二模型在每个 batch 前审一次主代理输出，严重度分三级，nit 排队不打断，concern 注入重述，blocker 硬阻断（豁免所有降级逻辑，必须中断）（advise-tool.ts:22-132）。子代理也可以有自己的 advisor。对高风险自治任务，这个设计的价值很大。

工作流引擎的四个成熟度档

第一档：无声明式工作流。 codex 只有 exec、app-server 协议和 cloud-tasks；opencode 只有自定义 slash command 加 ACP。都没有 DAG 或 pipeline 引擎。

第二档：运行时编排器。 qwen 的 workflow 工具三件套齐全：预算（token 限额）、journal 重放（按调用签名前缀 hash 命中已记结果就直接回放，不重跑）、stall 自愈（60 秒无进度触发中止重试，最多 3 次；工具在飞时计时器挂起，90 秒的构建不算 stall；子代理已拿到合法结构化输出则直接返回成功不重试）。kimi 的 Goal 状态机 4 态（active、paused、blocked、complete），配 token、turn、挂钟时间三维预算，任一维触顶就把 goal 推入 blocked；技术失败（流中断、过载）统一进 paused，用户可恢复。

第三档：模型即编排者。 dsh 让模型自己写 JS 编排脚本，脚本在 node:vm 沙箱求值、worker 线程执行（cordis-host-runner/src/sandbox.ts），ralph 组件围绕脚本做迭代执行：每轮起子代理、收 report、喂回，直到轮次上限，要求 fresh provider（不继承父上下文）和结构化输出。能力上限最高，调试门槛也最高。

第四档：DSL 加流内纠偏。 omp 的 workflowz 关键字触发确定性多子代理工作流，模型在 eval 里写代码调 agent() 扇出（并行分解、对抗式检查、管线），跨 JS、Python、Ruby、Julia，复用 task 的 CoW 隔离。

循环纠偏机制值得单独对比，因为模型在长循环中的行为漂移是共同问题：

项目	纠偏机制	位置
gemini-cli	loop-detector：LLM 裁判，置信度 0.9 + 二次确认	事后检测，最贵
dsh	repeat-tool-reminder：重复工具调用提醒	事后提醒
omp	TTSR：流内正则/AST 命中即中止、注入规则、重试	流内前置，最便宜

TTSR 的设计是「规则平时零开销」：规则带着条件模式（正则或 ast-grep）待命，逐 chunk 进缓冲区比对，命中才中止当前流、把规则作为 system reminder 注入、重试请求（export/ttsr.ts:4-6）。比事后提醒前置，比 LLM 裁判便宜几个数量级。

给 Agent 开发者的借鉴清单

长任务的 plan 模式选硬隔离。 工具层 deny 比 prompt 引导可预测得多，kimi 的「只能写当前 plan 文件」是最佳实践。
计划批准后打码。 正文换成文件指针，省 token 防重复审改（qwen）。
子代理继承父策略要完整。 模型、审批、沙箱、cwd 一起继承，防止父子分歧（codex 的注释是现成理由）。
递归深度预算要持久化。 跨重启存活，防止 fork 链逃逸（dsh）。
stall 检测要排除工具在飞。 否则 90 秒的构建会被误判卡死（qwen 的细节）。
批量子代理用爬坡并发。 固定大并发容易撞限流，爬坡加容量自愈更稳（kimi 的 5 起步、700ms 加 1、限流回退）。
循环纠偏前置比事后便宜。 流内模式匹配（TTSR）的投入产出比远高于 LLM 裁判（loop-detector 每次判定都是一次完整调用）。
思维链字段不统一是现实。 多 provider 场景要像 qwen 那样逐分支处理 wire 差异，或者像 omp 那样统一档位由 adapter 映射。

文档地图

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