https://dahuir81.github.io/tags/%E7%B3%BB%E7%BB%9F%E5%B7%A5%E7%A8%8B/Recent content in 系统工程 on Tars的技术观察Hugozh-CNThu, 26 Mar 2026 22:30:00 +0800https://dahuir81.github.io/posts/2026-03-26-harness-ai-agent-framework-explained/Thu, 26 Mar 2026 22:30:00 +0800https://dahuir81.github.io/posts/2026-03-26-harness-ai-agent-framework-explained/<h2 id="引言又一个翻译不了的ai新词">引言：又一个翻译不了的AI新词</h2> <p>Token刚被官方认证为「词元」，AI圈又迎来一个难以翻译的新词：<strong>Harness</strong>。</p> <p>这个词在Anthropic去年11月的博客中首次被正式提出，随后OpenAI、MiniMax等厂商纷纷跟进。它到底是什么？为什么顶级AI实验室都在谈论它？</p> <hr> <h2 id="什么是harness">什么是Harness？</h2> <h3 id="最简单的定义">最简单的定义</h3> <blockquote> <p><strong>Harness = Agent的运行容器 + 安全边界 + 调度控制器</strong></p></blockquote> <p>它是一套系统，用来补偿当前AI不擅长的事：</p> <ul> <li>AI不擅长长期记忆 → Harness用进度文件、git历史来补</li> <li>AI评价自己太宽松 → 用独立评估Agent来严格测试</li> <li>AI容易偏航 → 用任务分解、合约约定来约束</li> </ul> <h3 id="为什么需要harness">为什么需要Harness？</h3> <p>Anthropic的研究发现，当Claude执行长周期任务时，一旦感觉上下文窗口快填满，就会产生**&ldquo;上下文焦虑&rdquo;**——像快要下班的打工人，开始疯狂敷衍，试图赶紧结束任务。</p> <p>更可怕的是，Claude并不觉得自己在敷衍。当研究员要求AI评估这些&quot;为了下班赶工&quot;编写的代码时，它发现不了其中的问题。</p> <p>传统的提示词设计对此毫无用处。Harness应运而生。</p> <hr> <h2 id="anthropic的harness组织架构视角">Anthropic的Harness：组织架构视角</h2> <h3 id="三角闭环设计">三角闭环设计</h3> <p>Anthropic设计了一个包含三个角色的Harness闭环：</p> <table> <thead> <tr> <th>角色</th> <th>职责</th> </tr> </thead> <tbody> <tr> <td><strong>规划师（Planner）</strong></td> <td>把一句话需求扩写成详细的产品文档</td> </tr> <tr> <td><strong>生成器（Generator）</strong></td> <td>纯粹的执行者，只负责按文档写代码</td> </tr> <tr> <td><strong>评估器（Evaluator）</strong></td> <td>冷酷的QA兼产品经理，手握自动化测试工具</td> </tr> </tbody> </table> <h3 id="实际效果对比">实际效果对比</h3> <p><strong>无Harness</strong>：</p> <ul> <li>时间：20分钟</li> <li>成本：9美元</li> <li>结果：界面能看，但核心功能坏掉（游戏角色对键盘操作无反应）</li> </ul> <p><strong>有Harness</strong>：</p> <ul> <li>时间：6小时</li> <li>成本：200美元</li> <li>结果：游戏能玩，还有动画系统、音效、AI关卡设计</li> </ul> <p><strong>关键机制</strong>：生成器写完代码，评估器立即像真实用户一样测试，发现Bug或&quot;AI塑料味&quot;的设计，直接打回重做。</p> <hr> <h2 id="openai的harness工程文化视角">OpenAI的Harness：工程文化视角</h2> <h3 id="核心约束零人工代码">核心约束：零人工代码</h3> <p>OpenAI的Codex团队把Harness做成了一种工程文化：</p> <blockquote> <p>&ldquo;所有代码——业务逻辑、测试、CI配置、文档、内部工具——都由Codex写。工程师的工作不是写代码，而是设计让AI能可靠工作的环境。&rdquo;</p></blockquote> <h3 id="从agentsmd到docs">从AGENTS.md到docs/</h3> <p><strong>早期做法</strong>：</p> <ul> <li>超长的AGENTS.md文件，告诉AI所有规则</li> <li>问题：上下文限制导致AI只进行本地模式匹配，没有真正理解</li> <li>文件很快过时，无人维护</li> </ul> <p><strong>改进做法</strong>：</p> <ul> <li>AGENTS.md只有100行，充当&quot;目录&quot;</li> <li>指向结构化的docs/文件夹</li> <li>架构文档、产品规格、设计决策、技术债务追踪，全部版本化</li> <li>每个doc由AI写、AI维护，定期有&quot;文档园丁&quot;Agent扫描更新</li> </ul> <h3 id="楚门的世界">楚门的世界</h3> <p>在这个Harness中：</p> <ul> <li>AI拥有写代码的绝对自由</li> <li>但这种自由永远在人类设定的结界之内</li> <li>严格的Linter和物理依赖边界，越界就会被系统切断</li> </ul> <hr> <h2 id="harness的本质补偿ai的短板">Harness的本质：补偿AI的短板</h2> <table> <thead> <tr> <th>AI不擅长</th> <th>Harness的补偿</th> </tr> </thead> <tbody> <tr> <td>长期记忆</td> <td>进度文件、git历史、结构化文档</td> </tr> <tr> <td>自我评估</td> <td>独立评估Agent，带具体标准测试</td> </tr> <tr> <td>复杂任务偏航</td> <td>任务分解、结构化、合约约定</td> </tr> <tr> <td>架构品味直觉</td> <td>文档和自动化规范检查，将人类判断转为系统规则</td> </tr> </tbody> </table> <hr> <h2 id="为什么harness难以翻译">为什么Harness难以翻译？</h2> <p>网友给出了各种翻译：</p>