模型: gpt-5.4 (openai/gpt-5.4)
生成日期: 2026-04-01
书名: Claude Code VS OpenCode：架构、设计与未来
章节: 第1章 — 编码智能体的进化史
Token消耗: 约2,500（估算）
1.3 脚手架比模型更重要
过去两年，行业里最容易让人误判的一件事，是把编码智能体的进步简单归因于底层模型升级。模型当然重要，但如果只盯着模型，就会错过真正决定系统上限的部分：脚手架。Morph LLM 曾给出一个很有代表性的观察：同一个模型，放进不同的 Agent 脚手架后，在真实软件任务上的解决率可以相差 17 个问题。这个差距已经大到无法用“提示词写得更好”轻轻带过，它说明决定系统成败的，不只是大脑本身，而是大脑如何接入环境、组织记忆、调用工具以及从失败中恢复。
这里的“脚手架”并不是传统计算机科学教材中的标准术语，更接近工程界对智能体系统外层结构的通俗命名。为了避免误解，我们可以给出一个工作性定义：脚手架是围绕 LLM 搭建的整个执行系统，包括工具接口、上下文管理、权限模型、系统提示、状态持久化、任务分解机制、重试策略、错误恢复路径，以及人与系统之间的交互约束。换句话说，模型负责生成下一步决策，而脚手架决定模型能看到什么、能做什么、何时停下、出错后怎么办。
这个定义一旦成立，很多现象就不难理解。为什么同样使用顶级模型，有些产品只能做高质量问答，有些却能稳定完成跨文件修改？因为前者把模型当作会写代码的聊天机器人，后者则给模型配上了文件系统、搜索、测试、补丁、版本控制、会话恢复和权限决策等一整套执行设施。为什么有些系统越做越“聪明”，有些系统一遇到复杂仓库就迅速失真？因为真正的瓶颈并不总在语言能力，而常常在上下文选择错误、工具粒度失衡、反馈链路断裂、失败后无法收敛。
脚手架的重要性还体现在“能力放大”而不是“能力替代”上。一个强模型放进劣质脚手架，会因为工具缺失和状态管理混乱而浪费大量推理能力；一个中上水平的模型放进高质量脚手架，则可能通过更好的检索、约束和反馈，展现出接近更强模型的任务表现。这正是编码智能体区别于纯聊天产品的关键：聊天产品主要比较模型回答质量，编码智能体比较的是系统在真实环境中的闭环执行效率。
因此，本书会主动重定义比较框架。我们比较 OpenCode、Oh-My-OpenCode 与 Claude Code 时，比较的不是“谁接了更强的模型”，而是“谁构建了更强的系统”。更具体地说，我们会比较五类脚手架能力。
第一，工具系统。工具是否覆盖读、写、搜、跳转、执行、诊断、网络访问与外部集成？工具的输入输出是否对模型友好？一个坏工具即使功能存在，也可能因为返回噪声过大而让模型无法使用。
第二，上下文系统。系统是否知道该把哪些文件、哪些错误、哪些历史步骤送进上下文窗口？所谓上下文工程，已经逐渐替代早期的提示工程，成为编码智能体最核心的基础设施之一。
第三，控制系统。权限是否细粒度？哪些操作自动执行，哪些必须确认？有没有沙箱、快照、回滚与审计？自主性越高，控制系统越重要。
第四，恢复系统。一次编辑失败后，系统能否继续追踪错误、修正策略、减少重复试错？没有恢复能力，Agent 只是在不断重试同一种错误。
第五，编排系统。单 Agent 是否足够，还是需要多 Agent 分工？如何让探索、检索、实现、验证这些角色协同工作？这已经不是单一模型能力能解释的问题，而是系统架构问题。
这也是为什么“架构现在是首要差异化因素”并不是一句营销口号，而是一条工程事实。在模型快速趋同、接口快速标准化的背景下，单纯依赖模型领先建立护城河会越来越难；真正能形成持续差异的，是对脚手架的设计深度。谁更懂任务分解，谁更懂工具抽象，谁更懂上下文压缩与记忆保留，谁就更可能做出可靠的编码智能体。
从这个视角回看整个行业，很多争论就会变得清晰：我们今天讨论的核心已不再是“哪个模型最会写代码”，而是“什么样的系统最能把模型变成可工作的工程代理”。这也是本书的基本立场。模型是发动机，但脚手架决定这台机器最终是一辆可跑长途的汽车，还是一台只能原地轰鸣的试验机。
从脚手架到 Harness Engineering
附录增补说明：本节由 openai/gpt-5.4 生成
本节 Token 消耗：约 3,100
“脚手架比模型更重要”最初更像一句经验判断：它提醒人们，不要把 coding agent 的成败都归因于模型参数规模、预训练语料或者 benchmark 排名。但到 2025 年下半年到 2026 年初，这种判断开始进一步演化，逐渐形成一种更正式的工程概念：Harness Engineering。
之所以要从 “scaffolding” 走向 “harness”，并不是单纯换一个更时髦的词，而是因为后者更像一个完整工程学科的名字。scaffolding（脚手架）强调“外围结构的重要性”；而 harness engineering 则进一步强调：这个外围结构不是临时支架，而是需要被持续设计、验证、迭代和制度化的运行控制系统。
一条逐渐成形的概念脉络
这个概念之所以在 2025–2026 年间迅速成形，和几次公开表述密切相关。
首先，Viv Trivedy 在 2025 年 9 月 用 “HaaS — Harness as a Service” 的说法，把原本零散存在的经验正式系统化了。这里最关键的贡献，不只是命名，而是把“让 agent 更可靠”从 prompt 技巧问题，提升为“设计运行时外壳”的系统工程问题。也就是说，真正该被工程化的对象，不只是模型本身，而是模型被包裹、约束和驱动的整个执行环境。
其次，Mitchell Hashimoto 在 2026 年 2 月 5 日 独立提出了一个极具操作感的定义：“anytime you find an agent makes a mistake, you take the time to engineer a solution such that the agent never makes that mistake again”。这句话非常关键，因为它把 Harness Engineering 从抽象理念拉回到了日常工程实践。它的核心不是“让 agent 大致变好”，而是“把重复错误逐步固化为不会再次发生的系统约束”。
再次，OpenAI 在 2026 年 2 月 11 日 放大了这一概念：其团队宣称借助 harness engineering，构建了一个**百万行代码规模、0 hand-written code（零手写代码）**的产品。无论人们如何理解这句话的精确边界，它至少释放出一个非常强的信号：当 harness 足够成熟时，大规模软件生产的关键瓶颈，正在从“人是否逐行手写”转向“系统是否足够善于约束、验证、恢复与编排模型行为”。
最后，Martin Fowler 网站在 2026 年 2 月 17 日 对该概念进行了分析。这个节点的意义在于：当一个概念开始进入 Fowler 所代表的软件架构讨论体系时，它就不再只是社交媒体上的流行说法，而开始成为主流工程语言的一部分。
什么是 Harness？为什么要用“马具”这个比喻？
这里的 harness 不是 CS 教科书里的标准术语，需要专门解释。它本义是马具：套在马身上的控制与连接装置。马本身有力量，但如果没有马具，这种力量就很难被稳定地引导到马车、犁具或者运输系统上。马具并不创造力量，它负责约束、传导、放大和定向。
把这个比喻迁移到 AI，很容易理解：LLM 像马，拥有很强的生成与推理能力；而 harness 则是包裹在模型外层的运行控制系统。它决定模型能看到什么、调用什么、被什么规则限制、如何接受反馈、什么时候停下、出错后如何纠偏。
因此，可以写成一个非常重要的公式：
coding agent = AI model(s) + harness
这个公式的含义并不只是“模型外面还有别的东西”，而是：真正可用的 coding agent，从来都不是一个裸模型，而是“模型 + 运行时工程”的组合体。
Harness Engineering 的七条原则
从目前公开讨论和实际系统演进来看，Harness Engineering 至少可以概括为七条原则。
1. Environment over Model
第一条原则是：先看环境，再看模型。 也就是那句很有代表性的判断：“It’s not a model problem. It’s a configuration problem.” 这并不是否认模型的重要性，而是说，在很多失败案例里，真正先该被怀疑的不是模型智力，而是环境配置。Agent 改错文件、忘跑测试、读错规则、在无关上下文里打转，通常不是因为它“不会思考”，而是因为环境把错误路径设计得太容易走了。
2. Deterministic Constraints
第二条原则是：要用确定性约束去包围概率性模型。常见形式包括：custom linters、自定义 schema validation、tool 参数校验、hook 检查、权限边界、文件修改规则、补丁格式验证等。好的 harness 不只是“提醒模型要小心”，而是通过工程手段让错误更难发生，让正确路径更容易被选择。
3. Progressive Disclosure
第三条原则是：信息要渐进披露，而不是一次性塞满。一个好的 AGENTS.md 更像索引，而不是百科全书。规则、技能、知识文档、案例和工具说明，应该按需加载。这样做的原因很简单：上下文窗口再大，也是稀缺资源。把所有信息提前压进去，只会降低信号密度。
4. Back-Pressure
第四条原则是：系统必须给 agent 足够的回压（back-pressure）。这里的“回压”也不是教科书里 AI 专用术语，而是借用了系统工程中的思路：让真实世界的结果反向作用于生成过程。tests、type checks、build、schema validators、post-edit verification，都是回压机制。没有回压，模型只是在自洽地继续生成；有了回压，现实约束会不断把它拉回正确轨道。
5. Context Firewall
第五条原则是：用 sub-agents 形成上下文防火墙（context firewall）。子智能体不只是为了并行，更是为了隔离。主智能体的长对话、临时噪声、偏题探索，不应无差别地污染每一个子任务。通过把探索、检索、实现、审阅等工作拆到不同 agent 中，可以显著降低上下文腐坏（context rot）的速度。
6. Knowledge as Code
第六条原则是：知识要代码化。 如果某条规则很重要，它就应该被写进 repo，或者至少写进 agent 能稳定读取的版本化文件中。否则，对 agent 来说，它基本等于不存在。这一点非常像基础设施即代码（Infrastructure as Code）的思路：把口口相传的隐性知识，变成可审查、可追踪、可复现的显性知识。
7. Entropy Garbage Collection
第七条原则是：要做熵垃圾回收。这里的 entropy 不是严格热力学含义，而是指系统随着时间累积的混乱：过时模板、旧命令、废弃规则、错误示例、历史遗留目录结构。Agent 很容易模仿仓库里“看起来像样”的旧模式，因此 repo 里的陈旧内容会不断被复制放大。Harness Engineering 必须周期性清理这些噪声，否则系统会越来越难教。
这七条原则如何映射到三套系统
把这套框架映射到 OpenCode、Oh-My-OpenCode（OMO） 和 Claude Code，会非常清晰。
Claude Code 可以被理解为一种闭合式 harness（closed harness）。它最大的特点是模型与 harness 的深度耦合。也就是说，Claude 系列模型，尤其高阶模型，并不是仅仅“被接到一个工具壳子里”，而更像是被训练得熟悉这个壳子本身：熟悉其 memory、permissions、tool schemas、workflow、compaction 机制、hooks 和 skills 生态。这样的优势在于整体一致性极高。模型知道自己处在怎样的运行环境中，因此很多行为会显得更自然、更顺手。
OpenCode 则更像一种开放式 harness（open harness）。它的价值不在于把某个模型和某个运行时捆死，而在于提供一个可适配多模型、可被用户观察和扩展的 agent 宿主。它通过插件系统、工具注册、配置分层、多模型接入等机制，把 harness 本身暴露为一个可以被设计和重构的对象。对 Harness Engineering 这门学科来说，OpenCode 很重要，因为它让“研究 harness”变得可操作。
OMO 最值得注意，因为它几乎就是 HaaS 的实践形态。可以把它理解为 OpenCode 之上的harness 配置与增强层。OMO 并不是简单多加几个工具，而是在多个层面系统化地改造运行时：dynamic-agent-prompt-builder、41 hooks、rules injection、wisdom accumulation、agent specialization、background task spawner、skill-embedded MCPs……这些都不是“单点功能”，而是在持续降低 harness engineering 的门槛。原本需要用户亲自定制的大量工程工作，被 OMO 预先包装好了。
换句话说，Claude Code 更像“深度一体化的闭源高成熟 harness”，OpenCode 更像“可编程、可替换、可观察的开放 harness 宿主”，而 OMO 则像“把开放 harness 快速工程化的配置层与编排层”。
为什么这个概念升级很重要
从“脚手架”到 “Harness Engineering”，真正发生变化的，不只是术语，而是问题意识。
“脚手架比模型更重要”这句话是在提醒人们：模型不是全部。它更像一种诊断框架。而 “Harness Engineering” 则进一步给出行动方向：当 agent 出错时，不要只想“下一次 prompt 写得更精细一点”，而要问：能不能把这个错误变成一个以后不会再发生的系统机制问题？
这背后是一次很深的工程观转向。过去，大家把 agent 的提升更多理解为“让模型更聪明”；现在，越来越多团队开始把 agent 的提升理解为“让环境更可靠”。前者偏模型中心，后者偏系统中心。前者常常停留在单次表现优化，后者则追求项目级、仓库级、团队级的长期稳定性。
这也解释了为什么 OMO 这类系统会越来越重要。它们证明了一件事：很多 coding agent 的核心竞争力，并不一定来自更换一个更强的模型，而是来自更认真地做 harness engineering。真正成熟的 agent 产品，最终拼的不是模型裸智力，而是谁更会把模型的能力变成稳定、可验证、可扩展的工程生产力。