完整案例
Supply Chain Agent Team
让多个拥有不同职责、数据、目标和底线的供应链 Agent，在三个关键扰动场景中分析、争论、协商并形成受约束 Action。
核心问题供应链问题通常不会只属于一个职能。需求、库存、生产、采购、物流和财务拥有不同目标与底线；真正困难的是让这些局部判断形成一个可执行、可验证、必要时可升级的共同方案。
进入 Agent Team ↓系统 / 集成边界多 Agent 决策协作仿真；没有自治企业服务，也不直接执行 ERP、APS、WMS 或 TMS 动作。
INTERACTIVE PRODUCT
让供应链 Agent 团队真的协作一次。
选择一个扰动场景。每个 Agent 有自己的职责、数据、Journal 与底线；Agent 自己决定是否继续讨论，普通代码负责限轮、Context Budget、动作白名单、约束与 Simulation。
Scenario 01 · Demand Spike
SKU-A 两周需求 +28%
需求增加 2,800 件。团队需要在客户服务、库存覆盖、产能与采购溢价之间找到一个共同可接受方案。
Demand Agent
保护关键客户交付，同时避免把短期需求波动直接放大成长期计划。
查看数据与 Journal
未来两周 Forecast：12,800
原 Forecast：10,000
需求增幅：+28%
关键客户占本周期需求 46%
上一次类似促销中，需求峰值持续 11 天。
客户 A 对延期最敏感，应优先保护。
Inventory Agent
释放可用库存，但避免把短期服务问题变成新的库存风险。
查看数据与 Journal
现有库存：1,600
Safety Stock：1,000
当前 Coverage：18 days
Region B 可调拨：300
Region B 未来两周没有 Priority Customer 活动。
低于 12 天 Coverage 时，后续补货波动明显增加。
Production Agent
利用可用产能补缺口，同时控制换型和加班扰动。
查看数据与 Journal
可用弹性产能：1,500
当前 Overtime：0%
Line 2 有本周期空余窗口
额外 700 件将触发第二班次
Line 2 上次短期增产 1,400 件，没有造成次周积压。
连续两周高于 10% Overtime 会明显增加质量风险。
Procurement Agent
补足材料与外部供给缺口，同时限制紧急采购溢价。
查看数据与 Journal
Supplier Flex Capacity：900
标准 Lead Time：8 days
可加急部分：400
加急 Premium：14%
当前供应商 900 件弹性量并非全部能赶上 5 天生产窗口。
只加急前 400 件可以避免触发更高档溢价。
AGENT COLLABORATION
团队讨论
点击“启动 Agent Team”。每个角色的 Queued → Context → AI Response → Ready 状态会实时显示，不再等整批完成后一次性出现。
Agent 可以 accept、challenge、请求回应或请求已有数据，并自主决定是否还需要下一轮。
系统限制上下文增长、讨论轮数、路由和执行边界；模型不能无限聊天或直接改系统状态。
无可行解或 3 轮后仍有 unresolved request 时，系统停止自治并升级人工。
深入材料业务规则、产品决策、证据与限制含限制声明；需要审查设计判断与真实性边界时再展开。
概览
问题 → 工作流 → 系统。
案例从真实运营问题开始，而不是从技术栈开始。
这是一个面向展示与系统验证的供应链多 Agent Product。用户选择一个预设业务扰动后，多个角色 Agent 会基于各自的数据、职责、红线和 Journal 独立判断，再围绕冲突做第二轮协商；最终方案只能从允许动作集合中产生，并交给确定性验证器计算结果和检查约束。可以自动解决的问题进入 Simulation；无法同时满足关键约束的问题会明确升级给 Human Decision Maker。
业务规则
系统必须遵守什么。
业务规则本身就是架构的一部分。
- 每个 Agent 只能基于自己的职责、场景数据和共享讨论提出立场，不能直接修改系统状态。
- Agent 最终只能选择系统预先定义的 Action Catalog；未知动作不会进入执行层。
- 数量、覆盖缺口、成本、库存覆盖、加班等结果由确定性代码计算，不由模型生成 KPI。
- 如果动作触发红线、无法覆盖关键缺口，或涉及战略客户取舍，系统必须保留 Human Review。
- Scenario 03 被有意设计为不存在同时满足所有底线的自动方案，用来验证“知道什么时候停止自治”。
产品决策
哪些判断真正改变了设计。
关键权衡保持可见，而不是被实现细节淹没。
- 先选择三个结局不同的供应链场景，而不是试图一次覆盖整条端到端供应链。
- Agent 使用独立 Prompt Context 表达不同职责，但共享同一个受控 AI Runtime；页面展示的是结论和交互，不展示隐藏推理。
- 第一轮并行独立判断，第二轮只让关键冲突角色继续协商，避免无限 Agent 对话。
- 最终 Coordinator 只能返回 Action ID，随后由普通代码验证，而不是让 LLM 自由生成执行指令。
- Product 使用模拟数据和 What-if Engine，不伪装成真实 ERP / APS / WMS 线上控制系统。
- 没有为展示型场景新增 Supabase 表；当前 Product 是无持久状态的模拟，避免为 Demo 制造不必要后端复杂度。
证据
验证这些结论。
每一项证据都应该支持 Product 的一个具体结论。
- Demo交互式 Agent Team Demo
三个预设供应链场景；Agent 真实调用 AI Runtime，失败时会明确标记并使用确定性回退文案。
- 架构受约束协作架构
AI 负责观察、立场、协商与候选方案；普通代码拥有动作白名单、约束校验和 KPI Simulation；高影响决策保留人工边界。
- 评估三类供应链扰动验证
Demand Spike、Supplier Delay 与 Strategic Shortage 分别验证自动协作、跨职能 Trade-off 与必须升级人工三种不同结局。
- 源码实现源码
Next.js + TypeScript；复用现有 OpenRouter Runtime，不新增数据库对象。
限制
这个 Product 不声称什么。
成熟度只能建立在现有证据真正支持的范围内。
- 所有业务数据均为明确的模拟数据，不代表任何真实企业运营结果。
- Agent 使用共享 LLM Provider 的多个角色调用，并非多个独立部署、长期运行的自治服务。
- Journal 是场景内的角色上下文，不是跨会话持久记忆。
- Simulation 是受限业务模型，没有接入 ERP、APS、WMS、TMS 或真实供应商系统。
- 免费模型可能暂时不可用；单个 Agent 调用失败时 UI 会明确标记 deterministic fallback，而不是伪装成 AI 输出。
- 该 Product 证明的是协作架构、角色边界和决策流程，不声称已经具备生产环境中的治理、安全、权限和审计完整性。