MCP + 企业IM架构：AI Agent调用OA、ERP、MES时，身份和权限如何传递？

tongxunjishubiji

597人浏览 · 2026-08-31 17:20:08

tongxunjishubiji · 2026-08-31 17:20:08 发布

MCP + 企业IM架构：AI Agent调用OA、ERP、MES时，身份和权限如何传递？

过去，企业即时通讯系统与业务系统的关系比较简单。

OA审批完成，发一条消息；MES发现生产异常，通知设备负责人；ERP库存变化，把提醒推送给相关人员。企业IM承担的主要职责，是把业务系统中的事件及时送到员工面前。

AI Agent进入企业以后，这条链路开始反过来。

员工可能直接在企业IM中输入：

帮我查一下3号产线昨天为什么停机，把相关维修记录和处理流程一起整理出来。

看起来只是一句话，背后可能需要访问MES、设备管理系统、企业知识库和OA流程。如果员工进一步要求“创建维修工单”，Agent还会从查询数据进入业务执行。

从工程上看，难点很快就从“能不能调用”转向“以什么身份调用”。

Agent代表谁执行？员工在IM里的身份如何传到后端系统？同一个Tool，不同部门的人能看到哪些数据？查询和修改是否应该共用一套授权策略？这些问题如果没有提前拆开，后面很容易用一个高权限后台账号兜底，最后把原有权限体系绕过去。

Model Context Protocol（MCP）为AI应用连接外部工具和数据提供了标准化接口，但它只解决调用链中的一部分。企业还要把IM身份、Agent执行上下文、MCP授权和OA、ERP、MES自己的业务权限串起来。

本文就从这条调用链展开。

一、企业IM正在从“消息入口”变成“任务入口”

传统的企业IM集成，通常是“系统找人”。OA、ERP、MES产生事件后，通过消息接口把通知推到IM，员工再进入原系统查看和处理。

Agent模式开始出现另一条链路：员工先在IM里提出任务，Agent根据意图选择MES、ERP、OA或知识库等工具，再把结果带回会话。员工不一定需要先判断“这个问题应该去哪套系统里查”。

这使企业IM多了一个潜在角色：除了接收业务消息，也可以成为人和Agent之间的任务入口。

但IM没必要把模型、工具和业务逻辑全部塞进自己的服务端。比较清晰的拆法，是让IM继续负责身份、会话和交互，把任务编排、模型调用和Tool治理放到独立的Agent层。

二、MCP解决什么，又不解决什么？

MCP可以理解为AI应用连接外部工具和数据的一套开放协议。

在MCP的服务器侧能力中，常见的三个概念是：

能力	作用	企业场景示例
Tools	暴露可调用操作	查询MES异常、创建工单
Resources	提供可读取资源	设备资料、制度文档
Prompts	提供可复用提示模板	故障分析模板、审批摘要模板

其中，Tools尤其适合Agent执行外部操作。

传统方式下，Agent往往需要分别适配MES、ERP、OA、CRM和知识库的接口。MCP把这些能力包装成Tool、Resource等统一对象后，Agent侧的发现、描述和调用方式会更一致，重复适配也会少一些。

但这不等于企业可以把原有治理层拿掉。

MCP解决“Agent如何连接和调用外部能力”，IAM、API网关、业务权限和审计仍然负责“谁能调用、能访问什么、调用后怎么追踪”。

这两个层次最好从设计阶段就分开。

2.1 MCP、API网关和消息总线不是同一层

企业在评估MCP时，经常会遇到两个问题：

已经有API网关了，还需要MCP吗？

以及：

有Kafka、RocketMQ这样的消息总线了，MCP是不是重复建设？

三者解决的问题并不相同。

对比维度	MCP	API网关	消息/事件总线
主要服务对象	AI应用、Agent	应用、微服务、开放接口	系统之间的事件流
核心问题	Agent如何发现和调用能力	API鉴权、路由、限流、治理	异步事件传递
典型触发方式	Agent主动调用	程序主动请求	事件触发
是否负责业务权限	不应单独承担	可承担部分接口权限	通常不负责用户级数据权限
企业常见场景	Agent查MES、调用OA工具	管理ERP/MES业务API	生产异常、订单变化事件

