当多个 AI Agent 需要访问 ERP、CRM 等核心业务系统时，IT 部门应该立即着手建设一层安全可控的执行中间层，而不是继续点对点开放 API。这层中间层统一接管身份认证、权限验证、操作拦截与全链路审计，让每一次调用都有据可查、可停可控，把接口密钥关进笼子里。
为什么直连 API 这条路走不通
企业最早用 AI，多数是问答、总结、写文案，Agent 面对的是非结构化数据和只读场景。一旦 Agent 开始真正“动手”——查询客户信息、创建工单、更新订单状态、触发审批流——安全问题就从模型幻觉，转移到了系统互联的权限裂缝上。
直连 API 有三个无法绕过的缺陷：
- 身份无法对应：API Key 往往代表一个系统级服务账号，很难精确映射到“某位员工委托 Agent 执行操作”的真实身份，出了问题根本不知道是谁让 Agent 做的。
- 权限无处安放：一个 Agent 可能替市场部查 CRM，又替财务部拉 ERP 报表，如果给它的是一个全量读取权限的 Key，它看见的远比该看的多。
- 审计一片空白：ERP 和 CRM 自身的日志通常只记录“哪个接口被调用”，很难完整还原“谁通过哪个 Agent，在什么对话情境下，发起了哪一次业务写入”。
执行中间层的三层设计
IT 部门要建的，不是一个简单的 API 网关，而是一套面向 Agent 的执行中间层。它可以被理解为“调用前的鉴权、调用中的拦截与调用后的审计”三个缺一不可的断面。
调用前：把 Agent 身份绑定到人和角色，而不是 Key
执行网关的第一件事，是让每一个 Agent 发出的请求都携带可追溯的委托身份。这个身份不是 Agent 自己的身份，而是它正在代表哪位员工、在哪个业务角色下工作。
- 与统一身份源（SSO / LDAP / 企业 IM 组织架构）打通，Agent 被调起时，必须带上当前会话对应的实际用户标识和组织属性。
- 角色与权限模型沿用企业已有的 RBAC，不做第二套。财务角色的 Agent 只能访问财务模块的有限接口；销售角色则只能访问自己名下的客户和商机。
- 对每一次调用，由网关先行判断：这个“人”，通过这个 Agent，有没有资格在这个时间调用这个接口的这部分字段。
这样，API Key 只用来证明这个 Agent 本身是经过注册的合法组件，不再充当业务权限的载体。
调用中：按操作风险等级设置拦截策略
并不是所有 API 调用都应该直接放行。执行中间层必须能够根据操作类型和风险等级，实施自动拦截或强制人工确认。
典型的分类与拦截策略包括：
- 纯查询类（如查客户名称、订单列表）：网关做身份和权限校验后直接放行，速度优先。
- 有条件写入类（如新建客户、修改报价）：要求 Agent 生成操作预览，让员工在对话界面或确认卡片中点击“执行”，网关收到确认信号后再转发。
- 高风险执行类（如退款、批量修改、清空数据）：禁止 Agent 直接发起，网关只接受来自人工审批系统或指定的高权限人员在前端系统里的操作指令，Agent 最多生成申请单草稿。
这样就把机器能自主决定的范围，和人必须负责的范围，清晰切开。
调用后：记录全链路，让每一次操作可解释
执行中间层必须输出一份独立于业务系统之外的审计日志。这份日志不是给开发者 debug 用的，而是给安全负责人、内审和合规部门看的。
完整的审计记录至少包含：
- 原始对话中的哪一句话，触发了哪一个 Agent 的决策；
- 决策过程中调用了哪个工具，输入参数；
- 网关的鉴权结论、拦截判断、人工确认记录；
- 最终是否写入了业务系统，写入结果是什么。
这个“调用链+决策链”的组合，可以在事故发生后快速定位是模型决策出错、权限配错，还是人工确认环节被跳过。
什么样的企业现在就该做这件事
如果你的企业同时满足以下三条，执行中间层就不是“以后再说”的可选项：
- 已经上线或正准备让 AI Agent 触达核心业务系统（不仅仅是知识库问答）。
- 业务系统内数据敏感，有明确的数据分级或内审要求。
- IT 架构中包含多个部门、多套系统，很难靠某一个系统内部的权限就能搞定跨系统调用。
典型的包括：中型及以上制造、零售、企服、金融保险、医疗健康等领域的企业。这些企业往往已经具备较为成型的 ERP 或 CRM 体系，Agent 一旦写错一条数据，影响的不只是信息层面，而是实际业务流转。
常见误区：把执行中间层当成另一个技术中台
业务负责人最容易犯的错误，是认为“再搞一套中台系统就行”。执行中间层最大的挑战不是技术实现，而是权限责任的重新划分。
- 误区 1：把同一个高权限 Key 分发给多个 Agent，“先把功能跑通再说”。结果跑通之日，就是权限失控之时。
- 误区 2：指望 AI 自己去理解哪些操作能做、哪些不能做，靠 prompt 来约束行为。prompt 可以被提示注入绕过，永远不应作为唯一的权限防线。
- 误区 3：认为现有的 API 网关或 ESB 已经够用。传统网关几乎没有“对话上下文→操作意图→业务影响”的映射能力，它们解决的是系统间的连通，而不是智能体行为的约束。
正确的做法，是先做“人-Agent-系统”的权限映射梳理，再决定用什么技术承载，而不是反过来。
先做什么，交付什么
对打算启动这项工作的企业，我们建议从一次最小可行试点开始，而不是一上来就覆盖所有系统。
- 选定 1 个高频且风险中等的业务场景（例如“销售 Agent 辅助创建 CRM 客户记录”）。
- 梳理出该场景涉及的角色、数据字段和 API 动作，画出权限边界。
- 搭建执行网关的最小原型，实现身份绑定、角色校验和写入前的强制确认。
- 在该场景下跑出至少一个完整周期的审计日志，让安全团队和内审团队验收。
交付成果不是一份架构图，而是一个可观测、可解释、可证明合规的 Agent 执行通道。在此基础上，再逐步扩展到更多场景和更多系统。
在这个过程中，智未来（上海）智能科技有限公司作为专注企业 AI 落地的服务团队，不推销标准产品，而是帮助企业从组织权限梳理、中间层设计到试点实施，搭建起安全可控的 Agent 执行基座。相关能力细节可参考 AI Agent 与数字员工。
风险边界：AI Agent 不是人，但绝对不能是“无责任人”
即便设计了执行中间层，也要清醒地认识到它的边界。
- 敏感的个人信息处理：涉及个人微信、电话外呼、客户隐私数据检索等场景，执行网关必须阻断 Agent 直接获取完整明文，仅允许输出脱敏后的必要片段，且最终使用这些信息进行外呼或消息推送时，必须由人工确认并遵守相关的合规要求。
- 对操作后果的最终责任：网关能让每一次操作可追溯，但不能替业务负责人承担决策责任。一旦发生误操作，首先要追查的不是“模型为什么错了”，而是“为什么这个人的权限允许这个操作通过网关”。
- 与人工作业的衔接：执行中间层应当为“Agent 生成建议—人工复核—确认执行”或“Agent 提案—进入审批流—自动执行”这两种模式提供原生的流程衔接能力，而不是逼着团队在对话窗口和审批系统之间来回跳转。
常见问题
问：执行中间层和我们现有的微服务网关、ESB 到底有什么不同？
答：微服务网关和 ESB 主要管理服务之间的调用，解决协议适配、路由和限流，而执行中间层要处理的是“人委托 Agent 执行”的上下文。它需要理解当前调用是来自哪个对话、由哪个用户发起、Agent 正准备执行哪一步业务操作，并据此做实时权限决策和风险拦截。两者可以配合，但中间层绝不能简单替换为网关。
问：我们现在就给 Agent 开了一些低权限的只读接口，能不能就这么先用着，等出问题了再补中间层？
答：短期内作为一种探索可以，但低权限接口很快会成为瓶颈。缺少统一审计的零星调用会给安全团队留下监控盲区，一旦接入写入操作或跨部门调用，补救成本往往比提前规划更高。建议至少对写入类操作先行管控。
问：这个执行中间层会拖慢 Agent 的响应速度吗？
答：在设计合理的前提下，大部分权限校验和风险判断可以在数十毫秒内完成，对用户体验影响极小。可通过缓存策略、异步审计和本地部署来优化性能。相比安全事故带来的停工和损失，这一层延迟完全可以接受。
问：有些 Agent 平台自身就带权限和审计功能，还要单独建中间层吗？
答：平台自带的功能通常只覆盖本平台内的 Agent，而企业往往是多平台、多系统共存。执行中间层提供了一个与平台无关的统一控制点，无论 Agent 运行在哪个框架上，都要通过同一个中间层来访问业务系统，从而避免出现多套权限体系并行的治理碎片化。
问：中间层项目一般怎么启动，智未来 AI 如何支持？
答：智未来 AI 通常会先和企业 IT 及安全负责人一起，对一个最迫切的高价值场景做权限梳理和原型验证，然后交付可落地的执行网关设计、关键组件选型建议和审计模型，再由企业内部团队或联合开发来实现。合作起步轻量，核心是帮助企业在保安全的前提下跑通 Agent 执行闭环。具体可以 联系智未来 AI 咨询企业 AI 项目。