2026 年 5 月 5 日前后，Anthropic 与 Blackstone、Goldman Sachs、Hellman & Friedman 等华尔街机构推进了一项约 15 亿美元的 AI 合资项目，目标是把 Claude 相关 AI 能力部署到金融企业和私募股权投资组合公司中。与此同时，Anthropic 发布了面向金融服务行业的 10 个 Agent 模板，并开源了 anthropics/financial-services 仓库。
从表面看，financial-services 是一套金融行业模板，但其背后，是一套可以迁移到各行业的 企业级 Agent 架构。
本文我们分析一下这套架构的组成和运行逻辑，以及企业如何落地；供正在和准备做 Agent 落地的企业参考。
首先说一下重点：1）这套架构的核心是 Skill 和 统一语义模型，现在很多人都意识到了 Skill 的重要性，却忽视了 统一语义模型；2）这套架构虽然当前以 Claude Cowork plugin 或 Claude Managed Agents cookbook 的形式呈现，但其核心思想并不绑定 Claude，完全可以迁移到其他智能体框架中。
一、通用 Agent 架构
通用 Agent 架构可以抽象成下面 7 层：
1. 业务触发层
用户对话、slash command、定时任务、工单事件、系统事件
2. Agent 编排层
主 Agent 理解任务、拆步骤、调用工具、分派子 Agent
3. 领域 Skill 层
SOP、检查清单、计算方法、行业规则、输出模板
4. Connector 数据连接层
MCP server、API、数据仓库、SaaS、Excel、文档库
5. 领域语义层
把不同系统字段统一成业务对象
6. 确定性执行层
SQL、Python、Excel 引擎、规则引擎负责计算和校验
7. 治理与审批层
权限、日志、数据血缘、复核、人工审批、合规在这套框架中：
LLM 不直接替代业务系统，而是变成“懂业务流程的编排器”；业务规则沉淀在 skills，企业数据通过 connectors 进入，关键动作由权限和人工审批控制。
上面的 7 层是完整架构视图，抛开基础设施和治理能力，真正决定 Agent 能否落地的核心模块主要有 5 个：Agent、Skills、Connectors、统一语义模型（Canonical Schema）、Subagents。
二、核心模块
1. Agent：端到端业务流程
Agent 不是简单聊天助手，而是一个有明确职责的流程执行者。
例如金融里的：
GL Reconciler
读取总账和子账
做对账
找差异
追根因
生成 exception report
交给人审批迁移到其他行业：
| 行业 | Agent 示例 |
|---|---|
| 制造 | 质量异常调查 Agent |
| 法务 | 合同风险审查 Agent |
| 医疗 | 理赔拒付复核 Agent |
| 供应链 | 三单匹配异常处理 Agent |
| 客服 | 复杂工单升级 Agent |
2. Skills：领域专家方法
Skill 负责把企业内部的专业 SOP 沉淀成可复用模块。
金融里的 skill 可能是：
gl-recon
break-trace
audit-xls
accrual-schedule
variance-commentary
dcf-model其他行业中可以是：
| 领域 | Skill 示例 |
|---|---|
| 制造质量 | 8D 报告、CAPA、5 Why、鱼骨图、SPC 趋势分析 |
| 医疗 | ICD/CPT 规则、病历完整性检查、拒付原因分类 |
| 法务 | 合同条款风险矩阵、红线规则、偏离审批规则 |
| 供应链 | 交付风险分级、替代供应商筛选、库存覆盖天数计算 |
| 客服 | 客诉分级、补偿政策、升级路径、话术规范 |
| 保险 | 保单责任核对、材料完整性检查、欺诈风险信号 |
3. Connectors：安全连接企业系统
AI 不应该直接连接 ERP、CRM、MES、HIS、CLM 等系统，而应通过 MCP server 或 API 网关访问受控数据。
通用结构是：
企业系统
ERP / CRM / MES / QMS / CLM / WMS / 数据仓库
↓
领域语义 API / 只读视图
↓
MCP Server
↓
Agent 可调用的业务工具例如财务系统可以暴露：
get_trial_balance
get_gl_activity
get_ar_open_items
get_journal_entry制造系统可以暴露：
get_batch_history
get_inspection_results
get_machine_events
get_capa_history需要注意的重点是：不要暴露底层数据库，而是暴露业务语义。
4. 统一语义模型（Canonical Schema）
不同企业系统字段不一样，所以需要一层统一语义模型。
最好不要每个企业从零开始定义语义模型，而应该以行业通用语义对象作为骨干，再结合企业自身业务体系、流程口径和系统字段做扩展。不然很容易做成定制化，而对于涉及数据模型的项目来说，治理工作量往往很大。
金融里可以统一成：
TrialBalance
JournalLine
SubledgerItem
Invoice
Payment
AccountMapping制造里可以统一成：
ProductionBatch
InspectionResult
MaterialLot
MachineEvent
CAPA这样 Agent 面对的是业务对象，而不是各系统的杂乱字段。
5. Subagents：权限隔离
就像人脑在面对复杂计算时，交给计算机一样，企业 Agent 也不应该让一个模型什么都能做。
可以拆成：
Reader
读取外部文件、邮件、PDF
无内部系统权限
Orchestrator
调用内部系统
只读或有限权限
Critic
独立复核结论
Resolver
生成报告、底稿、工单草稿
Human Approver
审批、签字、执行关键动作合理使用 Subagents 可以降低 prompt injection、越权访问和误操作风险。
三、企业如何落地
以 financial-services 为例看整体流程:
1. 用户或系统触发对账任务
2. Agent 读取主体、期间、账户和容差
3. Connector 调用 internal-gl 和 subledger MCP 取数
4. Skill 执行字段统一、full outer join、差异分类
5. Critic 复核重大差异
6. Resolver 生成 exception report 和 reconciliation workbook
7. Human Approver 判断是否需要调整分录对于通用行业，建议按下面 6 步走。
第一步：选一个窄场景
不要一上来做“企业级通用 AI 平台”。
先选一个满足下面条件的场景：
高频
规则相对明确
数据来源清楚
人工现在很耗时
输出可以复核
最终动作可以人审批例如：
财务：AR/AP 对账、银行余额调节、月结 variance commentary
制造：质量异常调查、供应商批次追溯、CAPA 草稿
法务：合同初审、条款偏离摘要
供应链：三单匹配差异处理、供应商延期分析第二步：画清业务流程
每个场景都应该先整理清楚：
触发条件是什么？
输入数据有哪些？
哪些系统是 source of truth？
判断规则是什么？
哪些步骤可以自动化？
哪些步骤必须人工审批？
最终产物是什么？
失败时怎么升级？例如财务 AR 对账：
触发：每月结账第 2 天
输入：总账余额、AR open items、手工凭证、客户维度映射
source of truth：ERP GL + AR subledger
规则：差异超过 10,000 元进入 exception
输出：AR recon workbook + exception report
审批：财务经理确认差异处理
禁止：Agent 不能过账制造质量异常：
触发：某批次不良率超过 3σ 控制线
输入：生产批次、检验结果、设备参数、物料批次、工艺变更
source of truth：MES + QMS + PLM
规则：影响客户批次必须升级 SQE/QA
输出：8D 草案 + 影响范围 + containment action
审批：质量经理批准 CAPA
禁止：Agent 不能关闭 CAPA第三步：设计统一语义模型
这一步是“AI 落地”的地基。
以财务行业为例：
TrialBalance
JournalLine
SubledgerItem
Invoice制造行业：
Batch
InspectionResult
MaterialLot
MachineEvent企业要先把这些对象定义清楚，再让 MCP server 输出这些对象。否则 Agent 项目会陷在各种系统字段、口径差异的泥潭里。
第四步：建设 MCP Server
企业 MCP server 应该暴露业务语义工具，而不是暴露底层表。
例如不推荐：
run_sql(query)
query_sap_table(table_name, where_clause)
read_any_file(path)
update_any_record(object, id, fields)推荐：
get_trial_balance(entity, period, account_prefix)
get_gl_activity(entity, period, account_code)
get_ar_open_items(entity, as_of_date)
get_purchase_order(po_id)具体可以参考下面的原则：
按 Agent 最小权限开放工具
按业务对象命名工具
返回结构化 JSON
每条数据带 source_system / extract_timestamp / record_id
所有 tool call 进审计日志
只读优先
写操作只写草稿区或审批队列第五步：编写 Skills，把专家 SOP 固化下来
把专家 SOP 写成可复用 skill。
例如：
财务：对账规则、差异分类、底稿模板
制造：5 Why、8D、CAPA、批次追溯
法务：条款风险矩阵、偏离审批规则
供应链：三单匹配规则、价格差异分类第六步：设计 Agent 和 Subagents
一个典型结构：
主 Agent
负责任务编排
Reader
读取外部文件
Investigator
查询内部系统
Critic
复核结论
Resolver
生成报告
Human
审批和签字总结
financial-services 的价值，不是它提供了几个金融 agent，而是展示了一种企业 Agent 产品化方法：
用 Agent 定义流程
用 Skill 固化专业方法
用 Connector 接入系统
用 Canonical Schema 统一数据
用 Subagent 隔离权限
用 Managed Agent 后台执行
用 Human Approval 控制风险这套架构可以扩展到几乎所有知识密集型行业。