在已有API体系的企业里，没有必要为了MCP绕开原来的服务治理。一个常见组合是 AI Agent → MCP Client → MCP Server → API Gateway → 业务服务：MCP负责Agent侧的工具语义和调用协议，API网关继续承担鉴权、路由、限流和已有服务治理。

消息总线也不用被MCP替代。MES发现生产异常后，经Kafka、RocketMQ或企业事件总线触发后续处理，仍然是典型的事件驱动链路；MCP更适合Agent主动查询或执行外部能力。两者可以并存。

三、企业IM + Agent + MCP，完整架构应该怎么拆？

如果企业希望员工在IM中直接使用AI Agent，一个相对清晰的架构可以分成四层。

这里最好不要把“企业IM”和“MCP Host”简单画等号。

企业IM主要解决：

当前是谁
 ↓
说了什么
 ↓
结果返回给谁

Agent层解决：

用户要完成什么任务
 ↓
应该调用什么能力
 ↓
需要执行几步

MCP解决：

外部系统提供什么工具或资源
 ↓
Agent如何标准化访问

OA、ERP、MES继续负责真正的业务规则和业务数据。

边界拆开以后，权限和审计也更容易落地。

四、从一句“查停机原因”看完整调用链

假设生产主管在企业IM里输入：

查一下3号产线昨天14:00到16:00的停机原因。

背后可能经过下面的链路：

从Agent视角看，其中一个Tool可以抽象成：

{
  "name": "query_mes_downtime",
  "description": "查询指定产线在给定时间范围内的停机记录",
  "inputSchema": {
    "type": "object",
    "properties": {
      "lineId": {
        "type": "string",
        "description": "产线编号"
      },
      "startTime": {
        "type": "string",
        "format": "date-time"
      },
      "endTime": {
        "type": "string",
        "format": "date-time"
      }
    },
    "required": [
      "lineId",
      "startTime",
      "endTime"
    ]
  }
}

这个Schema解决的是：

Agent应该以什么参数调用工具。

它没有解决：

当前用户有没有权限查看3号产线。

也就是说，Tool Schema解决“怎么调用”，IAM、Policy和业务权限解决“谁能调用、能看什么”。这两个问题必须分开。

五、Agent到底代表谁？这是权限链里最容易出问题的一层

普通API调用通常比较确定：

某个应用使用某个身份访问某个服务。

Agent的调用链更复杂，因为它可能处在“代用户执行”的状态。

例如，生产主管可能有权查看整个车间，设备工程师只能查看负责设备，普通行政人员则不应该访问MES生产数据。

如果所有Agent最终都用同一个高权限Service Account访问MES，员工原来的数据边界就可能失效。用户自己查不到的数据，反而可能通过一句自然语言间接拿到。

因此，企业Agent至少要考虑五层身份和权限：

身份层	核心问题
IM用户身份	当前发起请求的人是谁
Agent执行身份	Agent代表谁执行
MCP访问身份	Client以什么授权访问Server
业务系统身份	MES/ERP最终认谁
数据权限	用户到底可以读写哪些具体数据

这五层最好能在一次调用中保持可追踪的映射关系。任何一层把“用户身份”替换成一个过大的后台身份，都可能造成权限扩大。

两个边界尤其值得单独检查：

IM登录成功 ≠ Agent可以调用所有工具

Agent可以调用某个工具 ≠ 用户可以访问工具返回的所有数据

很多Demo阶段跑得很顺的方案，到了生产环境，问题往往就出在这里。

六、Tool权限不能只有“允许”和“禁止”

即使一个员工有权使用某个MCP Tool，也不代表所有操作都应该自动执行。查询库存和修改库存、查看审批单和直接通过审批，风险等级显然不同。

企业可以把Tool治理拆成四层：

权限层级	需要解决的问题	示例
Tool可见性	用户是否应该知道该工具存在	财务工具不向无关部门暴露
Tool调用权限	用户是否可以执行	是否允许创建维修工单
数据范围权限	可以访问哪些数据	仅查询负责车间
高风险确认	是否需要人工确认	付款、删除、审批、状态变更

因此，生产环境里的Tool调用不宜变成“模型选中工具后直接执行”。在执行前，至少要检查Tool权限、参数和数据范围；涉及付款、删除、审批、状态变更等高风险动作时，再进入人工确认或额外审批。执行完成后，还要对结果做过滤并留下调用记录。

