金融 Agent 最容易被误读

一听到金融 Agent，很多人会先想到「AI 炒股」。这反而是最不该先写的方向。

值得看的，不是模型能不能给出股票建议，也不是它能不能在交易里跑赢市场。金融行业里更大、更稳定、更接近 Agent 落地的工作，往往没那么刺激：做 pitchbook，整理可比公司，筛 KYC 材料，复核估值假设，生成市场简报，准备客户会议，辅助月结，核对异常账目，给审计材料打底。

这些工作有几个共同点。它们高价值、重复性强、格式要求高、数据源复杂、需要专业判断，也必须留下复核痕迹。它们不适合被写成一句 prompt，却很适合被打包成一套垂直工作流。

所以金融 Agent 的核心问题，不是「能不能替人投资」。更现实的问题是：能不能把一类专业工作拆成可安装、可连接、可检查、可签核的工作包。

这件事正在发生。

Anthropic 发的不是金融聊天机器人

Anthropic 在 2026 年 5 月发布 Agents for financial services，重点是十个 ready-to-run agent templates。官方列出的方向包括 pitchbook、KYC、月结等金融服务里的耗时流程。配套 GitHub 仓库也是 reference agents、skills、data connectors 和不同部署方式。

这很像一个产品形态上的转向：从「给你一个模型，你自己接工具」变成「给你一组行业工作包，你按自己的系统和权限部署」。

GitHub 仓库里的说明也很克制。它明确把这些 Agent 定位成起草 analyst work product 的工具，不做投资建议，不执行交易，不批准 onboarding，不直接过账，每个输出都要给合格专业人士复核。这些限制看起来保守，但正是垂直 Agent 进入金融的必要条件。

金融不是一个可以靠炫技拿下的行业。银行、资管、保险、私募和投行需要的一套能进入现有流程、尊重权限边界、接入可信数据、留下审计记录的工作系统。

这也是为什么垂直 Agent 比通用 Agent 更容易先落地。客户买的是一个更接近业务结果的包。

工作包比框架更接近预算

通用 Agent 框架通常卖给开发团队：你可以在上面搭自己的工具、规划器、记忆、权限和流程。这个市场当然存在，但它要求客户先有很强的工程能力和清晰的业务抽象。

垂直 Agent 工作包卖的是另一种东西：它直接对准业务部门的痛点。

一个投资银行团队不一定想先讨论 agent runtime 的抽象边界，但它知道 pitchbook 初稿要花多久。一个风控团队不一定想先比较多 Agent 编排框架，但它知道 KYC 文件筛查哪里最耗人。一个财务团队不一定想自己定义 tool schema，但它知道月结时哪些表要核、哪些异常要标出来。

这就是垂直 Agent 的优势。它把复杂度前置到供应商和平台侧，让客户看到一个更像成品的东西：这个 Agent 能处理哪类流程，需要接哪些数据源，输出什么材料，哪里需要人签字。

预算也更容易从这里来。企业很难为「一个更通用的 Agent 框架」单独买单，却更容易为「让投研、投行、财务、合规每周少花几十小时」的具体流程买单。

论文侧也开始从任务题转向工作流

Herculean 这类金融 Agent benchmark 的出现，说明研究侧也在往同一个方向靠。它是在把 Trading、Hedging、Market Insights、Auditing 等流程放进 MCP-based skill environment，评估 Agent 在端到端金融工作里的表现。

这类 benchmark 的意义，不在于宣称 Agent 已经能胜任金融专业人员。恰恰相反，它更有价值的地方是暴露差距：模型在市场判断和部分交易相关任务上可能表现较好，但在 hedging、auditing 这类需要长期协调、状态一致和结构化验证的流程上仍然吃力。

这给垂直 Agent 泼了一盆必要的冷水。行业工作包不是把 prompt 写得更专业就够了。它需要把工作拆到可验证的步骤里：数据从哪里来，假设怎么形成，表格怎么核，输出怎么复查，失败怎么处理，人工在哪个节点介入。

金融行业的困难，正好逼 Agent 产品补齐这些工程能力。没有审计、没有复核、没有状态管理、没有权限控制，金融 Agent 就只能停在演示层。

质疑也说明方向对了

围绕 Claude for Financial Services 的讨论里，有一个很典型的问题：金融和代码一样，都可能因为细节错误造成严重后果；代码至少有 lint、compile、test，金融有没有类似的检查机制？

这个质疑很关键。它说明垂直 Agent 不能只靠模型自信。金融工作里的错误，有时一个单元格、一个假设、一条数据来源、一个日期口径、一个会计分类错。输出越像专业材料，越容易让人放松警惕。

