技术研究报告 · Technical Research Report

面向企业年金业绩报酬的
多智能体自动提取与计算系统
——架构设计、对抗鲁棒性与基础模型消融研究

A Multi-Agent System for Automated Extraction and Computation of Enterprise-Annuity Performance Fees: Architecture, Adversarial Robustness, and Base-Model Ablation
年金业绩报酬智能提取与计算课题组
基金公司年金业务 · 智能体原型 v0.3 · 2026 年 7 月

摘要 ABSTRACT

企业年金业绩报酬的计算长期依赖人工阅读合同、理解计提方式与核对基础指标,单份处理耗时以小时计,且随合同措辞的多样化而易错。本文提出并实现一套以「编排智能体 + MCP 工具集」重构该流程的系统:将合同解析、条款理解、参数标准化绑定、公式生成与安全计算拆解为可组合的工具,由编排智能体协同调用,并通过服务器推送事件(SSE)向前端实时反馈。系统的核心设计是确定性护栏——大语言模型只负责自然语言理解与公式生成,金额计算一律由本地抽象语法树(AST)白名单引擎执行,并与内置标准公式交叉验证;同时每个智能体均以规则引擎兜底,保证离线可用与流程不中断。

我们在两个维度上系统评估了该原型。其一,红蓝对抗:设计三轮共 28 个合法但刁钻的合同/报表样本(双口径、补充协议覆盖、定义分离、复合基准、模式伪装等「文字游戏」),逐轮攻击—修复—回归,系统防御率由 21.4% 经根因加固收敛至 100%,且前序表现零退步。其二,基础模型消融:在从纯规则引擎到 Claude Haiku/Sonnet/Opus 的四个能力档位上评测同一基准子集,三项准确率均达 100%,仅处理耗时相差约五万倍——验证了「确定性护栏拉平模型差异」的假设,并据此提出「规则打头阵、模型兜底疑难、按难度分级调用」的生产选型策略。

关键词:企业年金;业绩报酬;多智能体;MCP 工具;大语言模型;合同信息抽取;对抗鲁棒性;消融实验;确定性护栏

annuity-agent v0.3 · 三轮对抗 28 案例 · 四档模型消融 · 8 GB 设备可部署

1 引言

企业年金是我国多层次养老保险体系的第二支柱,由用人单位与职工共同缴费、委托专业机构进行投资管理。在企业年金基金的投资管理合同中,业绩报酬(又称浮动管理费)是投资管理人的重要收入来源之一:当投资组合的收益表现超过合同约定的门槛时,管理人可就超额部分按约定比例计提报酬。业绩报酬的计算并非简单套用一个公式,而需要先从数十页的合同中定位业绩报酬条款、理解其计提方式(超额收益法、高水位法等)、抽取计提比例与基准等参数,再从组合业绩报表中核对收益率、资产规模、净值、份额等基础指标,最后按合同口径完成计算与复核。

这一流程目前高度依赖人工。业务人员需逐条阅读合同、人工核算,单份处理往往耗时以小时计;而真实合同的措辞千差万别——同一个「计提比例 20%」,不同起草者会写成「百分之二十」「贰拾%」「名义 25% 实际按 20% 执行」等多种形态,稍有疏忽便可能取错参数、算错金额。随着大语言模型(LLM)在自然语言理解上的突破,一个自然的想法是:能否用 LLM 自动完成这条流程?

然而,将 LLM 直接用于金融金额计算存在三重风险:其一,不可审计——端到端的「黑箱问答」难以复核每一步的依据;其二,幻觉——模型可能生成看似合理实则错误的数值;其三,无法人工干预——业务合规要求「机器初算、人工复核」,纯模型输出难以嵌入这一工作流。本文的核心主张是:让聪明的部分(LLM)负责理解,让确定的部分(规则与安全求值)负责钱;LLM 可以出错,但金额必须永远正确、可复算、可审计。

