别把 Agent 做成聊天框：一次鲜食备货的 Harness 能力与技术设计
门店每天晚上最怕的一件事，不是“要不要用 AI”。
而是第二天早高峰前，三明治、沙拉、甜点到底备多少。
备少了，顾客买不到。备多了，当天卖不完，第二天就变成损耗。
我们先看一个连锁咖啡品牌的鲜食备货场景：系统要根据历史销量、当前存量、临期损耗、天气、商圈活动和配送窗口，生成第二天的备货建议。
这个场景看起来简单。
店长要看历史销量、当前存量、临期损耗、天气、商圈活动和配送窗口。总部要控制浪费率，也要避免早高峰断货。
如果你把它做成一个聊天框，让店长问一句“明天三明治备多少”，模型回一段建议，这不是业务 Agent。
最多是一个会解释业务的助手。
真正的难点是： 这个系统能不能把业务事实收进来，把工具按顺序跑起来，把输出变成结构化对象，把规则校验做实，把失败路径也设计成正式流程。
这篇文章会尽量用业务语言解释技术设计。
技术词会保留，因为真正落地时绕不开它们。但每个技术词前面，都会先讲它解决的业务问题。
一、先定“交付物”，不要先定聊天入口
业务 Agent 的第一个设计动作，不是画聊天框。
而是定义它最后要交付什么东西。
在鲜食备货场景里，这个东西不是“回答”，而是一张正式的备货计划单。
技术上可以把它叫 ReplenishmentPlan，你也可以先把它理解成“系统能保存、能审批、能追溯的一张业务单据”。
它至少要包含五类信息：
计划头：门店、日期、生成时间、数据快照版本、策略版本。
明细行：SKU、时段、建议数量、建议原因、证据来源。
风险标记：断货风险、临期风险、配送冲突、异常波动。
审批状态：自动通过、需要店长确认、需要区域经理确认。
审计轨迹：用了哪些输入、调用了哪些工具、哪个校验器放行。
这一步一旦定清楚，产品和技术的争论会少很多。
因为大家不再争“AI 要不要会聊天”，而是在争这个对象能不能进入业务流程。
能保存，能编辑，能回滚，能导出，能被后续系统消费，才叫能力闭环。
二、把能力拆成四段，模型只负责其中一段
把整个备货 Agent 拆开看，它不是一个大模型动作。
它至少是四段能力的组合。
第一段是收集事实。 系统读取销量、存量、配送、天气、活动和门店状态，形成一份“事实包”。
第二段是生成草案。 系统基于规则、历史模式和模型判断，生成一版或多版备货草案。
第三段是检查约束。 系统检查保质期、配送截止、最小陈列、异常波动、审批阈值。
第四段是落到业务。 系统把通过检查的方案写成草稿、推给人确认，或进入后续订货流程。
模型可以参与候选生成和解释。
但事实采集、硬规则校验、权限判断、发布动作，都不应该交给模型自由发挥。
这就是能力设计里的边界感：AI 可以参与判断，但不能替代流程边界。
三、每个工具都要有说明书，不能只写“查询数据”
很多 Agent 应用会输在工具设计上。
工具名字看起来都有了：查销量、查库存、算建议、做校验。
但开发一问参数、返回值、超时、错误码、幂等性，就发现全是口头描述。
这就是“工具契约”。
你可以把它理解成工具的使用说明书：谁能用，怎么用，用完会返回什么，出错时怎么告诉系统。
一份可运行的工具说明书，至少要说清六件事：
输入参数：storeId、businessDate、skuGroup、timeWindow 这些字段谁必填。
返回结构：返回明细、聚合值、置信标记，还是只返回摘要。
数据版本：本次运行读的是哪个快照，不允许前后工具读不同口径。
错误语义：缺数据、无权限、接口超时、业务无结果，要分开返回。
动作边界：查询工具只读，发布工具才允许写入，重复点击不能生成两份订单。
超时策略：工具慢了是重试、跳过、降级，还是直接进入人工确认。
这也是为什么我说，数据不是页面装饰，而是 Agent 的工具。
工具不是把数据库函数暴露给模型。
工具是带契约、带权限、带错误语义的业务能力接口。
四、Harness 的最小架构，是五个“控制台”
Harness 这个词听起来技术味很重。
你可以先把它理解成：让 AI 按业务规矩工作的控制台。
如果要让开发团队真正接得住，我会把这个控制台拆成五层。
第一层：流程指挥台（Orchestrator）。 决定本次运行走到哪一步，是否继续、暂停、重试或降级。
第二层：工具登记表（Tool Registry）。 登记所有可调用工具，管理工具字段、权限、超时和错误码。
第三层：规则引擎（Policy Engine）。 保存业务规则，例如保质期、配送截止、审批阈值和门店特殊策略。
第四层：质检员（Validator）。 检查输入、工具返回、模型输出和最终业务单据，失败时给出机器能读懂的原因。
第五层：运行记录本（Trace Store）。 记录每次运行编号、工具调用编号、数据版本、规则版本、提示词版本、模型版本和每一步耗时。
这五层不是为了显得复杂。
它们分别解决五个工程问题：流程控制、能力调用、规则治理、结果可信、事后复盘。
没有这五层，prompt 写得再好，也很难进入生产系统。
五、先画“流程站点”，再谈对话体验
技术上，我不建议从“多轮对话”开始设计。
先把系统会经过哪些站点画出来。
开发会把它叫状态机。业务可以把它理解成一张流程路线图。
一个最小闭环可以这样设计：
发起草稿：用户或定时任务发起备货请求。
采集事实：读取销量、存量、天气等事实，并锁定数据版本。
生成草案：由规则、模型或二者组合，生成备货候选方案。
检查方案：跑字段检查、业务规则检查和异常检查。
人工确认：命中风险阈值时，让店长或区域经理确认。
等待发布：通过检查后，等待写入订货系统。
发布或降级：发布成功，或进入可解释的降级方案。
状态机的好处是，开发者知道每一步的输入、输出和失败处理。
产品经理也知道哪里可以自动化，哪里必须让人确认。
这比一句“让 Agent 自主规划”更稳。
六、固定表头不是格式问题，是责任边界问题
如果模型最终只输出一段自然语言，后面所有系统都会难受。
它不能稳定入库，不能稳定校验，也不能稳定触发审批。
所以最终输出要先定义固定表头，也就是技术上说的结构化 schema。
例如每一行建议至少要有：商品、日期、时段、建议数量、建议原因、证据来源、风险等级、是否需要审批。
开发实现时，这些字段可以对应 skuId、date、timeWindow、recommendedQty、reasonCode、evidenceRefs、riskLevel、approvalRequired。
字段不是越多越好。
关键是每个字段都要有人负责解释。
建议数量来自候选生成器。建议原因来自规则或模型归因。证据来源指向工具返回的事实。风险等级来自校验器。是否需要审批来自策略引擎。
这样设计以后，模型不是在“写一篇建议”。
模型是在一个受控 schema 内补全可校验对象。
如果解析失败、字段缺失、字段越权、证据引用不存在，就不能发布。
七、质检员比提示词更重要，而且要分层
不要把所有控制都写进 prompt。
prompt 可以提醒模型，但不能替代质检员，也就是校验器。
我会把校验分成四层。
结构校验。 字段是否完整，类型是否正确，枚举值是否落在允许范围。
事实校验。 证据引用是否存在，输入快照是否一致，工具返回是否过期。
业务校验。 是否超过保质期，是否违反配送截止，是否触发审批阈值。
运行校验。 工具调用顺序是否完整，关键工具是否缺失，是否出现未授权调用。
这里要区分两个概念。
Agent 框架里的 guardrail，可以理解成安全护栏，适合做输入输出拦截和工具调用保护。
业务系统里的 validator，可以理解成业务质检员，还要承担领域规则校验。
二者可以协作，但不要混成一个东西。
八、过程可见不是给用户看热闹，而是留下运行证据
业务用户要看的是“为什么给这个建议”。
技术团队要看的是“这次运行到底发生了什么”。
所以运行记录不能只是一段聊天历史。
它至少要包括：
运行编号：一次端到端运行的唯一编号，也就是 runId。
工具调用编号：每次工具调用的编号、入参摘要、出参摘要和耗时。
数据版本：本次读取的数据快照版本，避免前后口径不一致。
规则版本：本次使用的规则版本，方便解释“为什么今天不一样”。
提示词和模型版本：方便复盘模型行为变化。
校验结果：哪些规则通过，哪些规则失败，失败原因是什么。
这不是为了给页面加一个漂亮进度条。
这是为了让系统能调试、能审计、能回放、能做回归测试。
九、失败预案要写成清单，不要只说“规则兜底”
很多 AI Demo 一到失败路径就露怯。
接口断了，就红字报错。模型没返回，就一直转圈。输出格式不对，就让用户重试。
这在业务系统里不够。
门店今晚还是要下单。明天早高峰不会因为模型超时就推迟。
所以失败预案要提前写成清单。
配置缺失：不启动模型，提示配置入口，不允许伪装成功。
工具超时：重试一次，仍失败则进入人工确认，不自动发布。
数据缺口：使用最近有效快照只能生成草稿，必须标记证据不足。
模型超时：用规则基线生成保守方案，并标记为规则兜底。
解析失败：丢弃模型输出，返回结构错误，不让自然语言绕过固定表头。
业务校验失败：保留候选方案，但进入 NeedsReview，不进入发布。
降级不是“模型不行就规则上”。
它要说明：哪个故障发生了，损失了哪类能力，系统还能交付什么，哪些动作必须交给人。
十、真正沉淀下来的，是业务专家的规则册和测试题
这类应用最后沉淀的，不只是一个补货助手。
更重要的是业务专家的判断路径。
过去，经验常常藏在店长脑子里、运营群里、日报里、Excel 里。
现在要把它拆成规则册和测试题。
规则册，也就是 policy，负责回答：什么情况下加量，什么情况下减量，什么情况下必须人工确认。
测试题，也就是测试集，负责回答：系统改版以后，这些判断有没有被破坏。
我会准备三类用例。
黄金用例：最常见、最稳定、应该自动通过的场景。
边界用例：临期、缺数据、配送截止、天气突变、活动冲击。
反例用例：模型容易说得很合理，但业务上必须拒绝的方案。
不写测试题的 Agent，很难从演示走向生产。
因为你无法证明下一次 prompt、模型、规则或工具升级以后，它还在正确工作。
十一、真正要迁移的，是你把经验讲成工程的能力
这套方法不只适用于鲜食备货。
合同评审、采购比价、项目周报、质量异常分析、门店巡检、客服工单分派，都可以用同一套思路重新设计。
不要先问“模型能不能回答”。
先问十个更硬的问题：
最终交付物是什么，能不能进入现有业务流程？
输入事实来自哪里，数据快照版本如何锁定？
哪些工具只读，哪些工具有写入副作用？
工具字段、错误码、超时和权限有没有写清？
状态机有哪些状态，失败后进入哪个状态？
输出对象的字段由谁负责，能不能被机器校验？
哪些规则是硬约束，哪些规则只是建议？
哪些结果必须人工确认，哪些可以自动通过？
失败预案是否明确说明能力损失和人工责任？
有没有正常题、边界题和反例题？
当你能回答这些问题，AI 应用就不再只是“会不会用模型”。
它开始变成流程设计、产品设计和工程设计的结合。
这也是我这次实践最大的收获。
业务专家的价值，不是去背模型参数，也不是去模仿开发写代码。
真正的价值是把经验拆成交付物、工具、规则、流程站点、质检、记录和测试题。
开发者看到这些，不会觉得你只是在讲概念。
他会知道接口怎么定义，状态怎么流转，失败怎么处理，哪些地方不能交给模型自由发挥。
对流程负责人、产品经理和业务专家来说，能力迁移的第一步很具体：明天就找一个高频闭环，先写清最终交付物，再列出输入事实、工具说明书、业务规则、质检规则、流程站点、失败预案和测试题。不要急着做大平台，先把一个小闭环跑扎实。跑通之后，再把这套结构复制到下一个流程。
未来的企业 AI 差距，很可能不在谁的模型更新更快，而在谁更早学会把业务经验变成可运行、可校验、可复盘、可测试的工程。
参考阅读： OpenAI Agents SDK：Agents、 Tools、 Guardrails、 Tracing。