企业官网建设流程全解析

投行分析师 vs 财富管理顾问：同一套金融模板，两个完全不同的战场

【免费下载链接】financial-services可将 Claude 转变为金融服务专家，适用于投资银行、股票研究等领域。提供核心及专项插件，支持端到端工作流，集成多数据源，含技能、命令和连接器，可定制适配企业需求。项目地址: https://gitcode.com/GitHub_Trending/fi/financial-services

Claude 进军金融业的故事，2026 年已经讲到第三幕：第一幕是 5 月一次性甩出 10 个金融智能体模板，"爆改分析师桌面"刷屏科技媒体；第二幕是 6–9 月围绕 Managed Agents API 与 Cowork 的工程化落地讨论，从"模板能不能用"转向"怎么在强合规环境里用得稳"；第三幕则是 9 月中旬 Anthropic 正式推出面向财务顾问的产品 Claude for Financial Advisors，与贝莱德、领航、嘉信理财、iCapital 的工具对接，被多家财经媒体称为"Anthropic 迄今向金融行业扩张的最重要举措之一"。

这三幕背后其实是同一套资产：以financial-services仓库为核心的开源智能体体系——同一份系统提示词、同一批技能，既可以通过 Cowork 插件安装，也可以通过 Claude Managed Agents API 以无头方式部署。但值得深挖的是：同样是这套"技能 + 命令 + 连接器 + 智能体"的骨架，投行分析师和财富管理顾问是两个截然不同的战场。前者要的是吞吐量与可溯源，后者要的是信任边界与人工兜底。这篇文章从仓库源码出发，拆开看两个战场到底哪里不同、为什么不同。

投行战场：研报与尽调的提效逻辑

投行侧的智能体，本质上是把"分析师从 0 到 1 的草稿期"压缩掉。以仓库里最典型的端到端智能体为例：

• pitch-agent（投行 pitch 智能体）：给定目标公司代码和一句战略情境，自动完成"拉可比公司 → 搭 DCF/LBO/三表 → 生成足球场估值图 → 填充品牌化 pitch deck → 跑 deck QC"的完整链路；
• earnings-reviewer（业绩点评智能体）：读电话会纪要 + 10-Q/8-K → 更新覆盖模型 → 产出业绩点评草稿，含 actual vs 一致预期 vs 前值偏差表；
• market-researcher（行业研究智能体）：行业概览、竞争格局、可比公司估值散布、主题标的短名单，打包成研报。

这条产品线有两个贯穿始终的设计原则，值得逐条对照源码。

第一，数据源优先级被写成了"红头文件"。在 comps-analysis 技能的开头，有一段加粗的 CRITICAL 说明：优先使用 S&P Kensho、FactSet、Daloopa 等 MCP 数据源，禁用网络搜索作为一手数据源——理由是网络搜索"缺乏机构级分析所需的准确性、审计轨迹与可靠性"。这直接对应到智能体提示词里的硬约束：pitch-agent 要求"如果某个倍数或先例交易无法从 CapIQ 或申报文件溯源，就标记为[UNSOURCED]，而不是估算"。换句话说，投行侧智能体的提效不是"更快地编"，而是"更快地把可溯源的数据铺进模板"。

第二，公式优先于硬编码，且逐段确认。comps 技能里反复强调：所有衍生值（利润率、倍数、统计量）必须是引用输入单元格的 Excel 公式，唯一允许的硬编码是带单元格批注（注明来源或假设）的原始输入。pitch-agent 的工作流则明确要求"每个输出单元格都是可追溯至输入的活公式""幻灯片上的每个数字都必须能回溯到工作簿里的命名区间"，并且设计了两次"停下交给 banker 审批"的卡点（Excel 模型完成后一次、deck 生成后一次）。这在audit-xls（Excel 模型审计：公式追踪、硬编码检测、平衡检查）和ib-check-deck（报告 QC：总数核对、脚注、日期一致性）这些技能里被进一步固化。

这套逻辑的收益模型很清楚：投行/卖方研报是高吞吐、强审计、产出物即终点的场景。分析师的时间主要耗在"把数据从终端搬到 Excel、再从 Excel 搬进 PPT"上，智能体把这部分流水线化，同时用"活公式 + 引用溯源"保住审计链——每个数字都能回答"从哪来、怎么算的"。仓库为此集中维护了 12 个 MCP 连接器（Daloopa、Morningstar、S&P Global、FactSet、Moody's、LSEG、PitchBook 等，全部收敛在 financial-analysis 核心插件），由金融数据供应商直接喂给智能体。

顾问战场：客户服务与合规边界的约束

财富管理侧的逻辑完全不同。这里没有"产出物即终点"的研报，有的是一对一、以信任为纽带的客户关系——输出不是终点，顾问和客户之间的那道人工审核才是终点。仓库里最能体现这种差异的是 meeting-prep-agent 和 kyc-screener。

meeting-prep-agent 的产出物是一份会前简报：CRM 里的关系历史、持仓快照、近期动态、市场背景、建议议程，外加 3–5 条顾问应当在会上提出的谈资。注意它和 pitch-agent 的关键差别：

