复刻 FIS-Anthropic：我从零做了一个 AML 调查 agent

日期：2026-09-12

AIPA-120 长文#4（旗舰）· 方法论 · 本文以本仓库可运行的 AML 子系统（src/aml/）为标本，复刻 2026 年银行 agentic AI 第一落点——金融犯罪合规——的完整工程路径：从证据汇集（RRF）、类型学比对、SAR 生成、人工兜底（HITL）到不可篡改审计 trail，五段架构逐一拆解；再用一套诚实的 eval 体系说明"漂亮数字"该怎么读；最后算清每案件单位成本，复盘真实 failure war stories，论证"合规即架构"。对标 Citi「GenAI Architect」一类岗位的显式职责。

---

1. 引言：银行的第一个生产级 agent，为什么是金融犯罪合规

2026 上半年，三家在银行核心系统里有最深护城河的厂商，几乎同时把"第一个真正落地的 agentic AI"指向了同一个场景——反洗钱（AML）调查，而不是大家想当然的智能客服。这不是巧合，而是一个可以被工程化论证的选择。

FIS 与 Anthropic 在 2026-05-04 宣布合作，把第一个 agent 押在"Financial Crimes"，目标是把 AML 告警与案件调查"从数小时压缩到数分钟"（FIS press release，2026-05）。十天后的 2026-05-14，Fiserv 发布 agentOS，首发四个一方 agent 里就有一个是"Agentic AML Triage Analysis"（Fiserv / GlobeNewswire，2026-05）。再往前，Facctum 在 2026-03 把"transaction monitoring + 全程审计可溯源"列为行业基线能力（Facctum，2026-03）。这三件事拼出一条清晰的产业判断：银行 agentic AI 的第一桶金，在金融犯罪合规。

为什么是它，而不是客服？我把决策逻辑拆成三条，恰好对应一个产品经理/架构师评估 AI 落点时该问的三个问题：

• 高价值（value density 足够高，养得起 agent）。 AML 是劳动密集型黑洞：行业误报率长期卡在 85%–95%（Facctum 2026 报告，2026-03），合规团队最多有 90% 的调查时间花在最终不立案的噪声上，EY 实践显示 AI 把调查时长砍约 50%（EY，2025-11）。客服省的是几分钟话术，AML 省的是调查员一上午的逐笔翻账——同一次 agent 调用，后者边际价值高一个数量级。
• 强审计（场景本身要求留痕，与 agent 可观测性天然契合）。 SAR（Suspicious Activity Report，可疑活动报告）写错了，要被 FinCEN、被监管现场检查（exam）翻出来追责。这场景先天就要求"谁、何时、基于哪笔交易、做了什么判断"全程可回放——而这恰好是 agent trace + 审计 trail 能给的东西。监管的留痕需求和 agentic 系统的可观测性需求，在这里是同一件事。
• 强人工兜底（HITL 是法定环节，不是产品妥协）。 SAR 签字权在人，agent 永远是"调查员副驾"而非"代签人"，FIS 反复强调"investigators remain in control of every decision"（FIS，2026-05）。这把"模型偶尔出错"从致命缺陷降级成一个可被流程吸收的成本——最终落笔的人会兜住。客服 agent 直接面客、没这层强制兜底，反而更难上生产。

所以这篇旗舰长文不讲愿景，讲工程。我用本仓库 src/aml/ 这套可运行子系统，把 FIS-Anthropic 新闻稿里抽象的五个能力——assemble evidence / evaluate typologies / draft SAR / surface highest-risk / traceable & auditable——逐段落地成代码、eval 和成本账，并诚实标注每处"做到了什么、哪里是原型、离生产还有多远"。

---

2. 市场时间窗：2026 上半年发生了什么

在动手前先确认时效——这是本项目的硬规则。下面这张表把四个关键事件按时间排好，它们共同定义了"现在做 AML agent 是不是踩在风口上"。

表 1：2026 银行 AML agentic AI 时间窗（关键事件）

读这张表，我得到三个对产品决策直接有用的结论：

第一，时间窗是真的，且很窄。 FIS GA 在 2026 H2、Fiserv GA 在 2026-08，意味着到 2026 年底，"AML triage agent"会从"前沿 demo"变成"采购清单上的标准项"。一个想进金融 AI 赛道的产品人/架构师，要在这扇窗关上之前拿出"我理解这套系统怎么搭"的证据。

