MCP 看起来像是我们一直在等的那块拼图：把模型连接到工具的清爽协议。MCP Server 公布它能做什么，客户端调用这些工具，模型保持“聪明”，工具层保持“确定性”，听起来一切都很完美。

直到你开始做一个真正的金融应用。

因为金融不是“几个工具就够了”的世界，而是：

• 成百上千个 API 端点：行情、基本面、预估、新闻、公告/申报、期权、利率、投资组合、风险……
• 每个端点几十个参数（有时更多）：标的识别、标的池、复权/公司行动、as-of、币种、权限、分页、过滤、覆盖项、区域差异……
• 持续变化：字段新增/废弃、供应商迁移、限流策略、按团队/地区/合同划分的权限与授权

这时 MCP 的现实限制就会浮现：单个 MCP Server 很难“合理地”暴露上千个工具，即使能做到，你也不想这么做。没有人希望模型在 1,200 个工具的“电话簿”里翻来翻去。

所以在金融里能跑得长远的模式其实很简单：

每个 MCP Server 保持小而精（约 20–30 个工具）。
能力扩展靠增加更多智能体（以及更多 MCP Server）。

下面我按从单用户到多供应商生态的路线，讲清楚三种架构，再补充为什么当智能体网络真正复杂起来时，Prompits 能带来系统级的帮助。

---

心智模型：MCP 是“前门”，智能体是“整栋楼”

MCP 最适合作为一个稳定的契约边界。你想要一个小而可控的对外接口面，不会因为供应商新增一个字段就把客户端搞崩。

复杂性要放到边界之后——也就是智能体：

• 它们可以扇出到数百个端点
• 它们可以管理参数矩阵
• 它们可以编码金融领域语义与防护栏
• 它们可以演进，而不需要每周都改客户端

这不是学术讨论，而是让金融应用保持可部署、可审计、可维护的基本功。

---

设计 1 —— 单用户 / 小团队：“薄 MCP，直接检索”

这是“先跑起来”的架构，而且它确实有用。

适用场景

• 量化研究工作站
• PM 的个人情报工具
• 数据源有限的小型内部产品

长什么样

• 应用连接一个或少数几个 MCP Server
• 每个 Server 暴露少量工具：
  • resolve_symbol()
  • get_prices()
  • search_news()
  • get_fundamentals()
• LLM（本地或云端）负责编排：选工具 → 调工具 → 生成答案

为什么能行
在这个规模下复杂度是有边界的：覆盖的资产类别/地区不多，权限体系不那么复杂，也没有几十个团队共同维护一个平台。

什么时候会崩
当你想扩展范围：

• 期权波动率曲面
• 按贡献者的预估历史
• 日内微观结构、多交易所行情
• 公司行动边缘规则
• 公告/申报解析与指引抽取
• 风险因子暴露
• 内部投资组合约束

你往往会走向两个坏方向之一：

1. 不断往 MCP 里加工具，最后变成一本文档；
2. 把所有东西塞进一个 fetch_everything(spec) 的超级工具，失去可测试性与安全性。

这就是企业架构登场的信号。

---

设计 2 —— 企业级：“智能体联邦 MCP（靠加智能体扩展）”

企业级金融应用里，这条规则几乎不可妥协：

如果你需要几百/上千个工具，不要做一个巨大的 MCP Server。
增加更多智能体。 每个 MCP Server 维持 20–30 个工具。

核心思路：通过增加智能体来“扩展 MCP”

把系统看成一个联邦：

• 每个领域智能体负责金融的一小块
• 每个领域智能体运行（或代理）自己的 MCP Server
• 每个 MCP Server 都小而精（20–30 个工具）
• 企业能力由许多小接口的“总和”组成

如果你真的需要“1,000 个工具”，你不是在一个地方写 1,000 个 tool definition，而是比如：

• 40 个领域智能体 × 每个 25 个工具
• 由不同团队负责
• 独立部署
• 权限边界清晰、可审计

企业里你会真正去做哪些智能体

金融在组织结构上天然会分片：

• 行情智能体（Market Data Agent）
  价格、日内 K 线、交易所覆盖、公司行动
