企业 Agent 接入 MCP，先解决什么？从工具契约到权限边界

很多团队说“把系统接给 Agent”，讨论很快就进入接口和协议。真正容易拖慢项目的，往往是接口背后的业务问题：这个动作代表谁发起？Agent 能看到哪些记录？接口超时后能不能安全重试？发生误操作时由哪个系统负责拦截？协议可以统一调用方式，却不会自动回答这些问题。

把业务动作收窄成工具契约

MCP 的工具适合表达可调用的业务能力，但工具名称只是入口，真正的契约还包括输入字段、允许范围、返回结构、错误语义和副作用。与其提供一个权限宽泛的“执行 SQL”或“调用任意接口”，不如按业务意图暴露受约束的动作，例如查询某类工单、核对客户资料或创建待审核草稿。工具越接近清晰的业务动作，权限审查、测试和审计越容易落到实处。

读操作与写操作也不宜混在同一个模糊接口里。查询工单和关闭工单的风险完全不同，参数校验、授权范围、确认方式和日志要求也应分别设计。对创建、发送、审批等有副作用的动作，可以先让 Agent 生成预览或草稿，再由具备相应权限的用户确认；底层系统仍需执行最终的规则校验。

调用链要保留真实用户身份

“Agent 服务账号能调用接口”不等于“当前用户有权查看这条数据”。如果所有请求最终都使用同一个高权限账号，Agent 就可能越过原有系统按用户、部门、租户或记录配置的访问规则。接入前应确定身份如何从登录入口传到工具服务、哪些操作使用用户委托授权、哪些后台任务使用专用服务身份，以及审计日志如何记录实际发起人。

认证通过也不代表动作可以放行。MCP 服务侧需要验证令牌面向的资源、有效期和范围；业务系统还要按自己的规则检查对象级权限、数据归属和状态转换。授权可以按整台服务器设置，也可以对敏感工具单独要求更严格的授权，具体做法要与企业身份体系和协议版本相匹配。官方规范对 OAuth 资源服务器授权流程和安全边界有更具体的定义，可参考 MCP Authorization 规范 与 Security Best Practices。

超时之后，先查状态再决定是否重试

Agent 调用业务接口时，网络超时只说明客户端没有及时拿到结果，不一定意味着服务端没有执行。对新增工单、发送通知或更新记录这类写操作，直接重试可能造成重复副作用。接口应支持幂等键或业务请求编号，并提供按编号查询最终状态的办法；Agent 流程则要区分“明确失败”“处理中”和“结果未知”，不能把三种情况都当作可以再试一次。

返回给模型的内容也要控制范围。工具输出应只带完成当前任务所需的字段，错误消息避免暴露令牌、内部堆栈或不必要的个人数据。排障所需的调用记录可以包含工具版本、请求编号、授权结果和执行状态，不必把所有敏感原文都复制进 Agent 日志。

治理的对象不止是一条连接

当 MCP 服务和工具逐渐增加，团队还要知道每个工具的业务负责人、数据范围、使用人群、版本以及下线计划。工具描述和参数变更都可能影响模型选择与调用方式，因此应经过兼容性验证，并在发布记录中关联到使用它的 Agent 和测试样本。对没有负责人、权限过宽或长期无人使用的工具，继续暴露只会扩大维护和安全面。

比较稳妥的接入顺序，是先选一个边界清楚的只读任务，验证身份透传、权限过滤、工具输出和异常处理；之后再进入低风险写操作，补上确认、幂等和状态查询；最后根据测试和运营记录扩大使用范围。每一步都可以沿用既有业务系统作为规则与数据的最终责任方。

宜天信达在企业 Agent 接入项目中，可结合现有身份、业务接口和审批体系梳理工具目录与授权边界。项目启动时，先拿一个具体的业务动作验证调用链，比一次性开放大量接口更容易发现权限和异常处理中的真实问题。