今天看到 Anthropic 的 financial-services 仓库，第一反应是：这个名字很容易被误读。

很多人会把它理解成一个金融 AI 工具。

是不是能自动写研报？

是不是能帮投顾做组合？

是不是能给交易员找机会？

是不是 Anthropic 也开始做“AI 炒股”了？

我把仓库克隆到本地，读了 README、agent prompt、plugin 结构、MCP 配置和 Managed Agent 模板，又跑了它自己的校验脚本。我的判断是：

这个仓库真正值得证券公司、银行科技部门看的，不是“它能不能替你做金融分析”，而是它把金融行业 Agent 应该怎么交付，拆成了一套很清楚的工程样板。

这不是一个金融大模型。

也不是一个投研神器。

它更像是一份写给金融机构科技团队的暗示：

以后行业 AI 项目，不应该只交付一个聊天框，而应该交付一套能进入业务流程的 Agent 工作流包。

这个仓库叫 Claude for Financial Services。

README 里的定位很明确：它提供金融服务场景中的 reference agents、skills 和 data connectors，覆盖投行、股票研究、私募股权、财富管理、基金运营、KYC 等场景。

我本地看到的结构大概是这样：

plugins/agent-plugins/ 放端到端 agent，比如 Pitch Agent、Market Researcher、Earnings Reviewer、GL Reconciler、KYC Screener。

plugins/vertical-plugins/ 放行业能力包，比如 financial-analysis、investment-banking、equity-research、private-equity、wealth-management、fund-admin、operations。

plugins/partner-built/ 放合作伙伴插件，比如 LSEG 和 S&P Global。

managed-agent-cookbooks/ 放 Managed Agent 的部署模板，每个 agent 都有 agent.yaml、subagents、steering examples 和安全说明。

claude-for-msft-365-install/ 放 Microsoft 365 插件的企业部署工具。

scripts/ 放检查、同步、部署和编排脚本。

我跑了 python3 scripts/check.py，它检查 manifest、YAML、JSON、跨文件引用，以及 agent 里打包的 skills 有没有和源文件漂移。结果是：80 个文件检查通过，0 个问题。

这个细节很重要。

因为它说明这里不是一堆“金融 prompt 大全”。

它是把金融工作流拆成文件、包、配置、权限和部署模板。

换句话说，Anthropic 开源的不是某个神奇答案，而是一种组织 AI 能力的方式。

券商和银行的科技部门，过去几年已经见过太多 AI demo。

一个聊天框，可以查制度。

一个知识库，可以问流程。

一个助手，可以写材料。

一个插件，可以总结会议。

这些当然有用，但它们往往停在“单点提效”。

真正难的是：怎么把 AI 放进机构已有的业务链条里。

比如投研，不只是“总结一篇公告”。

它要读公告、读电话会、对比一致预期、更新模型、解释差异、形成观点、再经过分析师审核。

比如投行，不只是“写一页 PPT”。

它要定 peer set、拉 comps、做 DCF、做 LBO、生成 football field、套银行模板、检查数字和脚注。

比如合规和运营，不只是“识别一个客户资料”。

它要解析文件、抽取实体、跑 KYC/AML 规则、查 sanctions 和 PEP、标出风险缺口，最后交给合规人员判断。

金融机构的工作不是一问一答。

它是带权限、带审计、带复核、带责任边界的连续流程。

这正是这个仓库值得看的地方。

它没有把 Agent 设计成“什么都能聊的智能体”，而是把 Agent 设计成一个个有岗位边界的工作单元。

我最注意的不是它列了多少 agent，而是每个 agent 都写了“不能做什么”。

Pitch Agent 可以做第一版 pitch。

但它不能对外沟通，不能绕过 banker 的审核。

Earnings Reviewer 可以处理财报、更新模型、起草 note。

但它不能发布研究报告。

GL Reconciler 可以找总账和子账的 break，追 root cause，生成 exception report。

但它不能直接过账。

KYC Screener 可以解析 onboarding 文件、跑规则、标出缺口。

但它不能替 compliance officer 做最终风险评级。

这些限制看起来很保守。

