如何设计智能体 Harness：把模型变成可放养员工的六个决策

如何设计一个 Agent 脚手架：把模型变成一个你能放手不管的工人，需要六个决策 August 15, 2026 · 13 min read · View source ↗ Claude 你的 agent 说活儿干完了，测试却从没跑过。它锐利二十分钟，然后忘掉你一开始给的一条规则。你每个会话都重打同样的三条指令。你没法走开，因为总有另一个待批准的按钮等着你点。 一个更好的模型解决不了这些。所有这些都活在包在模型外面的那层软件里：它被告知什么、它保留什么、它被允许碰什么、以及谁来检查结果。那层外壳就是脚手架（harness）。你已经有一个了。唯一的问题是，有没有人设计过它。 什么是 Agent 脚手架 有六样东西隔在模型和活儿之间： 让它持续运转的循环、它能调用的工具、它记忆里保留什么、崩溃之后什么能活下来、它被允许碰什么、以及谁来决定活儿干完了。 其中一半是开箱就有的。你的供应商造了那个循环、内置工具和记忆处理，这些你能改的不多。另一半是你自己的：你的指令文件、你的测试、你的权限、你对「完成」的定义。这一半，无论你有没有想过它，它都存在。你在聊天里反复重打的每一条规则，都是它的一部分。 人们在 2026 年初开始把这层东西叫「脚手架」。在那之前它没有一个公认的名字，这多半就是它长期无人管理的原因。 真实用例 DoorDash 把他们的脚手架搭成了一个平台。每个 agent 跑在自己的即抛型虚拟机里，开机时仓库、工具和凭证已经就位。活儿本身写成 YAML playbook，把 agent 步骤和普通脚本步骤混在一起。任何触达内部系统的东西，都经过一个网关，它只发放某个 playbook 声明过的工具，并记录每一次调用。他们一个月跑了 130,000 个自动化任务，包括每周超过 25,000 次代码审查。 OpenAI 把他们的脚手架搭成了一个仓库。完全没有平台。他们把仓库本身当成脚手架：指令文件保持在约 100 行，作为一个真正的 docs 文件夹的目录；架构规则由自定义 linter 强制执行，而不是写成模型可以跳过的散文。三个工程师用这种方式在五个月里合并了大约 1,500 个 PR。 Anthropic 把他们的脚手架搭成了一种角色分工。三个 agent，各干各的活。一个把一句话变成规格。一个实现它。一个在浏览器里驱动那个做好的 App 并给它打分。他们只通过互相写文件来沟通。它管用，而且花了 6 小时和 $200，而没套脚手架的那次只用了 20 分钟和 $9。花二十多倍的价钱，换来好得多的结果——这是没人愿意明说的那个代价。 三种完全不同的形态。它们的共同点是：没有任何一样是开箱就有的。 六个决策 这才是回本的部分。每一条都很短：它是什么、具体做什么、值多少、以及什么时候可以跳过。 1. 循环，以及它停在哪里 你的脚手架把「你的任务」加上「到目前为止发生的一切」发给模型。模型要么回复一个运行工具的请求，要么回复一条最终消息。如果是工具请求，脚手架运行它，把结果粘到历史里，再把整包东西发回去。重复，直到模型不再要工具。这就是整个循环，市面上每一个产品都是这样。 供应商拥有那个内层循环。属于你的是它周围的一切：它停下来之后会发生什么，以及它会不会再次启动。 这样做： 在开始之前，用一句话写下你的停止规则。「完成意味着测试套件通过、App 能启动。」而不是「完成意味着 agent 说它完成了」——后者正是你现在默认拥有的。 决定一次坏的结束会发生什么。一次跑到一半停下的运行，要么带着一条「哪里失败了」的说明重启，要么冻结并等你。选一个。没有答案，就意味着 agent 会悄悄发明它自己的答案。 给它设一个硬上限。轮数，或者墙钟分钟数。一个已经在同一个文件上磨了四十遍的 agent，不会在第四十一遍就修好它，而且它会乐此不疲地继续花你的钱去试。 如果你无人值守地跑它，把每一轮都记录到一个你事后能读的文件里。你会需要它的，而从记忆里重建一个六小时的会话是不可能的。 有人手动过了一遍五十个已发布的 agent 循环。只有 74% 明确说了「什么算完成」，只有 32% 在两次运行之间保留了任何记忆。这是清单上最便宜的修复，也是最常被跳过的那个。 2. 它能看到的工具 模型看不到你的系统。它看到的是一个函数描述的菜单，而就它而言，那个菜单就是整个世界。关于那个菜单，有两件事值得你注意。 这样做： 别再预先加载所有工具。如果你连着好几个 MCP 服务器，它们每一个的工具描述都会在每一轮被塞进上下文，无论这个任务需不需要它们。修法是把工具作为文件放到磁盘上，让 agent 只打开它需要的那些。Anthropic 发布过一个做好的版本：150,000 个 token 降到 2,000。 重写你的错误信息。大多数工具失败时给出一句写给人类看的话：「invalid request」。这对模型什么都没说，于是它瞎猜，而且通常猜错。改返回结构：哪个字段错了、一个合法的值长什么样、以及下一步该试什么。Siemens 认真测量过这个，任务完成度跳了 37 到 40 个百分点，而每次成功花的 token 大约是原来的一半。 把菜单砍小。去看看你的 agent 现在能访问多少个工具。任何你一个月没见它用过的，都移除。两个名字容易混淆的工具，比缺一个工具更让你吃亏。 如果你在搭自定义工具，要当心：你如何命名和分组它们，会可测量地改变行为。前缀和后缀不是装饰。 如果你只用一个 agent、一个仓库、只用内置工具，那这个可以跳过。省 token 是真的，但那还不是你的瓶颈。 3. 记忆里保留什么 模型对任务的了解，都住在一个缓冲区里。当缓冲区填满，较旧的材料会被总结然后扔掉。你不挑什么被丢，模型也不会告诉你这件事发生了。 这样做： 别填满它。在一个百万 token 的模型上，干到 300,000 或 400,000 就停。过了那个点，失败不再看起来像「困惑」，而开始看起来像「粗心」——那种它会删掉一个本该放过的配置文件的那种粗心。 在你自己挑的点上、有目的地修剪。与其让自动压缩在任务中途触发，不如把活儿分成阶段：研究，然后一份书面文档，然后一个计划，然后实现。每个阶段在一个干净的窗口里开始，只带上一阶段的文档。你在阶段之间读那份文档。更慢，但可靠得多。 钉死规则。把事实和规则分开。事实可以被总结掉。规则不能：永远别碰生产、永远别提交密钥、这个 API 契约是固定的。把那些放进一个 agent 在每次重置后都会重读的文件里，并且在系统提示词里重复它们。双保险，是刻意的。 当它开始顺着你时，重启。如果模型连续接受了五个建议而没有回嘴，这个会话就完了。某个错的东西在早期进来了，之后的一切都把它当成既定事实。开一个新窗口。 一项研究测量了 agent 违反一条书面政策规则的频率，发现违规从「规则完整可见」时的零，上升到压缩后的 30%，再到最差模型上的 59%。而在规则熬过总结、保留下来的地方，违规保持在零。钉死它完全修复了问题。那篇论文是单一作者、未评审的，所以把这个数字当成一个强烈暗示，而不是事实。反正这个修复一下午就能做完。 4. 崩溃之后什么能活下来 你的 agent 会在任务中途死掉。窗口填满、进程崩溃、你合上笔记本。任何只活在对话里的东西都没了。 这样做。仓库里放四个文件，并告诉 agent 保持它们最新： SPEC.md。你在建什么。你写它，agent 永远不改它。这是阻止目标在一次长跑中漂移的东西。 PLAN.md。步骤，每一条带一个朴素的验收标准。不是「改进错误处理」。而是「对 /orders 的请求，如果缺 id 就返回 400 并带一条消息，且断言这一点的测试通过。」 PROGRESS.md。什么做完了、下一步是什么、试过什么又失败了。这是新 agent 第一个读的文件。 DECISIONS.md。只追加。每一个做过的选择和为什么。没有它，一个后来的会话会把两小时前你已经做出的决定重新拉出来再辩一遍。 然后让 agent 在每一个管用的改动之后提交。小提交，带真实的提交信息。回滚变成 git revert，审查变成读 diff，你还免费得到一份完整历史，而不是自己去搭一个检查点系统。 如果你在建一个有很多独立功能的东西，加第五个文件：一个纯 JSON 的功能清单，每一个标记为通过或失败。这是最便宜的进度追踪器，agent 自己能更新它。 不在文件里的，就不存在。 5. 它被允许碰什么 一个在你笔记本上跑的 agent，拥有你的 SSH 密钥、你的 VPN 会话，以及你登录的每一个 CLI。它不需要恶意，就能让这件事以坏结局收场。它只需要上下文里有一个被投毒的网页。 这样做： 两条边界，放在操作系统层面。限制它能写哪些目录，把它的网络访问路由过一个带「允许域名清单」的代理。在 OS 层做，而不是在 agent 内部做，这样它 spawn 出来的任何东西也被覆盖。一个 shell 出去跑脚本、脚本再 shell 出去跑 curl 的 agent，能逃过应用内的限制，却逃不过这一个。 别再相信批准提示。人们点掉其中的 93%。一个你总是点过去的提示，不是安全控制，是你给自己造的一个延迟。提示用在你真正会停下来的那少数几件事上，边界用在其余一切上。 如果好几个人对共享系统跑 agent，就在那些系统前面放一个网关。它只发放某个任务声明它需要的工具，并记录每一次调用。那份日志，就是让一次事故变得「可调查」而不是「神秘莫测」的东西。 永远别把长期凭证放进沙箱。短期 token，限定到一个任务。如果 agent 能读到一个密钥，就假设这个密钥已经躺在某个上下文窗口里了。 Anthropic 报告说，在内部加上恰当的沙箱后，权限提示减少了 84%。这才是真正的论点：它不只是更安全，还更不烦人，而这才让它真正留得下来。 6. 谁来说它干完了 写代码的那个 agent，是判断「这代码能不能用」的最差人选。它给自己打分，而且打得宽松。 这样做： 在一个单独的会话里审查。全新窗口，不记得它写过这个东西。同一个模型没问题。重要的是，它不带着那个产生 bug 的推理链。 让它真的把东西跑起来。对一个 web App，在一个真实浏览器里驱动它。对一个 CLI，执行那条命令。读一个 diff 然后宣布它正确，不是验证，是对同一个猜测的第二意见。 用你已经经历过的失败，搭一个 eval 集。二到五十个任务，起步就足够了。真实的，来自你的仓库，你亲眼看过 agent 搞错的那些。 每个任务跑三遍，按最差的那一遍打分。这比听起来重要。每次尝试 75% 的成功率，意味着三次全过只有 42% 的概率。agent 是非确定性的，一次绿灯运行几乎不告诉你任何东西。 当心那个自信的错误答案。agent 的标志性失败不是崩溃。而是撞上一个错误，然后流利地写一段「为什么这没关系」。在一项生产研究里，这些大约 70% 是被一个人注意到而抓出来的，而不是靠任何测试。在你的日志里，去 grep 那些靠近错误处理处、长得像「解释」的文本。 关于重试策略，没有任何已发布的数据。重试多少次、用什么退避、到底该重试还是干净重启。人人都有观点，没人有数字。如果你发现自己在调这个调了好几天，要知道你正站在真正没人测绘过的地带。 周末版 如果你只搭五样东西、别的都不搭，就搭这五样，按这个顺序。 一个指令文件，一百行以内。一个通往真正 docs 文件夹的目录，而不是一部百科全书。长指令文件会被略读，跟长邮件一模一样。 任何坏过两次的东西，变成一个 linter。不是一段客客气气的散文。是一条让构建失败的规则。当你看到一个真实失败时就加一条；当一个更好的模型已经让它变得多余时，就删掉它。 四个文件。Spec、plan、progress、decisions。加上每一个管用的改动之后一次提交。 钉死那些永远不能被总结掉的规则。安全、政策、硬性限制。 二十个任务，每个跑三遍，按最差的那一遍打分。 这之外的一切，都是优化。 结论 你没有「不拥有一个脚手架」的选项。你现在就有一个。它是攒出来的：每一个凌晨两点加的变通、每一条粘进配置又被忘掉的规则、每一次因为「点比读快」而被点掉的权限。里面的决策全都做过了。只是不是由你做的。 而且它不是免费的。Anthropic 自己那次套了脚手架的运行，成本是没有套的二十多倍。这才是你在开始之前真正要回答的问题：一个脚手架，在「你根本无法交出去的工作」上才划算，而在「你只是想省二十分钟」的工作上，永远不划算。 从停止规则和四个文件开始。两者都是一个下午。两者都能活过下一次模型发布——这比这清单上大多数东西都强。 Tags: # X # Claude # Guide Related articles 10 SEO backlink Claude automations for 61k AI mentions in 3 months Link building is trial and error. SEO AI Claude Automation