第二，误报率 85%–95% 是这门生意的全部经济学。 agent 的核心价值主张不是"更准地抓坏人"（召回提升空间有限且风险高），而是"在不漏抓的前提下，把调查员从 85%+ 的噪声里解放出来"。这是一个省人力、不省合规责任的价值主张。任何夸大"AI 替代调查员"的方案都会撞上监管的人工兜底要求。

第三，架构跟着合规走。 FIS 强调"client data stays within FIS-controlled infrastructure""every agent decision traceable and auditable"；Fiserv 强调"policy controls, auditability and human oversight embedded in the design"。两家不约而同把"数据驻留 + 可审计 + 人工监督"放在架构第一性原则上。这直接决定了我下面五段架构里，"审计 trail"和"HITL"不是附属功能，而是承重墙。

---

3. 架构五段：把新闻稿翻译成可运行的代码

FIS 新闻稿那五个能力，本仓库 src/aml/ 逐一对应实现。我按调查员真实的工作流顺序——证据汇集 → 类型学比对 → SAR 生成 → HITL → 审计 trail——拆成五段，每段先讲生产系统该怎么做，再讲本仓库原型做到了哪一步、诚实差距在哪。

3.1 证据汇集（evidence assembly）：RRF 思路下的多源融合

FIS 的原话是 agent 在"case open"时"automatically assembles evidence across a bank's core systems"。生产里，一个 AML 案件的证据散落在核心账务、支付清算、KYC/客户主数据、制裁名单、历史 SAR 等异构系统里。把它们汇集成一份调查员能直接读的"案件包"，本质是一个多源检索 + 排序融合问题——和 RAG 里的 RRF（Reciprocal Rank Fusion，倒数排名融合）同构：每个数据源给出一路候选证据 + 各自的相关性排名，再用 RRF 把多路排名融合成一个统一的证据序，让"既出现在可疑交易里、又命中风险标记、还关联历史告警"的证据浮到最上面。

本仓库 types.ts 把案件证据建模成强类型契约：AmlCase 聚合 parties（含 riskFlags，如 new_account / high_risk_geo / pep / prior_sar）、accounts（含 openedDaysAgo）、transactions（含方向/渠道/整数分金额/dayOffset）。typology.ts 的规则命中（RuleHit）则给每条命中带上 evidenceTxIds——这就是融合后排到最前的证据交易，直接供 SAR 引用和 UI 高亮。

诚实差距：本仓库是单源合成数据，没有真正跨系统拉取，所以这里的"融合"退化成"在一个数据集内按规则得分排序"。真 RRF 需要多路真实数据源同时在线。但这套类型契约（强类型 + 证据可溯源 ID）就是为多源融合预留的接口——把 transactions 换成跨核心系统拉回的真实流水、把 riskFlags 换成实时 KYC/制裁命中，融合逻辑可以无缝套上去。一个工程纪律值得点名：金额一律用整数分（amountCents: number），禁止 float 货币运算，避开浮点累加误差与 SAR 金额对账错位——这是 10 年金融系统经验留下的肌肉记忆。

3.2 类型学比对（typology matching）：确定性规则引擎做"诚实基线"

FIS 说 agent"evaluates activity against known typologies"。AML 类型学是反洗钱的"病理学图谱"：structuring（拆分存款贴线规避 CTR 申报）、layering（分层快进快出冲淡资金来源）、mule_network（骡网络 fan-in 后快速转出）。本仓库 typology.ts 把这三类经典类型学落成确定性规则引擎，每条规则带显式阈值常量和监管依据注释。例如 structuring 的主规则 STRUCT-01：

≤10 天窗口内 ≥3 笔 $8,000–$10,000（不含）现金存款 → 判定为刻意贴线规避 CTR（美国 BSA 现金交易报告门槛 $10,000，FinCEN Form 112）。

每条规则吐出 RuleHit{ ruleId, typology, description（含触发的具体数值）, evidenceTxIds, score }，多条命中按主规则 0.6 / 辅规则 0.4 聚合到各类型学得分，最高分过 0.5 阈值（ASSESS_THRESHOLD）才输出 topTypology。

