Agent Harness 真正解决的不是“怎样让模型更聪明”，而是“怎样把一次依赖模型临场表现的对话，变成一套能持续、能恢复、能验收的工作系统”。六个决定最终都指向同一件事：把控制权从模型手里拿出来，交给循环、文件、权限和独立验收机制。
模型看到工具说明，调用工具，读取结果，再决定下一步。这段 inner loop 通常由模型厂商提供。真正决定任务能不能做完的，却是外层那些看起来很工程化、实际上经常被临时拼凑出来的部分：什么时候停，失败后怎么办，规则放在哪里，崩溃后靠什么恢复，进程能碰到哪些资源，以及谁来判断结果真的合格。
这也是为什么换更强的模型经常没有想象中有效。模型可以更会规划，却不会自己发明一个可靠的完成标准；可以少犯一部分错误，却无法保证压缩上下文后仍记得所有硬规则；可以写出更完整的代码，却不能成为自己代码最可信的验收者。Harness 要处理的正是这些模型能力之外的工程责任。
最直接的变化，是“完成”不再由模型宣布。
Agent 停止循环时，Harness 首先检查可验证的条件，例如测试是否通过、应用能否启动。运行中途结束，要带着失败信息重启，还是冻结等待人工处理，也必须提前决定。再加一道轮数或时间上限，避免模型在同一处反复消耗。无人值守时，每一轮都留下记录，失败后才有东西可以追查。
这相当于把过去每次开新会话都要重复交代的内容，编进任务生命周期。任务不是“模型最后回复了一段话”，而是一次有起点、有状态、有终止条件、有恢复路径的运行。
工具层解决的是另一个常见浪费：模型每轮都会看到整套工具菜单，即使当前任务只需要其中一项。把工具说明放进文件，需要时再读取，可以让上下文只包含当前真正可用的能力。Anthropic 的官方工程文章给过一个可核实的工作流案例：传统逐个加载工具约消耗 150,000 tokens，改成按需读取工具定义、让中间结果绕过模型上下文后，约降到 2,000 tokens。
工具少一点只是第一步，错误信息能不能指导下一步同样重要。“invalid request”只适合告诉人哪里失败了，不能告诉模型下一次调用该改什么。包含错误字段、合法值范围和可执行建议的结构化错误，才可能把猜测变成修复。
但 Harness 的重心继续向任务外部移动，因为模型上下文本身不适合承担长期状态。
研究、方案、实现、验收如果都挤在同一个窗口里，迟早会碰到上下文压缩。事实可以被总结，规则却不应该跟着被总结；“不能碰生产环境”“不能提交密钥”“这个 API 契约不能改”，一旦只剩摘要里的近似版本，模型表面上仍然记得，实际上已经换成了另一套约束。
更稳的结构是人为划分阶段：研究结束后写文档，方案阶段只读文档并形成计划，实现阶段再依据计划工作。每个阶段都留一份短而明确的产物，必要时重新开启干净窗口。这样会牺牲一点连续对话带来的顺滑感，但能降低长任务中目标漂移和规则遗忘的风险。
这里也有一项需要保留折扣的研究：上下文压缩后，规则违反率被报告为从 0% 上升到 30%，最差模型达到 59%；规则被单独固定后，违反率又回到 0%。不过论文由单一作者完成、未经评审，所以这些数字只能作为强提示，不能当成普遍定律。无论数字是否成立，把硬规则移出可压缩历史，仍是成本很低的防御。
我做过一个网页自动化工具，由 Chrome 插件、Electron 客户端、任务执行器和 AI 服务器组成，工作方式是录制、编辑和执行自动化流程。它和 Agent Harness 解决的是同一类工程问题：怎样让浏览器里的动作重复执行，而不是每次都靠人临场操作。
两类方案的分界在“决策权放在哪里”。录制流程把路径事先固化，适合步骤明确、需要重复执行的任务；Agent Harness 把每一步判断交给模型，再通过停止条件、测试和权限边界约束它，适合路径无法提前写死、需要根据现场变化调整的任务。
如果把两者接起来，边界会更清楚：先走已验证的固定流程，页面结构变化导致步骤失败时，再让模型接管异常分支；模型处理完之后，结果仍交给原来的验收规则。这样既不必让每个成功动作都付一次模型判断成本，也不必在页面变化后从头重写整套自动化。
状态也需要离开聊天窗口，才能跨崩溃和跨会话保存。SPEC.md 固定目标，PLAN.md 保存带验收条件的步骤，PROGRESS.md 记录完成、待办和失败尝试，DECISIONS.md 追加关键选择及其原因。每次有效修改后提交，让恢复、回滚和审查都借助已有的 Git 历史完成。
这四类文件分别回答目标、行动、状态和历史。它们不是让 Agent 拥有更好的“长期记忆”，而是把原本只存在于对话中的信息变成可以交接的工作材料。新 agent 先读进度，旧 agent 留下的上下文丢失，也不会把任务整体带回起点。
权限则必须放在模型和聊天界面之外。目录写入范围、网络允许访问的域名、凭据有效期，都应该在操作系统层或统一网关层限制。模型自己声称“不会访问某处”不构成安全边界，因为它调用的脚本还可以继续拉起其他进程。多人或多个任务访问共享系统时，由网关按任务授权工具并记录调用，后续调查才有完整证据。
提示框也无法替代这些边界。频繁出现、又被习惯性点过的审批会变成等待时间，而不是安全控制。短生命周期、按任务授权的凭据，比把长期密钥放进沙箱更可靠。Anthropic 官方材料提到，适当的沙箱机制在其内部减少了权限提示；这里真正可复用的不是某个百分比，而是把“是否允许”从人的即时判断改成系统的预先约束。
最后，验收必须离开生产代码的上下文。
写代码的 agent 适合提出方案，不适合独自证明方案正确。换一个没有上一轮推理记忆的会话来审查，实际运行 Web 应用或 CLI，再从已经发生过的失败中建立 eval 集，比让 agent 给自己写一段“看起来没问题”的总结可靠。
重复运行也不能省略。单次成功只说明这一次路径通过了，不能说明 agent 找到了稳定解法。每次都通过之后，还要看最差的一次，因为非确定性执行中的偶然成功会掩盖不稳定。另一个值得检查的信号，是错误附近那种解释腔很强的文字：执行已经失败，agent 却写出了一段流畅理由，说明这类内容。检索错误处理附近的日志，比只看最终状态更容易发现它。
因此，Harness 的最小形态并不是一个复杂框架。先写一句停止规则，再建立规格、计划、进度、决策四个文件；每次有效修改提交；把不可压缩的规则单独固定；用真实失败建立少量任务，多次运行并按最差结果验收。后面再逐步加入工具裁剪、权限网关、沙箱和长期运行能力。
这套设计最适合那些原本无法完全交给人的工作，例如持续软件研发、内部系统操作、跨工具的数据整理和需要反复验证的网页任务。它不适合拿来把本来几分钟就能完成的小事包装成自主代理。Anthropic 的案例里，带 Harness 的运行成本超过未带 Harness 的运行二十倍以上，文章把这个结果直接称为厂商通常不会主动宣传的取舍。Harness 改变的是交付范围和可靠性，不是让每个任务都变得更便宜。
真正值得继续问的是：Harness 能不能记录一次成功的模型决策路径，并在后续运行中优先复用，只有遇到异常才重新交给模型判断？如果可以，它就能把模型探索与固定流程结合成一条连续工作链；如果不能，Harness 仍然更像一套约束和恢复框架，而不是会积累经验的自主系统。