一次 LLM 调用不够
很多”AI 决策助手”的做法是：把用户的问题和一堆资料拼进 prompt，让模型直接输出答案。这在简单场景下能跑，但对于高风险的商业决策——绝对不够。
问题不在于模型不够聪明。问题在于：
- 缺乏流程约束：模型可以跳过检索直接给建议，也可以基于过期数据做出判断，没有任何机制能阻止。
- 缺乏可追溯性：最终建议里的一个判断，到底基于哪条证据？什么时候抓取的？谁做的这个判断？
- 缺乏失败保护：如果模型给出了格式错误的输出，或者某个阶段的产物不符合 schema，谁来拦？
Ludus 的答案是：不把分析当成一次 LLM 调用，而是当成一条有六道工序的生产线。
六阶段管道
Planning → Retrieving → Analyzing → Criticizing → Synthesizing → Validating
↑ ↑ ↑ ↑ ↑ ↑
└── 每阶段独立 Worker、独立 Prompt、独立质量门、独立恢复点 ──┘阶段一：Planning（规划）
Worker 读取冻结的 RunManifest（含 Charter、方法包版本、用户确认的档案），制定分析计划：
- 需要用哪些检索策略
- 每条策略的搜索 query 和来源优先级
- 分配每阶段预算
- 标记哪些假设需要特别关注
输出是一个结构化的检索计划，不能跳过。
阶段二：Retrieving（检索）
执行检索计划，通过 Connector Registry 调用外部来源：
Exa (优先) → Firecrawl → Tavily (备用)
↓ 失败时
cached (已有哈希的材料) → fixture (预置确定性数据)所有检索结果先写 RawArtifact，再经过信息质量门：来源等级、时间有效性、样本匹配度、指标口径对齐。不合格的材料被降级或拒绝，不能支撑正式结论。
阶段三：Analyzing（分析）
逐个因子分析。对每个关键主张，检查：
- 是否有直接证据支撑
- 证据的质量等级是否符合该主张的要求
- 是否存在相反证据
- 依赖的假设是否稳定
输出是一组 FactorResearchPacket——每个因子有自己的证据链、置信度和未解决的未知项。
阶段四：Criticizing（批判）
这个阶段的存在是 Ludus 和大多数 AI 系统最大的区别。Critic Worker 强制运行：
- Safety Anchor：识别集体盲点和主流叙事回声
- Devil’s Advocate：为每个选项构造最强反方理由
- Pre-Mortem：假设决策已经失败，倒推可能的失败原因
- Counterparty：从竞争对手或反对者视角审视决策
批判发现的三个最重要结果必须写入最终报告，不能只放在附录里。
阶段五：Synthesizing（综合）
综合所有因子和批判意见，生成结构化建议：
- 每个选项的支撑理由和反对理由
- 条件化建议（“建议选 A，条件是 X；如果 Y 发生，改为 B”）
- 六维质量画像：证据可用性、命题支撑度、假设稳定性、因果可信度、战略稳健性、流程质量
- 残余不确定性和推荐的验证行动
阶段六：Validating（验证）
Validation Worker 内有一个 ValidationOrchestrator，运行九个隔离的 Validator Contract：
| Validator | 检查 |
|---|---|
| Reference Validator | 引用完整性——每个关键判断是否可追溯到证据 |
| Conflict Validator | 是否存在对立证据未被处理 |
| Freshness Validator | 证据是否过期 |
| Completeness Validator | 必填字段和必检维度是否遗漏 |
| Abstain Validator | 质量不够时是否应该放弃给建议 |
| Schema Validator | 结构化输出是否符合合同 |
| Source Validator | 每条来源的 live/cached/fixture 状态是否正确标注 |
| Boundary Validator | 建议是否超出了方法包声明的适用范围 |
| Closure Validator | 行动项、领先指标、复盘日期是否完整 |
任何一个阶段质量门不通过：blocked（终态，只能重建 Run）。可修复的错误：needs_attention → resolution → 从 lastResumableStage 恢复。
中断与恢复
管道的每个阶段都可以进入 needs_attention 状态——不是因为系统崩溃，而是因为需要人类的判断力：
- 两条证据互相矛盾，而且都对关键建议有影响 → 需要人裁决
- 一个硬约束在分析过程中变得模糊 → 需要人确认
- 已授权的外部 Provider 需要恢复或切换 → 需要人操作
进入 needs_attention 时系统持久化 lastResumableStage，人类处理 resolution 后从精确的中断点恢复——不回到 queued、不重跑已完成阶段。
但有一条铁律：改变问题定义、目标、选项、约束或预算的干预不是 resolution，是 amendment。 amendment 必须创建全新的 Charter 和 Run，旧 Run 以 cancelled 终态保留。
no-run-no-report
这是 Ludus 最核心的质量约束：没有跑完所有六个阶段并通过质量门的 Run，绝对不能生成正式报告。
这个约束不是在文档里写写的。它在代码层面被强制执行：
- Report Publisher 的数据库查询有 FK 约束——没有
ready状态的 Run，report 记录无法写入 - 前端报告页只有
readyRun 才能访问报告对象 - Worker 无法跳过任何阶段直接进入
ready
fail-closed，不是 fail-open。宁愿不生成报告，也不生成没经过质量验证的报告。
效果
在球形机器人预置案例上，完整六阶段管道的表现：
| 维度 | 结果 |
|---|---|
| 检索材料数 | 12 条（8 live + 3 cached + 1 fixture 补充） |
| 质量门通过率 | 83%（2 条材料因时效性被降级） |
| 反方审查产出 | 5 条反对理由 + 3 个脆弱假设 |
| 条件化建议 | 推荐救援市场优先，条件：3 个月内确认 2 个采购意向；翻转条件：采购周期 > 12 个月 |
| 人类签署 | DecisionRecord 含 4 个行动项、6 个领先指标、复盘日期 |
管道设计的出发点
设计这条管道的过程中，我反复回到一个观察：没有人忘了做决定，但几乎所有人都忘了记录当时为什么做这个决定。没有人害怕不确定性，但几乎所有人都低估了假设的重要性。没有人拒绝反方意见，但几乎所有人都在压力下选择跳过它。
管道的价值不在自动化本身。在强制——在你说”我觉得选 A”之前，先让你看看证据够不够、反方怎么说、在什么条件下你会后悔。这不是一个技术判断，是一个设计选择。