这篇文章通过源代码解读对比了codex（OpenAI）、gemini-cli（Google）、qwen-code（阿里通义）、opencode（Anomaly）、kimi-code（月之暗面）、deepseek-harness（DeepSeek）、oh-my-pi/omp（Stencil Labs，fork 自 Pi）这7个开源Agent项目，从架构、上下文管理（压缩策略，记忆与跨会话）、会话管理（持久化，奔溃恢复）、工具调用、重连与容错、系统提示词与指令遵循、思维链与工作流编排（plan模式，子代理，工作流引擎）以及性能、可扩展和安全等维度，对这6个项目进行了对比，了解其工作原理，并总结了它们的优缺点。评估过程是对每个项目由独立分析任务逐文件取证（README/核心源码/配置/测试/文档），关键论断经源码抽样复核而得出。

本文适合 Agent 开发者（技术选型、架构设计、功能实现参考）或需要给项目嵌入Agent功能的人员。

评估日期：2026-08-21

1. 摘要

七个项目都是「编码 Agent / Agent Harness」类工具：都以 ReAct 式主循环驱动 LLM 与工具协作，都支持 MCP、子代理与某种 plan 模式，但在架构哲学、上下文治理、安全纵深、生态绑定上已经分化出四种流派：

流派	项目	一句话画像
原生内核派	codex、oh-my-pi	把热路径（循环、沙箱、shell、tokenizer）沉到 Rust，追求性能与隔离纵深
事件溯源平台派	deepseek-harness、opencode、kimi-code(v2)	会话即事件日志，一切状态可重放、可审计、可投影成 UI/存储
产品生态派	qwen-code、kimi-code	围绕自家模型构建全端产品线：daemon、IM 渠道、desktop、CUA、IDE、SDK
标准工程派	gemini-cli	Google 式完备：策略引擎、OTel、evals、perf 基线，但深度绑定 Gemini

五条关键结论（详见后文论证）：

1. 上下文压缩是同质化最高、差异最隐蔽的维度：7 个项目全部采用「LLM 摘要 + 尾部保留」范式，但触发阈值从 50%（gemini-cli）到 85%（kimi-code/qwen-code）不等；只有 oh-my-pi 有真 tokenizer（原生 BPE），其余全是字符启发式估算，中文场景下压缩时机的系统性偏差是集体盲区。
2. 安全纵深两极分化：codex（三平台原生沙箱 + 网络代理 + MDM 配置栈）与 gemini-cli（五级 TOML 策略引擎 + 四后端沙箱）构成第一梯队；opencode 在 SECURITY.md 中明确声明不提供沙箱，oh-my-pi/kimi-code 默认审批姿态宽松。
3. 事件溯源正在成为新一代架构的事实标准：deepseek-harness 的「Model-visible ⟺ logged」不变量、opencode 的 durable 事件 + projector、kimi-code v2 的 DI×Scope + 生成契约，都指向同一方向，会话日志是唯一事实源，UI/恢复/遥测全部从中派生。
4. 没有任何项目内置向量 RAG：跨会话记忆普遍是「文件 + 工具化访问」（codex memories、gemini-cli MEMORY.md、omp mnemopi 可选嵌入），检索靠 grep/LSP。把 RAG 嫁接到这些 harness 上是明确的机会点。
5. 选型第一决定因素是模型生态绑定：codex 只认 Responses API、qwen-code 深度适配 DashScope、kimi-code 独占 Kimi prompt_cache_key，先定模型，再选 harness，反之则付出适配层成本。

这是ai从：架构与工程质量（12%）、上下文管理（15%）、会话管理（8%）、工具调用（12%）、重连与容错（10%） 、提示词与指令（8%）、CoT 与编排（12%）、安全与权限（12%）和可扩展性（11%）这九个角度加权总分得到的排名：

deepseek-harness  4.62  ███████████████████████▏ 能力密度最高，但 developer preview
oh-my-pi          4.56  ███████████████████████   工程纵深最强，默认安全宽松
codex             4.37  █████████████████████▊    安全与持久化标杆，生态收紧
qwen-code         4.33  █████████████████████▋    全端生态最全，复杂度失控风险
gemini-cli        4.19  █████████████████████     工程护栏最完备，Gemini 绑定
opencode          3.93  ███████████████████▋      架构先进，安全/记忆短板明显
kimi-code         3.78  ██████████████████▉       工程化密度高，上下文手段单一

ai对deepseek-harness的评价非常之高，对其架构和思路大为赞赏

下面是每个板块的摘要对比性结论，详细信息单独文章放出

---

2. 项目基本盘对比

项目	语言/运行时	版本（仓库/本机实测）	许可证	核心源码规模*	测试文件数	Stars	Forks	月提交	贡献者	Open Issues
codex	Rust（tokio）+ TS/Py SDK	~0.147.x / 0.142.3	Apache-2.0	core 326k 行 Rust（全仓 1.44M，100+ crate）	1,385 Rust 测试文件、14,070 个 #[test]	111k	17k	1.2k	471	13k
gemini-cli	TypeScript / Node≥20	0.56.0-nightly	Apache-2.0	core 132k + cli 76k 行	965（core 测试代码 185k 行 > 实现）	107k	14k	75	442	556
qwen-code	TypeScript / Node≥22	0.21.14 / 0.21.13	Apache-2.0	core 295k + cli 401k 行	2,292	27k	2.9k	1.1k	418	873
opencode	TypeScript / Bun	1.18.20 / 1.18.18	MIT	主包 177k + core 67k（全仓 ~640k 含 UI）	645	200k	26k	396	456	4k
kimi-code	TypeScript / Node≥24.15	CLI 0.38.0 / 0.31.1	MIT	v1 70.9k + v2 110.7k + apps 130k	1,224	7k	1.1k	310	51	718
deepseek-harness	TypeScript / Node≥22	0.1.0-rc.5 / rc.6	MIT	非 vendor 491k 行 + 测试 259k，219 个叶子包	692 spec + 129 e2e	179k	20k	8.8k	28	0
oh-my-pi	TS（Bun）+ Rust（napi）	17.4.0	MIT（三层版权）	TS 170k + Rust 207k	2,192 TS + 157 Rust	26k	2.5k	4k	399	1k

3. 总体架构对比

架构风格总览

项目	架构风格	主循环位置	事件机制	插件化程度	耦合风险点
codex	单二进制多人格（TUI/exec/mcp-server/app-server），tokio 异步	codex-rs/core/src/session/turn.rs run_turn	ResponseEvent 流 + EventMsg 推送	高（hooks 11 事件/plugins/skills/extensions/MCP）	session/mod.rs 4,273 行 God Object 苗头
gemini-cli	core/cli 双层，ink/React TUI	core/src/agent/legacy-agent-session.ts:183 while 循环	GeminiEventType 事件流 + MessageBus	中（extensions 目录 + MCP）	Config 3,600+ 行服务定位器；新旧双轨并存
qwen-code	fork 骨架 + 四套 ContentGenerator + daemon	core/src/core/client.ts GeminiClient（类名未改）	ServerGeminiStreamEvent 扩展事件族	高（extensions + hooks + skills + channels）	单文件巨大（scheduler 6,496 行）、命名漂移
opencode	明确 client/server，TUI/Web/Desktop 皆 client	opencode/src/session/prompt.ts runLoop	durable 事件溯源（SQLite EventTable）+ SSE	高（npm/本地插件 + 15 钩子 + 自定义 agent/command）	V1/V2 双栈迁移中期
kimi-code	一核心多宿主（TUI/headless/ACP/Web/VSCode），v2 DI×Scope	v1 loop/run-turn.ts / v2 loopService	wire.jsonl 事件流 + 契约 manifest	中（plugins/skills/hooks/MCP）	v1/v2 双引擎双份维护
deepseek-harness	一切皆插件（vendored Cordis），profile→bundle→patch 组合	packages/core/agent-loop/src/agent.ts ReactLoopAgent	三类事件（会话/活事件/能力）+ waterfall	极高（运行时可自修改，cordis_define 工具）	概念词汇表庞大（seam/profile/bundle）
oh-my-pi	通用内核（agent 包）+ 产品层（coding-agent）+ Rust N-API 底座	packages/agent/src/agent-loop.ts（2,935 行）	异步生成器事件流 + 宿主钩子 ~60 个选项	高（extensions/custom tools/skills/marketplace）	coding-agent 单包 84.6k 行，内核与产品同包

本节解释 §3.1 表格中的术语，结论均出自源码取证，引证形如 file:line。

架构风格分化的根源

