模型: openai/gpt-5.4
生成日期: 2026-04-01
书名: Claude Code VS OpenCode：架构、设计与未来
章节: 第18章 — 理想编码Agent的架构
Token用量: 约 7,600 input + 2,050 output
18.1 共识架构
到了 2026 年，优秀 coding agent 的“理想架构”其实已经越来越有共识。不同产品当然还会在商业模式、界面风格、默认工作流、是否开源等问题上继续分化，但如果只看技术骨架，行业已经逐步收敛到一套相当稳定的组合：高空位、低细节的 system prompt（系统提示词），统一的 tool registry（工具注册表）/MCP clients（MCP 客户端层），紧凑的 context manager（上下文管理器），ReAct loop（推理-行动-观察循环），sub-agents（子智能体），以及OS-level sandbox（操作系统级沙箱）。
这里的“高空位”是一个很重要的概念。它不是计算机教材里的标准术语，而是 agent 设计里很实用的一个说法，意思是：提示词只定义高层原则，不塞满低层细节。也就是说，system prompt 不应该变成一本操作手册，更不应该承担所有行为逻辑。它只负责身份、边界、任务哲学、推理姿态这些稳定、不频繁变化的内容。至于具体工具怎么调用、哪些场景该走什么流程、上下文怎么压缩、何时委派子 agent，这些都应该被分配到别的层。
为什么会形成这个共识？因为早期做 agent 的人几乎都踩过同一种坑：把所有东西都塞进 prompt。身份说明塞进去，风格要求塞进去，安全规则塞进去，工具说明塞进去，产品逻辑塞进去，边缘情况塞进去，最后 prompt 变得像一个不断膨胀的企业规章制度文件。这样短期看似可控，长期却会迅速失效：模型记不稳，规则冲突，维护困难，而且每次修改都像在拆承重墙。
所以，理想架构的第一条共识就是：让 prompt 变小，把系统做大。 这里的“大”不是指代码量，而是指结构层次更清晰、职责更分离。
第二个共识是 tool registry 必须成为正式基础设施。工具注册表不是一份松散的函数列表，而是 agent 的“行动宪法”。它要回答几个问题：有哪些动作可以做？每个动作的输入输出是什么？副作用是什么？什么场景适合用，什么场景不适合用？是否存在权限要求？是否有替代工具？
在 2026 年的主流做法里，这层通常不再只包含本地内置工具，而是会把 MCP、LSP、宿主原生工具、插件包装工具统一成一个可被模型理解的接口层。也就是说，agent 不应该知道底层这个能力究竟来自内置代码、远程 MCP server，还是 IDE 的 LSP 服务；对它来说，这些都应该以统一 schema（结构化参数定义）的形式出现。
OpenCode、OMO、Claude Code 在这里虽然实现风格不同，但方向非常一致。OpenCode 提供的是可编程宿主；OMO 证明了工具不仅能操作文件和 shell，还能承担编排角色；Claude Code 则进一步说明工具系统之外还必须有宿主层策略控制。三者叠加起来，就形成了一个越来越清楚的架构蓝图。
┌─────────────────────────────────────────────────────────────┐
│ USER / IDE / CLI / API │
└────────────────────────────┬────────────────────────────────┘
│
v
┌─────────────────────────────────────────────────────────────┐
│ MINIMAL SYSTEM PROMPT │
│ - 身份与作用域 │
│ - 全局安全边界 │
│ - 规划/推理姿态 │
└────────────────────────────┬────────────────────────────────┘
│
v
┌─────────────────────────────────────────────────────────────┐
│ CONTEXT MANAGER │
│ - 紧凑会话状态 │
│ - JIT retrieval（即时检索） │
│ - structured notes（结构化笔记） │
│ - compaction（压缩）与 overflow recovery（溢出恢复） │
└────────────────────────────┬────────────────────────────────┘
│
v
┌─────────────────────────────────────────────────────────────┐
│ REACT EXECUTION LOOP │
│ think → choose tool / delegate → observe → update state │
└───────────────┬───────────────────────────────┬─────────────┘
│ │
v v
┌──────────────────────────────┐ ┌──────────────────────────┐
│ TOOL REGISTRY / MCP CLIENTS │ │ SUB-AGENT ORCHESTRATOR │
│ - 文件 / git / 搜索 / LSP │ │ - explore / review / doc │
│ - 浏览器 / 测试 / deploy │ │ - 并行且隔离的工作 │
│ - typed schemas + 描述文档 │ │ - 结果汇总与回收 │
└───────────────┬──────────────┘ └──────────────┬───────────┘
│ │
└──────────────┬──────────────────┘
v
┌─────────────────────────────────────────────────────────────┐
│ HOST RUNTIME + POLICY LAYER │
│ - 权限、审批、审计、成本控制 │
│ - 重试、限流、来源追踪、策略检查 │
└────────────────────────────┬────────────────────────────────┘
│
v
┌─────────────────────────────────────────────────────────────┐
│ OS-LEVEL SANDBOX │
│ - 文件系统范围 - 网络策略 │
│ - 进程隔离 - 凭证边界 │
└─────────────────────────────────────────────────────────────┘
这张图里最容易被低估的一层，是 context manager。Prompt engineering（提示工程）主要讨论“怎么写指令”；而 Context engineering（上下文工程）讨论的是“如何管理模型在这一刻实际看到的全部 token 状态”。后者明显更接近系统工程。
一个 coding agent 很少是因为“模型不够聪明”才失败，更常见的情况是：它看到的上下文是错的、旧的、臃肿的、互相冲突的、无关信息太多的。于是一个成熟的上下文管理器至少要做好四件事。
第一，保持活跃上下文紧凑。模型在当前步骤里真正需要的，通常只是任务目标、若干约束、少量关键文件、最近一次工具输出，以及一份短的中间状态总结，而不是整个聊天历史全文回放。
第二，做 JIT retrieval（即时检索）。这个术语可类比数据库中的按需加载：不是提前把所有资料塞进内存，而是在需要时拿进来。对 agent 来说，就是某个文件、某段历史、某条规则、某份文档只有在当下相关时才被注入上下文。
第三，维护 structured notes（结构化笔记）。这不是普通聊天记录，而是把“当前已知事实、待验证假设、已完成步骤、剩余风险”写成更适合机器消费的紧凑状态对象。它的作用类似于程序里的状态机快照。
第四，支持 overflow recovery（上下文溢出恢复）。这里的 overflow 指上下文窗口超限。优秀系统不能把这件事视为罕见事故，而应该把它当成日常运行条件之一：一旦接近上限，就压缩、重写锚点、保留关键状态，尽量优雅退化，而不是突然失忆。
在这之上，仍然是 ReAct loop 作为执行核心。ReAct 不是计算机教材里的经典术语，而是 agent 领域的经验范式，意思是模型通过“推理—行动—观察—再推理”的迭代方式解决问题。它适合 coding work 的原因很简单：编程任务不是纯问答，也不是一次性脚本。agent 必须检查文件、调用工具、根据返回结果修正路径，再继续下一步。
不过到 2026 年，ReAct 的最佳实践也发生了变化：它不再强调把所有思考都冗长展开，而更强调状态转移的纪律性。模型负责决策与解释，宿主负责日志、策略、权限、重试和执行边界。换言之，ReAct 不再等于“多想一点”，而更像“每一步都知道自己为什么行动，以及行动后如何更新状态”。
再往上走，就是 sub-agents。子智能体的真正价值不是“看起来很高级”，而是上下文分区与任务并行。一个 agent 去 codebase 里做探索，一个 agent 去查外部文档，一个 agent 专门复核某个结论，这些都属于把复杂任务拆成多个边界清楚的小工作区。OMO 在这一点上走得最远，Claude Code 也在更审慎地接纳，OpenCode 则提供了底层可组合性。
但这里也有一个经常被忽视的条件：sub-agent 只有在编排质量足够高时才有意义。也就是说，不是多几个 agent 就更强，而是何时分、怎么分、结果怎么回收 才是关键。否则子 agent 很容易从能力变成噪音源。
最后一层，也是决定这套架构能否真正落地的一层，是 OS-level sandbox。它的重要性在于把“安全”从提示词层面的说服，变成操作系统层面的约束。文件系统可见范围、网络访问策略、进程隔离、凭证边界、审计日志，这些机制一起决定 agent 是否能在高自治状态下被组织接受。
Claude Code 给行业最重要的提醒之一就是：安全不是自治的刹车，而是自治的地基。 没有沙箱，每次提升 agent 自主性都会同步提升恐惧；有了沙箱，自主性就被放进一个可管理的边界里，风险被显式约束，信任才有增长空间。
所以，2026 年的理想编码 agent 共识架构，本质上是在分层解决六类失败：system prompt 过胖导致规则腐烂，tool surface（工具表面）不清导致动作混乱，context 失控导致 token 污染，单循环过载导致效率低下，缺乏任务分治导致大任务难以伸缩，缺乏沙箱导致组织无法放心授权。
真正优秀的系统不是让模型背更多说明书，而是让不同层承担不同职责：prompt 负责原则，tool registry 负责能力声明，context manager 负责状态质量，ReAct loop 负责执行节奏，sub-agents 负责分工，sandbox 负责可信边界。这就是理想架构之所以已经逐渐形成共识的原因：它不是某家公司偏好的产品哲学，而是被现实反复逼出来的工程答案。