企业为什么不把CRUD直接封成MCP企业为什么不把 CRUD 直接封成 MCP？一个 2 万人企业的 Agent 权限架

企业为什么不把 CRUD 直接封成 MCP？一个 2 万人企业的 Agent 权限架构答案

本体不是 ACL，MCP 不是权限系统，用户有权限也不等于 Agent 可以自动执行。

很多企业已经为 CRM、ERP、HR、财务系统建设了完整的 API、RBAC、数据权限和审计。既然如此，为什么不把这些增删改查接口包装成 MCP Tool，直接交给 Agent？

这个问题听起来像集成问题，实际是授权问题。

企业不是不能复用 CRUD，而是不敢把一套面向人工操作设计的权限，原封不动交给一个会自主规划、循环调用、批量执行和自动重试的概率系统。

对于两万名员工、一人多岗、矩阵组织和多个异构业务系统并存的企业，更稳妥的答案是：

原生业务能力可以复用，MCP 也可以作为连接层；但本体不应成为第二套 ACL，Agent 的有效权限必须是用户权限、Agent 身份、本次任务委托和业务系统最终校验的交集。

企业担心的不是 CRUD，而是自动化倍率

一次人工修改客户记录，通常经历这样的过程：用户主动打开页面，找到具体记录，页面限制可编辑字段，用户填写数据并确认，后端再校验记录权限和业务规则。

表面看，它只是一次 UPDATE。实际上，UI、后端和人的操作节奏共同构成了安全边界。

Agent 的执行链不同：

用户提出目标
→ 模型自行规划
→ 选择工具
→ 生成参数
→ 循环调用
→ 自动重试
→ 批量处理

用户能改一条客户记录，不代表 Agent 可以自动修改一万条。

用户能看员工档案，不代表 Agent 可以批量抽取全体员工信息，再与其他系统的数据关联。

用户拥有订单删除权限，也不代表 Agent 可以在误判、提示词注入或重试异常时连续删除订单。

风险来自几个因素的乘积：

宽泛 CRUD 权限
× 自主规划
× 自动循环
× 批量执行
× 不受限制的重试

同一个权限交给人和交给 Agent，影响半径完全不同。传统权限系统回答的是“这个人能不能做”；Agent 场景还要回答“这个 Agent 能否为了这次任务，在这个时间窗口内，以多大数量、调用多少次、影响哪些资源”。

MCP 解决调用协议，不替企业完成授权

MCP 让 Agent 发现和调用工具。它定义 Client 与 Server 的通信方式、工具描述和调用形式，也规定授权相关协议边界。

但 MCP 不会自动提供：

CRM 的记录级权限；
HR 的字段级权限；
财务系统的职责分离；
采购系统的审批流程；
订单状态机；
跨系统事务；
幂等与补偿；
最终执行结果读回。

工具出现在 tools/list 中，只能证明它可被发现，不能证明当前用户可以操作每一条记录。

OAuth Scope 中有 crm.write，也不能直接推出“Agent 可以修改所有客户、所有字段和所有状态”。客户端弹出一次确认框，同样替代不了后端权限校验。

企业至少要处理三段授权关系：

用户 → Agent/MCP Host
Agent/MCP Host → MCP Server
MCP Server → 目标业务系统

第一段成立，不代表后两段自动成立。

MCP 的安全规范还反对 Token Passthrough。MCP Server 不应把一个并非为自己签发的 Token 当成透明凭证，原样转发给下游系统。更合理的做法是让 MCP Server 成为独立受保护资源，再通过 On-Behalf-Of 或 OAuth 2.0 Token Exchange 获取面向目标业务系统、Audience 正确的新 Token。

这不是协议洁癖。它决定了业务系统能否准确知道：谁在代表谁、哪个客户端发起调用、Token 原本签给谁，以及本次操作基于哪项委托。

组织本体能参与决策，但不能直接产生生产权限

企业本体可以表达这些关系：

张三属于华东销售部
张三担任大客户经理
张三兼任某项目负责人
张三负责华东区域重点客户续约

这些关系对授权有价值，却不能直接推出：

张三可以查看华东全部客户数据
张三可以修改所有续约合同
张三可以批准任意折扣
Agent 可以代表张三批量执行上述操作

原因很简单：职责不是权限。