围绕这一主张,本文的贡献包括:(1)提出并实现一套多智能体 + MCP 工具的年金业绩报酬自动化系统,具备确定性护栏与双引擎兜底(第 2 节);(2)以三轮红蓝对抗系统性检验其在刁钻合同措辞下的鲁棒性,并公开 28 个对抗样本作为回归测试集(第 4 节);(3)通过跨模型档位的消融实验,揭示确定性护栏对模型差异的「拉平效应」及其对生产选型的启示(第 5 节);(4)完整记录暴露—修复—收敛的工程过程(第 6 节)。

2 系统架构与设计

系统将年金业绩报酬的识别与计算全流程拆解为一条由编排智能体(Orchestrator Agent)调度的流水线,各环节以标准化的 MCP(Model Context Protocol)工具形式实现,可被进程内直调,亦可作为独立的 MCP 服务挂载给任意兼容客户端复用。整体架构如图 1 所示。

前端(单页 HTML · SSE 实时流 · 拖拽上传 / 人工确认重算 / 报告导出) 深蓝×金 · 中英文界面 · 8GB 设备友好 FastAPI 服务层(REST + SSE) 编排智能体 Orchestrator ① parse_document PDF 解析 + 合同/报表分类 PyMuPDF · 扫描件告警 ② extract_clauses 合同理解智能体 条款+参数抽取 ③ bind_parameters 参数绑定智能体 标准化+置信度+人工确认 ④ generate_and_calc 计算智能体 公式生成+AST安全求值 基础模型通道 Claude 订阅 / API / OpenAI 兼容(DeepSeek等) 规则引擎(兜底) 断网/无额度/模型异常时接管,流程不中断 每个智能体 = 模型优先 + 规则兜底(双引擎)
图 1 系统总体架构。编排智能体依次调度四个 MCP 工具;每个智能体采用「模型优先 + 规则兜底」双引擎;金额计算由确定性引擎执行。前端通过 SSE 实时展示流水线各阶段。

2.1 四个 MCP 工具与三个业务智能体

文档解析(parse_document)以 PyMuPDF 抽取 PDF 文本并按关键词打分分类为合同或报表;对文字层缺失的扫描件显式告警而非误判为「无条款」,避免把「没读到」当成「没有」这一危险误报。

合同理解智能体(extract_clauses)从合同中定位业绩报酬条款并抽取计提模式、计提比例、业绩基准、计提上限、频率等参数;从报表中抽取收益率、资产规模、净值、份额等基础指标。该智能体是本系统对抗鲁棒性的主战场(第 4 节)。

参数绑定智能体(bind_parameters)将抽取到的自然语言参数映射到系统的标准化参数字典(13 个标准参数,含编码、别名、类型、单位、来源),输出置信度;对低于阈值或单位不明的绑定标记「需人工确认」,并完成单位归一化(元/亿元→万元、份/亿份→万份,避免「差一个单位即差一万倍」的静默错账)。

计算智能体(generate_and_calc)根据已确认的标准参数生成可执行公式并求值,输出分步计算底稿。

2.2 确定性护栏:让钱的计算可复算、可审计

本系统最关键的设计是把「理解」与「计算」在信任层面分离。计算智能体生成的公式不是被直接 eval,而是被解析为抽象语法树(AST),在白名单约束下求值:只允许四则运算、比较、条件表达式与 min/max/abs/round,只允许数字与已绑定的标准参数变量;幂运算、取模、函数调用、属性访问等一律禁止。这既杜绝了任意代码执行(提示注入无法通过恶意「公式」执行代码),也防止了资源耗尽攻击(如 9**9**9 造成的大整数运算)。

更进一步,模型生成的公式必须与系统内置的标准公式交叉验证:两者各自求值,偏差超过 0.01 万元即弃用模型公式、采用标准公式并在结果中留痕。以超额收益法为例,标准公式为

fee = min( max(R − R₀, 0)/100 × AVG × δ/100, AVG × cap/100 )

