Harness Engineering 关注模型外围的执行系统：给代理什么工具、如何管理上下文、如何检查结果，以及失败后如何恢复。企业已经能让 AI 生成内容，却常常无法稳定完成整项工作，问题就可能出在这套执行系统，而不是提示词不够长。
为什么模型能力强，业务流程仍然会失败？
模型能给出合理建议，与系统能把任务完整做完，是两个不同的验收对象。一个订单助手可能正确理解需求，却读取了过期价格、漏掉必填字段，或在生成文件后忘记保存。单看最后一段聊天文本，很难发现这些问题。
GitHub 在 2026 年 9 月的术语解读中，将 harness 解释为围绕模型工作的工具、权限、记忆、上下文及编排等系统。这个解释帮助团队把问题拆开：究竟是知识不足、工具不可用、流程状态丢失，还是验收标准缺失。
一套最小 Harness 应包含哪些能力？
先明确任务入口和完成条件，再连接必要的数据与工具，最后提供结果校验和失败出口。对于生成报价草稿的代理，完成条件可以是字段齐全、金额计算一致、文件保存成功，并清楚标出需要业务人员确认的条款。
工具是否调用成功只是中间状态。数据库返回成功，并不说明查询到了正确客户；文件接口返回地址，也不说明内容符合要求。因此执行系统应同时保存动作结果和业务检查结果，让问题能够追到具体一步。
如何从一个真实工作任务开始设计？
假设要把客户询价整理为可审核的报价草稿。先记录原始询价、产品主数据和价格生效日期，要求代理先关联业务对象，再生成草稿。找不到产品编码时，应进入待补充状态，而不是根据相似名称默默选择。
随后定义检查项：产品数量能否对应询价、币种是否一致、运费是否单列、有效期是否存在。例子中的这些要求来自假设业务流程，实际项目必须由使用者确认。Harness 的价值就在于把这些条件变成每次都会执行的检查。
检查、重试和恢复怎样衔接？
检查应尽量靠近动作发生的位置。文件生成后立即检查可打开性，金额计算后立即做规则校验，外部请求失败后保存失败原因。等到任务全部结束才笼统问一句“请自查”，通常难以判断哪一步需要重做。
重试只适用于可能暂时失败、并且重复执行不会产生错误副作用的动作。读取服务超时可以有限重试；创建订单后没有收到确认，则应先查询订单是否已创建。恢复机制需要识别已经完成的步骤，避免把一次网络故障变成重复业务记录。
记忆和上下文为什么也是工程问题？
长任务会积累大量日志和中间材料。若把全部内容持续堆进模型上下文，关键信息反而可能被噪声掩盖。执行系统可以保留稳定的任务目标、已确认事实和结果索引，让代理按需读取原文，而不是重复解释全部历史。
记忆也需要标注来源和适用范围。某个客户上次使用人民币结算，不代表这次询价的币种一定相同。业务系统中的当前字段应优先于模糊的历史印象，过期记忆需要能被发现和纠正。
如何衡量 Harness 是否有改进？
固定一组真实任务，比较修改前后的任务通过情况、人工补救次数、执行时间与单次完成成本。不要只看模型调用次数：少调用一次但交付失败，可能比多做一轮检查更昂贵。
结果评估还应区分失败类型。若主要问题来自主数据错误，应先治理数据；若是工具参数经常不完整，应改工具接口或样例；若代理提前结束，则检查完成条件与状态保存。针对失败原因修改，才能避免规则越加越多却没有效果。
小团队应该做到什么程度？
先用现有工作流、数据库、日志和文件存储串起一个闭环，不必先建设通用代理平台。把正常任务与少量关键异常跑通，让实际使用者能看见输入、结果与待处理事项，就已经比无法追踪的聊天自动化更可维护。
随着模型和工具变化，旧规则也需要重新验证。曾经用于补救模型弱点的限制，后来可能只增加延迟和成本。Harness Engineering 是持续维护执行条件的工作，不是一次性写出越复杂越好的代理说明书。
一次失败怎样变成下一次的改进依据？
为失败记录保存任务标识、输入版本、最后成功步骤和具体检查结果。例如报价草稿金额不一致，应能看到哪些行参与计算、使用哪个税率、舍入发生在哪里，而不是只留下“模型输出有误”。这样的证据可以直接帮助判断该修数据、工具还是生成规则。
修复后把同一案例重新执行，并保留先前失败和现在通过的结果。如果规则只解决当前样例，却破坏其他正常任务，应重新调整。对小团队而言，每次从真实失败中增加一个可复用检查，比同时设计大量未遇到过的异常分支更容易维护。还应给规则注明业务负责人，避免后来系统升级时只剩一段没人理解的限制。
官方资料与核验范围
本文资料核验日期为 2026 年 10 月 17 日。下列日期指对应公告或工程文章的发布日期，不代表概念首次出现；产品可用范围、版本与接入条件请以官方当前说明为准。文中业务案例为帮助理解而设计的假设示例，不是实测成绩或客户交付承诺。