为什么旗舰系统第一层偏要用规则而非 LLM？因为它要当诚实基线（honest baseline）——整套 eval 体系的锚点（第 4 节）：你必须先有一个透明、可逐条审计的规则基线，才能回答"LLM 比规则强在哪、强多少、值不值那个 token 成本"。规则引擎每次判定都能在审计里写清"命中 STRUCT-01，证据是 T0007/T0011/T0019 三笔贴线存款"——这种逐条可溯源性恰是监管最想要的。

3.3 SAR 生成：LLM 起草，但戴着三层镣铐

FIS 说 agent"enhances SAR narrative quality"。SAR 叙述是 AML 调查的最终交付物，要按 FinCEN 的 5W1H（who/what/when/where/why/how）结构把可疑活动讲成监管看得懂的故事。这是唯一一个 LLM 真正不可替代的环节——规则引擎能判类型、能列证据，但把一串 RuleHit 写成连贯、有说服力、经得起 exam 的英文叙述，是语言模型的主场。

本仓库 sarDraft.ts（规则模板版）+ sarNarrative.ts（LLM 版接口）分两层实现，并诚实标注 generatedBy: 'rule-template'，避免把模板拼接冒充成"AI 生成"。LLM 版的 prompt 设计戴了三层镣铐，每层都对应一类可被 eval 抓的失败：

1. 防幻觉约束：叙述只能引用 citedTxIds 里真实存在于本案的交易 ID（evalChecks.ts 的 cited_tx_exist 检查会逐案验证引用的交易确实存在，否则判 hallucination）。
2. 结构约束：必须产出 ≥5 个 5W1H 段落（sar_min_sections 检查），少一个就判 format_violation。
3. 合规披露约束：叙述头部强制嵌入 EU AI Act Article 50 要求的 AI 生成披露 + 待人工复核标注（sarNarrative.ts，对应 Article 50 透明义务 2026-08-02 生效）。

这三层镣铐的设计哲学是：LLM 负责"写得好"，确定性检查负责"不写错"。 创造性留给模型，安全边界留给代码。

3.4 HITL：人工兜底不是按钮，是法定签字权

FIS 反复强调"investigators remain in control"。本仓库把 HITL 建模成 ReviewAction = 'approve' | 'return' | 'edit'——调查员可以批准、打回重做、或直接改写 agent 的草稿。关键设计原则：agent 的输出永远是"草稿"，落笔签字权在人。 系统对 SAR 的状态机里，没有任何一条路径能让 agent 绕过人工直接提交。

这不是产品保守，是法定要求。SAR 一旦提交即产生法律效力，签字人承担个人责任。所以 HITL 在这套架构里是承重墙而非装饰——它把"模型会出错"这个根本不确定性，转化成调查员日常就在做的复核动作。产品上真正要优化的不是"减少人工"，而是"让人工复核每案的时间从 1 小时降到 5 分钟"：agent 把证据列好、类型学判好、叙述写好，人只做"批准/打回/微调"的高价值判断。

3.5 审计 trail：append-only 哈希链，篡改可检测可定位

FIS 说"every agent decision is traceable and auditable"。本仓库 auditTrail.ts 把它实现成 append-only 事件日志 + 哈希链：每条 AuditRecord 的 hash = hasher(seq | prevHash | canonical(payload))，其中 prevHash 是上一条的 hash——形成 Merkle 式链式结构。任意一条历史事件被改动，其后所有记录的 hash 校验都会失败，verify() 能定位首个被篡改的序号。actor 区分 investigator / system / llm / reviewer，所以"这句叙述是 LLM 写的、这个判定是规则引擎出的、这次批准是张三在 14:32 点的"全部可回放。

诚实标注（直接抄自源码注释）：哈希用的是 FNV-1a（32-bit，纯算术、零依赖、确定性），不是密码学安全哈希——能检测无意篡改与作教学演示，但对蓄意抗碰撞攻击不安全。源码留了 setHasher() 注入口，生产应换 SHA-256（node:crypto / SubtleCrypto）+ WORM（一次写入多次读取）防篡改存储。这个诚实标注本身就是合规思维：监管不接受"我以为安全"，只接受"我知道边界在哪、生产怎么补"。

表 2：FIS 五能力 → 本仓库实现 → 诚实差距

---

4. eval 体系：诚实地知道 agent 到底行不行

旗舰系统和玩具 demo 的分水岭，是有没有一套能诚实回答"它到底行不行"的 eval。这套 AML agent 的 eval 体系我分四层，每层都对应一个具体的、容易自欺的陷阱。