其中 R 为组合收益率、R₀ 为业绩基准、AVG 为日均资产规模(万元)、δ 为计提比例、cap 为计提上限比例。高水位法则为 max(NAV − HWM, 0) × Q × δ/100。金额一律采用财务四舍五入(ROUND_HALF_UP)而非编程语言默认的银行家舍入。这套护栏使得——如第 5 节所示——系统的金额正确性不寄托于任何特定模型的发挥。

2.3 双引擎与轻部署

每个智能体都以规则引擎兜底:优先调用基础模型,模型不可用(断网、无额度、超时、返回异常)时自动落到内置的正则+词典规则引擎。这保证了离线可演示、生产不中断。系统后端不加载任何本地模型,仅做 API/CLI 调用,常驻内存约 200 MB,可在 8 GB 内存的笔记本上独立部署。基础模型通道支持三种:Claude 订阅 CLI、Anthropic API、以及 OpenAI 兼容通道(可接 DeepSeek、GLM、Kimi、通义千问或本地 Ollama,仅需配置端点 URL、密钥与模型名)。

3 系统使用

系统以单页 Web 应用形式交付。业务人员的典型工作流为六步:(1)将合同 PDF 与报表 PDF 拖入页面;(2)点击「开始智能解析」,左侧流水线逐节点点亮、实时日志滚动展示各智能体的工作;(3)查看识别出的计提模式、应计提金额与条款摘录,悬停任一条款数值、参数行或公式变量可三处联动高亮(「三向锚定」),便于溯源;(4)在参数绑定表中核对带「需确认」标记的参数,可直接改值,缺失参数在标红行补录;(5)点击「确认参数·重新计算」即时刷新结果;(6)导出自包含的智能分析报告(含条款引用、参数绑定表、计算底稿),可打印存档。

部署与切换基础模型均通过环境变量完成,无需改代码:

export ANNUITY_PROVIDER=claude_cli ANNUITY_MODEL=opus  # 走订阅 export ANNUITY_PROVIDER=openai ANNUITY_OPENAI_BASE=https://api.deepseek.com/v1 … # 接第三方

系统内置三层测试:基础流水线(3 例)、基准评测集(18 例)、红蓝对抗集(28 例),可由 run_all_tests.sh 一键回归。

4 红蓝对抗鲁棒性实验

「在受控案例上算得对」不足以支撑落地——真实合同的起草者可能(在法律允许范围内)采用各种「文字游戏」,系统必须证明自己不会被误导而「自信地算错」。为此我们设计了三轮红蓝对抗:红队构造刁钻但合法的合同/报表,蓝队(防守方)每被攻破即修复根因(通用逻辑,而非针对测试样本打补丁),并要求前序全部表现零退步。

4.1 评分准则:区分「算错」与「诚实降级」

金融系统中,「算不出并提示人工介入」是可接受的安全降级,而「自信地给出错误金额」才是真正的失分。因此评分刻意区分二者:系统给出确定的错误金额、或误判计提模式且未告警,判为被攻破(攻击方得分);系统算对,或正确标记「需人工确认 / 无法计算」而未给出错误确定值,判为防御成功。这一准则契合金融场景「宁可提示人工,也不自信算错」的安全底线。

4.2 三轮战况与收敛

100% 60% 20% 21.4% 62.5% 83.3% 第 1 轮 (14 例) 第 2 轮 (8 例) 第 3 轮 (6 例) 首测防御率 修复后防御率
图 2 三轮红蓝对抗的防御率变化。首测防御率(橙)21.4%→62.5%→83.3% 单调上升,每轮修根因后均回到 100%(绿)。首测率的单调收敛表明暴露—修复循环趋于稳态。
表 1 三轮对抗概览。
轮次案例主要攻击方向首测修复后
第 1 轮14 (A01–A14)双口径、补充协议覆盖、定义分离、数值诱饵、大写/中文数词、复合基准、临界翻转、模式伪装、否定局部化、单位混淆、脚注覆盖21.4%100%
第 2 轮8 (B01–B08)覆盖式污染、覆盖后否定、多重覆盖、负向误伤、模式诱饵、单位盲区62.5%100%
第 3 轮6 (C01–C06)报表多指标干扰、上限被覆盖、净值语言伪装、份额异称、全角中文混排83.3%100%

