Trending 排名：#1｜快照日期：2026-09-23｜Stars：36,592｜Forks：5,344｜主语言：Python｜License：Apache-2.0
做企业 Agent 最容易卡住的地方，往往不是写一个漂亮的 prompt，而是把它放进真实工作流：谁能读文件，谁能写文件，哪个步骤要人工签字，外部数据从哪里来，出错后怎么审计。
anthropics/financial-services 把这个问题放到金融服务场景里回答。仓库不是一个传统 SDK，更像一套可拆开的 Agent 工作台：上层是 Pitch Agent、GL Reconciler、KYC Screener 这类完整流程 Agent；中层是财务建模、投研、尽调、基金管理等垂直技能包；底层接 MCP 数据源、Claude Code 插件系统和 Claude Managed Agents API。
我更愿意把它看成一份企业 Agent 工程样板。它的价值不在“Claude 会做金融分析”这个口号，而在它把 Agent、Skill、Command、MCP Connector、Managed Agent Cookbook 放进同一个文件结构里，并且留下了验证脚本、CI 工作流和权限边界。对于正在把 Agent 接入内部流程的团队，这种组织方式比单个 prompt 更值得看。
📋 项目概览
| 项目 | 内容 |
|---|---|
| 项目名 | anthropics/financial-services |
| GitHub | github.com/anthropics/… |
| 一句话 | 面向金融服务工作流的 Claude Agent、技能、命令与数据连接器模板库 |
| Trending 排名 | #1 |
| Stars | 36,592（Trending 快照）；36,595（稍后 GitHub API 核验） |
| Forks | 5,344 |
| Watchers | 284（GitHub API 核验） |
| Open Issues | 216 |
| 主语言 | Python（API 语言字节占比 63.0%） |
| License | Apache-2.0 |
| 创建时间 | 2026-02-23 |
| 最近提交 | 2026-09-21，574ed36 |
| Release/Tag | 未发布 GitHub Release，未发现 Tag |
| inspected commit | 574ed3624aebd0418c7e96cd101262f30210ab26 |
🔥 为什么值得关注
很多 Agent 项目会停在“我能把一段任务跑完”。这类 demo 很好看，但进企业流程后会遇到更麻烦的问题：权限要分层，数据源要替换，输出要有人复核，模型的草稿不能直接变成业务动作。金融服务只是把这些矛盾放大了，因为它天然有合规、审计、数据许可和人工签字要求。
这个仓库的做法比较务实。它没有把所有能力塞进一个万能 Agent，而是按工作流拆成 10 个 Agent 插件、6 个垂直插件、49 个垂直技能目录、33 个 slash command、30 个托管子 Agent YAML。Pitch Agent 可以把 researcher、modeler、deck-writer 分成不同叶子工人；Managed Agent README 明确写了“加粗的 leaf 是唯一有 Write 权限的 worker”。这不是噱头，是真实团队会关心的权限切面。
它也没有把 Markdown 指令伪装成确定性系统。仓库里有 scripts/check.py、GitHub Actions 的 plugin-validate.yml、Claude Code 的 claude plugin validate 验证链，但仍有一些东西只是 Agent-mediated 的流程约束。比如 README 说 financial-analysis/.mcp.json 集中管理 11 个连接器，我实际解析这个文件时发现 JSON 语法在第 47 行附近缺逗号；scripts/check.py 也暴露了 meeting-prep-agent 的 3 个 bundled skill 缺少 vertical source。它很有价值，但还处在快速迭代的参考模板状态。
🏗️ 核心特性
- 工作流 Agent 与垂直插件分层
仓库把“完整流程”和“可复用技能”分开维护。完整流程放在 plugins/agent-plugins/<slug>/，比如 pitch-agent、gl-reconciler、market-researcher；垂直技能包放在 plugins/vertical-plugins/<vertical>/，比如 financial-analysis、investment-banking、equity-research。
这种结构解决了一个常见问题：你可以安装一个完整 Agent，也可以只拿底层能力。
# 已核验：claude plugin marketplace add 支持 <source>
claude plugin marketplace add anthropics/financial-services
# 已核验：claude plugin install 支持 <plugin> 与 plugin@marketplace 写法
claude plugin install financial-analysis@claude-for-financial-services
claude plugin install pitch-agent@claude-for-financial-services
claude plugin install gl-reconciler@claude-for-financial-services
- 同一套源文件同时服务 Cowork 与 Managed Agents
README 里反复强调“一份源，两种部署面”：Cowork 作为交互式插件入口，Managed Agents API 作为后端工作流入口。managed-agent-cookbooks/<slug>/agent.yaml 不复制系统 prompt，而是引用对应插件目录里的 agent prompt 和 skills。
以 Pitch Agent 为例，agent.yaml 里有三个关键点：
system:
file: ../../plugins/agent-plugins/pitch-agent/agents/pitch-agent.md
append: "You are running headless. Produce files in ./out/; do not assume an open Office document."
skills:
- { from_plugin: ../../plugins/agent-plugins/pitch-agent }
callable_agents:
- { manifest: ./subagents/researcher.yaml }
- { manifest: ./subagents/modeler.yaml }
- { manifest: ./subagents/deck-writer.yaml }
这段设计很直接：交互场景和 headless 场景共用同一份 Agent 知识，只在托管部署时追加运行环境约束。
- MCP 数据连接器集中在 financial-analysis
financial-analysis 插件承担核心连接器入口，README 列出了 Daloopa、Morningstar、S&P Global、FactSet、Moody's、MT Newswires、Aiera、LSEG、PitchBook、Chronograph、Egnyte、Box 等数据源。这里要加一个边界：README 表格是连接器目录，真实可用性取决于订阅、API Key、MCP 服务状态和企业授权。
我实际检查了 plugins/vertical-plugins/financial-analysis/.mcp.json，文件当前不是合法 JSON：
| 检查项 | 结果 |
|---|---|
python3 -m json.tool 等价解析 | 失败 |
| 错误位置 | line 47 column 5 |
| 直接原因 | egnyte 与 box 段之间缺少逗号，末尾大括号也不完整 |
| 影响 | README 所说的连接器思路成立，但该文件需要修复后才能作为 JSON 配置直接消费 |
- Agent 权限边界写进 Managed Cookbook
Managed Agent 模板里，每个工作流通常拆成 orchestrator + 3 个 leaf worker。Pitch Agent 的 leaf 是 researcher、modeler、deck-writer，只有 writer 负责最终写文件。Model Builder 则是 data-puller、builder、auditor。这种拆法的好处是：读、算、写可以分别审计，出错时也更容易定位。
| Agent | 典型 leaf workers | 写权限边界 |
|---|---|---|
| pitch-agent | researcher · modeler · deck-writer | deck-writer |
| market-researcher | sector-reader · comps-spreader · note-writer | note-writer |
| earnings-reviewer | transcript-reader · model-updater · note-writer | note-writer |
| model-builder | data-puller · builder · auditor | builder |
| gl-reconciler | reader · critic · resolver | resolver |
- 有验证链，但验证覆盖面要分清
仓库提供了两类验证：
| 验证入口 | 我实际运行的结果 | 能证明什么 | 不能证明什么 |
|---|---|---|---|
claude plugin validate | 19 个 marketplace/plugin manifest 全部通过，marketplace 有 1 个 description warning | 插件 manifest 能被当前 Claude Code CLI 识别 | 不证明业务流程正确 |
python3 scripts/check.py | 失败，3 个 bundled skill 缺 source | YAML/JSON/frontmatter/引用关系/skill drift 检查 | 不覆盖 .mcp.json 语法，也不验证模型行为 |
.mcp.json JSON 解析 | 失败 | 当前 connector 配置文件存在语法问题 | 不否定 README 的连接器设计 |
GitHub Actions plugin-validate.yml | 配置存在，固定 Claude Code 2.1.143 | CI 会跑插件校验 | 不等同于完整端到端业务测试 |
🔬 技术架构深度解析
这个仓库的产品层不是 Python 包，而是文件化 Agent 系统。GitHub 语言统计显示 Python 63.0%，但源码扫描后可以看到，真正的知识密度主要在 Markdown、YAML 和 JSON 里。
anthropics/financial-services
├── .claude-plugin/marketplace.json
├── plugins/
│ ├── agent-plugins/ # 10 个完整工作流 Agent
│ │ └── <agent>/
│ │ ├── agents/*.md # 系统 prompt / 工作流说明
│ │ ├── skills/* # agent 自带技能副本
│ │ └── .claude-plugin/plugin.json
│ ├── vertical-plugins/ # 6 个垂直技能包
│ │ └── <vertical>/
│ │ ├── skills/* # 可复用技能
│ │ ├── commands/* # slash command
│ │ └── .mcp.json # 数据源连接器配置
│ └── partner-built/ # LSEG / S&P Global 合作方插件
├── managed-agent-cookbooks/ # 10 套 Managed Agent 模板
│ └── <agent>/
│ ├── agent.yaml
│ ├── subagents/*.yaml
│ └── steering-examples.json
└── scripts/
├── check.py
├── validate.py
├── deploy-managed-agent.sh
├── orchestrate.py
└── sync-agent-skills.py
文件体量与知识分布
我在浅克隆的 574ed36 提交上用 git ls-files -z 写入临时文件后解析，避免终端输出截断导致统计失真。
| 指标 | 数值 |
|---|---|
| Git 跟踪文件总数 | 363 |
| Markdown 文件 | 241 |
| YAML 文件 | 40 |
| JSON 文件 | 39 |
| Python 文件 | 17 |
| Markdown 行数 | 40,196 |
| Python 行数 | 2,850 |
| YAML 行数 | 1,057 |
| Shell 行数 | 562 |
| PowerShell 行数 | 465 |
| 目录 | 文件数 | 主要内容 |
|---|---|---|
plugins/vertical-plugins | 130 | 垂直技能、命令、连接器配置 |
plugins/agent-plugins | 95 | 完整流程 Agent 与打包技能 |
managed-agent-cookbooks | 61 | Agent YAML、subagent YAML、steering examples |
plugins/partner-built | 36 | LSEG、S&P Global 插件 |
claude-for-msft-365-install | 25 | Microsoft 365 add-in 管理安装工具 |
.github/workflows | 3 | secret scan、version bump、plugin validate |
这组数据说明它更接近“Agent 工作流知识库 + 部署模板”，不是以 Python runtime 为中心的框架。
决策与执行流水线
Managed Agent Cookbook 的核心流程可以拆成 6 步：
用户 steering event
│
▼
orchestrator agent
读取 agent.yaml
内联 system prompt
上传 skills
创建 leaf workers
│
├── reader / researcher：读取材料、拉数据、整理证据
├── modeler / builder：建模、计算、填模板
└── writer / resolver：生成最终文件或待签字结果
│
▼
结构化输出 / handoff_request
│
▼
scripts/orchestrate.py
allowlist 目标 Agent
校验 payload schema
将 handoff 变成下一条 steering event
这里最有意思的是 handoff 设计。Managed Agent README 说，命名 Agent 之间不直接互相调用；如果一个 Agent 需要另一个 Agent，它输出 handoff_request，再由 scripts/orchestrate.py 或企业自己的 Temporal/Airflow/Event Bus 路由。这样做牺牲了一些“Agent 自治”的想象空间，但换来了更清晰的控制面。
权限控制不是一句安全声明
Pitch Agent 的 agent.yaml 显式启用了 read/grep/glob，默认关闭其他 agent toolset；MCP server 只声明 capiq 与 daloopa 两个远端。leaf worker 通过 callable_agents 挂进去，Managed Agent README 又限制子 Agent 只支持一层 delegation。换句话说，这套 cookbook 的安全边界主要来自配置、工具启用范围、worker 分工和外部编排器，而不是 OS 级沙箱。
我会把它的控制分成四类：
| 控制类型 | 仓库证据 | 成熟度判断 |
|---|---|---|
| 可执行校验 | claude plugin validate、scripts/check.py、GitHub Actions | manifest 层比较扎实 |
| Agent-mediated 流程 | Agent prompt、skills、commands | 依赖模型遵循指令，需要人工复核 |
| 外部系统边界 | MCP URL、API Key、数据供应商订阅 | 需要企业环境自行治理 |
| 人工签字 | README 明确所有输出 staged for human sign-off | 这是金融场景的必要边界 |
验证结果与缺口
本次运行了仓库自带检查，也额外做了 JSON 解析和 Claude CLI 帮助校验。
| 项目 | 结果 |
|---|---|
claude --version | 2.1.267 |
claude plugin marketplace --help | 确认 add <source> 命令存在 |
claude plugin install --help | 确认 install <plugin> 命令存在 |
claude plugin validate --help | 确认支持 --json、--strict |
claude plugin validate 全量插件 | 通过，marketplace 缺 description 警告 |
scripts/check.py | 失败，3 个 meeting-prep-agent bundled skill 没有 vertical source |
.mcp.json 解析 | 失败，JSON 语法错误 |
这不影响它作为架构样板的价值，但会影响“开箱即用”的判断。企业团队参考它时，第一步应该是跑自己的 schema 校验和连接器 smoke test，而不是直接把所有配置导入生产环境。
📖 README 核心内容摘要
README 把仓库分成两层：Agents 和 Vertical Plugins。
Agents 是完整流程入口。当前 README 列出的核心 Agent 包括 Pitch Agent、Meeting Prep Agent、Market Researcher、Earnings Reviewer、Model Builder、Valuation Reviewer、GL Reconciler、Month-End Closer、Statement Auditor、KYC Screener。它们覆盖投行材料、会议准备、投研、财务建模、基金管理、总账对账、KYC 等流程。
Vertical Plugins 是底层能力包。financial-analysis 是核心，提供 comps、DCF、LBO、三表模型、Excel audit、deck QC 等能力；investment-banking、equity-research、private-equity、fund-admin、operations 则把命令和技能按场景拆分。README 还列出 LSEG 和 S&P Global 的 partner-built 插件。
README 里的设计哲学可以概括成三句话：
| README 观点 | 工程含义 |
|---|---|
| Same system prompt, same skills | 交互插件和托管 API 不维护两套知识 |
| Everything is file-based | Agent 能力通过 Markdown/YAML/JSON 版本化 |
| Human sign-off | 模型输出是草稿或待审批结果，不直接做投资、交易、入账或审批动作 |
一个典型 Cowork/Claude Code 安装路径是：
claude plugin marketplace add anthropics/financial-services
claude plugin install financial-analysis@claude-for-financial-services
claude plugin install pitch-agent@claude-for-financial-services
一个典型 Managed Agent 部署路径是：
export ANTHROPIC_API_KEY=sk-ant-...
scripts/deploy-managed-agent.sh gl-reconciler
deploy-managed-agent.sh 的源码显示，它会解析 agent.yaml，展开 from_plugin 下的 skills，上传 skills，递归创建 subagents，最后向 /v1/agents POST orchestrator 配置。脚本还支持第二个参数 --dry-run，但 README 的快速上手没有把它作为主路径。
🚀 快速上手
如果只是看结构，不建议先安装插件。直接克隆、验证、读目录会更安全。
git clone https://github.com/anthropics/financial-services.git
cd financial-services
# 校验 marketplace 或单个插件 manifest
claude plugin validate .claude-plugin/marketplace.json
claude plugin validate plugins/agent-plugins/gl-reconciler
如果你要在 Claude Code 里试插件安装，可以按 README 的方式添加 marketplace：
claude plugin marketplace add anthropics/financial-services
claude plugin install financial-analysis@claude-for-financial-services
claude plugin install gl-reconciler@claude-for-financial-services
如果你要研究 Managed Agent 模板，先读这几个文件：
| 文件 | 看什么 |
|---|---|
managed-agent-cookbooks/README.md | orchestrator、leaf worker、handoff 模型 |
managed-agent-cookbooks/gl-reconciler/agent.yaml | 工具、MCP、skills、callable_agents 如何声明 |
scripts/deploy-managed-agent.sh | YAML 如何展开成 /v1/agents payload |
scripts/orchestrate.py | handoff_request 如何被外部编排器接住 |
scripts/check.py | 仓库作者希望校验哪些结构约束 |
最小阅读路径可以这样走：
README.md
↓
managed-agent-cookbooks/README.md
↓
managed-agent-cookbooks/<agent>/agent.yaml
↓
plugins/agent-plugins/<agent>/agents/<agent>.md
↓
plugins/agent-plugins/<agent>/skills/*
如果要接入真实金融或企业数据，先修复 .mcp.json，再用内部测试账号逐个验证 MCP 连接器。README 已经写明输出不构成投资、法律、税务或会计建议，业务系统也不应把这些 Agent 的输出直接当成审批结果。
📊 增长速度与社区热度
这个仓库创建于 2026-02-23，到 2026-09-23 快照日约 211.19 天。按 36,592 Stars 粗算，生命周期平均约 173.3 Stars/天。这个数只能当 baseline：Trending 快照没有保留每个仓库的“今日新增 Stars”，所以不能把它写成当天增长速度。
GitHub API 稍后核验时，Stars 从快照的 36,592 变成 36,595，只能说明两个观察点之间增加了 3 个 Star。Forks 为 5,344，Open Issues 为 216，Watchers 为 284。最近 5 条提交集中在 2026-09-14 到 2026-09-21，其中包括删除 claude-for-financial-advisors 目录、凭据放入 URL fragment、记录 file_path 访问策略等维护动作。
社区结构上，前 10 名贡献者的提交数比较集中：mihilmy 19、cxyback 17、manar-ant 12、tobinsouth 8、viveknair 5。没有 Release 和 Tag，说明它更像随主分支快速演进的参考仓库，而不是按语义版本发布的库。
今日 GitHub Trending 榜单
| Rank | Repository | Language | Stars | Forks | 今日新增 Stars |
|---|---|---|---|---|---|
| 1 | anthropics/financial-services | Python | 36,592 | 5,344 | 快照未保留 |
| 2 | agent-substrate/substrate | Go | 3,145 | 394 | 快照未保留 |
| 3 | dream-num/univer | TypeScript | 15,867 | 1,406 | 快照未保留 |
| 4 | davila7/claude-code-templates | Python | 31,243 | 3,552 | 快照未保留 |
| 5 | google/ax | Go | 8,094 | 374 | 快照未保留 |
| 6 | mvt-project/mvt | Python | 14,265 | 1,367 | 快照未保留 |
| 7 | superdesigndev/treg | Python | 2,379 | 227 | 快照未保留 |
| 8 | browser-use/video-use | Python | 26,119 | 3,135 | 快照未保留 |
🎯 适用场景
| 场景 | 为什么适合 | 使用边界 |
|---|---|---|
| 企业 Agent 工作流设计 | 目录结构展示了 Agent、Skill、Command、Connector、Cookbook 如何拆层 | 不能直接复制合规边界，需要结合企业权限系统 |
| Claude Code 插件开发 | marketplace、plugin manifest、commands、skills 都有现成样例 | 当前 marketplace description 有 warning，发布前应补齐元数据 |
| Managed Agent 部署研究 | agent.yaml 和 deploy 脚本展示了从文件到 API payload 的转换 | 需要 Anthropic Managed Agents API、PyYAML、jq、API Key |
| 金融分析内部助手原型 | 覆盖 comps、DCF、LBO、earnings、KYC、GL recon 等流程 | 输出必须人工复核，不能直接做交易、投资建议或入账 |
| MCP 数据接入样板 | README 集中列出多个金融数据供应商 MCP 入口 | .mcp.json 当前语法需修复，数据源通常还要订阅授权 |
| Agent 权限分层参考 | leaf worker 分工清楚，部分 writer 才有写入责任 | 这是应用层分工，不是容器或 OS 沙箱 |
💡 总结
anthropics/financial-services 有两个看点。
第一个是结构。它把 Agent 工作流拆成插件、技能、命令、连接器、托管模板和编排脚本，适合拿来研究企业 Agent 的工程组织方式。尤其是 Cowork 与 Managed Agents 共用一套源文件这点，对内部平台团队很有参考价值。
第二个是边界。README 写得很清楚：这些 Agent 草拟分析材料、模型、备忘录、研究笔记和对账结果，最后必须由合格专业人士复核。源码检查也能看到，仓库有 manifest 校验和结构检查，但仍存在 .mcp.json 语法错误、bundled skill source drift 这类问题。
所以我不会把它推荐成“装上就能跑金融业务”的工具。更准确的定位是：一套由 Anthropic 给出的金融服务 Agent 参考实现。它告诉你企业 Agent 该怎么拆文件、怎么接数据、怎么区分读写权限、怎么把模型输出放回人工审批链路。真正落地时，验证、权限、数据许可和业务责任还要自己补齐。
