1. 金融场景下的 Claude 协作工程从零搭建一套可复用的 Managed Agents 工作流金融行业对技术工具的态度向来是“先看合规再看效率”这一点我在过去两年给券商、保险和第三方支付团队做技术咨询时感受特别深。大家嘴上都在聊大模型真到落地环节卡住他们的往往不是模型能力而是三件事数据边界怎么划、Agent 行为怎么审计、多人协作怎么不打架。financial-services这个项目标题乍看很泛但结合 Claude、Cowork、Managed Agents API、plugin 这几个关键词它指向的其实是一个非常具体的工程命题——如何用 Claude 的托管 Agent 能力在金融业务场景里搭一套既能协作、又能被管住的智能工作流。我先把结论摆在前面这套东西不是“装个 Claude Code 就完事”的玩具它更像是在你的业务系统旁边架设一层受控的智能执行层。Managed Agents API 负责把 Agent 的生命周期托管起来Cowork 负责让多个 Agent 或多人围绕同一份金融数据协同plugin 负责把外部数据源、风控规则、报表工具接进来。三者叠在一起才构成一个金融团队真正敢用的东西。这篇文章我会按我实际搭过的一套流程来讲从整体设计思路、核心组件拆解、实操落地步骤到踩过的坑和排查方法全部摊开说。适合有一定工程基础、正在评估或已经动手做金融 AI 协作平台的读者纯小白也能看懂思路但动手部分建议先补一下 API 和容器的基础。2. 整体设计思路为什么金融场景不能直接套通用 Agent 方案2.1 金融业务的三个硬约束决定了架构走向通用 Agent 方案在互联网场景里跑得挺欢丢到金融里立刻水土不服原因就三条。第一是数据分级客户身份信息、交易流水、持仓明细这些东西的敏感级别完全不同不能一股脑塞进同一个上下文里。第二是行为可追溯监管和内部审计要求你能回答“这个结论是哪一步、哪个数据、哪个规则推出来的”Agent 如果是个黑盒这关直接过不了。第三是协作隔离投研、风控、运营三个团队用同一套 Agent 平台但彼此的数据和工具权限必须切开不能因为共用了一个 plugin 就串了权限。所以我在设计financial-services这套方案时第一件事不是选模型而是画边界。Managed Agents API 的价值就在这里——它把 Agent 的运行环境、会话状态、工具调用记录都托管起来你不需要自己维护一套复杂的状态机但同时又保留了足够的控制点去做审计和隔离。这比自己在服务器上裸跑一个 Agent 循环要省心得多尤其是在需要横向扩展多个 Agent 实例的时候。2.2 Cowork 解决的是“人和 Agent 同处一室”的问题Cowork 这个概念很多人第一次听会懵其实用一句话解释它让多个参与者可以是人也可以是 Agent围绕同一份工作空间协同。放到金融场景里典型画面是这样的——一个投研 Agent 拉完财报数据生成初步分析一个风控 Agent 同步检查这份分析里引用的数据是否触及敏感字段一个人类分析师在 Cowork 空间里看到两边的产出直接批注、修正、拍板。整个过程留痕谁在什么时候改了什么一清二楚。这跟传统的“人用工具”模式有本质区别。传统模式里Agent 是个被调用的函数人用完就走。Cowork 模式里Agent 是有“工位”的同事它持续存在于工作空间中能感知上下文变化也能被其他人 到。金融团队对这种模式接受度反而更高因为它更接近他们熟悉的“跨部门协作”心智模型只不过其中一个“部门”换成了 AI。2.3 Plugin 机制是连接金融业务系统的唯一正确姿势金融公司的数据不会放在 Claude 的上下文里它们躺在 Oracle、MySQL、Kafka、内部风控引擎、报表平台里。Plugin 就是把这些系统安全暴露给 Agent 的桥梁。我见过有人图省事直接把数据库连接串写进 Agent 的 prompt 里让它自己查这在金融场景是自杀行为——权限失控、SQL 注入、审计缺失随便一条都够喝一壶。正确的做法是每个 plugin 封装一个明确的业务能力比如“查询某客户近 30 天交易汇总”“获取某只基金的持仓明细”“调用反洗钱规则引擎打分”。Agent 只能看到 plugin 的接口描述和返回结果看不到底层表结构和连接方式。Managed Agents API 在调用 plugin 时会记录完整的入参和出参这就天然满足了审计要求。我后面会详细讲怎么设计 plugin 的粒度这是整套方案里最考验工程判断力的地方。3. 核心组件拆解Managed Agents API、Cowork 与 Plugin 的职责划分3.1 Managed Agents API 到底托管了什么很多人以为 Managed Agents API 就是“帮你跑 Agent 的云函数”这个理解太浅。它实际托管的东西包括Agent 的会话生命周期创建、挂起、恢复、销毁、工具调用的编排与重试、上下文窗口的管理与裁剪、以及最重要的——执行轨迹的持久化。最后这一点对金融场景是刚需。我举个实际例子。一个信贷审批 Agent 需要依次调用“查征信 plugin”“查收入 plugin”“跑评分卡 plugin”最后给出建议额度。如果中间某一步失败了Managed Agents API 会保留失败前的完整状态你可以选择重试、回滚或者人工介入。这个状态不是简单的日志而是可恢复的执行快照。我实测下来这套机制在需要“断点续跑”的长流程里特别有用比如批量处理几百个审批单时某个单子卡住了不会拖垮整批。另外要注意Managed Agents API 的计费和调用配额是按 Agent 会话维度算的不是按 token 简单累加。这意味着你在设计 Agent 时要尽量让一个会话干完一类完整任务而不是频繁创建销毁。我一开始没注意这点把每个小查询都开一个新会话结果配额消耗得飞快后来改成“一个客户一个会话会话内多轮工具调用”成本直接降了六成。3.2 Cowork 空间的结构与权限模型Cowork 空间不是简单的聊天室它有三层结构空间Space→ 频道Channel→ 线程Thread。空间对应一个业务域比如“对公信贷”频道对应一个具体任务比如“2024Q3 某行业授信复核”线程对应一次具体的讨论或执行。权限可以按这三层分别配置粒度足够细。金融场景里我建议的权限设计原则是数据权限跟着频道走工具权限跟着 Agent 走操作权限跟着人走。什么意思一个频道里能访问哪些数据由频道配置决定Agent 进入这个频道就自动继承一个 Agent 能用哪些 plugin由 Agent 自身的配置决定不随频道变化而人类用户能做什么操作只读、批注、审批、导出由他的角色决定。这三者正交互不干扰审计的时候也容易定位问题。我踩过的一个坑是早期把数据权限直接绑在 Agent 上结果同一个 Agent 被拉进不同频道时权限没法动态调整只能复制多个 Agent 实例维护成本爆炸。后来改成频道级数据权限Agent 变成“无状态的能力载体”问题才解决。3.3 Plugin 的粒度设计与安全边界Plugin 设计是整套方案里最需要克制的地方。我的经验是一个 plugin 只做一件事且这件事的业务语义要清晰到非技术人员也能看懂。比如“查询客户近 30 天交易汇总”是个好 plugin“执行任意 SQL”是个灾难。前者 Agent 知道自己在干什么审计人员也知道 Agent 干了什么后者等于把数据库钥匙交给了 AI。Plugin 的接口描述description要写得极其精确因为 Agent 是靠这段描述来决定什么时候调用它的。我通常会在描述里写清楚适用场景、输入参数的含义和格式、返回结果的结构、以及明确的调用限制比如“单次查询最多返回 100 条记录”“仅支持查询近 90 天数据”。这些限制不是给 Agent 看的是给 Managed Agents API 做参数校验用的超限直接拒绝避免 Agent 因为理解偏差搞出大查询拖垮生产库。还有一个细节plugin 的返回结果要做脱敏和裁剪。比如查询客户信息返回里不应该包含完整身份证号而是脱敏后的版本。这个脱敏逻辑放在 plugin 内部做不要指望 Agent 自己处理Agent 没有这个可靠性。4. 实操落地从环境准备到第一个金融 Agent 跑通4.1 环境准备与 Claude Code 的安装配置动手之前先把基础环境弄干净。我假设你用的是 macOS 或 UbuntuWindows 用户建议走 WSL2因为后面有些 plugin 的本地调试工具在纯 Windows 下会有路径问题。Node.js 版本建议 18 以上Python 3.10 以上这两个是跑 Claude Code 和调试 plugin 的常见依赖。Claude Code 的安装方式我试过几种最稳的是通过官方 CLI 工具装。装完之后第一件事是验证版本和登录状态很多人卡在“无法将 claude 项识别为可运行程序”这种问题上本质是 PATH 没配好。Ubuntu 下通常是~/.local/bin没加进 PATHmacOS 下如果是用 Homebrew 装的检查/opt/homebrew/bin。配好之后跑claude --version能出结果再跑claude进交互模式确认登录正常。提示如果你在公司内网环境Claude Code 的某些网络请求可能被拦截表现为登录转圈或 API 调用超时。这种情况先找网络团队确认出口策略不要自己乱改代理配置金融内网乱动网络设置是合规红线。环境变量方面Managed Agents API 的密钥建议用系统级密钥管理工具存不要写在.env文件里提交到代码库。我见过太多团队因为.env泄露导致密钥外流的案例。本地开发可以用direnv或者系统的 keychain生产环境走密钥管理服务。4.2 创建第一个 Managed Agent 并接入 plugin环境好了之后我们创建一个最小的金融 Agent 来跑通链路。假设场景是“查询某客户近 30 天交易汇总并生成简报”。第一步是在 Managed Agents API 里注册一个 Agent指定它的系统提示词、可用 plugin 列表、以及会话超时策略。系统提示词要写得像给新员工的工作手册而不是给程序的需求文档。我通常这样写“你是一名对公业务助理负责根据交易数据生成客户简报。你只能通过已授权的 plugin 获取数据不得推测或编造任何数字。生成简报时先列数据来源再列分析结论最后标注不确定性。”这种写法能让 Agent 的行为更可预测也方便审计时对照检查。Plugin 接入分两步先在 plugin 注册中心登记接口描述和参数 schema然后在 Agent 配置里引用这个 plugin 的 ID。我强烈建议在正式接入前用沙箱环境跑一遍 plugin 的边界测试比如传空参数、传超长字符串、传非法日期格式看它是否按预期拒绝。这一步能挡掉后面八成的诡异问题。4.3 Cowork 空间的初始化与成员配置Agent 跑通之后把它拉进 Cowork 空间。创建空间的顺序我建议是先建空间再建频道最后拉人和 Agent。频道创建时要明确三件事这个频道的数据权限范围、允许哪些 Agent 进入、人类成员的角色分配。数据权限范围我通常按“数据域 时间窗”来配比如“对公交易数据近 90 天”。时间窗这个维度很多人会漏结果 Agent 能查到几年前的数据既没必要又增加泄露风险。人类成员的角色我一般分四档观察者只读、参与者可批注、审批者可确认结论、管理员可改配置。金融场景里能导出数据的权限要单独控制不要混在参与者里。配置完成后做一次端到端演练让 Agent 在频道里执行一次完整任务人类成员分别用不同角色登录验证权限是否符合预期。我踩过的坑是Agent 的 plugin 权限和频道的数据权限叠加后出现了“Agent 能调 plugin 但 plugin 查不到数据”的情况排查半天发现是频道的数据权限没同步到 plugin 的查询上下文里。这个同步逻辑要在平台层做好不要指望配置人员手动对齐。5. 常见问题与排查技巧实录5.1 Agent 调用 plugin 失败的典型原因Plugin 调用失败是最高频的问题我整理了一张速查表基本覆盖了九成情况。现象可能原因排查方法Agent 完全不调用 pluginplugin 描述与任务语义不匹配检查 description 是否包含任务关键词必要时补充示例调用后返回权限错误Agent 未被授权该 plugin或频道数据权限未同步检查 Agent 配置和频道配置的权限交集返回结果为空查询条件超出数据权限时间窗核对频道时间窗配置与查询参数调用超时plugin 内部查询未加索引或返回数据量过大在 plugin 层加 limit 和超时优化底层查询返回格式解析失败plugin 返回结构与 schema 不一致用沙箱环境复现检查序列化逻辑这张表是我在实际项目里一条条攒出来的每次遇到新问题就补一行。建议你也维护一份自己的因为不同公司的 plugin 实现差异很大通用经验只能覆盖一部分。5.2 Cowork 空间里 Agent 行为异常的排查思路Agent 在 Cowork 空间里的行为异常往往不是 Agent 本身的问题而是上下文污染。什么叫上下文污染就是频道里之前的历史消息、其他人的批注、甚至无关的讨论被 Agent 当成了当前任务的输入。金融场景里这很危险比如 Agent 把别人随口说的一个数字当成了真实数据。排查方法是先看 Agent 的执行轨迹确认它引用了哪些上下文片段。如果发现引用了无关内容就要调整频道的上下文隔离策略。我的做法是给每个任务线程设置明确的“上下文边界”Agent 只读取当前线程内标记为“任务相关”的消息其他消息默认不可见。这个策略要在平台层强制不能靠 Agent 自觉。另一个常见问题是 Agent 在多人协作时“抢话”就是多个人同时给 Agent 下指令Agent 不知道该听谁的。解决办法是引入“指令优先级”机制审批者的指令优先于参与者参与者的指令优先于观察者。这个优先级要在 Cowork 空间的配置里显式定义Agent 按优先级顺序处理。5.3 性能与成本的平衡技巧Managed Agents API 的成本主要来自三块会话时长、工具调用次数、上下文 token 量。金融场景里会话时长往往是大头因为一个审批流程可能持续几小时甚至几天。我的优化经验是让 Agent 在等待人工介入时主动挂起而不是空转。Managed Agents API 支持会话挂起和恢复挂起期间不计时长。这个机制用好了成本能降一半以上。工具调用次数方面能合并的 plugin 调用尽量合并。比如“查交易”和“查持仓”如果经常一起用可以考虑做一个“查客户综合视图”的 plugin一次返回两类数据。但要注意别过度合并plugin 粒度太粗会降低复用性这个度要自己把握。上下文 token 量方面金融数据往往很长全量塞进上下文既贵又容易让 Agent 抓不住重点。我的做法是在 plugin 层做摘要返回给 Agent 的是结构化摘要而非原始数据Agent 需要细节时再通过二次调用获取。这样既控制了 token又保留了追溯能力。6. 我在金融 Agent 项目里攒下的几条硬经验第一条永远不要让 Agent 直接接触生产数据库。所有数据访问必须经过 plugin 这层封装plugin 内部做权限校验、脱敏、限流。我见过一个团队为了图快让 Agent 直连只读库结果 Agent 生成了一个全表扫描的查询把生产库拖垮了半小时。这个教训值几百万。第二条审计日志要独立存储且不可被 Agent 修改。Managed Agents API 自带的执行轨迹已经比较完整但金融合规往往要求日志存到公司自己的审计系统里。我的做法是在 plugin 层和平台层各埋一个日志点双写到一个只追加的存储里Agent 没有任何权限碰这个存储。第三条Agent 的“不确定性表达”要强制。金融场景最怕 Agent 一本正经地胡说。我在系统提示词里强制要求任何结论必须标注数据来源和置信度数据不足时必须明确说“数据不足无法判断”而不是给一个模糊的估计。这个约束看起来简单但能挡掉大量合规风险。第四条Cowork 空间的生命周期要跟业务周期对齐。一个授信复核项目结束了对应的 Cowork 空间要及时归档里面的数据和 Agent 会话要按策略清理。我见过空间越建越多、没人清理最后权限管理一团乱麻的情况。归档策略要在平台初始化时就定好别等出问题再补。这套financial-services的方案我前后迭代了三个版本从最初“能跑就行”到后来“审计能过、权限能切、成本可控”中间踩的坑基本都写在上面的内容里了。如果你正准备动手我的建议是先从一个最小的闭环开始——一个 Agent、一个 plugin、一个 Cowork 频道跑通之后再逐步加复杂度。金融场景里稳比快重要得多。