4.1 规则基线：recall 1.0 / FPR 5.6% 的诚实解读

evalBaseline.ts 在 66 案金标数据集（generator.ts 按真实类型学合成，每案带 ground-truth label）上跑规则引擎（evalRuleBaseline），得到典型结果：三类类型学 recall ≈ 1.0，normal 案件的 normalFalsePositiveRate ≈ 5.6%。

这两个数字漂亮，但必须诚实解读：这不是"性能指标"，而是"口径一致性指标"。原因是，金标数据集是用同一批类型学定义合成的，规则引擎再去判它——这本质是在测"我的合成器和我的判别器口径一致吗"，而不是"我的判别器在真实世界多准"。recall 1.0 只证明：我注入数据的类型学定义，和我检测数据的类型学规则，没有内部矛盾。把这个 1.0 写进简历说"我的 AML 系统召回率 100%"，是赤裸裸的自欺。

诚实的读法是：规则基线 = 一条性能下界 + 一个内部自洽性回归绊线。 它的真正用途有两个：(a) 给 LLM 一个必须打败的对手；(b) 在 CI 里当 tripwire——哪天有人改坏了规则或合成器，recall 会掉、FPR 会涨，CI 立刻红。那个 5.6% 的 FPR 同样要诚实看：它是合成 normal 案件里"长得像 structuring 的合法营业款"被规则误伤的比例，反映的是规则阈值的边界张力，而非真实客群的误报率。

4.2 代码型检查：能用断言判的，绝不浪费 LLM

evalChecks.ts 是 Hamel/Shreya evals 工作流最后一层"code-based check"的落地：凡能用确定性断言判定的失败，就不该浪费 LLM-as-judge（hamel.dev，2026-01）。它对每个案件的（评估 + SAR 草稿）跑五条断言，并把失败归桶到 failureTaxonomy 的失败类别：

• sar_min_sections（≥5 段）→ format_violation
• cited_tx_exist（引用的交易必须真实存在）→ hallucination
• cited_tx_nonempty（有判定就必须有证据）→ retrieval_miss
• top_typology_consistent（topTypology 与最高分项自洽）→ typology_misjudge
• amount_money_format（金额必须整数分）→ format_violation

codeCheckPassRate() 把全数据集的（案件×检查）聚合成 CI 质量门指标，并按失败类别计数——这样错误分析能直接看到"这版主要错在哪一类"。这层最划算：零 token 成本、确定性、可进 CI/CD。

4.3 LLM 必须打败基线 + judge 校准

第三层才轮到 LLM-as-judge，去判规则判不了的东西：SAR 叙述的质量（连贯性、说服力、是否抓住了案件要点）、细粒度幻觉（引用真实但解读错误）。这里有两条铁律：

1. LLM 版必须打败规则基线，否则没有上线理由。 如果 LLM 起草的 SAR 在质量 judge 上不显著优于模板拼接，那为它付的 token 成本和延迟就是纯亏。基线的存在就是为了逼出这个问题。
2. judge 本身必须被校准。 LLM judge 不是真理机器，它自己也会偏。所以要用 Cohen's kappa 衡量 judge 与人类标注者的一致性——kappa 校准 judge 的可信度，再用人工抽检（每 2–4 周抽 100+ 条新鲜 trace，外加每周 10–20 条异常 trace 轻量复审）校准整个系统。judge 没校准就拿它的分数做决策，等于用一把没校准的尺子量东西还信誓旦旦报小数点。

4.4 人工抽检：失败分布会漂移

最后一层是人工抽检，它防的是"失败分布漂移"——上线后真实案件的失败模式会和合成数据不同，且随时间变化。eval 不是一锤子买卖，是持续工程。这一层产出的真实 failure trace，又回流去更新 failureTaxonomy，闭环。

表 3：四层 eval 分工与诚实边界

---

5. 每案件单位成本：$/案件三段分解

旗舰系统要能上预算评审，就得回答"一个案件花我多少钱"。我把每案件单位成本拆成三段，这也是向银行 CFO 解释 ROI 时的标准话术：

表 4：每案件单位成本三段分解（量级示意，非真实账单）

