备少会断货，备多会损耗
店长关心明天卖不卖得完，总部关心早高峰会不会断货。AI 如果只给一句建议，很难让双方信任。
Schema
固定表头，保证结果能保存、审批和复盘。
业务 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
直播讲法：从场景冲突讲到工程闭环
建议按这个顺序讲。先让非技术观众听懂业务痛点，再逐步进入工具契约、质检、状态机和测试集。
01
痛点开场
备少断货，备多损耗。先让观众进入场景。
02
纠偏聊天框
聊天框不是终点，业务单据才是结果。
03
能力拆解
事实包、工具、规则、质检、失败预案。
04
技术翻译
Orchestrator、Registry、Policy、Validator、Trace。
05
行动收束
把一个高频闭环写成交付物、工具和测试题。
LIVE SCRIPT
直播讲师稿：三段可以直接照着讲
每段都保持一个原则：先讲业务问题，再讲对应的技术设计。不要让非技术观众掉队，也不要让技术观众觉得虚。
OPENING
开场三分钟
门店每天晚上最怕的不是“要不要用 AI”，而是明天早高峰三明治、沙拉、甜点到底备多少。 备少了，顾客买不到；备多了，当天卖不完，就变成损耗。 所以今天我们不从聊天框开始，而从一张真正能进入业务流程的备货计划单开始。业务 Agent 的第一步，不是回答问题，而是交付结果。
METHOD
能力设计段
一个业务 Agent，不能只看模型聪不聪明。 你要问五件事：最后交付什么单据；它读哪些事实；它能调用哪些工具；哪些规则必须检查；失败时怎么让业务继续跑。 把这五件事讲清楚，开发才知道接口怎么写，业务才知道哪里能自动、哪里必须人工确认。
TECH DEPTH
技术设计段
Harness 可以理解成让 AI 按业务规矩工作的控制台。 它至少有五层：流程指挥台决定走到哪一步；工具登记表说明每个工具怎么用；规则引擎保存业务规则；业务质检员检查结果能不能放行；运行记录本解释这次系统为什么这么判断。 这不是把事情复杂化，而是让 AI 从演示走向生产。