同一个大模型，在专业工具里像高级工程师，在简陋脚本里像实习生。差距往往不在基座“智商”，而在它运行的环境。

最近，Google 开发者工具/生态负责人 Addy Osmani 发长文系统梳理了“Agent Harness Engineering（智能体脚手架工程）”，直接点破了当前开发者常踩的坑：一遇到智能体跑偏就怪模型版本太旧，却很少反思自己的系统约束是否漏风。

这篇文章不卷参数，专讲架构。读完你会明白，为什么调优一个运行环境，往往比盲目换模型更能解决实际工程问题。

换把尺子：为什么实际表现差异不在模型本身？

开发者常陷入“唯模型论”的误区，以为换个评分更高的基座就能自动解决长程任务失败、幻觉或工具调用乱序的问题。但智能体的本质从来不是孤立的大语言模型，而是“模型 + 所有外部脚手架”。

脚手架（Harness）指的是系统提示、工具链、沙箱隔离、上下文策略以及拦截钩子（Hooks）的总和。模型只提供生成概率，脚手架负责提供状态管理、安全约束和反馈闭环。

问题来了：为什么同样的模型在不同产品里表现天差地别？

作者开篇就抛出了一个在工程圈流传甚广的观察：

在该工程语境下，作者指出架构迭代的边际收益往往大于单纯替换更强模型。它提醒我们，智能体执行失败多为配置与工程约束缺失导致，而非纯粹的模型能力瓶颈。

但这不能证明“强模型不重要”。它反映的是在特定编程与自动化任务中，系统控制逻辑对模型基线能力的放大或限制作用。如果你面对的是强依赖隐式知识或开放性创意生成的任务，这条经验法则的适用性会显著下降。

拆解“黑盒”：成熟智能体背后的系统脚手架长什么样？

把抽象概念落地，一个成熟的 Harness 通常包含六大模块：规则文件（如 CLAUDE.md/AGENTS.md）、工具链与 MCP 服务器、沙箱与文件系统、记忆与搜索注入、上下文生命周期管理、以及可观测性模块。

说白了，这就是一个把“文本生成”变成“状态机控制”的流水线。开发者能直接掌控的“表面面积”，远大于模型提供商。这也意味着，你对系统稳定性和安全性的责任面积更大。

下面这张图展示了行业对头部编程智能体 Claude Code 的架构逆向拆解。

读这张图时，重点看三件事：第一，知识注入层、内存工作区与权限门控是分层的；第二，多智能体之间设有“防火墙”；第三，工具分发是独立注册的。

这张图说明了当前成熟编程智能体的共性架构：各司其职，共同构成状态管理与安全拦截的闭环。它不能说明这是官方源码事实，也不代表其他垂直领域（如数据分析或客服）会采用完全相同的堆栈。它更像是一面镜子，反射出“架构收敛”的工程趋势。

从试错到固化：如何让智能体的失败成为资产？

工程上最麻烦的地方是，模型的不确定性会让调试变成玄学。作者给出的解法是“Ratchet（棘轮）机制”：把每一次偶然的翻车，变成永久性的系统规则。

别指望换个“最聪明”的模型就能自动写对业务逻辑。约束不到位，高智商模型也会变成高破坏力捣乱机。

具体来说，如果模型提交了包含注释掉的测试用例的代码，下一次迭代就必须把“禁止注释测试用例”写进 AGENTS.md；同时，在 pre-commit 阶段加一个 Hook 自动扫描 diff；甚至拆一个独立的校验 Agent 来拦截。成功时保持静默，失败时把错误直接注入循环让模型自纠。

除了规则固化，上下文管理同样关键。上下文窗口就像行李箱，塞满反而找不到钥匙。Harness 通过三种策略对抗“上下文衰减”：

1. none !important

   none !important智能压缩（Compaction）：定期总结旧对话并卸载到外部存储。none !important

   none !important
2. none !important

   none !important工具输出卸载：把几千行的日志丢回文件系统，只把摘要留给模型。none !important

   none !important