但如果你在证券公司、银行科技部门待过，就会知道：这才是能进入机构的写法。

很多 AI 项目失败，不是因为模型不会回答，而是因为系统不知道边界。

它能不能看客户资料？

能不能调用外部数据源？

能不能写文件？

能不能改 Excel？

能不能生成对客材料？

能不能触发交易、过账、审批、发送？

哪一步必须停下来等人看？

日志怎么留？

责任怎么分？

如果这些问题没有答案，AI demo 做得再炫，也很难进入生产流程。

Anthropic 这个仓库的启发是：Agent 的产品设计，首先不是“能力最大化”，而是“能力、权限、责任、审核点分离”。

金融行业尤其需要这一点。

如果只看表面，你会觉得这里有很多名字：agent、skill、command、connector、managed-agent cookbook。

但换成科技部门更熟悉的语言，它其实可以拆成四层。

第一层是业务角色。

比如 Pitch Agent、Market Researcher、Model Builder、Meeting Prep Agent、Statement Auditor。

这些不是技术模块命名，而是岗位命名。

它先问：这个流程在机构里原本是谁负责？

第二层是专业能力。

比如 comps-analysis、dcf-model、lbo-model、audit-xls、earnings-analysis、kyc-rules。

这些是可复用的 skills。

一个 skill 可以被多个 agent 使用，就像机构里一套估值方法、一套 Excel 审核标准、一套 KYC 规则，可以在多个业务场景复用。

第三层是数据连接。

仓库里配置了 Daloopa、Morningstar、S&P Global、FactSet、Moody's、Aiera、LSEG、PitchBook、Chronograph、Egnyte 等 MCP 服务。

这些不是装饰。

对金融机构来说，Agent 如果不能接入可信数据源，就只能停在“语言生成”。

它要真正参与投研、风控、财富管理和运营，就必须知道哪些数据来自哪里，哪些数据需要权限，哪些输出可以 trace 回来源。

第四层是部署和编排。

同一套 agent 和 skills，可以作为 Claude Cowork 插件安装，也可以通过 Managed Agents API 放到你自己的工作流引擎后面。

这对金融科技团队很关键。

因为大机构很少接受“所有东西都在一个黑盒 SaaS 里跑”。

它们需要接自己的权限、自己的数据、自己的流程、自己的审计要求。

所以这个仓库真正提供的不是一个 App，而是一种可被企业 IT 接管的包装方式。

如果你在证券公司或银行的科技部门，我不建议你读完这个仓库后立刻想：“我们也做一个金融全能 Agent。”

这条路很危险。

更靠谱的做法，是反过来，从一个小流程开始拆。

第一步，选一个高频、可复核、低外部动作风险的流程。

比如晨会材料准备、财报事件初筛、研究资料包生成、产品说明书审核、客户拜访前 briefing、KYC 文件预审、运营差错归因、制度问答后的材料生成。

不要一上来做交易决策、授信审批、合规处罚、投资建议发布。

第二步，把流程拆成角色。

谁读材料？

谁查数据？

谁做表格？

谁生成初稿？

谁检查数字？

谁最终审核？

在 Agent 系统里，这些角色不一定都要由不同模型完成，但边界要先拆出来。

第三步，定义每一步的输入和输出。

输入是公告、研报、CRM 记录、合同、财务表、交易流水、会议纪要，还是内部制度？

输出是 JSON、Excel、PPT、Word、Markdown，还是一个待审核任务？

金融机构最怕“AI 说了一段像样的话，但没人知道它从哪里来，也没人知道它该流向哪里”。

第四步，定义权限。

哪些 agent 只能读？

哪些 agent 可以写文件？

哪些 agent 可以调用内部系统？

哪些 agent 只能生成草稿，不能触发动作？

哪些步骤必须 human sign-off？

第五步，把方法沉淀成文件，而不是藏在聊天记录里。

这也是这个仓库最值得学习的地方。

agent prompt、skill、command、connector、部署配置、校验脚本，都应该变成可版本管理的资产。

否则一个 AI 项目上线后，很快会变成一堆没人敢改的提示词。