关键洞察：成本的大头不是模型，是人。 一次 SAR 起草的 token 成本（第①段）只有几美分到几角，但持牌调查员复核一个案件（第③段）的人力成本是它的几十上百倍。所以这套 agent 的经济学不是"省 token"，而是"用几角钱 token + 近乎零成本规则引擎，把第③段从 1 小时压到 5 分钟"——正好对上 FIS 新闻稿三个目标"reducing cost per case / reducing low-value manual work / cutting case review time"，全部指向第③段。

这也解释了第①段为何做"便宜档位起草 + 贵档位仅校验"分层：起草高 token、容错，用便宜模型；校验低 token、高风险，才动贵模型。而第②段近乎免费，正因类型学这层坚持用确定性规则而非 LLM——若连"判是不是 structuring"都丢给模型，单位成本会被无谓抬高一个量级。这是第 3.2 节"规则做诚实基线"决策的成本回报。

---

6. failure war stories：从真实 traces 里学到的

eval 跑出来的不只是数字，还有具体的失败故事。下面三个是从本仓库 trace 里抽象出的典型 failure，每个都对应一类要写进 runbook 的教训。

War story #1：贴线带的边界陷阱（typology_misjudge）。 structuring 规则的"贴线带"下限设在 $8,000（STRUCT_BAND_MIN_CENTS）。早期有个 normal 案件，客户连续存了几笔 $7,900 的合法现金营业款，规则没命中——对的。但如果把下限调到 $7,500 去"提高召回"，这批合法存款立刻被误判成 structuring，FPR 飙升。教训：AML 阈值是召回与误报的零和博弈，每一个常量都要有监管依据背书，不能拍脑袋调参去刷召回。 这就是为什么 typology.ts 里每个阈值常量都带注释写明依据。

War story #2：引用了不存在的交易（hallucination）。 LLM 版 SAR 起草曾出现"叙述里写了一笔 T0099，但本案根本没这笔交易"。这是经典的引用幻觉。evalChecks.ts 的 cited_tx_exist 断言专门抓它——逐案验证 citedTxIds 全部真实存在，否则判 hallucination。教训：LLM 写的任何"事实性引用"都必须有确定性检查兜底，不能信它的自觉。

War story #3：判了类型却没给证据（retrieval_miss）。 有案件 topTypology 非空（判了 layering）但 SAR 的 citedTxIds 为空——"我说他洗钱，但拿不出哪笔交易"。这在监管面前是灾难。cited_tx_nonempty 断言强制：有判定就必须有证据，normal 案件（无判定，topTypology=null）才允许无证据。教训：结论和证据必须强绑定，"无证据的指控"在合规系统里等于零。

这三个 story 的共性：它们都是被确定性 eval 抓住的，不是被 LLM judge 抓住的。 再次印证第 4 节的分工——能用代码断言抓的失败，永远优先用代码抓，又快又准又免费。

---

7. 合规即架构：监管约束直接长进系统骨架

这套系统最值得拿去面试讲的，是"合规不是事后贴的标签，是写进架构第一性原则的承重结构"。两个最硬的例子：

Article 50 标注（透明义务）。 EU AI Act Article 50 于 2026-08-02 生效，要求 AI 生成内容必须标注 + 机器可读标记。本仓库 sarNarrative.ts 把这条直接焊进 SAR 叙述头部——每份 LLM 起草的 SAR 强制带"【AI 生成披露】本叙述由生成式 AI 起草……依据 EU AI Act Article 50……需人工复核"。这不是 UI 上一个可关的提示，是叙述文本不可分割的一部分。合规要求 → 输出格式约束 → eval 断言，一条链焊死。

不可篡改审计（可问责）。 auditTrail.ts 的哈希链对应一整套监管框架（源码注释逐条标注）：SR 11-7 模型风险管理（2011 美联储/OCC，要求模型决策可追溯可复核，三道防线）、DORA 运营韧性（EBA 报告 2025-11，要求关键流程留痕、事件可重建）、NIST AI RMF + GenAI Profile（2024-07）、ISO/IEC 42001:2023（AI 管理体系）。这些框架的共同诉求——"谁在何时基于什么证据做了什么决定，必须不可篡改"——被直接翻译成"append-only + 哈希链 + actor 区分 + verify() 定位篡改点"。

