5 个 Agent 开了场核保辩论会

五个 AI Agent 围坐辩论的核保议会

V2 的死穴：跑一遍就祈祷

V2 核保系统画在白板上很干净：

原始文档 → Gemini 提取 → DealSchema → 11 个 SME 并行评估
→ 确定性聚合 → 单次报告 → 提问

每个阶段只跑一遍。没有迭代，没有反馈循环，没有自我评估。提取要么对了要么错了。

11 个领域专家——GPU 工程师、财务分析师、法律分析师，再加八个——各自孤立地评估。意见不一致？系统直接把所有意见拼在一起。问题去重？"比较前 100 个字符"。

用了一阵子，裂缝开始出现：

• 没有证据追踪。 SME 标记"CapEx 假设过于激进"，但不链接到哪份文档、哪一页、哪个数字。
• 没有跨 SME 推理。 法律说 PASS，风控说 FAIL——系统把两个意见并排放着，不去解决冲突。
• 没有质量门控。 提取阶段的垃圾一路默默传到下游。Garbage in, garbage out，中间没有检查点。
• 没有事实核查。 LLM 说什么就是什么。

V3：流水线变成了议会

V3 用一组能思考、验证、辩论的 agent 替换了线性流水线：

ExtractionAgent (5 阶段，带反思)
    ↓ DealSchema
11× SMEAgent (4 阶段，工具辅助)
    ↓ 11× SMEEvaluation
ICPanelAgent (5 步：聚合 → 综合 → 辩论 → 质疑 → 问题合成)
    ↓ 增强版 UnderwritingPacket
ReportAgent (3 阶段：草稿 → 自审 → 修改)
QuestionAgent (3 阶段：缺口分析 → 网络过滤 → 优先排序)

每个 agent 是一个自治的状态机。它们不是调一次 LLM 就完事——它们在各阶段之间迭代，反思自己的输出质量，用工具验证论断，只有质量达标才产出最终结果。

底层引擎：一个循环跑所有人

所有 agent 都跑在同一个 AgentRuntime 里——一个通用的执行引擎，核心就是一个循环：

for iteration in range(max_iterations):
    action = agent.plan(context)          # 思考：下一步做什么？

    match action.type:
        case DONE:     break
        case TOOL_CALL: 执行工具 → on_tool_result()
        case LLM_CALL:  调用 LLM → on_llm_response()
        case REFLECT:   自我评估 → on_reflection()
        case MESSAGE:   agent 间消息 → on_message_sent()

三个关键设计决策：

1. Runtime 与 agent 无关。 任何 BaseAgent 子类都能插入。Runtime 不关心跑的是提取 agent 还是报告 agent。
2. Context 不可变。 每次 with_tool_result()、with_llm_response()、with_memory() 都返回新实例。没有别名 bug，没有意外的 mutation。
3. 每一步都有追踪。 cost、token 数、耗时、工具输入输出——全部记在 AgentTrace 里。你可以审计每一步发生了什么、为什么。

五个角色，各管各的

提取 Agent——不对就重来

V2 跑一次 Gemini 提取就祈祷结果完整。V3 的 ExtractionAgent 有五个阶段：

1. 批量提取——跑传统提取管线拿到初始 DealSchema
2. 反思——自评完整性。哪些字段缺失？哪些看起来不对？
3. 针对性补读——重新读取特定文档，补齐 top-5 关键缺失字段
4. 验证——交叉验证高价值字段（运营商名称、GPU 型号、总 CapEx），配合网络搜索和事实核查
5. 最终反思——质量门控后才产出

模型：gemini-3.1-pro。质量阈值：80/100。

领域专家 Agent——说结论？先亮证据

V2 的 SME 是一次 LLM 调用吐一段主观评价。V3 的 SMEAgent 每个领域跑四个阶段：

1. 初始评估——结构化分析，strengths 和 concerns 带证据链接
2. 反思——检查证据充分率（目标 80%+）、置信度（目标 0.7+）
3. 工具验证——用 query_schema、web_search、calculate 佐证论断
4. 最终反思——质量门控

质量公式重度依赖证据：concerns_backed × 40 + strengths_backed × 30 + confidence × 20 + summary_quality × 10。

每个 SME 产出的是域内决策（PASS / PASS_WITH_CONDITIONS / NEEDS_CLARIFICATION / FAIL），不是整体交易推荐。SME 只管自己领域的事。

11 个领域：gpu_engineer、financial_analyst、legal_analyst、risk_underwriting、datacenter_engineer、product_manager、operations_analyst、commercial_analyst、market_analyst、security_compliance、energy_infrastructure。

IC 委员会 Agent——真正的裁判

这是最有意思的 agent。

V2 只是把 SME 输出拼在一起。V3 的 IC Panel 跑一个 5 步综合管线：

辩论和质疑是条件触发的——有冲突或 CRITICAL 担忧才跑。不做无用功。

质量阈值：90/100。系统里最高的门槛。因为 IC Panel 的输出是人类实际阅读的内容。

报告 Agent——写完自己骂自己，骂完再改

V2 一次性生成报告。V3 跑三个阶段：

1. 草稿——从 UnderwritingPacket 生成初始报告
2. 自审——同一个模型批评自己的草稿：担忧回应了吗？数字有出处吗？语气适合这类投资者吗？
3. 修改——应用改进，补充引用，修复没来源的数字

报告按投资类型区分：EQUITY 关注 IRR 和上行场景，DEBT_SENIOR 关注信用理由和条款约束。

提问 Agent——能搜到答案的问题就别浪费人家时间

V2 一次性生成所有问题。V3 过滤噪音：

1. 缺口分析——识别缺失字段、冲突，起草问题
2. 网络过滤——检查答案是否公开可查。能查到的就去掉（省运营商的时间）
3. 优先排序——按交易影响排序，CRITICAL 优先

每句话都得有出处

V3 里每个结论都追到源头：

• 源文档——哪份上传文件
• 位置——文档中哪里
• 片段——支持论断的原文

担忧严重度用 4 级系统（CRITICAL / HIGH / MEDIUM / LOW），替代 V2 的二元赞/弹。每个担忧还配有缓解建议。

不限制通信就会吵成一锅粥

Agent 之间通过结构化消息总线通信（REQUEST、RESPONSE、CHALLENGE、ESCALATION、INFO）。但不限制通信就会产生无限循环。所以分阶段管理：

一笔交易，烧多少钱

Arkane Cloud 测试案例的成本：

全流水线跑满 11 个 SME：每单几美元——比人工分析师便宜几个数量级。

63 个测试：58 个集成测试（mock LLM，0.1 秒跑完）+ 5 个端到端测试（真 API 调用）。整套测试在一个 Claude Code session 里写完——那是另一个故事。

变的不是调用次数，是系统跟自己的关系

从 V2 到 V3 的转变不是"多调几次 LLM"。核心变化是系统与自身输出之间的关系：

• 从"调一次祈祷结果好"到迭代式精炼。 Agent 反思质量，不达标就重来。
• 从观点到证据。 每个论断链接到源文档，带位置和原文片段。
• 从孤立评估到结构化辩论。 SME 意见不一致时，冲突被推理解决——不是被拼接掩盖。
• 从单次报告到自我批评的报告。 模型审查自己的工作，然后才交付。
• 从"生成所有问题"到"只问重要的"。 网络过滤去掉了有公开答案的问题。

流水线变聪明了，不是因为换了更好的模型。是因为给了 agent 一个能力：怀疑自己，也怀疑别人。

一个人独立思考容易犯错。但一群人互相质疑、要求出示证据——出来的结论就靠谱多了。 Agent 系统也一样。