MCP规范本身也强调Tool调用涉及信任和安全边界，客户端不能把来自不可信Server的工具描述或Annotations直接视为可信事实；敏感操作应有相应授权和用户控制机制。[1]

七、多个MCP Server怎么管？企业可能需要一层Agent/MCP Gateway

当企业只有几个MCP Server时，Agent直接连接问题不大。

但如果后续变成：

几十个Agent
 ×
几十个MCP Server

治理复杂度会迅速增加。

这时可以考虑在中间增加一层Agent/MCP Gateway。

需要强调：

Agent/MCP Gateway不是MCP规范要求企业必须部署的标准组件，而是一种工程治理方式。

它可以统一处理：

MCP Server注册与准入；
Tool目录和命名冲突；
用户身份与Agent身份映射；
Tool白名单；
数据范围策略；
高风险操作审批；
调用日志与Trace；
限流和异常检测。

Server变多只是表象。治理难度来自“哪个Agent可以代表哪个用户，在什么条件下调用哪个Tool”，以及这些调用能不能统一审计。

八、2026年的MCP为什么更值得企业架构师关注？

截至2026年8月，MCP已经不只是早期“本地AI连接工具”的形态。

2026-07-28版本做了几项对生产环境影响较大的调整：[2]

变化	对企业部署的意义
Stateless Core	更容易放到普通HTTP基础设施后横向扩展
Header-based Routing	网关、WAF、限流系统更容易按方法和工具做路由与治理
Cacheable Lists	Tool、Resource等目录可减少重复拉取
Tasks Extension	为长时间运行任务提供正式扩展机制
Authorization Hardening	持续补强OAuth相关授权安全
Extensions Framework	企业能力可以通过扩展演进

2026年6月，Enterprise-Managed Authorization（EMA）扩展进入稳定状态，目标是让组织通过企业身份提供方集中管理MCP Server访问，减少用户逐个Server授权的摩擦。[3]

8月22日更新的MCP路线图又把“Agent identity and enterprise-ready security”列为优先方向，开始更直接地处理Agent自身身份、委托和企业级安全问题。[4]

这些属于协议层已经发生的变化。基于这些变化可以做一个架构判断：MCP正在更接近生产级Agent基础设施需要的形态，但它仍然不能替代企业自己的IAM、业务权限和风险控制。

九、MCP进入企业后，安全边界为什么反而更长？

协议标准化并不会让风险消失。

企业至少要关注两类问题。

1. 传统软件和接口安全

包括：

MCP Server代码是否可信；
依赖和版本是否可控；
Token如何保存；
Server是否拥有过高下游权限；
是否存在无边界的网络访问；
输入参数是否校验；
Tool输出是否过滤。

2. Agent上下文安全

Tool返回的数据会进入Agent上下文，并可能影响后续判断。如果返回内容包含恶意指令、异常数据或不可信文本，风险就不只是“一次回答错了”，还可能影响Agent下一步选择什么Tool、带什么参数继续执行。

MCP文档也提醒，来自不可信Server的Tool Annotations不能当成强制安全保证。[1] 生产环境仍然需要访问控制、网络策略、沙箱、授权、审计以及必要的人工确认。协议标准化以后，安全边界并没有缩短，反而多了一层Agent上下文。

十、企业现在要不要把所有系统都MCP化？

没有必要。

落地时可以先从“只读、低风险、高频”的场景开始。

系统能力	是否适合优先MCP化	原因
企业知识库查询	较适合	高频、只读、风险相对可控
OA流程查询	较适合	员工使用频率高
MES状态查询	可以优先评估	适合异常分析和生产问答
ERP业务查询	可以评估	需要严格的数据范围控制
创建普通工单	第二阶段考虑	已经涉及业务状态变化
审批执行	谨慎	需要身份、授权与确认
财务付款	高度谨慎	高风险资金操作
删除生产数据	不宜直接开放	破坏性过高

推进顺序可以很朴素：先做只读查询，再开放低风险业务操作；涉及状态变更时加入人工确认，最后才考虑有限范围的自动执行。

