一、这是什么
给定一批材料与一个分析目标，系统要产出一份多章节的长文分析。这类任务用单次调用做不好—— 不是模型不够强，是一件事里混了太多种性质不同的工作：有的需要发散，有的需要收敛， 有的需要严格遵守口径，有的需要独立复核。
所以系统把这件事拆成四个角色，串成一条主流程，每个角色只做一件事：
| 角色 | 职责 | 为什么单独拆出来 |
|---|---|---|
| planner | 拆解目标，产出任务与章节结构 | 结构决策与内容生成是两件事。混在一起时，模型会为了好写而改结构 |
| gov | 供给事实与约束，按规则核定可写范围 | 约束必须在生成之前给定，事后检查已经来不及 |
| res | 按结构产出正文 | 纯生成，不承担判断职责，可以放心让它写 |
| judge | 独立复核，判定是否达标 | 复核者必须与生成者分离——同一个角色既写又评，等于没有评 |
角色命名去掉了业务语义，只保留职责类型。这是刻意的：这套编排的形状与具体领域无关， 换成任何「给定材料产出长文」的场景都成立。
二、规模
最后一组数字是文档链：19 篇实施计划、6 份接口规格、9 篇代码评审。 它比代码行数更能说明这个项目是怎么推进的——每一阶段先写规格再写实现，写完再评审， 不是一路写到底。
三、结构
三条设计要点，每条都对应一个具体的失败场景：
- 契约驱动阶段之间只传结构化的 Pydantic 对象，不传自由文本。原因是自由文本传递会让错误静默传播——上游写歪了，下游读不出来，最后表现为一份看起来通顺但结论错的产出。
- 硬约束独立规则引擎不在模型内部，也不在 prompt 里，而是一个独立层。写进 prompt 的约束是建议，写进代码的约束才是约束。
- 复核者分离judge 不参与生成，且有自己的判定标准。让生成者自评，实测的结果是评分虚高且不随质量变化。
四、评测
这是这个项目与其他多 Agent 实现真正拉开差距的地方。多数同类系统停在「能跑出一份东西」， 但能跑出东西不等于产出变好了——没有评测，你改一个 prompt 之后甚至不知道是变好还是变坏。
| 组件 | 做什么 | 解决哪个问题 |
|---|---|---|
| 阈值门禁 | 产出必须过一组阈值才允许进入下一阶段 | 拦住「先跑完再说」——不合格的产出流到后期，返工成本翻几倍 |
| 离线 A/B | 同一批输入跑两个版本，逐项对比打分 | 让「这次改动是不是真的变好了」有答案，而不是靠读几份输出凭感觉 |
| 基线对比 | 与一个固定的基线版本比，不只看绝对分数 | 绝对分数会随任务难度浮动，只有相对基线的变化才说明问题 |
| 基准报告 | 把一轮评测的结果落成可追溯的报告 | 让评测结论可复算——换个时间重跑，能对得上 |
为什么这件事值得单独做一层。LLM 的改动效果是非单调的——换个模型、调个温度、改一句 prompt，都可能让某一类任务变好而另一类变坏。没有量化对比，迭代就退化成「我觉得这版好一些」，几轮之后就没人说得清当前版本强在哪。
五、决策记录
- 为什么这么选
- 约束有两类：一类是「最好这样」的倾向，适合放进 prompt；一类是「绝不能这样」的硬边界，必须由代码执行。把后者交给 prompt，等于把否决权交给一个概率模型。
- 放弃了什么
- 灵活性。规则引擎要预先枚举被禁止的情形，遇到没枚举到的边界就管不住。而 prompt 式的约束理论上能覆盖没写出来的情况。这个代价是接受的——明确的边界被严格守住，比模糊的边界被大部分时候守住更有价值。
- 什么条件下会失效
- 如果任务对约束的要求本身是模糊的、需要按情况判断的，硬编码规则会变成枷锁，产出会被压得千篇一律。这种场景下应该把规则降级为「提示 + 事后校验」，而不是前置拦截。
- 为什么这么选
- 自由文本传递会让错误静默传播。上游少写了一个字段，下游读不到也不会报错，只会「合理地」补一个——最后表现为一份通顺但结论错的产出。契约把这类错误变成立刻失败，而不是延后暴露。
- 放弃了什么
- 表达的自由度。强制结构化会丢掉一些细腻的语境信息，某些需要「带着语气传递」的内容会被压平。
- 什么条件下会失效
- 当任务本身是开放式创作、结构无法预先定义时，强行套契约会把产出掐死。判断标准是：这个阶段的输出是否有一个稳定的骨架——有就上契约，没有就别硬套。
- 为什么这么选
- 七个阶段的产出都要过检，人工检查的必然结果是：前期认真、中期凑合、后期直接跳过。脚本化的门禁把「要不要放行」变成一个退出码，不通过就是不放行，没有商量空间。
- 放弃了什么
- 临场判断。有些时候产出确实「不太合格但足够用」，人工可以放行，脚本只会拒绝。代价是偶尔多做一轮返工。
- 什么条件下会失效
- 如果验收标准本身还不稳定（比如项目早期还在探索产出应该长什么样），硬门禁会频繁误拦，反而拖慢迭代。所以门禁的标准要随项目成熟度逐步收紧，一开始就按最终标准卡，会卡死在半路。
六、失败与边界
踩过的坑
- 契约过严早期把契约设计得过细，导致模型为了满足结构而牺牲内容质量——它把精力花在「填满字段」上。后来放宽了非关键字段的必填要求，产出质量反而回升。
- 回退循环judge 判定不达标就回退重生成，早期没有次数上限，遇到模型始终不达标的情况会陷入循环并持续烧调用。加了重试上限与降级路径（附警告放行并标记）才解决。
- 评测集污染拿调试时看过的样本来做评测，分数虚高。后来把评测样本与调试样本分开管理，评测集不参与调参。
已知不足
- 成本偏高四个角色加复核回退，单次产出的大模型调用次数是单次直出的数倍。这是换质量付出的代价，不打算优化掉——但需要按任务复杂度选择是否走完整流程。
- 评测偏主观部分评分维度依赖模型评判，虽然做了与基线的对比，但评判标准本身仍有主观成分。这是当前最想改进但没找到好办法的一块。
- 无并发优化章节生成是串行的，没有做并行调度。任务量小时影响不大，量大时是明显的瓶颈。
它不适合什么场景。一次性、短产出、对结构没有要求的任务——用这套流程是过度设计，单次调用更快也更便宜。它的价值只在「产出需要被反复验收与迭代」的地方。
七、链接与状态
| 状态 | 内部课题项目，源码不公开 |
|---|---|
| 原因 | 单位课题成果，代码与数据受约束；这也是它本来的形态 |
| 可提供的 | 以上全部方法说明、结构图与设计决策；面试中可就具体实现细节展开 |
页面上的所有描述都在公开展示范围内，不含具体业务指标口径、内部数据与原始材料。