七个项目都是「编码 Agent / Agent Harness」类工具，主循环都是 ReAct 式的「采样 → 工具批执行 → 结果回灌」，但架构风格已经分成了四类，根源在于三个初始约束不同：

1. 运行时与语言选型决定了能做什么，codex 与 oh-my-pi 选 Rust/原生内核，于是沙箱、tokenizer、shell 能编进进程，工具执行零 fork；其余五家用 TypeScript，工具执行必经子进程，但换取了更快的迭代与更宽的生态。
2. 「谁是事实源」决定了持久化层级，把模型可见内容做成 append-only 事件日志（dsh、opencode、kimi-v2）才能做到 fork/resume/审计/回放同源；快照式（gemini-cli）或转录式（codex/qwen/omp）则 resume 语义受限。这是从「个人 CLI」走向「可审计平台」的分水岭。
3. 宿主数量决定了是否需要 DI/Scope 与 client/server 分裂，只跑一个 TUI 的项目（codex、gemini-cli、omp）可以把循环、状态、UI 揉在一个进程；要同时服务 TUI/Web/IDE/ACP 的项目（kimi-code、opencode、dsh）就必须把内核与宿主切开，于是出现 DI 容器、作用域生命周期、SSE/事件投影这一整套机制。

三种架构原型（Mermaid）

点评：

• 事件溯源在可审计场景占优：dsh 把「模型可见内容必须可从日志重建」写成运行时不变量，request/header 全量快照意味着任何一次模型请求都能离线复现，fork、压缩、UI 回放、遥测全部是同一份日志的不同 fold。opencode 的 projector 同思路但粒度到 message/part。代价是写路径复杂度（dsh 的日志锁事件、崩溃孤儿锁检测）。相比之下 gemini-cli 的 JSON 会话记录是「快照式」的，rewind/resume 语义受限。
• 原生内核在性能上占优：omp 把 ripgrep 引擎、brush bash、58 个 coreutils 编译进进程，grep/bash 零 fork/exec，Windows 无需 WSL，这对「编程 Agent 的 90% 操作是文件与 shell」的现实是降维打击。codex 的 musl 静态二进制同理。纯 TS 项目（gemini-cli/qwen/opencode/kimi）的工具执行全部经过子进程开销。

4. 上下文管理

压缩策略对比（核心表）

项目	触发阈值	摘要方式	尾部保留	特色机制	token 计数
codex	model_auto_compact_token_limit（模型目录/配置，scope=Total 或 BodyAfterPrefix）	本地 LLM 摘要（handoff 提示词）+ 服务端 remote v2 + Memento/PrefixCompaction 策略	初始上下文按注入语义重注入	new_context_window 工具（模型自开新窗口不摘要）；PreCompact/PostCompact hooks；fallback buffer	bytes/4 启发式（自认粗略）+ API usage 回传
gemini-cli	50% 窗口（可远端 flag 调）	LLM 摘要（专用压缩模型别名）+ 二阶段 Probe 自校验	30% 尾部；工具输出 50k token 预算，超额落盘	切分点避开 functionCall/Response 对；失败降级纯截断不烧钱；新 ContextManager 管线（8 processors，默认关闭）	ASCII 0.33/字、CJK 1.5/字 启发式；媒体才调 countTokens API
qwen-code	85% + 13k buffer（对照 claude-code 三级阈值）	LLM 摘要 <analysis>+<state_snapshot>	未明示比例（保留最近意图）	microcompaction（旧工具结果清空，无需 LLM）；压缩失败熔断器；压缩后附 subagent 快照	ASCII/4 + 非 ASCII×1.1（注释自认 ±30%）
opencode	tokens.total ≥ limit.input − reserved（reserved=min(20k,maxOutput)）	LLM 摘要，强制结构化模板（Objective/Important Details/Work State）	preserve_recent_tokens（2k~15k，窗口的 25%），turn 内可切分	prune：40k token 保护区外的旧工具输出标记清空；溢出时剥离媒体重放；插件可替换摘要 prompt	length/4（全文件 3 行）
kimi-code	85% 或剩余 <50k	LLM 摘要（第一人称 handoff note，用会话语言）	保留的用户消息原样 + 摘要	摘要请求 5 次重试、128k 输出预算、溢出→缩窗→再压缩最多 3 轮；microcompaction 已禁用成死代码	ceil(ascii/4)+nonAscii；measured/estimated 策略枚举
deepseek-harness	80%（pressure）+ overflow 失败触发	LLM 摘要（可独立 summarizationProvider）+ 确定性工具结果裁剪（pruner 先行）	16% 尾部，tool-call/result 配对边界	摘要是带 surfaceOp:replace 的日志事件；maxTokens:8192；per-model 策略覆盖；spill：超大工具结果溢出到文件只留首尾预览	token-meter：优先复用上次真实 usage 作锚点，否则启发式重估价
oh-my-pi	六种触发（手动/溢出/length 截断/回合后/回合中/空闲）	方法链：LLM 摘要、shake（机械省略为 artifact:// 引用）、snapcompact（历史渲染成 PNG 位图给视觉模型读）、预裁剪	firstKeptEntryId 之后全部保留	帧形状按 provider 计费调优；显示转录与 LLM 上下文分离	原生 BPE（tiktoken-rs），按模型族切编码器，唯一真实 tokenizer

七个项目的上下文压缩都遵循同一骨架：估算 token → 触发 → 摘要/裁剪 → 重注入保留段，差异集中在三处：

1. 触发阈值：从 gemini-cli 的 50% 早压缩到 qwen/kimi 的 85% 晚压缩，本质是「摘要次数 vs 单次摘要成本/溢出风险」的取舍。
2. 裁剪与摘要的先后：dsh 与 opencode 走「确定性裁剪先行」路线（零成本削减工具输出），qwen 走「microcompaction 独立通道」，gemini/opencode 把超大工具输出落盘保留可找回性。
3. token 计数：除 oh-my-pi 外全是字符启发式，且系数各异（0.25～1.5 token/字符），CJK 文本上系统性偏移。

记忆与跨会话

项目	指令文件层级	跨会话记忆	向量/RAG
codex	AGENTS.md 项目根→cwd 全拼接 + override + 用户级	~/.codex/memories 文件系统 + list/read/search/add 工具	未发现
gemini-cli	GEMINI.md 四层（global/extension/project/userProjectMemory）	saveMemory 工具 + memoryService 后台 LLM 抽取（3h 空闲门槛、30 分钟节流）+ JIT 子目录上下文	未发现（ragLogger 仅旁观服务端 grounding）
qwen-code	QWEN.md/QWEN.local.md/AGENTS.md/.qwen/rules，支持 @import	auto-memory 体系：extraction/recall/dream（离线记忆整理）/forget/secret-scanner/team-memory git 同步；mem0 外接集成	模型选择性检索（200 候选→5 注入），非向量库
opencode	AGENTS.md/CLAUDE.md 首类命中 + 就近目录动态挂载	未发现持久记忆	未发现
kimi-code	AGENTS.md 用户级+项目层级（不读 CLAUDE.md）	未发现（仅 session resume/fork）	未发现
deepseek-harness	AGENTS.md/CLAUDE.md + local 覆盖，字节预算与去重	session-reference（跨会话日志提取）+ session-query 工具 + MCP 外接记忆示例	未发现
oh-my-pi	.omp/AGENTS.md + 继承 8 种外部约定（CLAUDE/CODEX/GEMINI/opencode/copilot…）+ sticky rules	mnemopi：SQLite 记忆引擎，可选本地 ONNX 嵌入；local/hindsight 后端生成项目摘要注入	可选嵌入检索（唯一带向量能力的，但非默认代码检索路径）

七个项目的「跨会话记忆」能力差距远大于压缩策略。可分三档：

• 成体系：qwen-code（auto-memory：extraction/recall/dream/forget/secret-scanner/team-memory/mem0 外接）、oh-my-pi（mnemopi SQLite + 可选 ONNX 嵌入）、gemini-cli（memoryService 后台 LLM 抽取 + saveMemory 工具）。
• 文件系统级：codex（memories 工具 + SQLite 整合）、deepseek-harness（session-reference 跨会话引用）。
• 基本无：opencode、kimi-code（仅指令文件，无持久记忆）。

指令文件层面则普遍支持 AGENTS.md/CLAUDE.md 类约定，差异在层级数与是否读 CLAUDE.md。

点评：