过去我们说 prompt，容易把它理解成一句技巧：

你要怎么问，模型才会答得更好。

但在这个仓库里，prompt 已经不是聊天技巧了。

它更像流程代码。

一个 agent prompt 里写的是岗位职责、产物、流程、工具、边界和审核要求。

一个 skill 里写的是专业知识、操作规范和输出标准。

一个 command 里写的是可触发的业务动作。

一个 MCP 配置里写的是数据源。

一个 managed-agent cookbook 里写的是部署方式、子 agent、权限和 handoff。

这对金融机构很有启发。

未来科技部门要管理的，可能不只是代码、接口、数据库和权限系统。

还要管理一批“AI 工作流资产”：

研究晨会 agent。

投行材料 agent。

客户经理 briefing agent。

KYC 预审 agent。

运营差错分析 agent。

内控制度解释 agent。

模型审核 agent。

它们不是聊天机器人，而是被流程化、权限化、审计化的工作单元。

谁能把这些资产管理好，谁就能更快把 AI 从 demo 推进真实业务。

这里也要说清楚边界。

这个仓库不是一个 clone 下来就能在你们机构跑起来的系统。

很多能力依赖外部金融数据源和企业权限，比如 Daloopa、Morningstar、S&P Global、FactSet、LSEG、PitchBook 等。

它也默认围绕 Claude Cowork、Claude Managed Agents、MCP、Microsoft 365 add-in 等生态来组织。

国内券商和银行如果要借鉴，肯定要替换数据源、权限体系、审计日志、内网部署方式、模型供应商和合规流程。

所以它不是交付物。

它更像参考架构。

你不能照搬它的 connector。

但你可以照搬它拆业务的方式。

你不能照搬它的金融数据源。

但你可以照搬它把数据源显式配置出来的方式。

你不能照搬它的审批流程。

但你可以照搬它把 human review 写进 agent 边界的方式。

你不能照搬它的产品形态。

但你可以照搬它“同一套 agent 和 skill，既能做前台插件，也能做后台托管 agent”的思路。

很多机构现在问的问题还是：

我们要不要接大模型？

要不要做知识库？

要不要上智能投研？

要不要做 AI 办公助手？

这些问题当然重要，但还不够具体。

更关键的问题应该是：

哪些流程值得先拆？

哪些步骤可以让 AI 做初稿？

哪些步骤只能让 AI 做证据整理？

哪些步骤必须人来判断？

哪些输出必须可追溯？

哪些动作永远不能自动触发？

哪些 prompt、规则和模板要进入版本管理？

哪些 agent 能复用同一套 skill？

当你这么问的时候，AI 项目就不再是“采购一个模型能力”，而是重新设计工作方式。

这也是我觉得 Anthropic 这个仓库最有意思的地方。

金融只是样板间。

真正被展示出来的，是 AI 时代专业工作的组织方式。

如果你在券商、银行、基金、保险或金融科技公司做技术、数据、运营系统、办公自动化、投研平台、风控平台，我建议你别只把这个仓库当新闻看。

可以挑一个你们机构里最熟悉的小流程，照着它的方式拆一次：

角色是谁？

输入是什么？

输出是什么？

数据源在哪里？

哪一步需要工具？

哪一步需要人审？

哪一步只能读，哪一步可以写？

最后能不能沉淀成一个可安装、可测试、可审计、可迭代的工作流包？

你会很快发现，AI 落地最难的地方，不是让模型说得更像专家。

而是把专家每天真正做的事，拆到足够清楚。

我接下来会继续在「赛博神经」里拆这类真实仓库和真实工作流：金融、内容生产、企业服务、个人工作台都会看。

如果你也在探索 AI 时代的工作方式，尤其是想把自己团队里的一个具体流程拆成 Agent 工作流，欢迎来找我一起试。

我不太想只聊“AI 会不会替代谁”。

更想和你一起把一个真实工作，拆到 AI 真的能参与、但人仍然掌握判断的位置。

这件事，可能比追下一个模型发布会更重要。

CyberUnion

让创造不再孤单

一起探索AI时代的工作方式