不要把“API已经存在”理解成“可以立即全部暴露给Agent”。API可调用，只说明技术接口存在；能不能成为Agent Tool，还要重新评估身份、数据范围、风险和审计。

十一、企业IM在Agent架构里适合放在哪一层？

员工每天已经在企业IM中处理沟通、文件、通知和业务消息。

如果Agent进一步进入工作流，企业未必需要让所有员工再适应一个完全独立的AI入口。

如果企业把现有IM作为交互入口，调用链大致会变成：员工在IM发起任务，Agent接收组织身份和会话上下文，再通过Tool或MCP访问OA、ERP、MES和知识库。

对于小天互连这类企业级私有化IM而言，如果未来进一步承接Agent交互，价值也不会只是“多一个AI聊天窗口”。

企业会继续追问：

现有组织身份能否传递到Agent调用链；
权限变化能否及时同步；
OA、ERP、MES等系统是否具备可治理的开放能力；
AI调用是否能够被记录和审计；
私有通信环境与Agent基础设施能否保持一致的数据边界。

因此，评价企业级私有化IM时，除了消息、群聊、文件和音视频，也会逐步增加组织身份、业务连接、Agent交互、权限治理和调用审计这些维度。

这里并不能简单推导为“小天互连已经支持MCP”。MCP属于Agent连接层的技术协议，企业IM属于通信与组织入口，二者是否组合、如何组合，仍取决于实际产品开放能力和企业自身的Agent架构。

11.1 从企业IM到Agent基础设施，变化的不是一个协议

传统企业IM主要解决人与人之间的消息传递，数字化阶段又把业务系统通知接了进来。进入Agent阶段后，链路继续向后延伸：员工在IM里发起任务，Agent理解意图，通过MCP或其他Tool协议访问业务系统，再把查询结果或执行状态带回来。

MCP解决了其中一个重要问题：Agent如何以更统一的方式发现和调用外部能力。

但如果企业只是给IM增加一个大模型聊天窗口，架构其实没有发生太大变化。Agent真正开始执行任务以后，麻烦才出现：员工身份要传到Agent，Agent权限要传到MCP，MCP最终还要受ERP、MES自己的数据权限约束。任何一层直接用高权限账号兜底，都可能把原来的权限体系绕过去。

所以企业IM能不能继续充当统一入口，看的不是“有没有AI”，而是这条身份和权限链能不能闭环，调用过程能不能被审计。

常见问题

MCP是什么？

MCP（Model Context Protocol）是一套用于AI应用连接外部工具和数据的开放协议。服务器可以向客户端暴露Tools、Resources、Prompts等能力，使Agent能够以较统一的方式访问外部系统。

企业已经有API，为什么还需要MCP？

API继续负责实际业务能力。MCP解决的是Agent如何发现、描述和调用这些能力，两者不是替代关系。

MCP可以连接ERP、MES吗？

可以通过MCP Server把现有业务API或能力封装成Agent可调用的Tool。但真正进入生产环境前，还需要解决身份认证、数据范围、权限和审计问题。

MCP能保证Agent不会越权吗？

不能。协议提供授权和安全机制，但用户到底能访问哪些业务数据，仍需要结合企业IAM、业务权限和策略系统控制。

为什么企业IM适合成为Agent入口？

企业IM天然连接员工身份、组织关系和日常工作场景。如果进一步接入Agent与业务系统，员工可以在已有沟通入口中完成查询和部分任务操作。

小天互连和MCP是什么关系？

两者处在不同层级。小天互连这类企业级私有化IM主要解决企业内部通信、组织与业务连接；MCP解决AI应用连接工具和数据的标准化问题。是否将二者结合，需要依据实际产品开放能力和企业Agent架构评估，不能直接等同为“支持MCP”。

参考资料

Model Context Protocol Specification：Tools / Security Considerations
https://modelcontextprotocol.io/specification/
Model Context Protocol Blog, The 2026-07-28 Specification
https://blog.modelcontextprotocol.io/posts/2026-07-28/
Model Context Protocol Blog, Enterprise-Managed Authorization: Zero-touch OAuth for MCP
https://blog.modelcontextprotocol.io/posts/enterprise-managed-auth/
Model Context Protocol Blog, The New MCP Roadmap, 2026-08-22
https://blog.modelcontextprotocol.io/posts/mcp-roadmap/