备少会断货，备多会损耗
店长关心明天卖不卖得完，总部关心早高峰会不会断货。AI 如果只给一句建议，很难让双方信任。
Schema
固定表头，保证结果能保存、审批和复盘。
业务 Agent 的核心，不是让模型更自由，而是让模型在业务规矩里交付结果。
备货不是回答一个问题，而是交付一张能保存、能审批、能追溯的业务单据。只有结果能进入流程，Agent 才真正进入业务现场。
01
从聊天框退出来
聊天框只能解释，不能天然进入业务流程。
02
先定义交付物
一张备货计划单，比一段自然语言建议更接近真实工作。
03
把经验变成结构
交付物、工具、规则、质检和失败预案共同构成 Harness。
04
最后再让模型进场
模型参与判断，但不能替代权限、规则、发布和复盘。
CASE STUDY
样板间：一家连锁咖啡门店的鲜食备货
这个场景足够日常，也足够完整。它有销量、存量、天气、临期、配送、审批和损耗，正好可以把业务 Agent 的关键设计讲清楚。
真正交付的是备货计划单
计划单要包含商品、日期、时段、建议数量、原因、证据、风险和审批状态。它必须能进入现有订货流程。
模型参与判断，但不接管所有动作
事实采集、硬规则校验、权限判断和发布动作，需要留在系统控制之内。模型适合参与生成草案和解释原因。
CAPABILITIES
能力设计：把一个 Agent 拆成可交付的五件事
非技术人员不需要变成程序员，但需要把业务经验讲成开发者能接住的结构：交付物、事实、工具、规则、质检和测试。
OPERATING FLOW
01
交付物
先定义一张能进入流程的业务单据，而不是一段回答。
02
事实包
销量、存量、天气、临期和配送窗口要统一成同一份快照。
03
工具说明书
每个工具都要写清参数、返回、权限、超时和错误。
04
业务质检员
字段、事实、规则和发布条件都必须能被机器检查。
05
失败预案
模型超时、数据缺口和校验失败时，系统仍要可解释。
Policy
业务规则册，说明什么能自动过，什么必须人工看。
Trace
运行记录本，说明系统为什么给出这个建议。
Tests
正常题、边界题、反例题，防止升级后判断被破坏。
SYSTEMS
技术设计：Harness 不是一个 prompt，而是五个控制台
每个技术词都对应一个管理问题。看懂这些结构，业务、产品和开发才能围绕同一个结果协作。
聊天框式 Agent
用户问一句，模型回一段。
看起来轻巧，但结果很难保存、校验、审批、回滚和追责。
一旦失败，往往只剩下“请重试”。
Harness 式 Agent
先定义交付物，再组织工具、规则、质检和运行记录。
模型负责参与判断，系统负责守住边界。
失败也要进入可解释的预案。
流程指挥台
决定系统走到哪一步，什么时候暂停、重试或降级。技术上是 Orchestrator。
工具登记表
登记每个工具怎么用、谁能用、出错怎么返回。技术上是 Tool Registry。
业务质检员
检查字段、事实、规则和最终单据是否合格。技术上是 Validator。
APPROACH
方法路径：从场景冲突走到工程闭环
这条路径适合任何业务 Agent 场景：先看见业务冲突，再定义交付物，最后把经验拆成工具、规则、质检、状态和测试。
01
场景冲突
备少断货，备多损耗。先看见业务里的真实拉扯。
02
纠偏聊天框
聊天框不是终点，业务单据才是结果。
03
能力拆解
事实包、工具、规则、质检、失败预案。
04
技术翻译
Orchestrator、Registry、Policy、Validator、Trace。
05
行动收束
把一个高频闭环写成交付物、工具和测试题。
PRACTICE
现场练习：把自己的业务场景拆成设计卡
把一个真实流程写成三张卡：场景卡、能力卡、技术卡。只要这三张卡写清楚，后续 PRD、原型和开发评审都会顺很多。
CARD 01
场景卡
场景：门店每天晚上要决定明天早高峰三明治、沙拉、甜点到底备多少。 备少了，顾客买不到；备多了，当天卖不完，就变成损耗。 关键判断：不要从聊天框开始，而从一张真正能进入业务流程的备货计划单开始。业务 Agent 的第一步，不是回答问题，而是交付结果。
CARD 02
能力卡
一个业务 Agent，不能只看模型聪不聪明。 需要问五件事：最后交付什么单据；它读哪些事实；它能调用哪些工具；哪些规则必须检查；失败时怎么让业务继续跑。 把这五件事讲清楚，开发才知道接口怎么写，业务才知道哪里能自动、哪里必须人工确认。
CARD 03
技术卡
Harness 可以理解成让 AI 按业务规矩工作的控制台。 它至少有五层：流程指挥台决定走到哪一步；工具登记表说明每个工具怎么用；规则引擎保存业务规则；业务质检员检查结果能不能放行；运行记录本解释这次系统为什么这么判断。 这不是把事情复杂化，而是让 AI 从演示走向生产。