模型: openai/gpt-5.4
生成日期: 2026-04-01
书名: Claude Code VS OpenCode：架构、设计与未来
章节: 第18章 — 理想编码Agent的架构
Token用量: 约 7,200 input + 1,950 output
18.2 五大定义性张力
一个 coding agent 的架构，不是由“功能清单”定义的，而是由它如何处理几组长期存在、无法回避的张力定义的。模型变强以后，这些张力并不会自动消失，反而会更加尖锐：因为模型越强、工具越多、上下文越大、自治能力越高，错误的代价也越大。对 OpenCode、OMO、Claude Code 这三套系统进行比较后，可以看到最核心的五组张力分别是：Autonomy vs Safety（自治 vs 安全）、Context richness vs Context rot（上下文丰富度 vs 上下文腐坏）、Generality vs Specialization（通用性 vs 专门化）、Simplicity vs Capability（简单性 vs 能力密度）、Open vs Closed（开放 vs 封闭）。
这里的“张力”不是教材里的严格术语，更像系统设计中的“拉扯关系”。意思是两边都重要，但很难同时把两边都拉到极致，所以架构必须选择重心，并用设计手段做平衡。
一、自治 vs 安全
coding agent 天生想变得更主动：少问、快做、连续执行、多步推进。因为从用户角度看，真正有价值的 agent 不应该每做一步都像在申请审批。但只要 agent 更主动，它的失误半径也会同步增大。一次错误 shell、一次误删文件、一次错误提交、一次不该发出的网络请求，都可能让“有用”直接转化成“有害”。
OpenCode 对这组张力的处理，整体上更偏向开发者控制。它提供了非常可编程的宿主和灵活的工具体系，但不会替使用者预先做过多重产品级限制。这样做的好处是实验自由度高，能力上限高，坏处是安全策略更多依赖使用场景与扩展作者自身的约束，而不是系统强约束。
OMO 的解法不是单纯把权限系统做得极重，而是通过编排纪律来降低风险。它增加了后台任务、专门 agent、规则注入、todo 驱动执行、hook 检查等机制，本质上是在说：如果 agent 的行为结构设计得更好，它就会更少走偏。也就是说，OMO 常常是在“宿主之上”用更好的 orchestration（编排）来换取更高自治下的可控性。
Claude Code 则把这组张力处理得最“产品化”。它通过 permission system（权限系统）、审批语义、分类器、成本控制、沙箱化执行等机制，试图把安全下沉到运行时基础设施层。它传达的核心观点是：安全不是自治的反面，而是让自治得以被大规模接受的必要条件。 这点非常重要。
二、上下文丰富度 vs 上下文腐坏
agent 要做好 coding work，当然需要大量上下文：用户意图、代码仓状态、最近变更、工具结果、历史决策、项目约束、文档说明，甚至更久之前的会话记忆。但上下文不是越多越好。信息一旦堆积到一定程度，就会发生 context rot（上下文腐坏）。
“腐坏”也是一个更偏工程经验的说法，不是标准教科书术语。它指的不是数据丢失，而是上下文虽然还在，却已经不再可靠：有的过期了，有的重复了，有的互相冲突了，有的和当前任务其实无关，却仍然占据了 token 预算并干扰判断。
OpenCode 在这一点上的启示是：上下文必须被结构化管理，而不是简单拼接。它的 session、message、compaction 等设计已经在说明，长任务对话不是“聊天记录越来越长”这么简单，而是需要状态管理。但 OpenCode 本身偏向通用宿主，因此它对“什么该长期保留、什么该被压缩”这件事，更多提供机制，较少强加单一策略。
OMO 则在这方面更积极。它通过 hook、rules injector、continuation、task-specific prompt 等方式，把上下文当成一种需要动态编排的资源。尤其是它很清楚地认识到：正确上下文不等于更多上下文。某个子 agent 往往在更窄、更干净的上下文里反而表现更好。因此 OMO 对这组张力的解法，是通过任务切分与按需注入来减少上下文污染。
Claude Code 的处理方式更像工业级产品：记忆系统、自动压缩、持久记忆与瞬时状态区分、多种 compaction 策略。它不假设上下文溢出是偶发事故，而是把它视为长期运行中必然发生的正常情况。因此它的答案是：把 context management 直接做成正式子系统。
三、通用性 vs 专门化
一个通用 agent 易于理解：一个助手，什么都做。一个专门化 agent 体系则更像组织结构：有人负责探索，有人负责审查，有人负责资料检索，有人负责规划。前者看起来简单统一，后者往往更利于复杂任务伸缩。
OpenCode 的立场更偏通用。它是一个很强的底座，允许开发者构建各种 agent、接口、插件和工具，但宿主本身并不预设一个非常强的 specialization（专门化）哲学。这恰恰是它的优点，因为它把决定权留给上层系统。
OMO 则明显往专门化方向走，但它真正高明的地方不在“agent 数量多”，而在于它把专门化变成了 prompt、工具和工作流共同决定的事情。某个 agent 不是因为名字不同就专门化，而是因为它拿到的上下文、工具权限、角色说明和交付目标都不同。这个设计说明，专门化最有价值的时候，是它能减少认知碰撞，而不是制造组织感。
Claude Code 处在两者之间。它的主体验通常还是统一助手，但也逐渐接受更窄职责的 task delegation（任务委派）和角色化结构。它不像 OMO 那样强调多 agent 身份体系，但它承认：在某些任务上，有限专门化比单一万能人格更有效。
四、简单性 vs 能力密度
系统每多一个 feature，能力就可能增强一点，但可理解性也可能下降一点。这里的“能力密度”不是教材术语，可以理解成：在单位系统复杂度里塞进了多少真实能力。如果能力增长主要来自重复工具、重复流程、重复模式，那复杂度就会上升得很快，真正的能力密度反而不高。
OpenCode 的优秀之处在于，它的核心底座相对清爽。它不是绝对极简，但它努力让宿主层逻辑保持可读、可扩展、可重组。正因此，它很适合作为基础设施——能力可以继续往上长，而不会把底盘本身搅乱。
OMO 则主动承受更多复杂性，因为它要解决的是更难的 orchestration 问题。Hook、skills、categories、background tasks、wisdom、continuation、embedded MCP，这些都会增加系统层数。但 OMO 的经验也说明：复杂不是原罪，无组织的复杂才是原罪。如果每一层复杂度都对应明确功能，那么它可能产生远高于成本的杠杆。
Claude Code 的办法是把复杂度尽量藏到产品内部。它内部工具可能很多，策略可能很多，模式也可能很多，但用户界面尽量维持统一、顺滑、低学习成本。这是典型商业产品解法：允许内部复杂，外部尽量简单。代价则是某些能力不一定完全对用户开放或可编程。
五、开放 vs 封闭
这是最深的一组张力。开放系统强调 inspectability（可检查性）、 programmability（可编程性）、 community experimentation（社区实验性）；封闭系统强调一致性、集成安全、端到端质量控制。两边都不是错，只是服务于不同目标。
OpenCode 代表了开放一侧最重要的价值：宿主必须可理解、可修改、可扩展。它天然适合研究者、平台开发者、工具作者以及需要深度嵌入自定义工作流的团队。代价是，开放系统通常把更多集成工作留给使用者自己处理。
OMO 的价值在于，它进一步证明了开放不是“只能做小修小补”，而是可以在宿主之上搭建出一整套新的编排哲学。换言之，开放平台真正厉害的地方，不是允许你改一点配置，而是允许你重写系统行为的组织方式。
Claude Code 则更偏封闭但不完全封死。它提供扩展面，但在强产品边界内提供。这样换来的是更高一致性、更强安全整合、更完整的商业体验。代价是，有些实验性想法无法立刻落地，只能等待官方暴露能力。
三个系统分别如何回答这五组张力
如果把三者浓缩成三句判断，可以这样概括。
OpenCode 的答案是：先保住一个可编程、可理解的基础，再让上层自己长。
OMO 的答案是：真正决定高级 agent 水平的，不是模型本身，而是编排结构。
Claude Code 的答案是：如果你想把自治真正带进生产环境，就必须把安全、压缩、审批、沙箱做成底层设施。
因此，理想 coding agent 不是简单复制三者中的任何一个，而应该是三者的综合体：在开放性上继承 OpenCode 的平台意识，在任务组织上吸收 OMO 的编排意识，在大规模可部署性上学习 Claude Code 的安全意识。五组张力不会消失，但好的系统不再假装它们不存在，而是逐层地、带着明确优先级地去解决它们。这才是“理想架构”真正应有的成熟度。