第 6 章 · Harness：让 Agent 持续、可控地运行
运行层，而不只是安全带
Harness 在 Agent 工程中通常指模型周围的运行与编排层。它把模型调用、工具执行、上下文、状态和控制逻辑组织成一个可持续运行的系统。不同团队对边界的划分并不完全一致，它不是单一产品或统一协议。
“工作台和安全带”只覆盖其中一部分。现代 Harness 还要回答：任务运行到哪了？模型下一次需要哪些信息？工具失败怎样恢复？什么时候应该停止？
六类核心职责
| 职责 | 具体问题 | 用户能观察到的表现 |
|---|---|---|
| 运行循环 | 何时调用模型、执行行动、检查结束条件 | 持续执行多步任务 |
| 上下文组织 | 如何选择指令、文件、检索结果和历史摘要 | 长任务中的摘要、引用与材料加载 |
| 工具路由与控制 | 请求交给谁执行，参数和权限是否合法 | 调用记录、批准提示、拒绝原因 |
| 状态与恢复 | 怎样保存进度、处理超时和中断 | 恢复任务、异常清单、检查点 |
| 预算与调度 | 限制调用次数、耗时和费用 | 到达限额后停止或请求调整 |
| 可观察性与评估 | 怎样证明做过什么，发现质量退化 | 日志、轨迹、测试和产物核验 |
并非每个产品都提供所有功能；多 Agent 协调、长期记忆也不是必需项。通常由模型提出下一步，Harness 根据策略放行、路由或拒绝；固定流程也可以直接指定工具。
Harness、框架、沙箱、界面分别是什么
- 框架/SDK：帮助开发者实现循环、工具和状态的库。
- Harness：实际运行这些机制的系统层，可以自建，也可以托管。
- 执行环境/沙箱：命令、脚本和文件操作发生的地方，提供相应隔离。
- 产品界面：用户交代任务、查看结果和管理设置的入口。
一个 IDE 或助手通常包含 Harness，但不能把整个产品简单等同于它。作为具体实现例子，OpenAI 文档把 Harness、执行环境和应用服务器明确区分；这不意味着所有产品都采用同一架构。官方架构说明
为什么“让它自己检查”还不够
设想 AI 把 9 月销售额写成 10 月，再自己读一遍并说“没有问题”。若检查仍依赖同一份错误摘要，循环再多次也未必纠正。
更可靠的做法是把检查落实到外部证据：
- 原始 CSV 与汇总结果逐项比对；
- 由程序校验金额和行数；
- 重新打开导出文件，检查实际内容；
- 给遗漏、错误和未完成事项保留状态，不把它们隐藏在最终回复中。
这也是 Harness engineering 的工作：围绕真实失败样例调整上下文、工具设计、验证和恢复流程，再看任务表现是否改善，而不只是换一个更大的模型。
安全来自实际配置
“删除前询问”是一种交互策略，不等于底层禁止删除。真正的边界可能由操作系统权限、沙箱、网络策略和业务 API 权限共同落实。自动批准范围不同，风险也不同；选择知名产品不能替代检查设置。
外部网页和文件仍是不可信输入。Skill 中写了“不要泄露”也不能替代凭据隔离。长期运行还应考虑重复执行、失效登录、工具版本变化与费用上限。
普通用户的检查方法
给它一个可恢复的练习目录，观察是否能说明当前进度、展示操作结果、保留失败信息，以及中断后能否正确续接。只授权任务需要的范围。对一次性普通任务不必搭建复杂平台。
自测： 把“绝不能删除文件”写在提示词里，和只授予读取权限有什么区别？前者是行为指令，后者是系统执行边界。
延伸阅读：Harness 与执行环境。