报告最怕“看起来很完整”
/v1/dual 跑通以后，B 线能生成结构化报告了。但我很快发现一个问题：模型很擅长把报告写得像报告，即使证据不够。
这在医疗问诊 demo 里尤其危险。它不是医疗建议，但如果输出语气太稳，用户会下意识把它当成判断。
所以我给 B 线加了一个 judge loop。它不是给用户看的，而是在报告生成前后检查：当前召回够不够，草稿有没有漏掉明显角度，要不要再查一次。
Judge 不负责自由发挥
Judge 看的东西很有限：草稿、recall_bundle、用户问题。它只回答几个问题：
- 现在的证据够不够支撑这份报告；
- 有没有明显缺失的角度；
- 是否需要追加检索；
- 如果要查，下一轮 query 应该是什么。
比如用户说腹痛，但第一次召回只覆盖了普通胃部不适，judge 就可能要求补查腹痛伴随症状、持续时间或红旗表现。它不是在诊断，只是在提醒报告别用太窄的证据写得太满。
为什么最多五轮
这里我没有做自由 Agent。循环最多五次。
这个上限很重要。模型如果被允许一直“再查一点”，成本和延迟都会失控，demo 也会变得不可解释。实际跑下来，大多数情况两三轮就够，五轮只是兜底。
我更愿意把它叫做“有界补证据”，而不是“智能体自动研究”。
A 线不走这个循环
A 线仍然保持轻。它负责继续问，不负责每轮做完整证据审查。否则 A 线会变慢，用户每发一句话都像在等报告。
B 线本来就是重路径，放 judge 和追加检索更合理。这也和最开始的双轨边界一致：A 线收信息，B 线组织证据。
测试只验证边界
这一轮补了 test_llm_judge.py 这类测试。测试不证明报告“医学正确”，也不做医学评估。它只验证几件工程事实：模型返回需要追加检索时，系统会追加；不需要时会停；达到上限时一定会停。
这个边界比看起来重要。没有它，judge loop 很容易从质量控制变成不可预测的成本黑洞。
B 线最终的目标不是写得更长，而是“宁可保守一点，也不要飘”。这句话比任何复杂 prompt 都更像这一阶段的设计原则。