所以金融 Agent 该补的，「更像金融机构可接受的软件系统」。

它需要引用可追溯的数据源，需要把计算过程留出来，需要标注哪些地方是模型推断，需要让人能复核关键假设，需要限制哪些动作永远不能自动执行。它还要能和 Excel、PowerPoint、Word、Outlook、数据终端、文件库、CRM、合规系统一起工作。

这也解释了为什么 Anthropic 的金融服务发布会强调 Microsoft 365、数据连接器、MCP 和部署方式。金融 Agent 不是一个孤立聊天窗口，它必须进入金融专业人士已经使用的工作环境。

垂直 Agent 会挤压「空白框架」的价值

这条趋势对通用 Agent 框架不是好消息，至少对那些只提供编排概念、却没有清晰行业交付物的框架不是好消息。

当客户还在探索 Agent 时，框架故事很有吸引力：多 Agent 协作、工具调用、记忆、计划、反思、评估。可一旦业务部门开始要结果，问题会变得具体：这个月结 Agent 能不能接我的总账系统？这个 KYC Agent 能不能按我的风险规则筛？这个 pitchbook Agent 能不能用我公司的模板和数据库？这个输出谁负责签字？

如果一个框架不能回答这些问题，客户就会转向更垂直的方案。

但这不等于平台层不重要。恰好相反，垂直 Agent 越多，平台层越需要处理共性问题：身份、权限、审计、工具接入、数据隔离、模型路由、日志、评估、回滚、人工审批。只是客户未必愿意为抽象名词付钱，他们愿意为具体工作包付钱。

未来更合理的分工可能是：平台提供治理和运行底座，垂直 Agent 提供行业流程包。谁只做一个空框架，谁会越来越难解释价值。

金融只是第一批样本

金融会先跑出来，因为它最值得。

金融工作里有大量高薪知识劳动，有规范化交付物，有强烈的数据依赖，有明确的复核流程，也有足够高的单位经济价值。一个 Agent 如果能帮投行、资管、保险或企业财务节省一部分分析和整理时间，哪怕不能完全自动化，也有商业空间。

其他行业会沿着类似路径走。

  • 法务会围绕尽调、合同审查、条款对比、案例检索形成工作包。
  • 医疗行政会围绕病历整理、理赔材料、随访计划形成工作包。
  • 销售会围绕线索研究、账号计划、邮件跟进、CRM 更新形成工作包。
  • 运维会围绕告警归因、变更准备、事故复盘形成工作包。
  • 人力会围绕岗位画像、简历筛选、面试反馈和入职材料形成工作包。

这些垂直 Agent 的共同点，是它们都不会从「万能助手」开始。它们会从一个个可定义边界的流程开始：输入是什么，输出是什么，工具有哪些，风险在哪里，谁来复核。

最后的门槛是责任归属

金融 Agent 要真进入生产，最大问题是责任归属。

如果 Agent 起草了 pitchbook，里面的可比公司选错了，谁负责？如果 KYC Agent 漏掉了风险信号，谁负责？如果月结 Agent 标错了异常，谁负责？如果输出材料被客户或监管看见，机构怎么证明它经过了合格复核？

这些问题不会因为模型更强就消失。垂直 Agent 越接近真实业务，越要接受行业已有的责任体系。它可以帮人做初稿、核对、检索、整理和提示风险，但不能绕过专业人员的判断和签字。

这也决定了金融 Agent 的产品形态。它不能只提供「自动完成」，还要提供「可复核地完成」。它的理想输出一份能看见来源、假设、计算、修改记录和待确认事项的工作底稿。

这类产品看起来没有通用 Agent 那么酷，但更可能被企业长期使用。

值得写的是垂直化

Anthropic 的金融 Agent 发布、配套 GitHub repo、Herculean benchmark、官方帮助文档里的适用边界，放在一起看，趋势不是「AI 进入金融」这么简单。

更准确的说法是：Agent 正在从通用能力叙事，转向垂直工作包叙事。

早期市场喜欢问「这个 Agent 什么都能做吗」。企业市场更快会问「它能不能把这个流程做得更稳、更快、更可查」。前一个问题导向万能助手，后一个问题导向行业工作包。

金融只是第一批压力测试。它高价值、高风险、高审计要求，正好能检验 Agent 产品是不是只会生成漂亮文本，还是已经能进入真实组织。

如果金融 Agent 能跑通，其他行业会很快复用这条路径：把专业流程拆成 skills、连接器、模板、检查点和人工签核，再包成可部署的垂直 Agent。

到那时，Agent 市场的竞争不会只看谁的模型更强，也不会只看谁的框架更优雅。更重要的是，谁能把行业里的具体工作做成一个可靠的包。