“负责合同管理”不等于拥有合同审批权；“负责销售预测”可能只需要聚合数据；“协助财务对账”也不等于可以修改付款状态。

自然语言里的“负责”“管理”“协助”“统筹”，都不够精确，不能直接编译成生产环境的 Allow。

本体更适合扮演授权上下文：

岗位与职责
→ 形成属性和权限候选
→ 进入版本化策略
→ 检查数据范围、职责分离和审批
→ 得出当前动作的授权结论

本体提供关系，策略决策点（PDP）计算授权，源业务系统保留最终校验和否决权。

两万人并不难，难的是关系变化和撤权

两万名员工对关系数据库、图数据库、IAM 或策略引擎来说并不是大数字。真正麻烦的是：

一人多岗、兼职和借调；
临时代理和矩阵汇报；
项目团队与跨法人任职；
区域和产品线组织；
外包和合作伙伴；
短期授权与职责分离；
入职、调岗、离职；
多个系统之间的撤权传播。

所以容量评估不能只看员工数。更值得测的是：

Identity、Position、Assignment 数量
动态项目关系和授权策略数量
每秒授权决策量
Agent 并发调用量
组织变更事件量
撤权传播时间
缓存最大陈旧时间
跨系统部分失败数量

Agent 的调用频率也远高于人工点击。人工用户一分钟可能只做几次操作，一个 Agent 却可能在同一个任务里调用数百次工具。原系统的人工并发容量，不能直接拿来当 Agent 场景的容量基线。

一套长期稳定的分工方式

不建议用 Ontology 替代业务系统，也不建议让 MCP Server 自己承担全部权限逻辑。更稳妥的架构是：

HR / MDM
  → 人员、组织、任职事实权威

IdP / IAM / IGA
  → 用户身份、Agent 身份、账号生命周期和基础授权

组织本体
  → OrgUnit、Position、Assignment、项目、职责和数据域关系投影

PDP
  → 结合用户、Agent、委托、动作、资源和风险进行策略决策

MCP Gateway
  → 认证、工具过滤、参数限制、限流和策略执行

Action Layer
  → 具名业务动作、审批、SoD、幂等、预期版本、补偿和读回

CRM / ERP / HR / 财务系统
  → 最终记录权限、字段权限、状态机、事务和业务规则校验

这套架构的关键不是多加几个中间件，而是明确谁拥有哪类事实。

HR/MDM 拥有人员、组织、Position 和任职关系；IAM/IGA 拥有身份生命周期和基础访问；本体是可重建的关系投影，不复制所有源系统 ACL；PDP 输出 Allow、Deny、NeedApproval 或 Indeterminate；MCP 执行工具与策略边界；源业务系统仍拥有最终业务否决权。

Agent 应调用业务动作，而不是数据库遥控器

生产写操作最好暴露为具名动作：

submit_expense_claim
cancel_unshipped_order
assign_case_to_self
request_purchase_approval
approve_discount_within_limit

尽量避免把这些接口直接交给 Agent：

execute_sql
call_api(method, url, body)
update_record(table, id, arbitrary_patch)
delete_record(table, id)

两者的差别不只是名字。

cancel_unshipped_order 可以明确：订单尚未发货、调用者是订单所有者、取消窗口仍有效、请求必须幂等、退款需要读回。

update_record 只知道“改一行数据”，并不知道这次修改在业务上是否成立。

企业 Agent 真正需要管理的产品单位不是 Tool 数量，而是 Action Contract：权限、参数、前置条件、状态机、影响范围、审批、幂等、补偿、读回和审计的组合。

有效权限必须逐层收窄

可以把最终授权写成一个交集：

EffectiveAllow
=
用户在源系统中的权限
∩ Agent 自身权限
∩ 本次任务委托范围
∩ MCP 工具允许范围
∩ 组织与职责策略
∩ 业务动作前置条件
∩ 实时风险策略
∩ 审批与职责分离
∩ 源系统最终 Allow

至少有三个不变量不能被破坏：

本体 Allow 不能覆盖源系统 Deny
Agent 权限不能大于用户权限
本次执行不能超出明确任务委托

如果用户身份过期、Agent 无法识别、委托已失效、组织数据过期、Token Audience 不匹配、PDP 返回未知，或者执行后无法读取最终状态，都应该默认拒绝或进入人工处理，而不是让模型“酌情判断”。

