AI AGENT 工程范式进化史 • 第四站 • HARNESS ENGINEERING
Demo 里已经跑通，到了生产却不敢让它动手。
12 号桌点了一份 38 元的番茄炒蛋，备注写得很清楚：孩子吃，不要放葱。 菜端上来，葱花还是铺了一层。
第三站解决了信息问题：系统拿到了桌号、原始备注、出餐状态和餐厅的客诉规则，因此判断也没错——重做一份不放葱的，并从账单里免掉这道菜。
可真正难的地方，现在才开始。谁能改账单？重做指令发到哪个档口？原菜怎样记损耗？如果免单成功、后厨却没收到重做单，系统下一步应该做什么？
01 / 从上一站往前一步
Context 把信息递到手里，Harness 才让动作落到店里。
上一站我们关心的是：12 号桌说的“刚才那份”到底是哪道菜，原备注是什么，餐厅此刻执行哪条客诉规则。信息装配正确，Agent 才能做出靠谱判断。
但“知道该重做”与“真的完成重做”之间，还隔着收银系统、后厨出餐屏、库存、跑菜员和经理审批。Context 决定它此刻看见什么；Harness 决定它能在哪里、拿什么、按什么规矩行动。
02 / 先看真实现场
一句“重做并免单”，要穿过四套系统。
在演示环境里，我们可以做一个叫 handle_complaint 的按钮，点击以后直接返回成功。但餐馆里没有这样一只万能按钮。一个决定至少要拆成四个真实动作。
| 系统 | 需要完成的动作 | 最怕出现的情况 |
|---|---|---|
| 收银 POS | 从 12 号桌账单免去 38 元 | 重复免单或越权改价 |
| 后厨出餐屏 KDS | 向热菜档重新发单，并保留“不放葱” | 备注丢失或重复出菜 |
| 库存 / 损耗 | 记录原菜退回或报损 | 账面库存与实际不一致 |
| 跑菜任务 | 撤回原菜，追踪新菜送达 | 旧任务未关，新菜无人送 |
Demo 证明的是“模型会选工具”；生产要证明的是：多个真实动作能在正确权限里完成，结果可以核对，中途失败也不会把现场越弄越乱。
03 / Harness 到底搭在哪里
它不是工具架，而是 Agent 的整套工作现场。
2026 年 2 月，Mitchell Hashimoto 与 OpenAI 的文章先后使用 Harness Engineering 这一说法，讨论如何把说明、工具、运行环境、验证、隔离和可观察性一起围在 Agent 周围。这个词还不是一套封闭的行业标准，但它指出了一个很实用的工程边界：模型外面那层决定行动能否可靠发生的系统。
对这家餐馆来说，Harness 不是再给 Agent 多接几个接口，而是把六件事同时说清楚：工具怎么调用、任务在哪里运行、用谁的身份、能做多大动作、怎样确认完成、出错后停在哪里。
- 工具契约： 字段、前置条件、回执和错误类型都能被机器判断；
- 受控环境： 每桌任务的状态、凭证、超时和可访问系统彼此隔离；
- 身份与权限： 查单、改价、免单、作废和付款分别授权；
- 执行记录： 一次处理经过哪些系统、拿到什么回执，可以沿同一任务追踪；
- 结果验证： 不只看接口返回，还要核对 POS、KDS 与桌台状态；
- 失败恢复： 重复调用、部分成功和人工接管都有明确出口。
04 / 先别造万能按钮
一个好工具，应该窄到不容易做错。
如果工具只叫“处理客诉”，Agent 很难知道它究竟改了什么。更稳妥的做法，是把真实动作拆成边界清楚的小工具，例如 void_bill_item、refire_dish、record_waste 和 close_runner_task。
{
"table_id": "T12",
"order_item_id": "ITEM-07",
"instruction": "不要放葱",
"reason": "制作未遵循原备注",
"idempotency_key": "T12-ITEM07-REFIRE-01"
}
idempotency_key 相当于这次重做的唯一号码。网络超时后再次提交，后厨系统应该返回同一张重做单，而不是让厨师再炒一份。工具输出也不能只有 success，还要返回新单号、档口、预计时间和最终状态，系统才能继续核对。
工具越像一句模糊指令，风险越容易藏在里面；工具越像一份可检查的动作契约，Agent 才越知道自己做成了什么。
05 / 把钥匙一把把分开
会查单，不等于能改账；能免小单，不等于能改所有账。
餐馆不会因为一个服务员会用收银机，就把后台最高权限交给他。Agent 也需要按动作分级，而不是一次拿到整套管理员账号。
| 动作 | 系统默认 | 示例放行规则 |
|---|---|---|
| 查询桌台与菜品状态 | 只读 | 仅当前门店、当前班次 |
| 发送重做单 | 允许 | 必须引用原菜品和原备注 |
| 免去不超过 50 元的单品 | 限额执行 | 客诉证据完整并留下回执 |
| 整桌免单、现金退款或作废付款 | 暂停 | 经理人工确认 |
人工审批不是“Agent 失败了”。当动作金额更高、不可逆，或者现场证据互相矛盾时，停下来请经理确认，本来就应该是流程的一部分。
06 / 真正棘手的不是报错
最危险的是：一半已经做成。
假设 POS 已经从账单免掉 38 元，KDS 却在发送重做单时超时。此时不能把整套流程从头再跑一遍，否则账单可能再次减 38 元；也不能把任务简单标成失败，因为顾客的账单确实已经改变。
可靠的 Harness 会把每一步的状态和回执留住：先确认 POS 的免单凭证，再查询 KDS 是否已经生成重做单。没有就补发；已经有就继续追踪。恢复不是回到开头，而是从最后一个已确认事实继续。
失败不可怕，状态不明才可怕。Harness 的价值，是让系统知道哪里完成了、哪里没完成、下一步允许做什么。
07 / 给动作留下可查的现场
一句“处理好了”，必须能对得上四张回执。
对话里只留下最终回复远远不够。一次客诉处理至少要串起：使用了哪版规则、以什么身份执行、调用了哪些工具、每个系统返回什么、顾客桌台最终处于什么状态。
这里要记录的是业务依据、工具事件和结果状态，不是把模型的隐含推理全部倾倒出来。手机号、支付信息等敏感字段也要脱敏。可观察性不是“什么都存”，而是留下定位、恢复、审计真正需要的证据。
08 / 把 12 号桌真正处理完
顾客看到的是一份新菜，系统背后完成的是一次受控执行。
- 确认原菜仍在桌台账单中，且此前没有处理过同一客诉；
- 用客诉事件号生成稳定的免单键与重做键；
- 从 POS 免去该单品 38 元，并保存凭证；
- 向热菜档发送带原备注的重做单，确认 KDS 返回新单号；
- 记录原菜损耗，关闭旧跑菜任务，创建新菜送达任务；
- 核对账单金额、新菜状态与桌台任务，再向服务员报告处理结果。
如果任何一步无法确认，系统停在可恢复的位置，并把已经完成的动作和待处理事项一起交给人，而不是只说一句“执行失败”。
09 / 上线前，先故意把它弄坏
只测顺利完成，永远测不出 Harness。
在真正开放自动执行前，团队应该主动模拟：收银权限过期、重做单重复提交、KDS 超时、菜品已经售罄、经理拒绝审批、POS 与桌台状态不一致。
可以先让 Agent 只查状态、生成处理草稿；等日志和验证稳定后，再开放低风险、可逆、容易核对的动作。每扩大一层权限，都要同时补上失败出口。
最小可用 Harness：
一组边界清楚的工具、一套最小权限、一次可追踪的执行、一个结果校验，以及一条失败后的安全出口。
10 / 下一站从哪里开始
它已经能看见错误，但还不会靠反馈把下一次做得更好。
餐馆现在能把决定安全地落到收银、后厨和跑菜现场，也能发现番茄炒蛋仍然带葱、出餐超时或顾客依旧不满意。可“发现问题”还不等于“知道下一轮该改什么”。
第四站只带走一句:
Harness 不是工具架，而是 Agent 真正工作的受控现场。下一站，我们让执行结果回到系统里，成为下一轮行动的依据。
它已经能发现问题，
下一轮为什么还会照旧重来？
因为留下执行结果，还不等于把结果变成有效反馈。
【进入第五站 · 没有反馈的 Loop，只是更贵的重试 →】
关于这个系列
《AI Agent 工程范式进化史》——跟着同一家餐馆连续升级，一站一站讲透 AI Agent 工程的演进：
Prompt → Chain → Context → Harness → Loop → Graph → 还会有的…
参考来源：
[1] Mitchell Hashimoto, My AI Adoption Journey, 2026-02-05。正文用它说明“Harness Engineering”这一称呼及“把重复错误转成说明或程序化验证”的原始表述。
[2] Ryan Lopopolo / OpenAI, Harness engineering: leveraging Codex in an agent-first world, 2026-02-11。正文用它说明工具、环境、知识组织、隔离运行、日志、指标和机器可执行约束共同支撑 Agent 工作。
口径说明：
两篇来源主要讨论编程 Agent。本文把相关工程原则映射到餐馆的收银、出餐、损耗和跑菜流程，是原创教学案例，不代表行业存在统一的 Harness 标准。12 号桌、38 元番茄炒蛋、50 元权限阈值、工具名和故障过程均为示意，不是公开实验或通用餐饮规则；正文没有引用准确率或效率提升数字。