• 阈值差异的本质是取舍：gemini-cli 50% 早压缩 = 摘要次数多、信息损失早但永不溢出；kimi/qwen 85% 晚压缩 = 尽量保留原文、但单次摘要更贵（kimi 摘要预算高达 128k token）且溢出风险留给恢复链；dsh 80% + 失败兜底 + 裁剪先行是折中。对长对话的实际影响：早压缩项目在第 N 轮就依赖摘要保真度（gemini 用二阶段 Probe 补救），晚压缩项目在临界点的单次摘要失败会直接触发 overflow 恢复（qwen 用熔断器防死循环）。
• dsh 的「裁剪先于摘要」更优：工具输出（日志、文件内容）通常占历史 60% 以上且高度可裁剪；确定性裁剪零成本、零信息歧义，能把相当一部分 pressure 在不烧摘要 token 的情况下化解。opencode 的 prune（40k 保护区）是同类思路。gemini-cli 的 50k 工具输出预算落盘是第三种形态，把大输出移出上下文但保留可找回性，比直接截断信息损失小。
• token 计数是集体软肋：除 omp 外全部是字符启发式，且各家系数不同（0.25~1.5 token/字符）。CJK 文本上 gemini 的 1.5 系数会高估（提前压缩），kimi 的 +1/字会低估（压缩滞后）。压缩决策建立在估算之上，意味着中文重度用户的压缩时机系统性偏移。改进建议：接入各模型官方 tokenizer（或 omp 式的原生 BPE）成本不高，收益直接。
• 跨会话记忆的分水岭是 qwen-code：dream（离线记忆整理）+ recall（选择性注入）+ secret-scanner（防密钥入库）+ 团队同步，是唯一成体系的「自写笔记」设计；其余项目的记忆基本停留在「手工维护的 Markdown」。若做长期项目助理，这是关键差异。

5. 会话管理

项目	持久化格式	resume/fork	并发控制	恢复/容错设计
codex	JSONL rollout（按日期目录）+ SQLite 索引 + zstd 冷压缩	resume/fork/revert/archive/分页历史；fork 记录血缘	单写者后台任务 + mpsc 命令通道	revert 保 thread ID 新建不可变文件；写入失败 terminal_failure 复现
gemini-cli	JSON 记录（~/.gemini/tmp//chats）	–resume + /resume save/resume <tag> + checkpointing（影子 git 仓库文件快照，默认关） + /rewind	shell 不活动超时；未发现会话写锁	磁盘满降级提示
qwen-code	JSONL 转录 + checkpoint 记录	–continue/–resume/–fork-session + /restore（文件级检查点回滚）	session-writer-lease 文件锁单写者租约（O_NOFOLLOW、锁 schema v2、转录哈希校验）	buildSessionRecoveryPlan：clean/interrupted-prompt/interrupted-turn/degraded-history 四类修复计划 + 孤儿 tool_use 修复
opencode	SQLite WAL（session/message/part 表，ULID）	–continue/–session/–fork/–replay；share 上传云端	每 session Runner + BusyError；WAL 支撑多进程	无状态循环重推导 + 中断 tool_use 标记 interrupted 防 provider 报错
kimi-code	wire.jsonl 事件流 + state.json；minidb（自研 KV：WAL+快照+全文索引含 CJK bigram）	–continue/–session/fork（fork 不继承 goal）	index append 串行化 + O_APPEND 原子性；wire 无跨进程锁	records 重放重建（「只重建内存状态」契约）
deepseek-harness	append-only SessionEvent 日志；JSONL(zstd) / SQLite 双后端	load/inspect/fork/seed；crash 补合成 turn/end	coordinator LRU + 活会话权威快照等待	Model-visible ⟺ logged 不变量；格式版本拒绝策略
oh-my-pi	JSONL 树（每条 parentId）+ blob 内容寻址仓	fork 只移 leaf 指针不改写历史；/tree 导航；导入 Claude/Codex 会话	AgentBusyError 禁并发 prompt；SQL/Redis 存储适配器预留	终端 breadcrumb + continueRecent；分支摘要

总述：持久化模型的三个层次

七家的会话持久化可归入三个递进层次，层次越高，resume/fork/审计能力越强，但实现复杂度也越高：

1. 快照式（snapshot），代表：gemini-cli。把「当前对话状态 + 工具调用点」整体序列化成 JSON 文件，必要时另存影子 git 快照。恢复=读回最近快照。优点是简单；缺点是历史不可分叉、不可重放，每次回滚靠外部 git commit。
2. 转录式（transcript），代表：codex、qwen-code、kimi-code、oh-my-pi。把会话写成追加式（append-only）日志（JSONL），每条记录一个事件/消息。恢复=从日志重放。codex/kimi 是线性日志；oh-my-pi 是带 parentId 的树形日志，分支零成本。转录式已能 resume/fork，但状态投影仍需调用方现场重建。
3. 事件溯源式（event sourcing），代表：deepseek-harness、opencode。日志即唯一真相（source of truth），所有可读状态（消息、部件、上下文、UI）都是日志的投影（projection）。写入只追加事件，读取由 projector 折叠事件流。这一层天然支持审计、重放、双后端、不变量断言，代价是要维护投影机与事件 schema 版本。

另有两个中间态/变体：

• oh-my-pi 的树形 JSONL + leaf 指针：仍是转录式，但每条记录 parentId，整条日志是一棵树；fork=移动 leaf 指针、不改写任何历史，是七者中分支成本最低的设计。
• deepseek-harness 的双后端事件日志：同一份 SessionEvent 流可落地为 JSONL(zstd) 或 SQLite，靠「格式版本拒绝 + 中断尾合成 turn/end」保证可恢复，并设了一条 repo 级不变量「Model-visible ⟺ logged」。

点评：

• 持久化模型的三个层次：快照式（gemini-cli JSON）→ 转录式（codex/qwen/kimi/omp JSONL）→ 事件溯源式（dsh/opencode）。层次越高，resume/fork/审计能力越强，但实现复杂度递增。omp 的树形 JSONL + leaf 指针是优雅的中间形态：分支零成本且历史不可变，比 qwen 的 fork-session 复制更省。
• qwen-code 的 writer-lease 与 session-recovery-plan 是被低估的工程：多进程写同一会话转录是真实痛点（daemon + TUI 并存），文件锁 + 哈希校验 + 四类恢复计划的组合在七个项目中独一份。相反 kimi-code 的 wire.jsonl 无跨进程锁，隐含「单进程持有会话」假设，其 kap-server 多会话场景依赖进程边界而非锁。

6. 工具调用（Function Calling）

机制对比