用户身份和 Agent 身份必须同时留下

企业需要同时回答四个问题：

这次操作是为谁执行的？
实际由哪个 Agent 执行？
哪个客户端取得了授权？
基于哪一次任务委托？

推荐保留三个主体：

Subject = 最终用户
Actor   = Agent Identity / Agent Version
Client  = MCP Client / Agent Host

如果只使用用户 Token，业务系统无法区分用户本人操作和 Agent 自动执行；如果使用共享服务账号，又无法还原真正的用户和 Agent。

更稳定的做法是让 Agent 拥有独立身份，用户通过 Delegation Grant 委托有限能力。委托应包含有效期、用途、资源范围、金额、数量和最大使用次数。审计同时记录 Subject、Actor、Client 和 Delegation。

跨系统动作没有免费的 ACID

MCP、企业本体和工作流平台都不会自动让多个系统共享一个数据库事务。

跨系统动作可能停在这种状态：

CRM 更新成功
ERP 调用超时
财务系统尚未执行
通知发送失败

此时不能简单重试整个动作，否则可能重复建单、重复付款或重复审批。

长期方案需要幂等键、Expected Version、Outbox/Inbox、Saga、补偿动作、执行状态机、对账任务和人工异常队列。

外部调用结果不确定时，应进入：

UNKNOWN → RECONCILE_ONLY

先查询现实状态，再决定补偿或继续，而不是直接重新执行。

落地时先旁路，再逐步开放写操作

一开始就让本体接管全公司权限，风险很高，也没有必要。

建议按下面的顺序推进。

1. Shadow 决策

本体和 PDP 旁路计算，不改变真实权限。重点比较本体/PDP 结论与源系统真实决定，找出本体允许但源系统拒绝、离职未撤权、调岗后旧权限残留、项目角色未同步以及无法解释的决策。

2. 低风险只读

只开放用户本来就能访问、且源系统会再次校验权限的数据。限制查询范围、字段和批量大小。

3. 低风险单系统写操作

只开放少量具名动作，要求参数白名单、影响范围限制、幂等、Expected Version、执行后读回和 Kill Switch。

4. 高风险写操作

增加人工审批、职责分离、双人复核、金额和数量限制、短期委托、独立 Agent Identity 和异常冻结。

5. 跨系统动作

最后处理 CRM、ERP、HR 和财务系统之间的 Saga、补偿与对账。

什么时候只做一层薄 MCP 就够了

企业本体并不是每个系统的前置条件。

如果某个业务系统已经提供：

完整的记录和字段权限；
受控 Custom API；
审批与业务状态机；
事务和幂等；
完整审计；

最合理的做法可能就是把这些业务命令薄封装成 MCP，再补上 Agent 身份、任务委托、限流和执行读回。没必要为了“统一”复制一套 ACL。

Ontology 更适合处理跨系统组织和项目关系、统一数据域分类、动作目录、策略上下文和跨系统审计关联。它应理解权限所需的关系，不应拥有所有业务系统权限。

结论

企业 Agent 权限建设最容易走向两个极端。

一个极端是：业务系统已经有权限，把 API 封成 MCP 就够了。

另一个极端是：企业已经建设本体，应把全部权限迁入本体统一管理。

两条路都不稳。

长期更可行的分工是：

本体描述组织和关系
PDP 计算 Agent 本次任务权限
MCP 执行工具和协议边界
Action Layer 管理业务副作用
源业务系统保留最终否决权

本体不成为第二套 ACL，Agent 权限始终逐层衰减，源业务系统永远保留最终 Deny。只要这三个条件成立，两万人的规模不是根本障碍。

如果它们被破坏，即使企业只有两千人，权限架构也会很快失控。

参考资料

发布摘要

企业为什么不直接把 CRM、ERP、HR 的 CRUD 接口封装成 MCP，交给 Agent 使用？问题不在 CRUD，而在 Agent 会自主规划、循环调用、批量执行和自动重试。本文分析企业本体、MCP、IAM、PDP、Action Layer 与源业务系统之间的权限边界，并给出一套避免第二套 ACL、支持独立 Agent 身份和任务委托的落地架构。

企业为什么不把CRUD直接封成MCP