主题
2.11 Harness 工程与 Loop 工程：从单次问答到自主工业级闭环
发动机需要车身、转向和刹车才能成为可用的车，行驶时还要持续根据路况调整。模型周围的运行系统与任务循环可以分别用 Harness 和 Loop 来理解：前者提供工具、状态与执行约束，后者组织一步步行动及其反馈。
为什么单次模型调用还不够
在早期，大家以为只要提示词写得好，AI 就能无所不能。但到了工业落地阶段，工程师们发现：
- 光有聪明的大脑（模型）远远不够：如果没有隔离的沙箱、没有工具拦截网关、没有科学的评测基准，模型就会成为“不可控的黑盒”；
- 真实任务必须多步循环：解决一个真实系统的 Bug，往往需要 10~30 步“探索代码 ➔ 尝试修改 ➔ 运行报错 ➔ 自我反思 ➔ 再次测试”的闭环迭代。
深入拆解 Harness 工程（生产支架与考场）
Harness 的原意是“马鞍 / 挽具 / 固定支架”。在现代 AI 体系中分为两大方向：
1. 运行支架：Agent Harness（生产运行环境）
- 全封闭无菌手术室与专业外科工具台。
- 核心组件：
- 沙箱隔离（Sandbox）：通过 Docker 容器或轻量虚拟机，让 Agent 拥有独立的操作系统环境，通过限制文件、网络与进程访问减少影响范围；隔离效果取决于挂载、权限和具体配置；
- 安全护栏（Guardrails）：实时拦截高危操作（如泄露密码、向外发送垃圾邮件、违规删库）；
- 状态快照与回滚：随时记录系统的当前快照，发生问题时恢复已记录的内部状态；外部操作需要另行处理。
2. 评测支架：Eval Harness（可复现的评估环境）
- 国家级驾照封闭考场。
- 代表标杆 —— SWE-bench：
- 用于评估真实仓库问题修复能力的基准之一。
- 考试流程：Eval Harness 自动拉取真实的开源项目历史 Issue，启动干净容器，把问题丢给 Agent；
- Agent 在规定时间内自主翻看代码、改动文件；最后由 Eval Harness 自动运行隐藏的测试用例，依据对应版本的测试集合和判定规则，判断修复是否解决目标问题并保留相关行为。
深入拆解 Loop 工程（控制闭环与停止与恢复）
Loop 工程（循环工程） 专注于设计 Agent 的自我修正机制与生命周期控制：
常见的循环控制机制
| 安全机制 | 避免了什么恶性事故？ | 日常生活比喻 |
|---|---|---|
| 死循环检测 (Infinite Loop Guard) | AI 陷入“改错 ➔ 还原 ➔ 再改错 ➔ 再还原”的死胡同 | 扫地机器人卡在桌角时，连续碰撞 3 次自动倒车换方向 |
| Token 与成本预算熔断 | 后台任务失控，一夜之间烧光几千元 API 余额 | 手机设置单月流量封顶，超标立刻自动断网保护钱包 |
| 最大步数限制 (Max Iterations) | 任务漫无目的，一直卡在死循环里空转 | 考场敲钟交卷，哪怕没做完也必须立刻停笔输出总结 |
| 状态快照回滚 (Checkpoint Rollback) | 发现前 10 步方向全错了，越改越烂 | 玩单机游戏时一键读取 10 分钟前的存盘点推倒重来 |
一次失败，需要由哪部分负责
假设智能体连续三次运行同一条失败命令。工具层负责返回真实错误，状态层记录已经尝试过什么，循环控制负责判断是否还有新依据。若没有新的输入或修改，仅重复执行往往没有意义。
| 责任 | 应保留的信息 | 避免的问题 |
|---|---|---|
| 工具执行 | 命令、工作目录、退出状态 | 不知道实际执行了什么 |
| 状态管理 | 进度、修改文件和待办事项 | 恢复时重复劳动 |
| 循环控制 | 剩余预算、失败次数、停止条件 | 无限制重试 |
| 评估 | 固定输入、预期结果、环境版本 | 同一成果无法复查 |
“Loop 工程”在这里是一种描述任务循环设计的用语，并非所有框架统一定义的独立层。它与运行支架有重叠，重点在于行动如何继续、失败如何处理、何时停止。
快照为什么不能撤销所有事情
游戏读档可以恢复游戏内状态，但不能让已经寄出的包裹自动回来。同样，恢复会话或工作目录，并不能撤回已发送的邮件、已经完成的支付或外部数据库中的写入。
因此，要区分内部状态恢复和外部操作补偿。查询类操作通常便于重试；写入类操作需要请求标识、重复检查或对应撤销步骤。恢复后重新执行任务时，要先确认哪些动作已经发生。
评测结果怎样才可比较
比较两个智能体时，除了模型名称，还应记录工具集合、任务输入、运行环境、允许时间、最大调用次数和人工介入方式。一个系统允许多次尝试，另一个只允许一次，两者的最终通过率就不能直接等同。
对于自己的项目，可以先固定几个常见任务：修复一个已知错误、添加一个小功能、解释一条调用路径。保留原始版本和验收方法，再记录每次运行结果。这样能看到更换模型或工具后到底改善了什么，而不是只凭某一次演示印象判断。
一条有用的执行记录
日志不必保存所有冗长内容，但应能追溯“为什么执行这一步、输入是什么、得到什么结果、后续怎样调整”。遇到失败时，这些信息比一句“智能体出错了”更有用。
例如“测试未通过”还应附测试命令、失败用例、错误摘要和相关文件位置；“没有运行测试”则应说明环境缺什么。把这两种状态区分开，才能安排下一步工作。