3. none !important

   none !important渐进式披露：工具说明按需加载，别在启动时一股脑全塞进 Prompt。none !important

   none !important

而 Hooks 则是这套机制里的执行层。它可以在工具调用前、文件修改后、commit 前运行检查：危险命令直接拦截，格式问题自动修复，测试失败就把错误重新注入 Agent loop，让模型自己回去改。

重点看三条链路：

1. none !important

   none !important失败沉淀链路：Agent 出错 → 记录具体失败 → 更新规则文件 / Hook / reviewer subagent。none !important

   none !important
2. none !important

   none !important执行拦截链路：工具调用前、文件修改后、commit 前触发检查，成功时静默通过，失败时返回明确错误。none !important

   none !important
3. none !important

   none !important上下文管理链路：长日志和旧上下文被压缩、卸载或按需披露，避免模型在拥挤上下文里硬推理。none !important

   none !important

它说明的是：好的 Harness 不是靠一次性写完，而是在真实失败中不断长出来的。模型负责生成，Harness 负责把失败变成约束、把约束变成流程、把流程变成下一次自动执行的安全边界。

每一次失败，都让系统往前咬住一格，而不是原地打转。

这套思路很工程化，但并不是免费午餐。多重拦截、沙箱执行、日志卸载和上下文压缩，都会带来额外的系统复杂度、延迟和 Token 开销。原文主要讨论机制设计，并未给出具体成本测算。真正落地时，还需要结合业务场景单独评估：哪些错误值得固化成规则，哪些检查会拖慢开发流，哪些上下文值得保留，哪些应该果断丢掉。

底座抬升之后：Harness 会消失还是进化？

一个常见疑问：随着模型底座越来越强，这些繁琐的脚手架是不是就没用了？

作者的观点很明确：Harnesses Don't Shrink, They Move.（脚手架不会缩小，只会迁移）。

这句引文点出了动态演进的规律。能力底座抬升后，旧假设被移除，但新解锁的复杂任务会带来全新的失败模式。现代大模型的后训练（Post-training）阶段，往往已经与特定的交互循环强耦合，导致一定程度的“架构过拟合”。

在此基础上，作者进一步推演了行业趋势：开发范式正从直接调用 LLM API（提供文本补全），转向调用 Harness API（提供完整运行时）。框架提供标准循环、工具分发与沙箱，开发者只需专注领域特定的 Prompt 与工具配置。

需要明确的是，“Harness-as-a-Service（HaaS）成为默认基座”目前属于前瞻性趋势判断。该推演基于作者对工具链演进的经验总结，尚未转化为第三方市场数据或统一的行业协议标准。它更适合理解为应用层开发范式的演进，而非底层基础设施的既定事实。

所以，这把尺子适合怎么用？

这篇长文的价值，不在于提出了什么底层算法创新，而在于把碎片化的工程共识整合成了一套可操作的心智模型。对 Agent 开发者而言，明天的项目可以先从这几步开始：

1. none !important

   none !important检查你的 Prompt 是否写成了“许愿池”。 把每一条系统指令都对应到一次历史失败上，没有依据的约束果断删掉。none !important

   none !important
2. none !important

   none !important在关键工具调用前后加 Hook。 用校验替代重试，用拦截替代事后补救。none !important

   none !important
3. none !important

   none !important给上下文做“断舍离”。 长任务务必拆分规划与执行，把中间结果卸载到文件，别让模型在拥挤的窗口里硬推理。none !important

   none !important

Harness 范式最适合强工具依赖、流程结构化、可量化验证的任务。但在强依赖隐式知识、开放性推理或需要极高创造力的场景下，它的能力边界依然受限于模型本身的训练分布。

智能体的稳定性确实是“管”出来的。把调参的精力分一半给架构设计，你的 Agent 可能会少出很多幺蛾子。

原文：Agent Harness Engineering

作者：Addy Osmani（Google 开发者工具与生态负责人）

链接：https://x.com/addyosmani/status/2053231239721885918