1. 从financial-services这个标题说起一个被低估的工程化命题第一次看到financial-services这个标题很多人第一反应是这不就是个行业分类吗。但如果你真的在金融科技领域待过就会明白这四个字背后压着的东西有多重。金融行业的软件系统从来不是能跑就行——它要面对的是毫秒级的交易延迟、动辄七位数的资金流水、监管层面的审计追溯以及一旦出错就可能上新闻的容错底线。所以当我拿到这个标题结合关键词里出现的 Claude、Cowork、Managed Agents API、plugin 这些词我基本能判断出这个项目的真实意图用 AI Agent 的方式去构建一套面向金融业务场景的协作与自动化服务体系。这个判断不是拍脑袋。你看关键词的组合逻辑——Claude 是模型底座Cowork 指向多智能体协作Managed Agents API 是把 Agent 能力封装成可调用的服务接口plugin 则是扩展机制。这四个词串起来就是一条完整的AI 能力工程化落地链路。而financial-services作为标题说明这套东西不是通用玩具而是瞄准了金融这个对准确性、可审计性、权限控制要求极高的垂直领域。我写这篇东西的目的很直接把这条链路拆开讲清楚每个环节在金融场景下该怎么设计、为什么这么设计、实际落地时会撞上哪些墙。适合的读者是那些已经用过 Claude 或类似工具、想把它往生产系统里塞的工程师以及正在评估AI Agent 能不能进我们业务的技术负责人。如果你只是想了解 Claude 怎么注册、怎么装那网上教程一抓一大把我这里不重复那些。需要先说明一点金融场景对 AI 的态度是用其长、避其短。模型擅长的是理解、归纳、生成、编排不擅长的是精确计算和最终决策。所以整套架构的核心思路是让 Agent 做它擅长的事把确定性逻辑和资金操作牢牢锁在传统代码里。这个边界意识是后面所有设计的前提。2. 为什么金融场景需要 Agent 协作而不是单点调用2.1 单模型调用的天花板在哪里大部分人接触 Claude 是从对话开始的问一句答一句顶多挂个 API 做批量处理。这种模式在金融业务里很快就会撞墙。原因很简单一个真实的金融工作流比如客户提交了一笔跨境汇款申请需要完成合规审查、汇率锁定、反洗钱筛查、账务记账、回执生成这里面涉及至少五六个专业环节每个环节需要不同的知识、不同的数据源、不同的权限。你当然可以把所有东西塞进一个超长 prompt 里让模型一次性输出。我试过结果是灾难性的。模型会在合规判断上给出模棱两可的结论会在汇率计算上出现幻觉更致命的是——你无法追溯它到底是基于哪条规则做出的判断。金融业务最怕的就是黑箱决策监管来查的时候你说模型这么认为的这等于自爆。所以单点调用的天花板不在能力而在可解释性和责任边界。一个 Agent 干所有事出了问题你连定位都定位不了。2.2 Cowork 模式解决的核心矛盾Cowork 这个词翻译过来就是协同工作它对应的是多智能体架构。核心思路是把一个大任务拆成若干子任务每个子任务交给一个专门的 AgentAgent 之间有明确的输入输出契约。放到金融场景里这个拆法就非常自然了。合规审查 Agent 只负责读规则库、比对交易特征、输出通过/拒绝/需人工复核三态结论汇率 Agent 只负责对接行情源、计算锁定价格记账 Agent 只负责生成符合会计准则的分录。每个 Agent 的职责单一意味着它的 prompt 可以写得非常聚焦它的输出格式可以被严格约束它的行为可以被单独测试和审计。这里有个关键设计点Agent 之间不直接对话而是通过结构化的消息总线传递数据。我见过一些实现让 Agent 互相聊天来协作在金融场景下这是大忌。因为自然语言传递会引入歧义和不可控的语义漂移而结构化消息比如 JSON Schema 约束的对象可以做到字段级校验。一个 Agent 输出的risk_level: high下一个 Agent 拿到的一定是字符串high不会变成风险较高这种模糊表述。2.3 协作架构下的责任追溯金融系统有个硬性要求任何一笔业务操作都要能回答谁在什么时候基于什么依据做了什么决定。多 Agent 架构天然适合这个要求因为每个 Agent 的输入、输出、调用的工具、消耗的时间都可以被完整记录。我的做法是给每个 Agent 调用都生成一条审计日志包含agent_id、task_id、input_hash、output、tool_calls、timestamp、model_version这些字段。这样当监管问这笔交易为什么被拒时你可以精确地拉出合规 Agent 当时读到的规则版本、比对的具体字段、以及它引用的规则条款编号。这套东西用单模型是做不到的因为单模型的中间推理过程是不可见的。提示审计日志的存储要和业务数据库分离用只追加append-only的方式写入防止被篡改。金融场景下日志本身就是合规资产。3. Managed Agents API 在金融业务里的接入姿势3.1 托管 Agent 与自建 Agent 的取舍Managed Agents API 的核心价值是把 Agent 的运行环境、工具调用、状态管理这些脏活累活托管出去你只需要定义 Agent 的行为和它能用的工具。对金融团队来说这个取舍很现实自建一套 Agent 运行时你要处理并发、重试、超时、工具沙箱、上下文窗口管理这些工程量不小而且容易出安全漏洞。但托管不等于甩手。金融场景有几个特殊约束必须自己把控数据不能出境、敏感字段必须脱敏、工具调用必须白名单。所以我的建议是分层——把 Agent 的编排逻辑和工具定义放在托管侧把真正接触敏感数据的工具实现放在自己的内网通过受控的接口暴露给 Agent。这样既享受了托管的便利又守住了数据边界。具体来说Agent 需要调用的工具分三类只读查询类查客户信息、查行情、查规则库、计算类算汇率、算手续费、算账务分录、写入类提交审批、发起记账。前两类可以相对开放第三类必须加人工确认或双人复核。这个分级不是技术问题是业务风控问题但必须在 API 接入设计时就体现出来。3.2 工具定义的 Schema 设计要点Managed Agents API 里工具是用 JSON Schema 描述的。这个 Schema 写得好不好直接决定 Agent 会不会乱调工具。金融场景下我总结了几个必须遵守的规则。第一所有金额字段必须用字符串加货币单位不能用浮点数。这不是矫情浮点数在金融计算里的精度问题能让你在对账时怀疑人生。Schema 里定义成{type: string, pattern: ^\\d(\\.\\d{1,2})?$}配合一个currency枚举字段。第二枚举值要穷举不要留开放字符串。比如交易状态宁可定义[pending, approved, rejected, manual_review]四个值也不要让模型自由发挥。模型一旦输出probably_ok这种值下游系统直接崩。第三必填字段和可选字段要分清且必填字段越少越好。每多一个必填字段模型出错的概率就上升一点。把非核心信息设计成可选让 Agent 在信息不足时能优雅降级而不是硬编一个值出来。下面是一个合规审查工具的 Schema 示例我简化过{ name: check_compliance, description: 对一笔交易执行合规规则检查返回三态结论, input_schema: { type: object, properties: { transaction_id: {type: string}, amount: {type: string, pattern: ^\\d(\\.\\d{1,2})?$}, currency: {type: string, enum: [CNY, USD, EUR, HKD]}, counterparty_country: {type: string}, business_type: {type: string, enum: [trade, service, capital]} }, required: [transaction_id, amount, currency, business_type] } }注意counterparty_country我故意设成可选。因为实际业务里有些交易对手国信息可能缺失如果设成必填模型可能会编一个出来。设成可选模型在缺失时就会走信息不足需人工复核的路径这才是安全的。3.3 上下文管理与成本控制金融业务的对话往往很长一个客户经理可能连续处理几十笔业务。如果把所有历史都塞进上下文token 成本会爆炸而且模型注意力会被稀释。我的做法是按业务实体做上下文隔离——每笔交易是一个独立的会话上下文处理完就归档不带到下一笔。同时用 Agent 的 memory 机制存一些跨会话的稳定信息比如客户的风险等级、历史异常记录。这些信息用摘要形式存储而不是原始对话。实测下来这样能把单笔业务的 token 消耗压到全量上下文的五分之一左右而且模型判断的准确率反而更高因为干扰信息少了。注意上下文隔离的边界要和业务实体对齐。如果一笔业务涉及多个关联交易那这些交易应该共享一个上下文否则 Agent 看不到关联关系反洗钱筛查会漏。4. Plugin 机制把金融规则做成可插拔的模块4.1 为什么规则要插件化金融行业的规则变化频率远超一般软件。今天监管发个文明天某个业务的开户门槛就变了这个月汇率政策调整下个月跨境汇款的材料要求就不一样。如果把这些规则硬编码在 Agent 的 prompt 里每次变更都要改 prompt、重新测试、重新上线运维成本高得离谱。Plugin 机制解决的正是这个问题。把每一类规则封装成一个独立的插件插件对外暴露标准的接口Agent 通过调用插件来获取规则判断结果。规则变了只改插件内部实现Agent 侧完全无感。这就像给系统装了一排可热插拔的保险丝哪根烧了换哪根不用动整个电路。我实际落地时的插件划分是这样的合规规则插件、费率计算插件、账务规则插件、报表格式插件。每个插件有独立的版本号Agent 调用时指定版本这样即使插件升级了正在处理中的业务仍然用旧版本保证一致性。4.2 插件的接口契约设计插件接口设计有个核心原则输入输出必须是纯数据不能有副作用。也就是说插件只能做给定输入返回输出的纯函数式操作不能自己去写数据库、发消息。所有副作用由 Agent 编排层统一处理。这样做的好处是插件可以被无限次重放和测试。你拿一笔历史交易的数据喂给插件得到的结论应该和当时完全一致。这对金融审计太重要了——监管要求你能复现任何一笔历史决策如果插件有副作用复现就无从谈起。接口的输入我用一个统一的RuleContext对象包含交易信息、客户信息、时间戳、以及一个rule_version字段。输出用RuleResult包含decision三态、matched_rules命中的规则 ID 列表、reason人类可读的说明。matched_rules这个字段是审计的关键它让每个决策都能追溯到具体规则条款。4.3 插件加载与热更新的工程细节插件热更新听起来美好做起来有坑。最大的坑是更新过程中的请求一致性。如果插件正在被 100 个并发请求调用你这时候替换插件文件可能出现一半请求用旧版、一半用新版的情况对于金融业务这是不可接受的。我的方案是双缓冲加载新版本插件先加载到一个新的命名空间等所有在途请求处理完再原子性地切换指针。切换的瞬间新请求走新版老请求继续走老版直到结束。这个机制需要插件本身是无状态的这也印证了前面说的纯函数原则。另外插件的依赖要锁死。金融插件可能依赖一些计算库这些库的版本必须固定不能出现今天装了个新版本计算结果变了的情况。我用 lock 文件加哈希校验加载时先验证插件包的完整性防止被篡改。5. 从开发到生产的完整落地路径5.1 环境准备阶段容易忽略的事搭这套东西环境准备阶段有几个细节特别容易被忽略。第一是模型版本锁定。Claude 的模型会迭代不同版本的行为可能有细微差异。金融业务要求可复现所以生产环境必须锁定具体的模型版本号不能写latest。升级模型版本要走完整的回归测试流程就像升级数据库一样严肃。第二是网络出口的白名单。Agent 调用外部工具时出口必须严格限制。我见过有团队图省事开了全通结果 Agent 被 prompt 注入攻击后去调了一个不该调的接口。金融系统的网络策略应该是默认拒绝逐个放行。第三是密钥管理。API key、数据库密码这些绝对不能写在代码或配置文件里。用专门的密钥管理服务配合短时效的临时凭证。Agent 每次调用工具时动态获取凭证用完即弃。5.2 灰度发布与回滚策略金融系统上线新功能灰度是必须的。我的做法是按业务量比例灰度先放 1% 的流量走新 Agent 流程同时保留旧的人工流程作为对照。对比两个流程的结论差异如果差异率超过阈值就自动回滚。这里有个关键指标叫决策一致率。新 Agent 和旧流程对同一笔业务的判断一致的比例。初期这个指标可能只有 80%随着 prompt 调优和规则完善会逐步上升。但要注意一致率不是越高越好——如果 Agent 和旧流程 100% 一致那说明 Agent 没带来任何增量价值可能只是简单复读了旧规则。理想状态是 95% 一致剩下 5% 是 Agent 发现了旧流程遗漏的边界情况。回滚策略要设计成秒级生效。因为金融业务的时效性很强一旦发现 Agent 行为异常必须能立刻切回人工。我用的方案是配置中心加开关开关一关所有请求走旧路径Agent 侧只记录不决策。5.3 监控指标该盯哪些Agent 系统的监控和传统系统不一样。传统系统看 QPS、延迟、错误率Agent 系统还要看决策质量指标。我列几个必盯的指标含义告警阈值建议决策一致率与基准流程结论一致的比例低于 90% 告警人工复核率被标记为需人工复核的比例高于 15% 告警工具调用失败率工具调用异常的比例高于 2% 告警平均决策耗时单笔业务端到端耗时超过 SLA 告警幻觉检测命中数输出与事实不符的次数大于 0 即告警其中幻觉检测这个指标最容易被忽略但最重要。我的做法是让一个独立的校验 Agent 去核对主 Agent 的输出比如主 Agent 说该客户风险等级为低校验 Agent 就去查客户数据库确认。两者不一致就记一次幻觉。这个机制能抓住大部分事实性错误。6. 踩过的坑和对应的解法6.1 Prompt 注入在金融场景的真实威胁Prompt 注入不是理论问题。我遇到过真实案例客户在交易备注里填了一段精心构造的文本试图让 Agent 忽略合规检查。因为备注字段会被拼进 Agent 的上下文模型确实有可能被带偏。解法有两层。第一层是输入净化所有用户可控的文本在进入 Agent 上下文前都要经过清洗剥离掉类似指令的句式。第二层是结构化隔离用户输入永远放在明确的user_input字段里和系统指令在结构上分开让模型清楚哪些是数据、哪些是指令。Claude 本身对这类攻击有一定抵抗力但不能全指望模型工程上必须兜底。6.2 长尾业务的处理困境标准业务 Agent 处理得很好但金融业务的长尾特别长。总有一些奇奇怪怪的组合情况规则库里没有对应条款Agent 就卡住了。早期我的处理是让 Agent 硬判结果错误率很高。后来改成主动弃权机制Agent 在遇到规则未覆盖的情况时明确输出无法判断需人工介入而不是硬编一个结论。这个改动让错误率大幅下降虽然人工复核率上升了但整体风险可控。金融业务里承认不知道比猜一个要安全得多。6.3 多 Agent 协作的死锁问题多 Agent 协作偶尔会死锁。比如合规 Agent 等汇率 Agent 的结果汇率 Agent 又在等合规 Agent 的确认互相等。这在设计时不容易发现因为单测时每个 Agent 都是独立的。解法是给协作流程加超时和依赖方向约束。规定 Agent 之间的调用必须是有向无环的不允许循环依赖。同时每个 Agent 调用设超时超时后走降级路径。这个约束在架构评审时就要卡死不能等到出问题再补。7. 一些实操层面的经验补充关于模型选型金融场景我倾向于用能力更强的模型做核心决策用轻量模型做预处理和格式化。因为核心决策错一次的代价远高于省下的那点 token 成本。这个账要算清楚。关于测试Agent 系统的测试用例不能只覆盖正常路径。我专门建了一个对抗用例库收集各种边界、异常、恶意输入每次 prompt 或规则变更都跑一遍。这个库是慢慢积累的越用越值钱。关于文档Agent 的行为逻辑一定要写清楚包括它在什么情况下会做什么判断。因为金融业务的交接很频繁一个 Agent 的行为如果只存在于某个人的脑子里这个人一走系统就成了黑箱。文档要写到一个新人看完能预测 Agent 在给定输入下的输出这个程度。最后说个心态问题。金融场景引入 AI Agent不要指望一步到位替代人工。合理的预期是先做辅助再做增强最后才是替代。辅助阶段 Agent 给建议人来决策增强阶段 Agent 处理标准件人处理例外替代阶段才是全自动。每个阶段都要有足够长的观察期用数据说话而不是拍脑袋上线。我见过太多团队跳过前两个阶段直接冲全自动结果出了事整个项目被叫停反而倒退。稳一点慢一点在这个领域不是坏事。
