1. 从financial-services这个标题能读出什么第一次看到financial-services这个项目名很多人会下意识觉得它是个业务系统——账户、交易、风控、对账那一套。但结合关键词里的 Claude、Cowork、Managed Agents API、plugin 来看这其实是一个面向金融业务场景的 AI 智能体协作框架而不是传统意义上的银行核心系统。换句话说它要解决的不是钱怎么流转而是金融业务里那些重复、繁琐、需要多角色配合的脑力活怎么交给一组可编排的 AI Agent 去干。金融行业有个很尴尬的现实业务复杂度极高但大量时间花在了信息搬运和格式转换上。一份尽调报告要在招股书、年报、行业研报、新闻公告之间来回比对一个合规审查要在监管条文、内部制度、历史案例之间反复检索一次投研分析要把财报数据、电话会议纪要、卖方观点整合成一份能看的材料。这些活的共同点是信息密度高、容错率低、流程高度重复。传统做法是招一堆分析师硬扛或者写一堆 RPA 脚本——前者贵且慢后者脆且笨。financial-services这个项目想做的事就是把这套流程用 Managed Agents API 重新组织一遍。它不是一个单体应用而是一组 plugin 的集合每个 plugin 封装一类金融场景的能力再通过 Cowork 这样的协作层把多个 Agent 串起来。你可以把它理解成一个金融业务的操作系统——底层是 Claude 的推理能力中间是 Managed Agents API 提供的编排和状态管理上层是一堆开箱即用的 plugin。这篇文章适合三类人看一是想在金融场景落地 AI 的技术负责人二是被重复性金融分析工作折磨的业务人员三是想搞清楚 Managed Agents API 到底怎么用的开发者。我会从架构设计、plugin 机制、协作编排、实操踩坑几个角度把它拆开讲尽量把为什么这么设计讲透而不是只丢一堆 API 文档。2. 为什么金融场景需要 Agent 协作而不是单个大模型2.1 单模型方案在金融场景的三个硬伤很多人第一反应是金融分析嘛把材料丢给 Claude让它输出结论不就行了我一开始也这么想实测下来问题很大。第一个硬伤是上下文窗口的物理限制。一份完整的尽调材料动辄几百页招股书加年报加研报轻松超过 50 万字。你不可能把所有东西塞进一次对话里就算模型支持长上下文成本和延迟也会爆炸。更麻烦的是金融材料里关键信息往往藏在附注、脚注、表格里模型在超长上下文中的注意力衰减会让它漏掉这些细节。第二个硬伤是单一职责的缺失。金融分析天然是多角色的有人负责数据提取有人负责逻辑校验有人负责合规审查有人负责撰写结论。你让一个模型同时干这四件事它会在角色之间反复横跳输出质量极不稳定。这就像让一个分析师既做数据录入又做投资决策专业度必然打折。第三个硬伤是可追溯性。金融行业对结论的可解释性要求极高监管问起来你得说清楚这个数字从哪来、经过什么处理、依据什么规则判断。单模型的黑盒输出根本没法满足这个要求。2.2 Managed Agents API 解决的到底是什么问题Managed Agents API 的核心价值是把一个 Agent 干所有事拆成多个 Agent 各干各的由一个编排层统一调度。它提供了几个关键能力Agent 生命周期管理每个 Agent 有独立的系统提示、工具集、状态可以单独启停和版本管理。状态持久化Agent 之间的中间结果可以落盘支持断点续跑这对动辄跑几十分钟的金融分析任务至关重要。工具调用编排Agent 可以调用外部工具数据库查询、文件解析、API 请求编排层负责处理调用顺序和错误重试。消息路由Agent 之间通过结构化消息通信而不是自由文本保证信息传递的准确性。用一句话概括Managed Agents API 把多 Agent 协作从概念变成了可运维的工程实践。你不用自己造轮子去处理 Agent 之间的通信、状态、错误恢复这些它都帮你管了。2.3 Cowork 在架构里的位置Cowork 是这套体系里的协作层。如果说 Managed Agents API 是操作系统内核那 Cowork 就是进程调度器。它负责定义 Agent 之间的协作拓扑谁先跑、谁依赖谁、谁可以并行处理 Agent 之间的数据传递格式转换提供人工介入的检查点金融场景里关键决策点必须有人确认汇总各 Agent 的输出生成最终交付物我个人的理解是Cowork 让Agent 团队这个概念变得可管理。你可以像管理一个真实团队一样管理它给每个 Agent 分配职责、设定交付标准、安排协作流程、在关键节点做 review。3. plugin 机制金融能力的模块化封装3.1 为什么是 plugin 而不是单体应用financial-services选择 plugin 架构这个决策背后有很实际的考量。金融业务的特点是场景碎片化但底层能力复用率高。比如从 PDF 里提取财务表格这个能力在尽调、投研、审计、合规场景里都要用比对两版监管条文差异这个能力在合规和法务场景里都要用。如果做成单体应用每加一个场景就要改核心代码维护成本会指数级上升。做成 plugin 之后每个 plugin 封装一类原子能力场景通过组合 plugin 来实现。这就像乐高积木——底层积木标准化上层组合千变万化。更重要的是plugin 架构让能力可以独立演进。财务表格提取的准确率提升了只需要更新那一个 plugin所有用到它的场景自动受益。这在金融这种规则频繁变化的行业里价值巨大。3.2 一个典型 plugin 的内部结构我拆过几个 plugin 的实现结构基本一致分四层层级职责关键设计输入适配层接收各种格式的输入统一转成内部标准格式PDF/Excel/HTML 都走同一套解析接口能力核心层实际的处理逻辑调用 Claude 做推理或调用确定性算法做计算校验层结果质量检查数值范围校验、格式校验、交叉验证输出封装层标准化输出统一成 JSON schema方便下游 Agent 消费这个结构里最容易被忽视但最重要的是校验层。金融场景对准确性要求极高一个数字错了可能导致整个结论崩塌。校验层要做的事包括数值是否在合理区间、单位是否一致、时间口径是否对齐、多个来源的数据是否互相印证。我见过太多项目跳过这一步结果 Agent 输出看起来头头是道实际数字全是错的。3.3 plugin 之间的依赖管理plugin 不是孤立的它们之间有依赖关系。比如财务比率计算plugin 依赖财务表格提取plugin 的输出风险评估plugin 又依赖财务比率计算的结果。financial-services用了一套声明式的依赖描述每个 plugin 在元数据里声明自己需要什么输入、产出什么输出编排层自动解析依赖图并决定执行顺序。这里有个坑要注意循环依赖。金融场景里很容易出现 A 需要 B 的结果、B 又需要 A 的结果的情况。比如估值需要增长率预测而增长率预测又需要当前估值作为参考。解决办法是把这类互相依赖的能力合并成一个 plugin或者引入迭代收敛机制——先给个初始值跑几轮迭代直到收敛。4. 用 Cowork 编排一个真实的金融分析流程4.1 场景设定一份上市公司深度分析报告假设我们要生成一份上市公司的深度分析报告涉及的工作包括财报数据提取、财务指标计算、行业对比、风险识别、结论撰写。用 Cowork 编排的话流程是这样的数据提取 Agent从年报 PDF 里提取三张报表和关键附注指标计算 Agent基于提取的数据计算 ROE、毛利率、资产负债率等指标行业对比 Agent拉取同行业公司的公开数据做横向对比风险识别 Agent结合财务指标和公告信息识别潜在风险点报告撰写 Agent整合以上所有输出生成结构化报告这五个 Agent 不是简单串行而是有并行有依赖。指标计算和行业对比可以并行风险识别依赖前两者报告撰写依赖全部。4.2 编排配置的关键字段Cowork 的编排配置用 YAML 描述核心字段包括workflow: name: listed-company-analysis agents: - id:>
API 深度解析)
