跨案例对比
一句话： 把四个案例并排放在一起就能看到，技术深度是问题本身挣来的：阶梯上的每一级都由工作的某个具体特征触发，而几个相同的思想（基于来源、独立审核、人工 gate、由代码掌管数字）以越来越强的形式反复出现。
四个案例并排对比
Section titled “四个案例并排对比”| 1. 辅导 / 客服 | 2. 内容运营 | 3. 医疗机构研究 | 4. 交易研究台 | |
|---|---|---|---|---|
| 系统复杂度 | 低 | 中 | 中高 | 高 |
| 输出 | 带引用的回答 | 可编辑的 HTML 素材和 PNG | 带拆分和工作簿的数据集、说明来源/筛选规则/局限/合规的 README，以及 BuildManifest | 已发布的判断、推荐卡片、模拟组合、打分结果 |
| 核心模式 | 检索并回答 | 带审核循环的分阶段流水线 | agent 定义并挑战，代码构建 | agent 在确定性后端之上解读并提出异议 |
| Agent 数量 | 不需要 | 4 | 5 | 6 |
| 谁掌管事实和数字 | 源文档，通过引用 | 仓库中的标准事实文件 | 确定性流水线；agent 不做任何计算 | 后端；agent 引用 evidence ID |
| 独立检查 | 基于来源和拒答 | 使用更强模型的 Fact & Compliance Reviewer 阅读真实成品 | 挑战者：七个视角、2/3 复核者确认、看不到答案的 critic | 看不到其他信号的 Risk agent；文本带哈希存储 |
| 人工 gate | 升级转人工 | 上报 operator；营销人员编辑、标记完成并手动发布 | 大文件下载前的 GATE R；交付前的 GATE D | PM 启动审阅；导师批准门槛和规则冻结 |
| 时间与新鲜度 | 下线被取代的文档 | 标准事实在一处保持最新 | 来源版本和哈希；与上一次运行的 manifest 对比 | 时点快照；每次运行的截止时间；首次报告值 |
| 绝不能发生 | 编造的答案 | 未确认的事实到达营销人员手中 | 联系执业者；DIRECT 字段进入营销视图 | 真实订单；前视偏差；agent 自己敲的数字 |
| 如何评判成功 | 评测集准确率、引用、拒答 | 验收测试；审核者拦截埋入的错误 | 九条断言通过；连续两轮 QA 无问题；GATE D 签字 | 扣除成本后的 holdout 和前向结果；判断打分 |
是什么触发了每一级的升级
Section titled “是什么触发了每一级的升级”| 升级 | 迫使升级的问题特征 |
|---|---|
| RAG → 流水线 | 输出是一件产出物，而创作者不应该审批它 |
| 流水线 → agent 规划的构建 | 输出是必须向第三方证明其正确性的数据，于是数字移进代码 |
| 构建 → 决策研究台 | 输出是基于随时间变化的数字对未来做出的判断，所以必须按时点处理并打分 |
如果这些特征都不存在，就留在较低的一级。这正是 syllabus 在 Lesson 1 中强调的：不要为了显得高级而硬上多 agent 架构。
反复出现的思想
Section titled “反复出现的思想”“基于来源”演变为”所有权”。 Lesson 1 要求模型引用来源。Lesson 2 把事实放进审核者核对的标准文件。Lesson 3 禁止 agent 做计算。Lesson 4 连敲一个数字都不允许。每一步都去掉了一个模型可能出错的地方。
“审核”演变为”隔离”。 Lesson 2 的审核者独立于撰写者。Lesson 3 的 ontology critic 在看不到答案的情况下重新推导代码集。Lesson 4 的 Risk agent 看不到其他信号，它的文字也不能被编辑。
人工 gate 越来越靠前。 在 Lesson 2 中，人签发的是成品。在 Lesson 3 中，人在 GATE R 批准数据源和代码集，然后才开始高成本的下载。在 Lesson 4 中，门槛和规则冻结在它们要评判的结果出现之前就获批。
“不存在的东西”也是设计出来的。 Lesson 2 不产出 PPTX。Lesson 3 没有任何联系功能。Lesson 4 没有下单路径，并由仓库扫描检查。彻底不做一项能力，比把它关掉更安全。
为新问题选择原型
Section titled “为新问题选择原型”按顺序问以下问题，遇到第一个”是”就停下：
- 答案是否已经存在于文档中，而系统只读不写？从 Lesson 1 开始。
- 输出是否是一件要经过多个阶段并需要独立审核的产出物？从 Lesson 2 开始。
- 输出是否是会被第三方质疑、每个数字都必须可复现的数据？从 Lesson 3 开始。
- 输出是否是基于变化中的数字做出的决策，并且事后可以对照实际结果打分？从 Lesson 4 开始。
大多数客户需求落在第 1 或第 2 级，但很多需求被包装成第 4 级来提。
把四个案例串起来的核心原则是什么？
把每项职责放在可以被核查的地方。事实放在可以被引用的地方，数字放在可以被复现的地方，异议放在不会被引导的地方，决策放在可以被打分的地方。agent 的数量由此推导出来，而不是反过来。
客户描述了一个问题，并要求"像交易研究台那样的一组 agent"。你怎么判断？
和客户一起过一遍上面的四个问题。如果输出是基于现有文档的带引用回答，交易研究台式的架构只会增加成本和故障点，没有任何收益。让机制匹配问题的特征，并说明出现哪种特征才值得往上升一级。