Agent 为什么“会做却做不完”：Harness 的六个设计决定
一个好理解的比喻
模型像发动机，Harness（运行框架）像整辆车：它规定方向盘、刹车、仪表盘、道路边界和到达终点的判定。
一、Harness 到底是什么
它不是一段更长的系统提示词，而是围绕智能体建立的一整套运行环境：任务循环、工具接口、上下文与记忆、权限控制、故障恢复以及评估机制。模型决定“这一步想做什么”，Harness 决定“它能不能安全、持续、可验证地做下去”。
二、六个必须明确的设计决定
决定 | 失控信号 | 最低限度的保护 |
|---|---|---|
何时停止 | 反复修改、成本持续上升 | 步数、时间、费用和失败次数上限 |
能看见哪些工具 | 工具太多、选错动作 | 按任务提供最小工具集合 |
保留哪些记忆 | 忘记约束或被旧信息干扰 | 分开目标、事实、进度与决策 |
崩溃后如何恢复 | 重启后重复执行或丢失进度 | 检查点、幂等操作和恢复日志 |
可以触碰什么 | 误删、越权、外发敏感信息 | 最小权限；不可逆动作单独确认 |
怎样算完成 | 只声称成功，没有证据 | 可检查的验收标准与失败出口 |
三、一个周末能搭起来的最小版本
写一页任务说明：目标、范围、不能做什么、完成证据。
准备四份短文件：spec（规格）、plan（计划）、progress（进度）、decisions（关键决策）。
设置停止预算：最多尝试次数、最长时间和最高成本。
把删除、付款、发布和对外发送等动作设为必须确认。
每完成一个可工作的阶段就保存检查点，并记录如何恢复。
结束前运行验证；验证不过就明确报告未完成。
四、先写“完成契约”
要素 | 应该写清楚什么 |
|---|---|
输出 | 最终需要交付的文件、状态或结果 |
证据 | 测试、日志、截图、引用或人工复核点 |
边界 | 禁止触碰的系统、数据和外部对象 |
退出 | 哪些条件下应该停止并请求帮助 |
回滚 | 出错后如何恢复到已知安全状态 |
五、评估时看最坏情况，而不只看演示
挑选约 20 个有代表性的真实任务，每个重复运行三次。除了成功率，还要记录最差结果、耗时、成本、失败后是否可恢复，以及是否出现越权或不可逆动作。平均表现很漂亮，也可能掩盖一次代价极高的失败。
不要为了“更自主”而扩大授权
Harness 只有在它让原本无法稳定委派的任务变得可控时才值得。每增加一项工具或权限，都要同时增加对应的限制、记录和恢复手段。
最小检查清单
停止条件能被程序判断，而不是只写“做完为止”。
不可逆动作需要额外确认。
中断后不会重复执行有副作用的步骤。
完成声明附带可检查的证据。