项目	注册机制	Schema/校验	并行调用	错误处理	审批门控
codex	ToolExecutor trait + ToolExposure（Direct/Deferred/Hidden）	JSON Schema + strict 标志（校验在 API 侧）；apply_patch 用 lark freeform 语法	parallel_tool_calls:true 恒开；FuturesOrdered 边流边执行；per-tool supports_parallel_tool_calls；执行闸门 RwLock	RespondToModel（回传继续）/ Fatal（终止）二分	UnlessTrusted/OnRequest/Granular 五开关/Never；guardian 评审器；审批缓存
gemini-cli	BaseDeclarativeTool+BaseToolInvocation 两阶段；按模型家族差异化声明	JSON Schema + Ajv	Scheduler 状态机批量并行；wait_for_previous 参数让模型显式控制串行；tail-call 替换	ToolErrorType 分类；错误以 functionResponse 回传；STOP_EXECUTION 终止流	shouldConfirmExecute → MessageBus → 策略引擎；「Always Allow」 可收窄为命令前缀/参数模式
qwen-code	tool-registry + 懒注册（computer-use 35 工具）	JSON Schema	partitionToolCalls：安全工具合批并行、非安全串行（[Read,Read,Edit,Read]→[[R,R],E,R]）	tool-error/guard/xml-tool-call-fallback（解析模型 XML 方言）	五档 ApprovalMode，默认 AUTO = LLM 分类器三层过滤，自修改面强制过分类器
opencode	Tool.define Effect Schema + 本地 .opencode/tool/* + 插件工具	Effect Schema（可附 JSONSchema7）；InvalidArgumentsError 自动生成改写指引	AI SDK step 内并发（unbounded），每 callID 独立 Deferred	repairToolCall 大小写纠正 → invalid 靶工具；doom_loop 检测触发 permission ask	三层通配规则 last-match-wins；ask→UI；always 会话内解锁排队；reject 带 feedback 回传模型
kimi-code	builtin 工厂 + zod schema → JSON Schema；描述 .md?raw 导入	zod 双向	ToolAccesses 资源冲突感知调度：无冲突并发、冲突等待、结果按 provider 序回传	每 call 必有配对 result；失败回传要求先诊断	manual/yolo/auto + DSL 规则（Bash(rm *)）+ 18 策略链；session-runtime 记忆
deepseek-harness	defineTool（schema DSL + render 投影）；工具目录由代码生成（启动每个插件读 schema）	JSON Schema DSL；白名单只给模型 name/description/parameters	独占屏障 + 有界滚动池（默认 10） + 启动前重分类 + 模型序提交 + 取消补合成结果	管线：pre-execute→守卫→approval→execute（超时/重试 around 包装）→post-execute（accept/block/replace）	per-session ask/never，fail-closed（缺席即拒绝）；permission-presets
oh-my-pi	BUILTIN_TOOLS 工厂 + omptype schema + markdown 描述注入	自研 omptype（TypeBox 风格）	per-tool concurrency: shared/exclusive：exclusive 串行屏障、shared 并行；跳过调用补合成结果	ToolError/ToolAbortError 区分超时与取消；未配对调用合成结果保 provider 配对	三层（工具 tier + 参数级 policy + 用户覆盖）；全局 always-ask/write/yolo（默认）

七家在工具调用上的分化集中在三个轴线上：

1. 注册与可见性，「模型一次能看见多少工具」被各家当作核心治理问题。codex 用 ToolExposure 把「声明 / 可发现 / 隐藏」三态做成 trait 方法，让工具能按 surface 差异化暴露；dsh 用 defineTool 的 schema DSL + render 投影，把「给模型看的白名单」与「运行时完整定义」分开；omp / kimi 用工厂 + schema（omptype / zod）在构造时定型；opencode 用 Effect Schema 把校验内建进 Tool.define。共同点：都意识到「把全部工具一次性塞给模型」会污染 prompt 与降低调用准确率，于是演化出 deferred / 白名单 / 工具搜索等机制。

2. 并行调度，这是分歧最大的一轴，存在四种范式：

   • 模型显式控制（gemini-cli wait_for_previous）：把串/并的决定权交给模型，灵活但依赖模型自觉。
   • 静态属性分区（qwen partitionToolCalls、kimi ToolAccesses、omp concurrency）：按工具的资源/副作用属性静态归类，安全合批并行、不安全串行，可预测、可证明无冲突。
   • 流式边到边执行（codex FuturesOrdered）：工具一从流里析出就 tokio::spawn 入队，边收边跑，结果按入队序回传。
   • 有界滚动池 + 重分类（dsh）：并行度有界（默认 10），每个调用启动前重新读 executionMode，独占调用形成屏障、并行调用滚动入池，取消时为未启动调用补合成结果。

3. 审批门控，分化的轴是「缺省即放行还是缺省即拒绝」（fail-open vs fail-closed）：

   • fail-closed：dsh（ask 缺审批支持即转 deny）、codex（UnlessTrusted 默认对未受信项目要求审批）。
   • fail-open：omp（默认 yolo）、kimi（hooks fail-open）、gemini-cli（OnRequest 模型自觉）。
   • 中间态：qwen 的 AUTO 模式用 LLM 分类器在「自动放行只读」与「人工确认危险」之间动态裁决，是七者中唯一把审批决定权部分外包给一个独立 LLM 调用的设计。

并行工具三种语义对比（mermaid）

内置工具面广度（大类计数）

能力	codex	gemini-cli	qwen-code	opencode	kimi-code	dsh	omp
文件/搜索	✔	✔	✔	✔	✔	✔	✔（+AST 编辑/ast-grep）
shell/PTY	✔ unified_exec	✔ + 后台 shell	✔	✔	✔（超时自动转后台）	✔ bash/pwsh/持久 PTY/terminal	✔ brush 内嵌 + PTY
代码智能	tool_search	—	LSP 6.7k 行	lsp（实验）	—	lsp	LSP 14 ops + DAP 28 ops
计划/待办	update_plan	enter/exit_plan + tracker_*	plan + todo	plan（实验）+ todo	Plan + TodoList + Goal 状态机	plan/todo/goal	plan + todo
子代理	multi_agents（实验）	invoke_agent + A2A 远程	agent/team/arena	task（general/explore）	Agent/AgentSwarm×128	5 provider 子代理接缝	task + hub + advisor + IRC
定时/自治	—	—	cron/loop/monitor	—	cron（抖动防齐射）	schedule（事件日志原生）	—
网络	web（extension）	web_search/fetch	web	webfetch/websearch	WebSearch/FetchURL	web_fetch/search 三 provider	web_search 23 provider 链
多模态	view_image	—	image_gen/CUA 35 工具/mobile	—	ReadMediaFile（视频）	read_image	browser/computer/tts/语音
记忆	memories（ext）	save_memory	memory 体系	—	—	session_* 5 工具	retain/recall/reflect/learn

上表按九大能力大类横比七家。多数大类（文件/搜索、shell/PTY、计划/待办、网络）各家都有，差异在「特色标注」，即某家在该类上做了独有的深化。下文只解释带特色标注或有数字的项；普通「✔」不赘述。

文件/搜索类

• omp ✔（+AST 编辑/ast-grep）：omp 除 read/edit/write 外，有 ast_grep（tools/ast-grep.ts，基于 ast-grep 的结构化代码搜索/重写）与 ast_edit（tools/ast-edit.ts，AST 级编辑），比文本级 edit 更精确，不依赖 LSP。codex 的 apply_patch 是 freeform diff（见 §1.3），omp 的 ast_edit 是 AST 投影，路线不同。

shell/PTY 类

• codex ✔ unified_exec：见 §1.10，交互式进程执行框架，带审批/沙箱/重试编排。
• gemini-cli ✔ + 后台 shell：见 §2.10，shell 不活动超时转后台，配套 list/read background 工具。
• kimi ✔（超时自动转后台）：kimi 的 bash 工具超时后转后台进程（类似 gemini-cli），让长跑命令不阻塞 turn。
• dsh ✔ bash/pwsh/持久 PTY/terminal：dsh 支持 bash、PowerShell、持久 PTY、terminal 工具。
• omp ✔ brush 内嵌 + PTY：见 §7.8，vendored brush-core Rust shell，内嵌而非 spawn 外部。

代码智能类

• codex tool_search：codex 的工具搜索工具，让模型按需发现 deferred 工具（见 §1.2 的 Deferred exposure），避免一次性塞满工具列表。
• qwen LSP 6.7k 行：见 §3.7，统一 lsp 工具，12 ops，代码量 7270 行（NativeLspService 1650 + lsp.ts 1224 + types.ts 646 等）。
• opencode lsp（实验）：见 §4.9，9 ops，无 diagnostics/rename/codeActions。
• dsh lsp：dsh 有 LSP 工具。
• omp LSP 14 ops + DAP 28 ops：见 §7.9，LSP 14 ops（含 rename_file/code_actions/raw request）、DAP 28 ops（七者唯一）。

计划/待办类

• kimi Plan + TodoList + Goal 状态机：kimi 有 Plan、TodoList 工具，外加 Goal 状态机（goal 是 kimi 独有的长期任务抽象，有状态迁移）。
• dsh plan/todo/goal：dsh 也有 goal。
• 其余各家 plan/todo 普遍有，不赘述。

子代理类

• codex multi_agents（实验）：codex 的多 agent 工具，实验性。
• gemini-cli invoke_agent + A2A 远程：gemini-cli 的 invoke_agent 工具 + A2A（Agent-to-Agent）远程协议。
• qwen agent/team/arena：qwen 的子代理有 agent、team、arena 三种形态。
• opencode task（general/explore）：opencode 的 task 工具，分 general 与 explore 两种子代理类型。
• kimi Agent/AgentSwarm×128：见 §5.7，AgentSwarm 单批最多 128 个子代理，批独占。
• dsh 5 provider 子代理接缝：dsh 支持 5 个 provider 的子代理接缝。
• omp task + hub + advisor + IRC：omp 有 task、hub（子代理中心）、advisor（只读顾问子代理）、IRC（IRC-backed 并行协调）。

定时/自治类

• qwen cron/loop/monitor：qwen 有 cron、loop、monitor 三种自治工具。
• kimi cron（抖动防齐射）：见 §5.8，确定性 per-task 抖动防 thundering herd。
• dsh schedule（事件日志原生）：见 §6.8，schedule 走共享会话持久化屏障，schedule/change 是原生会话事件。

网络类

• omp web_search 23 provider 链：见 §7.10，23 个 provider，按 SEARCH_PROVIDER_ORDER 链式 fallback。
• 其余各家 web_search/web_fetch 普遍有（1-3 个 provider），不赘述。

多模态类

• codex view_image：codex 的图像查看工具。
• qwen image_gen/CUA 35 工具/mobile：qwen 有 image_gen（图像生成）、CUA 35 工具（见 §3.1）、mobile（移动端自动化）。
• kimi ReadMediaFile（视频）：kimi 的 ReadMediaFile 支持视频。
• dsh read_image：dsh 的图像读取。
• omp browser/computer/tts/语音：见 §7.11，browser + computer + tts + WebRTC 语音 + inspect_image，七者多模态面最广。

记忆类

• codex memories（ext）：codex 的记忆工具（扩展）。
• gemini-cli save_memory：gemini-cli 的 save_memory 工具。
• qwen memory 体系：qwen 的记忆体系。
• dsh session_ 5 工具*：dsh 的 5 个 session_* 记忆工具。
• omp retain/recall/reflect/learn：omp 的记忆四件套，retain（存）、recall（取）、reflect（反思）、learn（学习），是七者中最结构化的记忆工具集。

7. 重连与容错

项目	重试策略	流中断处理	超时	特色
codex	200ms×2^n×jitter；默认 request 4 次/stream 5 次；尊重 Retry-After	流关闭未 completed 显式报错；连接级无限重试（5s 起翻倍封顶 60s）	stream_idle 300s、ws connect 15s	WebSocket→HTTPS 传输降级；x-codex-turn-state sticky routing
gemini-cli	maxAttempts 10、5s 起 30s 封顶、±30% jitter；不重试 400；SSL 错误码谱系	mid-stream 4 次重试 + RETRY 事件让 UI 丢弃半截渲染；InvalidStreamError 9 类	shell 不活动超时	持续 429 → 自动降级 Flash 模型；配额错误分类
qwen-code	1.5s 起 30s 封顶；持久模式：6 小时绝对上限 + 30s 心跳	InvalidStreamError 6 类内容级重试（协议标签泄漏/畸形工具调用/降级响应…）	流不活跃超时设计文档	Qwen 配额耗尽检测；模型降级事件；循环检测
opencode	2s 起×2×0.25 jitter、30s 封顶、5 次；retry-after(-ms) 优先；5xx 全重试	onInterrupt 收尾 + 孤儿 tool 清理	MCP 30s、bash 参数级	重试状态对用户可见（session status=retry 倒计时）
kimi-code	10 次、0.5s 起 32s 封顶、25% jitter（设计意图：扛过典型过载窗口 2~3 分钟）	溢出→缩窗→压缩→重试循环（3 轮熔断）	subagent 2h、hook 30s fail-open	Retry-After 优先；x-trace-id 全链归因；goal 技术失败统一 paused
deepseek-harness	maxRetries 2、0.5s 起 10s 封顶、10% jitter；五类可重试码；另有无限档	流空闲看门狗 5 分钟映射 TIMEOUT；EMPTY_RESPONSE 视为错误	streamIdleTimeoutMs 300s	重试本身落会话日志（llm/retry 事件可审计）；MCP 独立退避重连
oh-my-pi	分类重试（AIError.classifyMessage）；8s 封顶×75~100% jitter	replay 安全判定：已产出可见内容的流禁止盲目重试	工具级 timeout 模块	凭据轮换重试 + fallback chains（降级链 delay=0 获全新预算）；MAX_PAUSED_TURN=8 防失控

七个项目都会重试，重连/容错策略的差异在于为谁优化，可分三类：

1. 配额毛刺友好型（qwen-code、gemini-cli、kimi-code）， 服务对象是免费/配额型 API 的真实工况。特征是大预算（10 次起）、长封顶（30s~6h）、专门处理配额耗尽/模型输出协议污染，并把「模型本身降级输出」也当成可重试错误。它们假设后端会持续 429 若干分钟，所以宁可等也不让用户看到失败。
2. 严格短重试型（codex、deepseek-harness、opencode）， 假设后端是自建/付费稳定服务，重试预算小（2~5 次）、封顶短（10~30s），失败快速上抛。但各自有「逃生阀」：codex 给连接级错误开无限重试 + 传输降级；dsh 把重试审计化；opencode 把重试状态透传给用户。
3. 副作用安全型（oh-my-pi）， 唯一把「流已产出可见内容时能否盲目重试」当成一等问题处理的项目，并引入凭据轮换/降级链让重试跨「凭据边界」获得全新预算。

一个共性：没有项目实现 turn 内断点续跑（原报告点评已指出），重试都是「整请求重发」，所以「重试是否安全」取决于「重发会不会产生重复副作用」。omp 的 replay 安全判定解决的就是这个问题，其余项目处理较粗。

8. 系统提示词与指令遵循

项目	组装方式	指令文件层级	动态注入	覆盖/定制	安全姿态	多语言
codex	base_instructions（Responses instructions 字段）+ 模型目录下发指令	AGENTS.md 根→cwd 全拼 + override	<environment_context> XML（cwd/shell/网络域名/沙箱）+ 30+ context fragment	base_instructions/compact_prompt 可配；规范版按模型族指令模板由服务端下发，仓库仅持 fallback（详见下文订正）	guardian 评审 + sandbox tags	英文
gemini-cli	PromptProvider 分 section（可开关）+ modern/legacy 双份	GEMINI.md 四层 + MEMORY.md	日期/git/IDE 差分上下文/topic/技能/子代理清单	GEMINI_SYSTEM_MD 整体替换 + 导出	注入消毒（去换行/括号）+ safety checker	英文
qwen-code	分层 layers + interaction mode（interactive/headless/acp）	QWEN.md 层级 + rules	IDE 上下文、hook 输出标签、记忆召回前后插	QWEN_SYSTEM_MD/IDENTITY_MD 覆盖	「Denied Tool Calls 不得绕道」条款 + 标签转义	UI 9 locale + 输出语言文件（核心提示词英文）
opencode	agent.prompt 或按模型族 14 份 base prompt（claude/gpt/codex/gemini/kimi…）+ 折叠两段利缓存	AGENTS.md/CLAUDE.md 首类命中 + 就近目录挂载	<env> 块、MCP instructions、skills、SessionReminders	自定义 agent frontmatter	content-filter 转错误（无主动过滤）	英文
kimi-code	system.md 模板 + {{变量}} + profile 体系（coder/explore/plan）	AGENTS.md 用户级+项目级（不读 CLAUDE.md）	contextInjector 对账重放 + appendSystemReminder 两通道（其余注入被约束）	agent.yaml extends 派生	<system-reminder> 权威性声明 + 拒绝绕行	语言跟随用户
deepseek-harness	PromptSection 按 order 组装 + waterfall	AGENTS.md/CLAUDE.md + local 覆盖，字节预算	PromptContext 缓存安全快照 + agent.inject()	persona 段遮蔽、preset 组合、complete 段独占	未发现内容安全过滤（guard 是循环卫生）	英文模板 + UI locale
oh-my-pi	Handlebars 模板 + personality 三套 + 块级去重	.omp/AGENTS.md + 继承 8 种外部约定 + sticky rules	日期/plan 状态/aside 消息/magic keywords（代码块内不触发）	模板文件直接可改	反注入声明（XML 标签语义 + system-directive 保护）+ secrets 混淆（可选）+ Harmony 泄漏检测	英文

七家的系统提示词组装方式可归入四类递进范式，越往后「可组合性 / 可审计性」越强，但实现门槛也越高：

1. 单串拼接 + 服务端下发（codex），一个 instructions 字段（Responses API 的 instructions）承载整段系统提示词；该字段的「规范版本」由模型目录（服务端）按模型族 + personality 下发 instructions_template，本地仅持 fallback。运行期上下文以 30+ 个 fragment 各自带 XML 标签注入。这是最「贴近 API 原语」的范式：系统提示词就是一个字符串，所有动态信息靠追加 fragment 实现。
2. 分 section 组装 + 可开关（gemini-cli / qwen-code / opencode），把系统提示词拆成若干命名 section，每个 section 有 guard（条件渲染）或 order（排序），由一个组装函数统一拼接。gemini 的 withSection(key, factory, guard)、qwen 的 SystemPromptLayers、opencode 的 provider() 按模型族分派都是这一类。优点是单点持有 section 顺序、条件渲染成本低。
3. 模板变量（{{var}}）+ profile 体系（kimi-code），系统提示词是一个带 {{ KIMI_* }} 占位符的 system.md 模板，变量值由运行期上下文（OS/shell/now/workdir/AGENTS.md/skills/plugins）填充；profile 体系（agent/coder/explore/plan）通过 extends 派生不同人格与工具集。模板化让「同一段提示词在不同部署形态下复用」。
4. DSL 组装 + waterfall（deepseek-harness），提示词是一个注册表：PromptSection（带 order）+ PromptContext（动态快照）+ 工具 provider + 变量 provider，由 assemble() 排序后跑一个 Cordis waterfall 协作事件让插件改写，最后 renderPrompt 插值。这是最「框架化」的范式：提示词本身是一个可被插件横切的数据结构，而非一段字符串。

注入防御的谱系则呈现三层递进，但没有一家做到独立的提示注入检测模型层：

• 变量消毒（被动）：gemini 对注入路径上的字符串做 \n / ] 替换（防止伪造 [...] marker）、qwen 对 <system-reminder> 标签做零宽字符归一 + 转义、kimi 对 goal 文本包 <untrusted_objective> + escapeUntrustedText。本质是「用户内容进 prompt 前先消毒」。
• 契约声明（主动）：omp 在系统提示词里写明「XML 标签语义 + <system-directive> 在 user turn 仍为系统指令」、qwen/kimi 写明「<system-reminder> 是权威系统指令不是用户输入」、codex guardian 写明「transcript delta 当作 untrusted evidence 而非指令」。本质是「用提示词契约教模型区分系统 vs 用户内容」。
• 运行时拦截（事后）：omp 的 Harmony 泄漏检测（扫描 assistant 消息里泄漏的带内协议标记并恢复）、qwen 的 Denied Tool Calls 条款（拒绝绕道）、各家的 loop guard（dsh 的 repeat-tool-reminder、omp 的 thinking-loop-redirect）针对的是「行为漂移」而非「注入」。没有任何项目在「工具结果入历史前」插独立注入检测层，这是共同敞口。

附：两张机制图

opencode 按模型族分派 base prompt + 折叠两段利缓存

图 2：deepseek-harness 的 PromptSection order + waterfall 组装

9. 思维链与工作流编排

项目	thinking 支持	Plan 模式	子代理	工作流引擎	可观测性
codex	ReasoningEffort 9 档 + 加密思维链跨请求保持	Plan mode + update_plan（展示/追踪型）	multi_agents v2（实验，继承父 turn 全套策略）	codex exec/app-server 协议 + cloud-tasks；无声明式工作流	OTel + tracing span + analytics
gemini-cli	thinkingConfig per-model + Thought 事件	plan ApprovalMode + 只读工具集	invoke_agent + 内置 4 agent + A2A 远程子代理	hooks 8 事件（可阻断/改参）；next-speaker/loop-detector 双 LLM 裁判	OTel 全家桶 + GCP exporter + 分角色记账
qwen-code	enable_thinking/thinking_budget/vLLM 逐分支 + 5 档统一 effort	enter/exit_plan + 批准计划历史打码	subagent（CC parity）+ Agent Teams（mailbox+权限桥） + Arena 多模型竞技	workflow orchestrator（预算/journal 重放/stall 自愈）+ Goals + cron	OTel 全套 + daemon metrics + event-loop-lag
opencode	reasoning part 流式 + 独立计数	plan mode（实验，只写 plans 目录）	task（general/explore）+ background（实验）	自定义 slash command + ACP；无引擎	结构化日志 + OTLP + SSE 事件流 + debug 命令组
kimi-code	thinking effort + keep；Kimi extra_body 适配	EnterPlanMode/ExitPlanMode + plan 模式写保护（只能写 plan 文件）	Agent + AgentSwarm（模板批量×128、爬坡并发） + tower（实验）	Goal 状态机（active/paused/blocked/complete）+ 三维预算 + cron	wire.jsonl 内嵌请求 trace + vis 回放 + kimi-inspect
deepseek-harness	reasoning effort 选择 + replayState	plan 模式（log-only 状态，软引导）+ exit_plan_mode 审批	6 provider 接缝（含 codex/claude-code 子代理）+ report 回传 + 深度预算持久化	workflow：模型编写 JS 编排脚本（worker+vm） + ralph 迭代 + schedule	40+ 运行时不变量 + OTel + request/header 可重建
oh-my-pi	ThinkingLevel 8 档 + ultrathink 关键字	plan 模式 + 独立 plan 模型角色 + handoff	task（worktree/pi-iso 隔离 + 结构化输出 schema 校验）+ hub 名册	advisor（第二模型逐轮监督可硬阻断） + IRC + workflowz（agent/parallel/pipeline DSL）+ TTSR（流内命中即中止-注入-重试）	OTel GenAI span + 本地 stats 看板 + 火焰图 profiler

七家在「让模型怎么想、怎么计划、怎么分工、怎么编排」这四件事上呈现清晰的谱系分化，越往右「运行时对模型行为的约束与纠偏」越强：

1. 思维链（thinking）的暴露与续接，三类范式：

   • 服务端加密、客户端续接（codex）：请求里带 include: ["reasoning.encrypted_content"]，把模型上一轮的加密思维块原样回传，跨请求续接但客户端不可读。
   • 协议字段 + 事件流（gemini-cli / qwen-code / kimi-code）：用 thinkingConfig / enable_thinking / thinking.keep 等协议字段开关与定档，思维以 Thought 事件 / reasoning part 流式吐给前端并独立计 token。
   • 统一档位 + 关键字越级（dsh / omp）：把各家 provider 不同的 effort 字段归一成一个内部档位阶梯，再用 ultrathink 这类 magic keyword 让用户一句话顶到最高档。

2. Plan 模式的两种语义，沿「软引导 → 硬隔离」递进：

   • 软引导（dsh / qwen）：plan 状态只是注入一段 guidance 提示词 + log-only 会话状态，沙箱/审批策略独立运作，计划本身不强制执行。
   • 工具层硬隔离（opencode / kimi）：plan 模式在权限策略层 deny 所有编辑工具，只放行 plan 文件目录；kimi 更精确到「只能写当前 plan 文件」。
   • 展示/追踪型（codex update_plan）：plan 是一个 TODO/checklist 工具，模型调用它更新步骤状态、UI 展示，但不参与执行约束（且在 codex 自己的 Plan mode 里反而被禁用）。

3. 子代理的隔离与治理，从「同一进程继承父策略」到「独立上下文第二模型监督」：

   • 继承型（codex multi_agents v2）：子代理全盘继承父 turn 的模型/provider/effort/审批/沙箱策略。
   • 协议型（gemini A2A / dsh 6 provider 接缝）：把子代理抽象成可插拔 provider，含远程 A2A agent、claude-code/codex 子代理。
   • 隔离型（omp task / kimi AgentSwarm）：子代理在 CoW 工作区副本上干活，产物 diff 回主区；kimi 批量拉到 128 个 + 爬坡并发。
   • 监督型（omp advisor）：第二模型逐轮审主代理输出，可发 blocker 硬阻断，七家中唯一的「独立上下文监督」设计。

4. 工作流引擎的成熟度，从「无引擎」到「模型自己写编排脚本」：

   • 无声明式工作流（codex / opencode）：只有 exec/app-server 协议或 slash command + ACP，没有 DAG/pipeline 引擎。
   • 运行时编排器（qwen / kimi）：journal 重放 + stall 自愈 + 三维预算 + Goal 状态机 + cron 的「准工作流」。
   • 模型即编排者（dsh）：模型用 eval/Cordis 写 JS 编排脚本，跑在 node:vm 沙箱 + worker 线程里，ralph 负责迭代执行，能力上限最高、调试门槛也最高。
   • DSL + 流内纠偏（omp）：workflowz 关键字触发确定性多子代理工作流（eval 里 agent() 扇出），TTSR 在流内用 regex/AST 命中即中止-注入-重试，实现「按需上下文」纠偏。

附：两张机制图

kimi-code 的 Goal 状态机 + 三维预算

注：kimi GoalStatus 是 4 态（active/paused/blocked/complete）；qwen 的 GoalStatus 是 5 态（多一个 usage_limited，goals/goal-protocol.ts:49-54）。两者状态机同源但档位不同。

oh-my-pi 的 advisor 逐轮监督 + TTSR 流内纠偏

10. 其他关键维度

性能设计

项目	Prompt caching	启动优化	token/成本核算
codex	prompt_cache_key + WS 增量请求 + sticky routing	会话启动预热（prewarm handle）	cache_read/write 细分 span
gemini-cli	Gemini implicit caching（仅 API key/Vertex）	perf-tests 基线（冷启动 927.6ms 回归）	OTel 分 LlmRole 记账
qwen-code	openai 前缀缓存 + 自动 caching + /stats 命中率	compile-cache	telemetry usage + session token 限额
opencode	6 家 provider 显式缓存断点（前 2 system + 后 2 消息）+ 两段折叠	动态 import + AVX2 二进制 + startup debug	成本分层计价 + >200k 档位 + stats 命令
kimi-code	prompt_cache_key 会话亲和（Kimi/OpenAI/Anthropic 全注入） + fork 后缓存探针	单二进制 SEA + 原生热更新	usage 区分 cache read/creation
deepseek-harness	usage cache 字段透传（无自建缓存）	—	token-meter 逐节点计价 + session-stats
oh-my-pi	Anthropic cache_control + 1h TTL + append-only 稳前缀设计 + fork 继承缓存身份	原生底座热路径零 fork	stats 本地看板（tokens/s、cache rate、成本）

七家在「让长会话的每一轮都命中前缀缓存」这一工程问题上分化为三档：

1. 把缓存断点放置当一等工程问题（opencode、oh-my-pi）：opencode 在协议无关层写统一的 CachePolicy，omp 专门设计 append-only 上下文 + fork 缓存身份继承，把「稳前缀」做进数据结构。
2. 吃 provider 原生缓存但做会话亲和（codex、kimi、qwen）：用 prompt_cache_key / metadata.user_id 把同一会话的请求钉到同一缓存槽，再加 fork 探针或断点标记。
3. 只读不写（gemini-cli、deepseek-harness）：gemini 吃 Gemini 隐式缓存只读 cachedContentTokenCount；dsh 连断点都不碰，只把 provider 返回的 cache 字段透传进账本。

点评：opencode 与 omp 把「缓存断点放置」当成一等工程问题（opencode 跨 6 家 provider 写断点策略、omp 为缓存命中率设计 append-only 上下文与 fork 缓存身份继承），这类优化的 ROI 在长会话中可观（缓存读价通常 10%）。gemini-cli 只吃隐式缓存、dsh 完全不碰断点，是明显的优化空间。性能评测注意：gemini-cli 是唯一有公开 perf 基线回归框架的（冷启动/CPU/长会话恢复），其余项目的性能数字均不可横向引用。

可扩展性

项目	MCP	自定义工具	多 provider	SDK/API	独特扩展面
codex	client（3 传输+OAuth）+ 自身即 MCP server	extension tools/hooks/plugins/skills	仅 Responses API 兼容（chat wire 已移除）	Python + TS SDK（包装 app-server）	execpolicy 策略语言、connectors、marketplace
gemini-cli	client（4 传输+OAuth/SA 冒充）	MCP/SDK 注册/扩展 discovered	Gemini 中心（OpenAI 兼容有限）	@google/gemini-cli-sdk	a2a-server（自身作为 A2A agent）、ACP 模式、devtools
qwen-code	client 3 传输 + OAuth + 连接池 + daemon 动态增删	extensions（含 claude/gemini/qoder 格式转换器）+ hooks + skills	4 套生成器：OpenAI 兼容/Anthropic/Gemini/Qwen OAuth + 12 provider 预设	TS/Python/Java 三 SDK	channels 9 IM、desktop、CUA、mobile-mcp、audio
opencode	client 3 传输 + OAuth + roots + 状态机	npm/本地插件 15 钩子 + .opencode/tool/*	models.dev 目录 75+（文档数）+ 自定义 provider 配置	OpenAPI 生成 SDK + Effect client + 嵌入式 sdk-next	HttpApi 单源生成全端、share 云服务
kimi-code	client 3 传输 + 进程级共享 OAuth + 脱敏投影	plugins（manifest+GitHub zip 安装）+ skills + hooks	6 协议（kimi/anthropic/openai×2/google/vertex）+ models.dev 导入	node-sdk + klient 契约 facade	kap-server REST/WS（experimental）、ACP 双实现
deepseek-harness	仅 client（无 server 侧）	defineTool + extensions 运行时自修改（opt-in）	DeepSeek 官方 + pi-ai 第三方目录 + OpenAI 兼容	JSON-RPC SDK（TS/Python）+ ACP server + API gateway	skill 6 级目录链、hooks 兼容 CC/Codex、e2b 云沙箱
oh-my-pi	client 完整 + 发现 5 家 IDE 的 MCP 配置	custom tools 工厂 + extensions + marketplace	13 wire API + 69 provider 目录 + owned dialect 兜底（无工具调用模型走带内协议）	Bun/Node SDK（createAgentSession）	ACP、browser-relay、语音（WebRTC live）、collab 加密直播

点评：provider 开放性排序：omp > opencode > qwen > kimi > gemini-cli > dsh > codex，codex 砍掉 chat wire_api 后，接第三方模型必须自建 Responses 兼容代理，这是明确的生态收紧信号。omp 的 owned dialect（给无原生工具调用的模型伪造带内工具协议 + 伪造结果检测）是独家能力，意味着它能把任何会聊天的模型变成 agent。dsh 的反向问题是第一方只有 DeepSeek 路由，跨生态要靠 pi-ai 第三方库（其依赖治理中被特别豁免）。

生态与社区

• 提交强度：dsh（8.8k/月）≫ omp（4k）> codex（1.2k）≈ qwen（1.1k）> opencode（396）> kimi（310）≫ gemini-cli（75）。dsh/omp 的高强度与少数核心贡献者组合，意味着路线图高度受控于单一团队，对使用者是双刃剑（演进快但方向不可控）。
• Issue 治理：gemini-cli（556 open/442 贡献者）最健康；codex 13k open 是规模问题；opencode 4k open 需关注；dsh 0 open 是强清理策略。
• 文档国际化：opencode（README 22 语言 + docs 16 语言 + locale 同步 CI）与 dsh（双语 blob-hash 配对门禁，中文文档与英文同等权威）是标杆；qwen 中文文档主源在外部站点；codex 文档外迁到官网（离线不友好）。

文档与上手难度

项目	文档质量	上手路径	学习曲线
codex	仓内文档空心化（stub 外链官网）；协议文档完整	一行安装 + codex doctor	用户低 / 开发者高（100+ crate）
gemini-cli	97 篇结构化 docs + settings schema 代码生成	npx 即用	低
qwen-code	60+ 设计文档带日期；中文文档外部站	安装脚本 + /auth	中（功能面太宽）
opencode	36 页 docs + CONTEXT.md 领域词汇表 + 威胁模型	一行安装	中（Effect 门槛）
kimi-code	VitePress 双语 + GOAL.md 设计先行 + 分层 AGENTS.md	单二进制 + /login	低-中
deepseek-harness	生成目录（tool-catalog 1873 行等）+ cookbook + postmortem	npx dsh web	高（Cordis 范式前置）
oh-my-pi	80+ 篇子系统级文档（含语义与边界条件）	一键脚本	中（源码构建需 Bazel+Rust）

点评：文档与代码同步机制上，dsh（生成目录 + 门禁校验）> gemini-cli（schema 生成）> opencode（openapi 生成），生成式文档是大型 agent 项目的必然选择，手写目录（omp 80+ 篇）的维护成本会随版本漂移。上手难度最低的是 gemini-cli/kimi-code（开箱即用、概念少），最高的是 dsh（需理解 profile/bundle/seam 词汇表）。

安全与权限控制

项目	OS 沙箱	网络管控	审批模型	企业管控	敏感数据保护	安全文档
codex	Seatbelt / Landlock+seccomp / Win 受限令牌（三原生）	MITM 代理 + 域名 allow/deny + 凭据代理	Granular 五开关 + guardian	10 层配置栈 + MDM + requirements.toml	keyring 加密凭据 + process-hardening	SECURITY.md（Bugcrowd）
gemini-cli	Docker/Podman/sandbox-exec/bwrap/Win 原生 四后端	沙箱内网络策略	四档 + 五级 TOML 策略引擎 + Always-Allow 收窄	Admin>User>Workspace>Extension>Default 策略带	路径 checker 硬编码屏蔽 .git/.env	SECURITY.md（Google VRP，5 日响应）
qwen-code	Docker 镜像 + macOS .sb 六套	—	五档（默认 AUTO 分类器）+ allow/ask/deny 规则	trusted folders + daemon trust policy	memory secret-scanner + team secret-guard	SECURITY.md（阿里云盾）
opencode	无（SECURITY.md 明示）	—	通配规则三层 + reject-feedback	enterprise 策略包（存在但轻量）	.env 读取需确认（默认）	SECURITY.md 含威胁模型
kimi-code	无 OS 沙箱	kap-server loopback+token	manual/yolo/auto + 18 策略链	workspace trust 门控 MCP	敏感文件硬过滤（.env/密钥/凭据，防注入外泄）	SECURITY.md
deepseek-harness	bwrap/Landlock、Seatbelt、Win ACL（仅文件效果，不管网络/进程）	明确不在词汇表	ask/never fail-closed + 审计事件	credentials 引用化（值不落配置）	凭据每次操作重解析 + describe 不暴露	无独立 SECURITY.md（有 sandbox 子系统文档）
oh-my-pi	pi-iso 工作区隔离（APFS CoW/overlayfs/ProjFS），隔离的是工作区不是系统调用	—	三层 tier，默认 yolo	profiles	secrets 混淆（默认关）	无 SECURITY.md

七家的「沙箱」实指两种正交的隔离：

• 系统调用/进程隔离（codex、gemini-cli、qwen、dsh）：用 OS 原生机制（Seatbelt/Landlock/seccomp/Win 受限令牌/Docker/bwrap）约束子进程能做什么，能调哪些 syscall、能访问哪些文件路径、能连哪些网络。目标是「agent 逃逸到系统」。
• 工作区文件系统视图隔离（oh-my-pi 的 pi-iso）：给子代理一个工作区的 CoW 副本干活，产物 diff 回主工作区。约束的是「agent 改坏本地仓库」，不约束子进程系统调用，子代理在副本里仍能任意执行命令，只是改动被隔离在副本里。

两者正交，理想方案是叠加（omp 补上 Landlock 层就完整）。

点评：

• 沙箱语义需要澄清：codex/gemini/dsh 的沙箱约束的是子进程的系统调用/文件/网络；omp 的 pi-iso 约束的是工作区文件系统视图（子代理在 CoW 副本上干活，产物 diff 回主工作区），防的是 agent 改坏本地仓库；OS 沙箱防的是 agent 逃逸到系统。两者正交，理想方案是叠加（omp 补上 Landlock 层就完整）。
• 默认审批姿态谱系：fail-closed（dsh）→ ask 默认（codex OnRequest、opencode、gemini default）→ AUTO 分类器（qwen）→ yolo 默认（omp）。给非专家用户的产品必须改默认值，omp/kimi 的 yolo/auto 适合开发者自用，不适合托管服务。
• kimi-code 的敏感文件硬过滤值得点名：它直接在工具层阻止读写 .env/私钥/凭据文件，注释明说目标是「被注入的 prompt 无法外泄凭据」，这是七个项目中唯一把「防提示注入外泄」落到工具策略的代码。其余项目要么靠沙箱（codex 网络 deny）要么没有。

11. 评分卡与综合对比总表

维度权重与评分（1–5 分，基于 §3–§10 证据）

维度（权重）	codex	dsh	gemini-cli	qwen-code	kimi-code	opencode	oh-my-pi
架构与工程质量（12%）	4.5	5.0	4.0	3.0	4.5	4.5	5.0
上下文管理（15%）	5.0	4.5	4.0	4.5	2.5	4.5	5.0
会话管理（8%）	5.0	5.0	3.5	4.5	4.0	4.5	4.5
工具调用（12%）	4.5	5.0	4.5	4.5	4.0	4.0	4.5
重连与容错（10%）	4.5	4.5	4.5	5.0	4.0	4.0	5.0
提示词与指令（8%）	3.5	4.0	4.0	4.0	4.0	4.0	4.5
CoT 与编排（12%）	3.5	5.0	4.0	5.0	4.5	3.5	5.0
安全与权限（12%）	5.0	4.0	4.5	4.0	3.0	2.0	2.5
可扩展性（11%）	3.5	4.5	4.5	4.5	4.0	4.5	5.0
加权总分	4.37	4.62	4.19	4.33	3.78	3.93	4.56

能力 × 成熟度象限

成熟度依据：版本阶段与兼容承诺（dsh 明示破坏性变更、SESSION_FORMAT_VERSION=0；kimi v2 刚转默认；opencode/codex/gemini 已长期迭代）、生态规模、文档完备度。

综合对比总表（全维度速查）

维度	codex	gemini-cli	qwen-code	opencode	kimi-code	dsh	oh-my-pi
压缩阈值	模型目录限额	50%	85%	input-reserved	85%	80%	六触发
真 tokenizer	✗	✗	✗	✗	✗	✗	✔ 原生 BPE
向量/记忆	文件型	LLM 抽取	auto-memory 体系	✗	✗	会话引用	mnemopi 可选嵌入
持久化	JSONL+zstd+SQLite	JSON 快照	JSONL+锁	SQLite 事件溯源	wire.jsonl+minidb	事件日志双后端	JSONL 树+blob
fork/resume	✔/✔/revert	✔/✔/checkpoint	✔/✔/restore	✔/✔/replay	✔/✔	✔/✔	✔ 树分支
并行工具	FuturesOrdered	状态机+模型控制	安全分区	无界并发	资源冲突感知	有界滚动池	shared/exclusive
重试上限	4/5 次+连接无限	10 次+Flash 降级	6h 持久档	5 次	10 次	2 次(可无限)	分类+降级链
沙箱	三平台原生	四后端	Docker/macOS	✗ 明示	✗	文件效果	工作区隔离
plan 模式	展示型	硬切换工具集	打码+策略	硬 deny(实验)	写保护	软引导	独立 plan 角色
子代理	实验	+A2A 远程	Teams/Arena	general/explore	Swarm×128	5 provider 接缝	hub/advisor
多 provider	Responses only	Gemini 中心	4 生成器	75+(models.dev)	6 协议	DeepSeek+pi-ai	13 API+69 目录
MCP 双向	✔/✔	✔/✗	✔/✗	✔/✗	✔/✗	✔/✗	✔/✗
默认审批	OnRequest	default	AUTO 分类器	ask	manual	fail-closed	yolo
OTel	✔	✔(+GCP)	✔	✔	✔(默认开)	✔	✔
SDK	Py+TS	TS	TS+Py+Java	OpenAPI+Effect	TS(+facade)	TS+Py(JSON-RPC)	Bun/Node

12.共性模式提炼

七个项目高度趋同的部分（可视为 2026 年 Agent Harness 的事实标准）：

1. ReAct 主循环 + 类型化事件流：无论 Rust/TS，都是 loop { 采样 → 工具批执行 → 结果回灌 }，UI 经事件流解耦。差异仅在事件粒度（dsh 到 chunk、gemini 到 turn event）。
2. LLM 摘要压缩 + 尾部保留：全部实现，差异在阈值（§4.1）与摘要提示词（qwen 的 <state_snapshot>、dsh/opencode 的结构化模板、kimi 的第一人称 handoff）。
3. AGENTS.md 分层指令：7/7 支持 AGENTS.md 或同族文件，用户级 → 项目级层级合并是标配；CLAUDE.md 兼容 5/7。
4. MCP 作为通用扩展总线：7/7 实现 MCP client（stdio/HTTP/SSE 变体），工具名空间 mcp__server__tool 一致；仅 codex 同时是 MCP server。
5. plan 模式 + 子代理：7/7 有 plan 概念，6/7 有子代理；差异在隔离与预算治理（§9）。
6. JSONL/SQLite 持久化 + resume/fork：会话可恢复是底线能力。
7. OTel 可观测性：7/7 集成（kimi 默认开启需注意隐私）。

细微差异如何改变结果（选型时要盯住的三个「魔鬼细节」）：

• token 估算系数：决定压缩时机在中文场景偏移方向（gemini 高估偏早、kimi/qwen 低估偏晚、opencode/dsh 居中）。
• 并行工具的取消语义：用户中断时，dsh/omp 会为未执行调用补合成结果保证历史可重放；gemini/qwen 依赖事后修复。长会话稳定性差异由此而来。
• 审批 fail-open/closed 与默认档位：决定它能否直接放进托管服务（只有 dsh/codex 的默认姿态可托管）。

结语

这七个项目展示了开源 Agent Harness 的三条演化路线：向系统要纵深（codex/omp 的 Rust 化与沙箱）、向架构要可审计性（dsh/opencode/kimi-v2 的事件溯源）、向生态要覆盖面（qwen/kimi 的全端产品线）。没有全能冠军：

• 要当下可用的最强综合：deepseek-harness（接受 preview）或 oh-my-pi（接受宽松默认安全）。
• 要生产稳妥：codex / gemini-cli / opencode 三选一，按模型生态定夺。
• 要特定模型的最优体验：跟着模型走（Qwen→qwen-code、Kimi→kimi-code、Gemini→gemini-cli）。

对 Agent 开发者的三条通用启示：其一，上下文治理决定长任务上限，优先选择有「裁剪/落盘/多方法链」的项目，纯摘要方案在超长会话中信息损失不可逆；其二，事件溯源值得作为自研架构的默认选择，fork/resume/审计/UI 回放全部免费获得；其三，安全默认值必须显式设定，七个项目的默认审批姿态从 fail-closed 到 yolo 不等，托管部署前务必逐项核对。