4.3 典型攻击与根因修复

第 1 轮暴露的最危险两类:(i)「无中生有」——合同写「业绩基准为年化 3.60%(一年期 LPR)上浮 40 个基点,即年化 4.00%」,早期抽取贪婪地取到 LPR 基数 3.60% 而非落地值 4.00%;当组合收益率恰为 3.90% 时,真实超额为负、应计提 0,系统却凭空算出正的报酬。(ii)「上限失效」——计提上限正则首现命中诱饵「风险准备金合计不超 20%」,真实 0.5% 上限被架空,金额虚高 2.5 倍。根因在于抽取采用「取第一个正则匹配」。我们将其重构为「多候选收集 → 加权消歧 → 真歧义降级」:每个参数按多条角色正则收集全部候选,以权重表达「哪个才是有效值」(如「实际按/最终以…为准」高权重、「即年化 X%」取落地值、「名义/原」低权重);对风险准备金、投资比例等负向上下文的数值予以过滤;若消歧后仍存在等权多值,则标记为歧义、转「需人工确认」。计提模式判别亦从子串匹配升级为加权信号并剔除否定语境(识破「区别于高水位法」「不以净值创新高」)。

第 2 轮红队白盒攻击第 1 轮的加固逻辑本身,命中新引入的覆盖式弱点:通用的「由 X% 调整为 Y%」正则不限定主语,会把「递延部分由 30% 调整为 40%」误当作计提比例的覆盖;「须经理事会批准/方可生效」的被否定覆盖仍被采信;「由 25% 下调为 20%,后恢复为 25%」的多重覆盖只取首个。修复是将覆盖式从通用正则中移除,改由受控函数在「计提比例」引导句内解析——主语限定杜绝跨参数污染、剔除被否定的覆盖、多重覆盖取句内最终值。

第 3 轮作为收敛验证,仅打穿一个一致性缺口:第 2 轮的覆盖逻辑只施加于计提比例,未同步到计提上限,导致「上限被补充协议下调」未被识别。修复是将同构的覆盖解析一致地应用到计提上限。

工程启示 对抗的价值恰在于:第 1 轮的加固(覆盖式)正是第 2 轮的攻击面。这印证了「加固会引入新弱点,对抗必须多轮」;而三轮首测防御率的单调收敛,说明系统正逼近稳态。所有修复均为通用逻辑,28 个对抗样本仅作验证与回归,不是被硬编码的答案——它们已永久纳入回归测试集,今后每次改动都会重跑以防退化。

5 基础模型消融研究

课题将大模型接入计算全流程,一个关键问题随之而来:系统表现对基础模型的能力档位有多敏感?若强模型与弱模型表现相近,生产选型可优先考虑成本与延迟。我们据此设计消融实验。

5.1 实验设计

自变量(单一操纵变量):底层基础模型档位——纯规则引擎(无模型)、Claude Haiku、Sonnet、Opus。因变量:计提模式识别准确率、条款参数抽取准确率、人机计算一致率、单份平均耗时。控制变量:同一份 v0.3 代码、同一 8 案例基准子集与其人工手算真值、同一套提示词、同一评分脚本;唯一变化的是模型档位。评测子集覆盖两类支持模式与多种措辞难度(中文数词、干扰项、复合基准、单位换算、高水位、强负例)。

我们提出两个假设:H1(护栏拉平假设)——因金额由确定性引擎计算、规则引擎全程兜底,只要关键参数抽取正确,人机一致率即不依赖模型档位;H2(抽取梯度假设)——模型质量主要体现在条款抽取环节,强模型面对刁钻措辞应有更高准确率。

5.2 结果

