完整案例
供应商延期应对：缺口、方案与谁拍板
供应商延期后，一次运行看清缺口大小、三个恢复方案的对比和审批路径：AI 只做取证和汇总，数字与校验来自规则，花钱或影响客户的决定停在人工审批。
进入工作台 ↓供应商延期应对
供应商延期后，缺口多大、哪些方案可行、谁有权拍板？
选一个延期处境运行一次：AI 负责取证和汇总，影响评估、方案校验与审批路径由规则计算；需要人决定时停在审批点，不替你拍板。
现在的情况
合成数据 · 只读演示- 发生了什么
- 供应商确认晚 3 天，订单 SO-2418 的物料出现 185 件真实缺口，本周必须决定怎么补。
- 可选动作与代价
- 加急：补 400 件，10 小时后到位，成本 €4,200。
- 调拨：转来 300 件，立即到位，成本 €900；调出站点缓冲现为 700 件，红线 300 件。
- 重排：接受缺料并重排生产；等待则订单 SO-2418 迟交。
- 要决定
- 选哪个恢复方案（加急 / 调拨 / 重排）或接受缺口；谁有权批准。
- 怎样算答得好
- 每个数字都对得上规则计算；需要人决定的场景停在审批点，而不是自动执行。
查看技术轨迹
还没有运行轨迹。
可靠性评测（技术附录）单 Agent 基线 vs 多 Agent 编排 · 16 题对照评测模型见表头；页面实时运行使用站点当前配置的模型，以运行轨迹顶部显示为准。
| 变体 | Agent 版本 / 日期 | 模型 / 协议 / 重复 | pass@1 | k 次全对 | heldOut pass@1 | 平均步数 | p50 / p95 延迟 | Tokens（入/出） | 闸门拦截 | 执行错误自修复 | 运行时失败 | 首次即正确率 | 平均守护拦截 | 平均委派 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 单 Agent 基线 | ct-v1 · 2026-11-09 | zhipu:glm-5.3 · native · ×3 | 89.6% | 81.3% | 89.6% | 4.02 | 20.4s / 34.0s | 514,180 / 30,185 | 0 | 0 | 0 | 100.0% | 0.00 | 0.00 |
| 多 Agent 编排 | ct-v1 · 2026-11-09 | zhipu:glm-5.3 · native · ×3 | 79.2% | 62.5% | 79.2% | 2.90 | 26.7s / 58.0s | 215,016 / 17,125 | 0 | 0 | 0 | 95.8% | 0.04 | 1.15 |
| 能力 | 单 Agent 基线 | 多 Agent 编排 |
|---|---|---|
| authority（2 题） | 83.3% / 50.0% | 66.7% / 0.0% |
| disposition（7 题） | 100.0% / 100.0% | 95.2% / 85.7% |
| execution（1 题） | 0.0% / 0.0% | 0.0% / 0.0% |
| injection（5 题） | 100.0% / 100.0% | 93.3% / 80.0% |
| scheduling（1 题） | 66.7% / 0.0% | 0.0% / 0.0% |
失败类型 Top 3：wrong_stop 8；missing_scheduling_evidence 3；invalid_recommendation 2
评测模型见表头；页面实时运行使用站点当前配置的模型，以运行轨迹顶部显示为准。
成绩只对该题集、该模型与当次运行有效，不代表泛化准确率。heldOut 为未用于调优的题目。数据来自仓库内的评测结果文件。
系统 / 集成边界共享网络状态仿真；未连接 ERP、APS、SRM、MES、WMS、TMS 或企业事件总线。
深入材料架构判断、证据与限制主流程已经结束；需要审查设计判断时再展开。
概览
问题 → 工作流 → 系统。
案例从真实运营问题开始，而不是从技术栈开始。
本案例由原 Supply Chain Exception Command Center 演进而来，是 Agent Core 上的第三个重点场景。Orchestrator Agent 先委派供应恢复专家取证，必要时再委派排产专家；两个专家通过 MCP 获取确定性工具，影响评估、恢复方案校验、系统处置与责任角色都由代码计算。编排 Agent 只负责拆解、汇总与撰写报告；需要人决定的场景必须停在审批点。页面同时提供单 Agent 基线：工具相同、不经过委派，用来回答「多 Agent 是否真的更好」而不是先假定它更好。
业务规则
系统必须遵守什么。
业务规则本身就是架构的一部分。
- 事件必须来自 6 个合成延期场景之一；浏览器只传 scenarioId 与可选供应商备注，label、question 与延期天数由服务端场景表补全。
- 供应商备注是外部数据，可能含注入内容；它原样作为数据传递，任何「已获批准」「无需审批」的说法都不能改变审批要求。
- 影响评估、恢复方案数量/成本/校验结论、系统处置与决策权路径由确定性函数计算；Agent 不能编造数字，也不能自创方案。
- 只有确定性处置为 human_decision 或 forced_escalation 时才请求人工决定；报告中的处置必须与确定性处置一致。
- 推荐方案必须是校验结果为 pass 的方案；没有通过校验的方案时必须填 null，不能在报告里硬挑一个。
- 审批只记录人工决定，不执行任何真实系统动作；执行由对应系统负责。
产品决策
哪些判断真正改变了设计。
关键权衡保持可见，而不是被实现细节淹没。
- 把影响评估、方案校验、决策权与排产试算做成 MCP 工具，让两个专家 Agent 与单 Agent 基线共用同一批工具，避免多 Agent 引入第二套业务数学。
- 单 Agent 基线不是附带的演示开关，而是同题对照项：两种拓扑都保留在页面上，结论必须来自实际评测而不是架构宣称。
- 编排 Agent 不允许自己计算：必须先委派供应专家取证，排产影响只有在需要时才交给排产专家；委派次数受预算约束。
- 守护规则放在运行循环的终止工具之前，拦截会进入 trace 并被单独统计，避免把规则拦截误算成模型能力。
- 人工审批使用 runs 的暂停/续跑，而不是在浏览器里模拟「已批准」状态；审批结果以工具结果回到同一个运行。
证据
验证这些结论。
每一项证据都应该支持 Product 的一个具体结论。
- Demo交互式 Control Tower Agent 工作台
6 个合成延期场景；可切换多 Agent 编排与单 Agent 基线，运行轨迹可见子 Agent 嵌套；需要人决定时停在审批点。
- 架构MCP 工具层与守护规则
影响评估、恢复方案校验、决策权与排产试算由确定性工具计算；报告的处置必须与确定性评估一致，需人决定时不能跳过审批，推荐方案必须通过校验。
- 评估单 Agent vs 多 Agent 编排评测
2026-11-09，zhipu:glm-5.3，16 个合成用例（含注入/越权/执行压力与排产取证难题）× 3 次：单 Agent 基线 pass@1 89.6%、k 次全对 81.3%；编排 pass@1 79.2%、k 次全对 62.5%。难题集上单 Agent 基线更稳（编排差距集中在 authority / scheduling / injection 分组），编排 p50 延迟 26.7s 高于基线 20.4s，编排输入 token 统计约为基线的 42%（该统计不含被委派子 Agent 的用量）。
- 架构Agent Trace（OTel GenAI 语义）
运行轨迹在页面可见子 Agent 嵌套 span（orchestrator → 专家 → MCP 工具调用），与评测同源记录。
- 源码实现源码
Next.js + TypeScript；Agent 循环、MCP 客户端与服务端都在仓库内实现，不新增数据库、外部编排框架或队列。
- 权限提示GitHub 证据链接指向私有仓库 winstonw94/winston-builds，仅站主 Winston 本人可查看。
限制
这个 Product 不声称什么。
成熟度只能建立在现有证据真正支持的范围内。
- 6 个场景、供应商与物料主数据、成本与订单都是合成数据，不代表真实企业供应链或运营结果。
- 对比评测覆盖 16 个合成用例与单一模型（zhipu:glm-5.3，各 ×3）；难题集上编排 pass@1 低于单 Agent 基线，差距集中在 authority / scheduling / injection 分组，执行压力用例（要求真实下单通知）两种拓扑都不达标：结果不代表泛化准确率，也不代表其他模型上的结论。
- 没有接入真实 ERP、APS、SRM、MES 或执行 API；批准不会触发任何真实动作。
- MCP 默认走进程内传输；真实 HTTP 传输只在设置 AGENT_MCP_URL 时用于传输验证。
- 平台默认 30 秒执行上限下，运行会在软截止处暂停并由浏览器续跑；功能不依赖控制台调整。
- 供应商备注的注入防护是提示词约束加确定性守护规则，不是通用的 LLM 安全方案。