合规即架构的方法论一句话总结：把每一条监管要求，翻译成一个可被 eval 验证的系统不变量（invariant）。 Article 50 → "每份 SAR 必带披露段"；可问责 → "审计链 verify() 必须 ok"；人工兜底 → "状态机无路径让 agent 绕过 HITL"。监管不再是合规部门的 PDF，而是工程师 CI 里的红绿灯。这正是 agentic 系统在强监管行业能上生产的前提——可观测性与可审计性，本就是 agent 架构和金融监管的最大公约数。EU 单一 AML 规则手册将于 2027-07-10 适用，监管口径从"告警是否触发"转向"触发是否合理且可论证"，规则基线的逐条可解释性正好踩在这趋势上。

---

8. 结语：对标 Citi GenAI Architect

把这套 AML agent 通读一遍，它其实是一份针对"金融机构 GenAI Architect / AI 产品架构师"岗位的能力证明。以 Citi 一类银行的"GenAI Architect"JD 为镜，这套系统恰好打中它最看重的几条：

• 能把前沿模型落进强监管场景：不是做 demo，是带着 SR 11-7 / DORA / EU AI Act / FinCEN 5W1H 的约束做工程——合规是设计输入，不是验收障碍。
• 能定义并维护 eval 体系：四层 eval、规则基线的诚实解读、LLM 必须打败基线、Cohen's kappa 校准 judge——这正是 Anthropic / LangChain 的 Solutions Architect / Forward-Deployed 岗 JD 里"为客户设计并维护 eval 套件"的同款能力。
• 能算清单位成本：$/案件三段分解，知道大头在人不在模型，知道优化杠杆在哪——这是架构师而非纯工程师的视角。
• 能把可审计性当承重墙：哈希链审计 trail + HITL 法定签字权 + Article 50 标注，全程可回放可问责。

而我的差异化在于那 10 年金融零售背景：整数分记账纪律、对 CTR/SAR/FinCEN 流程的熟悉、对"省人力但不省合规责任"这条经济学红线的直觉——这些不是看几篇论文能速成的。FIS-Anthropic、Fiserv agentOS 打开的这扇窗在 2026 H2 就要变成行业标配，能拿出"我从零搭过这套系统、且诚实知道它每一处边界"的证据的人，才接得住这个时间窗。

---

SOTA 检查（2026-06-11 更新）

• 当前主流方案：银行 AML agentic AI 的 2026 SOTA 由两条主线定义——(1) 核心系统商 + 前沿模型商深度绑定：FIS × Anthropic Financial Crimes AI Agent（2026-05-04 宣布，GA 计划 2026 H2，BMO/Amalgamated 试点，Claude 提供推理、FIS 提供数据与治理层，Anthropic Applied AI / FDE 团队驻场共建）；(2) 核心系统商自建 agent OS：Fiserv agentOS（2026-05-14 发布，GA 预计 2026-08，AML Triage 为首发一方 agent，跑在 AWS Bedrock AgentCore，部分一方 agent 与 OpenAI 共建）。Facctum（2026-03）代表"transaction monitoring + 全程审计可溯源"的行业基线能力。
• 是否仍是 SOTA：是。截至 2026-06-11，"证据自动汇集 + 类型学比对 + LLM 起草 SAR + 强 HITL + 不可篡改审计"这套五段架构仍是银行金融犯罪合规 agent 的主流形态，且尚处 GA 前夜（两家 GA 都在 2026 下半年），是当下最热的落地窗口。
• 是否有更新替代品 / 待观察：(1) FIS / Fiserv 两家 GA 后的真实生产指标（误报降幅、$/案件、调查时长）将取代当前的咨询侧估算（EY 约 -50% 调查时长，2025-11），届时需用真实数据重校本文成本表（第 5 节）。(2) EU AI Act Article 50 透明义务 2026-08-02 生效、EU 单一 AML 规则手册 2027-07-10 适用，会进一步抬高"可解释 + 可审计"的强制门槛——监管口径从"告警是否触发"转向"触发是否合理且可论证"，对规则基线的可解释性是利好。(3) 本文实现层面的已知差距（FNV-1a 非密码学哈希、单源合成数据、LLM judge 未接真模型评分）均已在正文诚实标注，是后续 P3+ 的补强项。
• 本文时效声明：本文为 2026-06 时点的工程复刻与市场分析，主线案例（FIS/Anthropic、Fiserv agentOS、Facctum、EY）均为近 12 个月内发布；两家 GA 落地后请以官方披露的真实生产指标为准更新第 2、5 节。