100 50 0 规则引擎 Haiku Sonnet Opus 100 / 100 / 100100 / 100 / 100 100 / 100 / 100100 / 100 / 100 模式识别 参数抽取 人机一致
图 3 四档模型在 8 案例子集上的三项准确率(单位 %)。四档全部为 100%,无差异——直接支持 H1「护栏拉平假设」。
表 2 基础模型消融结果(8 案例子集,单次运行)。
档位模式识别参数抽取人机一致单份均耗时
规则引擎(无模型)100%100%100%0.003 s
Claude Haiku100%100%100%61.9 s
Claude Sonnet100%100%100%39.7 s
Claude Opus100%100%100%49.2 s

结果清晰:四个档位在三项准确率上高度一致,均为 100%(图 3、表 2),H1 得到有力支持——确定性护栏把模型能力的差异挡在了金额之外。真正被模型档位拉开数量级差距的是处理耗时(相差约五万倍);值得注意的是耗时甚至不随模型强弱单调(Sonnet 反快于 Haiku),因为在订阅 CLI 模式下每次调用的进程启动开销是耗时主体,而非模型净推理速度。

5.3 讨论:结论「太好」的边界

一个诚实的反问是:若规则引擎都能 100%,要模型何用?答案在评测集的难度带。本基准集的案例虽措辞刁钻,但都是规则引擎经三轮对抗加固后已能解析的结构化条款;在这类案例上,模型的语言理解优势没有用武之地。模型价值真正会显现的,是规则引擎失效的长尾疑难——自由格式的非结构化条款、需跨段推理的隐含约定、罕见计提模式、真正的语义歧义。因此本实验结论应严格表述为:在「规则可解」难度带内,模型档位不影响准确率、只影响成本与延迟;在「规则失效」难度带,模型质量的边际价值尚待更难的评测集检验。

一次被识破的「假成绩」 消融过程中我们接入第三方模型 DeepSeek 时,评测一度显示三项 100%,但实为假数据——因 TLS 证书问题,30 次模型调用全部失败并被规则引擎静默兜底。识别依据有三:每次调用都有 SSL 报错、单份耗时仅 0.2 秒(而真模型需数十秒)、参数计数与规则引擎完全一致。这一插曲揭示了一个重要原则:双引擎兜底在生产是优点,在实验中是陷阱——必须显式区分「谁真的算了这道题」。我们据此为评测器增加了调用统计与告警:模型通道一旦有失败即醒目提示,并在结果中标记 valid_for_ablation: false,杜绝此类假数据混入。

5.4 生产选型建议

基于「护栏拉平 + 规则碾压速度」,推荐分层调度而非单一模型:规则引擎处理绝大多数结构化条款(瞬时、零成本、经三轮对抗已足够稳健);仅当规则引擎判定「缺失/低置信/歧义」时才升级调用大模型;模型档位再按疑难难度分级(常规疑难用便宜快速的档位,复杂合同才动用最强档)。这样既守住准确率,又将 token 成本压到最低。换言之,本系统的价值不在于「接了多强的模型」,而在于「用确定性护栏让模型可错、用规则引擎让常规免费」。

6 开发历程与工程实践

本原型的演进本身即一份工程案例。系统从 v0.1 的最小可运行原型(多智能体骨架、安全公式引擎、SSE 前端、三组基础测试)起步;v0.2 引入 5 份仿真真实合同与 18 案例基准评测集,并经两路独立代码评审修复了 30 余处问题——其中包括 SSE 事件流的生命周期缺陷(重连导致事件重复且流永不终止)、单位不换算的「差一万倍」静默错账、报告 HTML 注入、公式引擎的幂运算 DoS、以及前端的存储型 XSS 等;v0.3 则完成三轮红蓝对抗加固与基础模型消融。

贯穿始终的工程纪律有三:其一,修根因而非补测试集——所有对抗修复都是通用逻辑,测试样本只作验证;其二,零退步硬约束——每轮修复后,前序全部对抗轮次、基准集、基础案例与真实合同一并回归,确保不为防新攻击而牺牲旧表现;其三,可复核留痕——每次变更一次提交,CHANGELOG 与开发日志完整记录暴露—修复—收敛的全过程,含前述「假成绩」事件的诊断与教训。