• 基本面智能体（Fundamentals Agent）
  财报、指标、分部、管理层指引
• 新闻与事件智能体（News & Events Agent）
  新闻、聚类、实体抽取、事件日历
• 期权智能体（Options Agent）
  期权链、Greeks、IV 曲面、持仓量
• 利率/宏观智能体（Rates/Macro Agent）
  曲线、掉期、通胀、远期与外汇衍生品
• 风险/因子智能体（Risk/Factor Agent）
  暴露、情景库、压力测试输入
• 组合/内部系统智能体（Portfolio/Internal Agent）
  持仓、PnL、约束、合规标记

每个智能体对外暴露的 MCP 菜单都要稳定。至于背后怎么调用数百个端点、怎么处理参数组合与供应商差异，这些复杂性都应该留在智能体内部。

需要一个“前台”编排智能体

你仍然需要一个协调者——可以叫 LLM 编排智能体（LLM Orchestrator Agent）：

• 理解用户意图（“为什么涨跌？”“筛选这些股票” “构建对冲篮子”）
• 选择正确的领域智能体
• 组合结果，输出带证据的叙事

这个编排智能体不需要“认识 1,000 个工具”，它只需要知道该问哪个智能体。

你绕不开的胶水：注册与路由

当智能体变多后，你必须解决路由：

• APAC 的期权该找谁？
• 这个用户的权限允许调用哪些智能体？
• 现在哪个智能体健康、延迟低、成本更优？

一开始可以用静态配置，企业规模后往往会变成平台能力：发现、健康检查、配额、成本预算、故障降级。

为什么这套设计能扛住现实

• 团队可以负责自己的领域，而不是协作维护一个单体怪物
• 工具列表保持可读（每个 Server 20–30 个）
• 故障可隔离（期权挂了不影响基本面）
• 权限更可控（策略贴近数据域）
• 变化可管理（对外契约稳定，内部快速迭代）

到这里，MCP 不再是“工具列表”，而是“能力边界”。

---

设计 3 —— 生态级：“供应商智能体 + Plaza + Broker 驱动的发现与选择”

企业很难，生态更难。

生态级意味着你不是在集成“你的数据源”，而是在集成别人的系统、别人的数据、别人的语义，还经常带着严格的许可限制。

这时最正确的一步，反而是：

让供应商自己写智能体。

因为他们最懂：

• 数据语义、默认值、边缘案例
• 覆盖范围的细节与坑
• 性能优化与缓存策略
• 必须严格执行的授权、许可与限流

所以在设计 3 里，平台不再试图编码所有数据集，而是协调一群专业智能体。

供应商智能体：供应商自带的“智能边界”

一个 供应商智能体（Vendor Agent）：

• 暴露一个 MCP Server，仍然是 20–30 个精选工具
• 内部映射到大量私有 API、参数矩阵
• 在边界处严格执行许可、权限、限流
• 返回结构化数据包，并附带溯源与 as-of 元数据

你不想自己重写供应商的领域逻辑。你想要供应商把它封装成智能体。

Plaza：生态的“广场”，用于发现与证据交换

点对点集成无法规模化。你需要一个共享的协调层，这就是 Plaza（广场）。

Plaza 是一个共享的发现与发布空间，让智能体可以：

1. 发布能力声明
2. 发布产物/证据包（evidence bundles）
3. 在不硬编码集成的情况下协作

你可以把 Plaza 理解为混合体：

• 能力注册表（capability registry）
• 公告板（bulletin board）
• 证据账本（evidence ledger）

Plaza 上会发布什么（更贴近现实）

能力声明

• “OptionsVendorAgent：实时期权链 + Greeks；需要 OPRA 权限”
• “FilingsVendorAgent：SEC 申报解析 + 指引抽取；5 分钟延迟”
• “MacroRatesAgent：曲线/掉期；多币种；EOD + Intraday”

产物（证据包）

• 标准化的期权链表（含时间戳、覆盖、权限上下文）
• 从申报与新闻抽取的事件时间线（关联标的与实体）
• “为什么涨跌”的证据包（价格跳变 + 相关新闻 + 同行联动）

