接上工具，不等于搭好了 Harness

AI AGENT 工程范式进化史 • 第四站 • HARNESS ENGINEERINGDemo 里已经跑通到了生产却不敢让它动手。​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 元权限阈值、工具名和故障过程均为示意不是公开实验或通用餐饮规则正文没有引用准确率或效率提升数字。