Google Cloud AI 总监 Addy Osmani 写了一篇关于 Agent Harness Engineering 的长文，核心公式很简单：Agent = Model + Harness。模型只是系统的一个输入，真正决定 Agent 表现的，是围绕模型搭建的那一整套脚手架。

过去两年，行业一直在争论哪个模型最聪明、哪个写代码最干净、哪个幻觉最少。这些当然重要，但它忽略了系统的另一半。一个普通模型配上精心设计的 harness，能稳定地打赢一个顶级模型配上粗糙 harness 的组合。越来越多最有意思的工程工作，已经不在模型选择上了，而在设计模型周围的那层脚手架上。

Harness 具体包括什么？系统提示词、工具描述、文件系统、沙箱、子 Agent 编排、钩子和中间件、可观测性工具、记忆和搜索机制。Claude Code、Cursor、Codex、Aider，这些产品本质上都是 harness。底层模型可能一模一样，但你体验到的行为差异，绝大部分来自 harness 的不同。

文章里最核心的一个理念是：把每次 Agent 的失败都当作永久性的信号来处理，而不是当成偶发事件重试一下就算了。Agent 提交了一个注释掉测试的 PR？那下一版 AGENTS.md 里就要写明"禁止注释测试"，下一个 pre-commit hook 就要自动拦截，审核子 Agent 也要更新规则。每一条好的系统提示词，都应该能追溯到一次具体的历史失败。

他还提到了几个关键的 harness 设计模式：用文件系统和 Git 做持久化状态管理；用 bash 做通用工具层；用沙箱保证安全执行；用记忆文件注入跨会话知识；用压缩、渐进式披露和工具调用卸载来对抗上下文腐烂；用循环、规划和拆分来支撑长时间自主执行。

还有一个很有意思的观点：模型变强了，harness 的需求不会消失，只会转移。以前需要的那些"防止模型犯蠢"的脚手架可以拆掉了，但新的能力边界又会带来全新的失败模式，需要全新的脚手架来应对。所以 harness 是一个活的系统，永远在随着模型能力的变化而演化。

最后他说，现在行业正在从"基于 LLM API 构建"转向"基于 Harness API 构建"。SDK 已经把循环、工具、上下文管理、钩子、沙箱这些东西开箱即用地提供了。你要做的，是选一个 harness 框架，配置核心支柱，然后把精力集中在你自己领域的 prompt 和工具设计上。

说白了，当所有人都在追最新模型的时候，真正拉开差距的，是你围绕模型构建的那套系统有多扎实。模型是标准品，harness 才是你的竞争壁垒。

原文地址：x.com/addyosmani/status/2053231239721885918

#科技先锋官##How I AI#