面向企业系统的MCP服务器：构建、安全与治理

本指南面向中型企业的工程负责人、架构师及IT治理负责人，帮助他们让AI Agent或助手调用现有ERP、CRM或财务系统——前提是Agent架构本身已确定（智能体AI架构指南涵盖检查点设置；本页介绍其底层连接层）。该层通过智能体AI自动化服务交付。若第二个专用Agent也需调用此Agent，我们的A2A与MCP指南将决定该切换是否还需要A2A协议。

本指南内容

• MCP服务器应从企业系统中开放哪些内容？
• 三层开放矩阵
• 服务器安全：身份、范围与网关
• 规模化治理：注册表、审查与撤销
• 搭建MCP服务器的步骤计划
• AI在构建MCP服务器中的作用
• 现有交付记录与尚未完成的内容
• 替代方案：谁来构建和运营MCP层
• 本指南的局限性
• 常见问题
• 下一步

MCP服务器应从企业系统中开放哪些内容？

仅开放Agent任务所需的最小具名操作集，而非对ERP、CRM或财务API的通用透传。get_invoice_status或list_open_orders这样的工具是经过刻意设计、类型明确、可审计的函数；而转发任意SQL或无限定REST调用的工具不是MCP工具，而是加了额外步骤的完整API，继承了其背后系统的全部风险。

三层开放矩阵

在构建任何工具之前，将每个候选的ERP、CRM或财务操作归入以下三层之一。决定审批规则的是层级本身，而非其所涉及的系统。

大多数初始MCP服务器的写入层范围过大：一个同时接受折扣百分比的create_order工具，将Agent的权限扩展至无人审核过的范围。工具字段的命名应尽量贴近任务需求，而非API所允许的最宽范围。

服务器安全：身份、范围与网关

模型上下文协议（MCP）的授权规范将MCP服务器定位为OAuth 2.1资源服务器角色：它接受Bearer令牌，验证每个令牌是否专门为其签发，并拒绝范围为其他服务器的令牌——这是OAuth 2.0资源指示器（RFC 8707）所定义的受众绑定要求。由此产生三项选择。

• 通过公司自有身份提供商进行认证，而非使用静态共享API密钥，以便令牌绑定到调用Agent的自身身份，日后的审计或撤销才有据可查。
• 将每个令牌的范围限定为其所需的最小工具集。能调用服务器上所有工具的令牌使上述三层矩阵形同虚设；应按工具或工具组授予范围，遵循规范自身的最小权限指导。
• 在多个MCP服务器前部署网关。一旦存在第二个服务器，用于认证、限流和日志记录的单一执行点比各自独立保障每个服务器更易于安全管理和审计。

Netbase按照其构建任何系统的方式保障这一层的安全：传输中使用TLS、基于角色的访问控制、可审批写入工具的任何仪表板均启用MFA，以及其在自有交付中已应用的ISO 27001和SOC 2 Type II框架及符合GDPR、HIPAA对齐和CCPA的实践。

规模化治理：注册表、审查与撤销

治理应在第二个工具上线之前启动，而非等到第十个。维护一个包含每个MCP服务器、其开放的每个工具以及连接到它的每个Agent或调用方的注册表：没有这份目录，就没有可供审查的内容，而一个无人记得存在的连接也是一个无人会撤销的连接。一个已发布的MCP治理框架将该注册表（结合最小权限范围和自动化凭证轮换）视为企业级MCP治理的核心。

以下三项实践可保持注册表的有效性：

1. 记录每次调用的日志，包括调用方身份、工具名称、参数，以及该调用是自动审批还是已上报，从而使有争议的写入操作可追溯至触发它的具体调用。
2. 定期审查连接，方式与对任何其他系统账户进行访问审查相同，并撤销无法合理说明的连接。
3. 保持有效的终止开关。撤销令牌或禁用工具应只需一个操作，而非一次部署。

现有交付记录与尚未完成的内容

Netbase已构建MCP服务器所处的系统类型，并交付了针对其中已定义操作的AI项目，但尚未在一个项目中同时完成两者：

• 面向美国客户的多租户云ERP（未命名）。自2020年起，作为离岸开发和管理合作方，以SaaS形式交付云ERP；第1阶段涵盖CRM、知识库、工作与项目管理及API集成——MCP工具目录将从中提取首批只读工具。
• ERP与CRM咨询（未命名）。Odoo咨询与定制、将目录、库存、订单和客户数据通过API同步的电商到ERP集成，以及Vtiger到ERP的升级；每项均是MCP工具所封装的那种有界、明确操作，而非原始数据库连接。
• 带CRM同步的WhatsApp AI聊天机器人（未命名）。一个Agent在已定义的操作集上读取和写入CRM数据，在MCP成为其调用规范之前交付。
• 此外已交付的AI项目，匿名：检索增强型知识助手、文档AI及MLOps流水线，客户未在此列名。

尚未存在的内容。目前没有已发布的Netbase记录描述已交付的MCP服务器、已发布的工具注册表，或Agent通过MCP调用客户ERP、CRM或财务系统的案例。上述矩阵和步骤计划来源于Netbase的ERP/CRM集成与面向Agent的交付实践及所引用的来源，而非某个有实测数据的MCP项目；不作任何关于持续时间、成本、准确率或采用率的声明。

替代方案：谁来构建和运营MCP层

何时暂缓构建。单个内部脚本、仅有一个调用方且无第二个Agent计划时，几乎不需要协议、注册表或网关；对于单调用方集成而言，这些额外开销带来的互操作性并无用武之地。待第二个Agent、助手或合作伙伴需要相同工具接口时，再向MCP方向构建。

在Netbase定制开发中，客户拥有为其创建的知识产权，大多数项目在发现阶段后以固定总价合同运行。底层API工作位于系统与API集成和ERP与CRM开发，面向Agent的层位于AI集成，通过智能体AI自动化和企业AI Agent平台交付，适用于专业服务等ERP、CRM和财务数据涉及相同审批问题的行业。

本指南的局限性

• MCP规范较新，版本迭代频繁；在针对其构建授权流程之前，请先核查最新版本。
• 三层矩阵和步骤计划是初步设计，不保证任何特定工具对您的系统是安全的。
• 不作任何关于持续时间、成本、准确率或采用率的声明；实际数字取决于您自己的系统和调用量。
• 范围界定、日志记录和注册表可降低风险，但并不消除对异常写入操作进行审查的必要性，正如OWASP关于过度代理的指导所建议的那样。

下一步

请告知您希望Agent调用哪些ERP、CRM或财务操作，我们将预约方案审查，围绕这些操作界定开放矩阵、认证模型和注册表。您也可以查看智能体AI自动化服务或浏览更多Netbase洞察。

相关服务与解决方案