Projects

这四个系统各自的细节写在下面每篇文档里。这里只讲一件事：做它们的过程中反复撞到的四条经验—— 每次以为是新问题，最后都发现是同一条规矩在不同场景里的写法。

四个系统共用的四条经验

一、收益几乎全部来自「少做」

投关问答那套，同一批 856 题上有 524 题全程没启动 Agent，相对全量走 Agent 下降 61.2%； AFAC 那套里，官方把 token 效率直接算进总分（准确率 ×0.5 + 推理分 ×0.3 + token 效率 ×0.2）， token 用得越多分越低。两个看起来相反的结论其实一致：真正的优化不在把链路跑得更顺，而在让更多东西根本不进链路。 先收敛入口，再谈能力——入口散着的时候，鉴权、审计、熔断都无从谈起。

二、证据先冻结，答案后生成

同一个约束换了三个场景：投关项目里是 as-of 版本链 + 受理时刻冻结 reference_time + 短句柄引用映射； 金融长文本那套是「凡是能算的一律由代码算」的确定性事实闭包；编排运行时里是 证据层 / 候选层 / 生效层三层记忆。三者的共同点是：把「你依据什么」变成一个对象， 而不是模型在生成时的自由发挥。做不到这一点，「可追溯」就只是一句宣传语。

三、判定权不放在模型手里

规则判定、程序断言、数据库约束、提交校验——这些在所有项目里都是独立一层。 模型可以提方案、提候选、提改进方向，但「达没达标」必须由确定性机制出结论。 AFAC 那套的提交校验有 11 类（总量上限、reasoning 最短长度、哈希一致、CSV 与证据双向一致…）； 投关项目的 Agent 路有 10 条确定性断言，失败直接 safe_failure，不做「让它再试一次」； 编排运行时的子 Agent 准入只有一个收口函数，并发与预算由计数和闸门决定。 把判定交给模型，等于把验收标准写成一句愿望。

四、先定义口径，再谈数字

投关那套的启动率口径（同一批 856 题上「走与不走 Agent」的对照，不是版本间 A/B）、 Context F1 口径（350 题 × 4 条金标准，句子级清洗后算、块 ID 不稳定也算命中）， AFAC 那套的 token 明细（逐题逐域可加总，跨实验拼产物作废）， 编排运行时里的并发与超时默认值——数字先立口径，才谈得上比较。 口径立不住，两个好看的数摆在一起也没有意义。

项目文档

• 金融投关问答助手（IR-Agent） —— 四路分流意图识别、Dense + BM25 双路检索、检索封成 MCP、证据冻结与引用绑定、程序 + 语义双核验。 含启动率与 Context F1 的口径定义。
• 金融长文本的高效问答与记忆压缩 —— AFAC 2026 天池赛题四。三级切块、先定位文档再检索、确定性事实闭包、证据预算、题型化作答与提交校验。 官方评分公式与本系统 token 明细。
• Multi-Agent 编排运行时 —— 子 Agent 准入 / 调度 / 通信 / 恢复 / 收口五环节，三层记忆治理与全文 + 向量混合检索。 子 Agent 准入、并发与超时公式、三层记忆与混合检索。