v0.1MVP 骨架 v0.2真实合同+评审+基准 v0.3三轮对抗+消融 v0.4→上线路线
图 4 原型演进时间线。每一阶段以量化门槛推进,v0.3 已完成对抗加固与模型消融。

7 讨论:局限与上线路径

能力边界。v0.3 的确定性计算引擎覆盖超额收益法(含上限封顶)与高水位法两类主流模式。基于 5 份仿真合同的实测暴露了四类待扩展模式:分档累进费率、多年考核期乘数、亏损结转台账、排名调节系数——前两者可通过扩充标准公式模板低成本支持,后两者需引入持久化台账或外部数据。

工程与合规缺口。当前任务状态存于内存(重启不可查),生产需落库并接入统一身份认证与不可篡改的审计日志;LLM 通道会外发合同文本片段,接入生产须按数据分级评估,必要时私有化部署模型或脱敏。

实验局限。消融为单次运行,未估计方差;严谨版应对每档每案例重复多次、报告均值与标准差,并在更难的「规则失效」难度带上复算,才能测出模型能力的上限。第三方模型(DeepSeek/GLM/Kimi)因评测环境的网络限制需在有公网出口的机器上补测,系统已通过 OpenAI 兼容通道预留接入能力。

上线路径。建议五阶段推进,每阶段设量化晋级门槛:原型验证(已完成)→ 离线盲测(30–50 份真实合同、双专家标注真值,抽取≥95%、一致率≥99%)→ 影子运行(机器与人工并行、月末比对、机器不进流程,一致率≥99% 持续一季)→ 辅助试点(机器初算+人工复核,修正率<5%)→ 正式上线(审计认可)。

8 结论

本文实现并系统评估了一套面向企业年金业绩报酬的多智能体自动提取与计算系统。其核心是「让 LLM 负责理解、让确定性引擎负责钱」的护栏式架构:三轮红蓝对抗证明系统在合法而刁钻的合同措辞下可算对或诚实降级,防御率经根因加固收敛至 100% 且零退步;基础模型消融揭示确定性护栏拉平了模型档位差异,为「规则打头阵、模型兜底疑难」的分层选型提供了实证依据。这套方法论——确定性护栏、双引擎兜底、多轮对抗、区分「算错」与「诚实降级」——为把大语言模型稳妥地嵌入金融计算流程提供了一个可复现的范例。系统在 8 GB 设备上即可部署,全部代码、测试集与文档均已开源留档。


参考文献

  1. 人力资源社会保障部、财政部. 企业年金办法(人社部、财政部令第 36 号). 2018.
  2. 人力资源社会保障部. 企业年金基金管理办法(人社部令第 11 号). 2011(后经修订).
  3. 中国人民银行等. 关于规范金融机构资产管理业务的指导意见(银发〔2018〕106 号,「资管新规」). 2018.
  4. 国家互联网信息办公室等. 生成式人工智能服务管理暂行办法. 2023.
  5. Goetzmann W N, Ingersoll J E, Ross S A. High-Water Marks and Hedge Fund Management Contracts. The Journal of Finance, 2003, 58(4): 1685–1717.
  6. Hendrycks D, Burns C, Chen A, Ball S. CUAD: An Expert-Annotated NLP Dataset for Legal Contract Review. NeurIPS Datasets and Benchmarks, 2021. arXiv:2103.06268.
  7. OWASP GenAI Security Project. OWASP Top 10 for Large Language Model Applications(含 LLM01 Prompt Injection). 2024.
  8. Board of Governors of the Federal Reserve System. SR 11-7: Guidance on Model Risk Management. 2011.
  9. NIST. Artificial Intelligence Risk Management Framework (AI RMF 1.0). 2023.
  10. Model Context Protocol (MCP) Specification. 2024.