# 行业借鉴与适用边界

本页记录公开一手材料如何影响 v0.1 的设计。它们不是产品背书、不是实现证明，也没有提供本项目的合成数据、规则或评测结果。除链接标题外，以下均为压缩概述，不摘录长文。

2026-09-19 增加了实际代码复用：PydanticAI Slim / Pydantic Evals 2.45.0。组件选择、版本、许可、离线验证与当前未证明的价值见 [复用说明](FRAMEWORK_REUSE.md)。下表的零售咨询和产品资料属于方法借鉴，不是第三方实现已接入的声明。

| 来源 | 可核实的相关观点 | 本项目的迁移 | 未采纳/未实现 |
|---|---|---|---|
| [BCG，Always-On Merchandising: How AI Agents Are Transforming Retail（2026-04-15）](https://www.bcg.com/publications/2026/how-agentic-ai-is-transforming-retail-merchandising) | 将品类决策描述为连接商品结构、定价、促销、库存的过程；提出数据、定量引擎、guardrails、decision rights 与评测标准是重要准备条件。 | v0.1 将定量工具、行动门禁、证据和人类权利写进同一决策卡。 | BCG 描绘的是专用互联 agents 的未来模型；v0.1 没有多 Agent、实时系统或商业部署。 |
| [McKinsey，From dashboards to decisions: empowering merchants with agentic AI](https://www.mckinsey.com/industries/retail/our-insights/from-dashboards-to-decisions-empowering-merchants-with-agentic-ai) | 文章讨论 merchant 在库存、促销、商品结构等高频决策中从回顾数据走向行动支持，并强调业务工作流。 | 将输出从 dashboard 指标扩展为 owner、复盘和行动条件。 | 没有把文章的工作流或能力声明为已实现，也不声称本项目可取代 merchant。 |
| [Blue Yonder，Assortment Planning](https://blueyonder.com/solutions/retail-planning/assortment) | 其公开说明强调以客户/门店差异、空间约束、门店簇和业务规则规划结构，并使计划—执行—结果闭环。 | 采用 store cluster 比较和 `need_coverage` 角色保护，避免只按销量下架。 | v0.1 无货架空间、平面图、需求转移模型、客户忠诚度数据或闭环执行。 |
| [SymphonyAI，Scaling Category Performance with Vertical AI](https://www.symphonyai.com/resources/scaling-category-performance-with-vertical-ai) | 文章将速度与准确性归于可重复的决策循环、业务上下文和从实际工作流持续改进。 | case context 明确实验、授权、新鲜度和竞品信息的边界；结果保留用于离线评测。 | 无零售知识图谱、领域预训练或真实持续学习。 |
| [Anthropic，Building Effective AI Agents](https://www.anthropic.com/engineering/building-effective-agents) | 建议先选择尽量简单、透明的方案，只有任务确实受益时再增加编排复杂度；也说明 routing 适合类别可可靠区分的任务。 | v0.1 先采用单 orchestrator + 可复算工具；将模型提案限制为不可越权的假设。 | 没有宣称遵循该文即可保证可靠性；也尚未证明 specialist 路由有增益。 |
| [Anthropic，Evaluation guidance](https://docs.anthropic.com/en/docs/test-and-evaluate/define-success) | 官方评测文档强调先定义成功标准、使用任务相关样本并迭代评测。 | Golden set 将 schema、证据、数值、决策、权利、未知项和行动性分开评分，并用盲化 case 评估。 | 不把离线 Golden 分数解释为真实业务 ROI、模型通用安全性或对人类优越。 |

## 本项目的独特主张（需用评测验证）

项目的设计重点不是“更会生成建议”，而是回答：在什么证据、实验与授权条件下，系统才有资格建议一个有界行动；条件不足时为何应 `HOLD`、`INVESTIGATE` 或 `ESCALATE`。这是设计假设，不能仅凭上述行业资料成立。

## 四组比较设计

为避免把“输出更丰富”误当成“决策更好”，同一盲化输入应比较：

| 组别 | 输入/输出 | 可评价的内容 | 当前状态 |
|---|---|---|---|
| A Dashboard only | 同一汇总指标给人类查看 | 人工诊断与行动质量 | 模板，未运行 |
| B frontier LLM direct | 同一原始行与 context，直接回答 | 无工具门禁时的建议质量 | 校正 live 实测记录与适用边界见 `artifacts/live_experiment/REPORT.md`；不作优越性结论 |
| C Category Agent | 本系统工具、门禁、固定卡 | 证据、数值、权限与选择性行动 | 离线可运行；校正 live 实测记录与适用边界见 `artifacts/live_experiment/REPORT.md` |
| D Human + Agent | C 的卡交由人类复核 | 人机协作后的最终判断 | 模板，未运行 |

所有组都不读取 Golden 标签；case 使用不透明 ID 和中性标题。种子扰动是稳健性检查，不能冒充独立 holdout。缺少真实人员、模型调用或盲测结果时，结果必须写为 `not_run`，不得填 0 或虚构胜率。