元数据

• 新鲜度（as_of）
• 覆盖标签（资产类别、地区、交易所/场内场外）
• 可靠性（延迟区间、错误率）
• 许可提示（能否共享原始数据、仅能共享衍生数据、能否再分发）

Plaza 在金融里尤其重要，因为金融不是“取数”，而是“取到你能辩护的数据”。Plaza 让溯源成为习惯。

Plaza 必须有的护栏

Plaza 不能是一个“大家随便丢数据”的仓库，它必须具备：

• 身份与组织边界（谁能看什么）
• 权限感知（可见性规则）
• 以产物为主（优先共享衍生/引用而非原始 dump）
• 可追溯（防篡改日志）

Plaza 做不好，就会变成世界上最有效的数据泄漏系统。

Data Broker 智能体：帮你选“最合适的供应商”

当供应商智能体多了，你需要“选择”能力。

Data Broker 智能体会：

• 查询 Plaza 发现候选项
• 按需求推荐最合适的供应商/服务：
  • 覆盖匹配
  • 延迟与可靠性
  • 成本与权限约束
  • 许可允许的使用方式（原始 vs 衍生 vs 可再分发）
• 给出在权限缺失时的 fallback 链

这是“会思考的路由”，不是一张静态配置表。

Analyst 智能体：聚合与合成的“决策级情报”

最后，总得有人把一堆证据变成能用的结论。

Analyst 智能体会：

• 跨供应商聚合输出
• 对冲突进行调和并给出置信度
• 产出衍生/合成结果：
  • 共识视图
  • 混合曲线
  • 影响评分
  • 异常检测
  • 叙事聚类
• 发布“简报”而不是原始数据堆

现实中，这一层才是用户记得住的价值：取数只是门槛，合成才是产品力。

---

Prompits 在哪里发挥作用：编排与演化复杂的多智能体系统

设计 2 和 3 真正落地后，难点就不再是“能不能调用工具”，而是系统级问题：

• 30+ 智能体如何协作而不变成意大利面？
• 工作流如何安全地版本化？
• 每次请求怎么选最合适的智能体组合？
• 如何衡量质量 vs 延迟 vs 成本？
• 如何持续改进而不把线上打崩？

这正是 Prompits 擅长的地方：把多智能体从“拼起来能跑”升级到“可治理、可进化”。

Pathways：可版本、可审查、可回放的工作流

Prompits 用 Pathway（路径） 表达工作流，用 Post（节点） 表达步骤/检查点。

在金融里，一个“简单问题”往往是可复现的流程：

1. 标的解析 + 公司行动规则
2. 多源证据拉取
3. 标准化 + 时间/币种对齐
4. 分析（因子、事件研究、情景）
5. 叙事 + 引用 + 合规安全摘要

Pathways 让你像写软件一样管理它：版本、测试、审查。

Plaza 式协作：发现、发布、复用

Prompits 的 Plaza 思想天然适配生态设计：

• 智能体发布能力
• 发布证据包
• 共享产物，便于复用与审计

这可以减少重复的供应商调用，也让输出更“可辩护”。

Pathfinder + Profiler：路由与持续优化

• Pathfinder 决定执行顺序与跨智能体委派
• Profiler 评估结果并给工作流打分

这让你能：

• 为不同地区/资产类别选择更优的供应商智能体
• 在“快/便宜”和“慢/强”之间动态切换模型
• 找出哪些工作流变体更可靠、更准确、更省钱
• 不靠拍脑袋持续演进

Press：可搜索的知识产物库

复杂系统会生成大量有价值的中间产物：

• 清洗后的数据集
• 映射表
• 事件抽取结果
• 证据包
• 可复用的简报

Prompits 的 Press（可搜索的知识空间）让这些产物成为资产，而不是一次性聊天输出。

---

让你保持理智的一条规则

如果只记住一句话：

不要靠把 MCP Server 做大来扩展 MCP。
靠增加更多智能体来扩展。
每个 MCP Server 保持 20–30 个工具，再在其上构建路由、溯源与合成能力。

这就是 MCP 在真实金融世界里能跑起来、能扩展、还能长期维护的方式。