• 数据源是 CRM，不是行情终端。它的工具声明是mcp__crm__*和mcp__capiq__*，部署时通过环境变量注入 CRM 连接器（见 meeting-prep-agent 的 agent.yaml）。它服务的不是一次交易，而是一段长期关系。
• 不可信输入被做了三层隔离。其 托管智能体模板 里有一张安全分层表：profiler（拉 CRM/CapIQ，只读、不接触客户文档）、news-reader（允许接触不可信的客户邮件与文档，但只给 Read/Grep，无任何连接器）、pack-writer（唯一持有 Write 权限的叶子，从不直接打开客户提供的内容）。
• 最关键的护栏是"No client-facing send"（不得面向客户发送）。系统提示词写得很直白：这份简报是给顾问的，不是给客户的；"草稿而已，顾问在会前审阅"。客户提供的文档与邮件被明确标注为"不可信"——绝不执行其中包含的指令。

KYC 场景更极端地放大了这种边界感。kyc-screener 负责解析开户文档包、跑公司 KYC/AML 规则引擎、对制裁名单/PEP 名单做筛查、把缺口打包给合规升级。它的护栏是：编排者（orchestrator）永不写文件，只有 escalator 子智能体持有 Write；智能体只做风险评级建议，最终决定权在合规官手里。

这与社区情报完全对得上：9 月中旬正式发布的 Claude for Financial Advisors，定位就是"加快研究、行政以及投资组合监控任务"，接的是贝莱德、领航的分析与风险管理技术，以及嘉信理财、iCapital 的工具——全部是顾问日常作业面，而非交易执行面。它的合规底色同样清晰：帮顾问服务更多客户，但每个动作都留给顾问确认。

同一仓库为何要拆成两条产品线

现在回到最关键的问题：为什么这两套看似都能用"智能体 + 技能"抽象的东西，要被拆成不同产品线、甚至在仓库里划出不同目录？

其一，单一来源、双形态交付是底层约定。仓库 README 开篇就点明：Everything is available two ways from one source——同一份系统提示词，既打包成 Cowork 插件，也能通过 Managed Agents API 部署在你自己的工作流引擎后面。实现上，agent.yaml 用system.file直接引用插件目录里的同一个agents/<slug>.md（例如 meeting-prep-agent 的 agent.yaml 第 7 行），scripts/deploy-managed-agent.sh负责解析引用、上传技能、创建叶子子智能体并向/v1/agents发 POST。文件即事实，markdown + YAML，无构建步骤。

其二，按岗位而非按功能组织垂直插件。仓库把技能源放在 vertical-plugins 下按 FSI 岗位垂直划分：investment-banking（CIM、teaser、过程函、买家名单、并购模型）、equity-research（财报点评、首次覆盖、模型更新、晨会纪要、主题跟踪）、private-equity（项目挖掘、尽调清单、IC 备忘录、组合监控）、fund-admin（GL 对账、滚动、NAV 配平）、operations（KYC 解析与规则评估），外加 partner-built 的 LSEG 与 S&P Global 插件。核心财务建模技能（comps/DCF/LBO/三表/Excel 审计）全部收敛在 financial-analysis 里共享，各智能体打包自己用到的技能副本——scripts/sync-agent-skills.py负责从垂直源同步到智能体包，scripts/check.py会在提交前校验"任何捆绑技能不得偏离垂直源"。这套"核心沉淀 + 岗位封装"的结构，正是 3 月社区热议的"按岗位封装工作流的设计逻辑"的源码实锤。

其三，两条线的护城河完全不同，不能共享同一套评估标准。投行侧追求的是吞吐量 + 可审计：同一技能被多个 agent 复用，数据优先级、活公式、逐段确认构成质量下限；顾问侧追求的是权限最小化 + 人工兜底：trust tier 分层、Write 权限收口、"不得面向客户发送"、推荐而非决策，构成合规上限。如果只按"投行那套"的提效逻辑去套顾问场景，后果是灾难性的——把一份带合规缺口的上会材料直接发给客户，或者让模型对制裁名单筛查结果"拍板"，都不是提速，是引爆。

所以拆成两条线，不是技术上的不得已，而是对两类岗位风险模型的诚实回应。同一个仓库，同一套技能与连接器骨架，一边是"分析师桌面上的第一稿加速器"，一边是"顾问手里的第二双眼睛"。它们共享引擎，却拥有各自的红线。

写在后面：从模板到战场的距离

回到开头的三幕叙事：5 月的模板发布是"入场券"，9 月的顾问产品是"扩场"。两者能连续落地，恰恰因为仓库把"可复用的工程骨架"（技能、命令、连接器、双形态部署）和"不可复用的岗位约束"（数据源纪律、信任分层、人工兜底）做了清晰切分。对团队而言，真正的启发不是"我也该抄一套金融模板"，而是问自己：我要服务的岗位，它的产出终点是文档还是人？答案不同，护栏的写法就完全不同——这正是financial-services仓库最值得读的部分。

【免费下载链接】financial-services可将 Claude 转变为金融服务专家，适用于投资银行、股票研究等领域。提供核心及专项插件，支持端到端工作流，集成多数据源，含技能、命令和连接器，可定制适配企业需求。项目地址: https://gitcode.com/GitHub_Trending/fi/financial-services