企业官网建设流程全解析

MCP 这三个字母，我差不多从去年开始就在团队内部反复讲。最初大家的反应很一致：不就是一套让大模型调用外部工具的标准协议嘛，写个 Demo 连跑通都费劲，直到我们真的决定把 AI 自动化中台从玩具级 Demo 推到生产环境，才发现架构演进、权限沙箱、协议网关、稳定性治理，每一层都有比想象中多得多的坑。这篇文章不聊宏观趋势，只聊我本人实践过程中踩过的坑和最后沉淀下来的工程方案，给正在或准备用 MCP 做内部 AI 自动化的后端、算法和平台工程师一个参考。

如果你是被业务方催着"AI 能不能替我把这个流程跑起来"的技术负责人，这篇文章尤其适合你：它可以帮助你在启动项目前就意识到，MCP 落地最大的挑战不在协议本身，而在如何把"可控性"嵌入到架构里。

1. 从 Demo 到生产，差的不只是稳定性

1.1 Demo 只要"能跑"，生产要"可控"

我见过太多项目的起点一模一样：写一个 Python 脚本，调大模型 API，把几个工具的说明塞进 System Prompt，再让模型输出一段 JSON，代码里根据action字段去调用对应函数。这种 Toy Demo 在演示的时候很惊艳，但离生产级中台差了三个维度。

第一个维度是权限。Demo 里模型调用的数据库账号通常是 DBA（Database Administrator）权限，能查能写能删。但在生产环境，我们不可能让一个可能被提示词注入的模型拿到这种权限。第二个维度是审计，Demo 不需要回答"这个任务是谁发起的、模型为什么调用了这个工具、结果是否合规"，生产运营必须一清二楚。第三个维度是治理：超时、重试、限流、熔断、灰度发布，这些在中台里一个都不能少。

我觉得"可控"才是生产级的核心词。一个 AI 自动化系统，哪怕任务完成率只有 80%，只要每次调用都有审计、有边界、能回滚，业务方就敢用；反过来，如果模型能力很强但行为不可控，谁也不敢让它碰核心流程。

1.2 MCP 给架构演进带来的变量是什么

MCP 的全称是 Model Context Protocol，它定义了 AI 应用（Host）如何通过标准化接口发现和调用外部能力（Server）的规则。相当于给"大模型调用工具"这件事做了一个统一信封：不管工具内部是查数据库、发消息还是操作浏览器，对外都暴露成一致的list、call之类的协议方法。

这个标准化带来的真正变量，是架构上的解耦。过去我们每接一个新系统，就要改 Agent 代码，在 Prompt 里加一段描述，再写一个分支函数；现在只需要实现一个 MCP Server，并在中台注册，Agent 就能通过协议自动发现和调用。

我们内部把 MCP 定位成"自动化中台的南向接口标准"，而不是一个 SDK。这个定位非常重要，它决定了我们不会为了某个具体模型或框架去定制工具，而是让所有工具都向协议对齐。后面所有架构演进，都是围绕这个定位展开的。

2. 中台架构演进：三轮重构的完整脉络

2.1 第一版：Prompt 硬编码，工具一多就崩

我的第一版实现非常朴素。工具定义直接写进 System Prompt，每个工具有一个名字、一段描述、一个参数示例，然后让模型输出类似{"action": "search_order", "params": {"order_id": "123"}}的结构，代码里用一堆if elseif做路由。

这个版本维护到 10 个工具以内还能凑合，一旦超过 15 个工具，Prompt 会占掉大几千 token，大模型开始频繁选错工具。最典型的问题是把query_order和query_order_list搞混，或者给update_order传了只读查询才用的参数。由于工具描述完全依赖人工维护在 Prompt 里，新增一个字段就要重新发版，Agent 逻辑和工具逻辑彻底耦合在一起。

更危险的是没有任何权限控制。模型只要输对一个 action 就能执行任意函数，这在 Demo 场景下无所谓，但设想一下，AI 被诱导调用一个删除生产库存的接口，后果不敢想。第一版给我的教训是：工具接入必须标准化，而且必须在协议层做拦截，不能裸奔。

2.2 第二版：引入 MCP Gateway，把工具变成协议资源

第二版我们做了关键动作：搭建独立的 MCP Gateway，作为 Agent 与所有工具之间的统一入口。Agent 不再直接访问任何业务系统，只跟 Gateway 打交道。

Gateway 内部维护一组 MCP Server 连接，支持两种传输模式：stdio 本地子进程和 Streamable HTTP 远程服务。Agent 通过 MCP SDK 向 Gateway 发起tools/list获取全部可用工具，再通过tools/call调用具体工具。每个工具描述和入参 schema 都来自对应的 MCP Server，不再写死在 Prompt 里。

这次重构效果非常明显。新增一套系统，只需要开发一个 MCP Server 并注册到 Gateway，Agent 侧零代码变更；老系统下线，只需要从注册中心摘除对应 Server，所有调用自动失败，不会出现"Agent 还在尝试调用已下线接口"的情况。Gateway 成了整个中台的路由核心，也是后面做权限和审计的最佳位置。

我建议所有打算做 AI 自动化的团队，哪怕还在 Demo 阶段，也先把这一层抽出来。因为 MCP Gateway 本质上给你提供了一个全局 AOP 切面：限流、鉴权、审计、熔断，都能在一个统一的地方完成，而不是散落在各个工具实现里。

2.3 第三版：异步化、事件驱动与任务编排

第二版跑通之后，我们又撞上一个新问题：同步调用扛不住生产场景。很多工具不是几十毫秒能返回的，比如触发一个 CI/CD 流水线、跑一个数据导出任务、抓取一个页面并做解析，耗时可能长达几十秒甚至几分钟。同步 MCP 调用在这种场景下体验极差，客户端超时、连接断开、重复提交，各种问题接踵而至。

第三版我们把中台改造成异步任务引擎。核心思路是：所有耗时超过 1 秒的工具调用，统一走"提交-查询-回调"模式。Agent 调用工具时，Gateway 立刻返回一个task_id，任务在后台 worker 中执行，执行完成后通过事件回调通知 Agent，或者由 Agent 主动轮询查询结果。

MCP 协议本身也支持进度通知机制，但很多现成 Server 并没有实现，所以我们在 Gateway 层做适配：自己维护任务状态机，把异步任务的进度同步到调用方。这个方案让我们把 CI/CD、数据导出、批量消息推送这些重操作都接了进来，AI 自动化中台才真正具备"干活"而不是"聊天"的能力。

下表是我们三轮重构的核心差异对比：

3. 权限沙箱：中台最容易翻车的命门

3.1 为什么必须做沙箱：模型不可信，工具也不可信

很多人在搭建 AI 自动化中台时，注意力全放在模型调优和工具开发上，权限隔离往往被排在最后。我的意见恰恰相反：权限沙箱应该跟架构同期设计，否则后面每一轮迭代都在还技术债。

先摆两个事实。第一，大模型不是确定性程序，同样一段 Prompt，这次可能选对工具，下次可能因为措辞变化选了另一个同名工具，甚至被恶意构造的外部输入诱导调用危险工具。第二，即便模型选对了工具，工具本身也可能因为输入参数解析异常而做出危险操作。比如一个"执行 SQL"的工具，模型可能生成DELETE FROM orders而不是SELECT * FROM orders，如果没有沙箱约束，事故就发生了。

所以我把权限沙箱理解为三层：网络层隔离、系统层隔离、数据层隔离。目标不是限制模型能力，而是让 MCP Server 进程只拥有完成本职工作所需的最小权限，任何越界行为都会被外部机制挡住。

3.2 基于 Session 的细粒度权限模型

我们采用的方案是基于 Session 的授权粒度。每个用户登录中台后，系统会为这次会话签一个短期令牌，令牌里只包含该用户被允许访问的工具白名单和资源路径白名单。Agent 发起所有工具调用时，Gateway 先校验令牌，再判断目标工具是否在白名单内，最后执行参数级校验。

举个例子，同样是数据库查询类 MCP Server，我们会在工具定义里区分query_readonly和execute_script两种能力。前者允许执行 SELECT，SQL 必须通过只读检测；后者需要额外审批。即使模型成功触发了execute_script，如果用户当前会话没有该权限，网关会直接拒绝并记录一条安全审计日志。

这里有一个关键细节：不要把数据库账号或云厂商密钥直接配置在 MCP Server 里，让 Server 拿着万能钥匙去连所有库。我们是用"每任务临时凭证"的方式，任务启动时从密钥管理系统拉取最小权限凭证，注入到容器环境变量中，任务结束立刻销毁。这样一来，即便某个 MCP Server 被攻破，攻击者拿到的也只是一次性临时凭证，而不是长期的万能钥匙。

3.3 沙箱隔离的具体实现：Docker 与资源约束

系统层的沙箱我们靠 Docker 容器解决。每个 MCP Server 或异步任务都在独立容器中运行，容器配置了非常严格的安全参数。这里给出一个我实际使用的容器启动示例：

docker run --rm \ --read-only \ --cap-drop ALL \ --security-opt no-new-privileges \ --memory 512m --cpus 0.5 \ --pids-limit 128 \ --network mcp-sandbox \ --tmpfs /tmp:rw,noexec,nodev,nosuid,size=64m \ sandbox-mcp-server

我来解释几个关键参数：

• --read-only：根文件系统只读，防止容器内的进程篡改系统文件或植入持久化恶意程序。
• --cap-drop ALL：丢弃所有 Linux capabilities，容器内进程基本无法做提权操作。
• --no-new-privileges：禁止进程通过setuid等方式获得新权限。
• --pids-limit：限制进程数，防止模型或恶意输入触发 fork 炸弹。
• --tmpfs：临时目录有限大小且不可执行，避免容器把临时文件写成可执行文件。
• --network mcp-sandbox：挂到隔离网络，没有外部网络路径。

在网络层，我们在宿主机上配置了 eBPF 网络策略，只允许容器访问特定域名和端口的白名单。比如某个查询订单的 MCP Server，只允许访问内部数据库的 3306 端口；某个浏览器自动化 Server，只允许访问已验证过的站点列表。这个白名单必须由平台管理员维护，模型没有能力修改。

3.4 审计与追踪：出事了能还原现场

权限沙箱的另一半是审计。我们在 Gateway 里对所有工具调用统一打点，记录会话 ID、用户 ID、Agent ID、目标工具、传入参数（脱敏后）、调用耗时、返回状态码。每个字段都有标准格式，直接进入 ClickHouse，支持按用户、按工具、按时间段检索。

日志脱敏必须提前做，这个坑我踩得挺深。一开始我们把模型传入的原始参数直接打到日志里，结果 SQL 里的表名、文件路径、用户输入全被明文记录，一旦日志泄露就是一次安全事故。后来我们封装了统一的脱敏组件，对疑似敏感字段做替换，比如订单号、手机号、邮箱地址都会变成哈希或掩码串。

实践中我们还会把"模型最终执行的参数"和"用户原始意图"分开记录。这两个内容对排查问题非常关键：如果模型把用户的一句话理解错了，跟实际情况对比就能立刻看到偏差。

4. 实战踩坑与排查实录

4.1 坑一：JSON Schema 写得太宽松，模型输出成灾难

MCP Server 的工具定义里，inputSchema直接决定模型能否正确生成参数。我们最开始写 schema 非常随意，字段只给type和description，不加additionalProperties，不设枚举，不写示例。结果就是模型经常把工具名塞进参数里，或者对本来应该用整数的地方传字符串，调用 10 次能失败 6 次。

一个典型的"宽松"定义长这样：

{ "name": "query_orders", "description": "Query orders", "inputSchema": { "type": "object", "properties": { "status": { "type": "string" }, "limit": { "type": "integer" } } } }

看起来够用，但模型会纠结status到底该传"paid"还是"已支付"，limit传"50"而不是50。我们改造后的 schema 是这样：

{ "name": "query_orders", "description": "Query orders by status. Only returns the first N orders.", "inputSchema": { "type": "object", "properties": { "status": { "type": "string", "enum": ["pending", "paid", "shipped", "closed"], "description": "The order status. Use the machine-readable code, not Chinese." }, "limit": { "type": "integer", "minimum": 1, "maximum": 100, "default": 20, "description": "Max number of orders to return." } }, "required": ["status"], "additionalProperties": false } }

加上enum、minimum、maximum、additionalProperties: false之后，错误率直线下降。现在我们的规范是：所有工具 schema 必须有示例值，所有枚举必须穷举，所有可空字段要写default，并且用description明确说明单位、格式和边界条件。

4.2 坑二：工具返回超大 JSON，直接把上下文窗口撑爆

MCP 调用完成后，Server 返回的内容会原封不动进入模型上下文。我们的一个数据查询工具早期会把整个结果集都返回，比如一次查出 10 万行，Agent 的下文直接爆掉，对话失去上下文，更不用说 token 成本了。

后来我们做了三层整改。第一，服务端强制分页，query_orders这类工具只返回前 50 条，并在响应中附带total_count和next_cursor，如果模型需要更多数据，必须显式调用翻页工具。第二，对返回内容做摘要清洗，字段只保留模型推理真正需要的列，去掉created_at、raw_payload这类冗余信息。第三，Gateway 层统一加输出限制，单个工具响应体超过 100KB 会被截断并告警。

这三个措施下来，同样的任务，上下文占用降低了差不多七成，错误率也显著下降。我的经验是：MCP Server 的输出设计要遵循"给模型刚好够用的信息"原则，而不是把底层系统的完整数据一股脑倒出来。

4.3 坑三：同步调用让生产流程卡死

前面提到异步化，但异步化也不是天上掉下来的。我们第一版接入一个"自动生成周报"的流程时，工具调用内部要拉数据、跑分析、渲染 PDF，整体耗时 3 分钟。Agent 按同步方式等 3 分钟，HTTP 连接早断了，模型侧反复重试，导致任务重复执行，周报被生成了三份。

修复方案是设计了一个异步适配层，把工具的执行逻辑封装成任务模型：提交时生成task_id，立即返回给 Agent；后台 worker 执行任务，把结果写入存储；Agent 可以通过get_task_status工具查询进度，也可以由通知服务通过 Webhook 回调推送完成事件。所有异步任务都有状态机：PENDING、RUNNING、SUCCEEDED、FAILED、CANCELED。

这里有个小技巧：为了让模型不要傻等，我们在get_task_status的 description 里明确写清楚"轮询间隔建议 10 秒，不要连续高频调用"。否则模型可能会在几秒内疯狂查询几十次，白白消耗资源。

4.4 坑四：权限卡得太死，AI 自动化直接失去意义

权限沙箱和安全做多了，也会遇到反面问题：所有操作都要审批，AI 自动化就变成了"人工点同意按钮的中台"，业务方意见非常大。我们花了很长时间才对权限策略做分级。

现在内部实行三级策略。低危操作用白名单直接放行，比如只读查询、调用内部接口获取数据；中危操作做参数级校验，比如写操作只能改符合规则的数据；高危操作强制人工审批，比如删除资源、导出大批量数据、修改核心配置。审批本身也做成 MCP 工具，模型会主动发起"请求审批"调用，把操作意图提交到审批队列，负责人通过后任务自动继续。

分级之后中台才终于平衡了安全与效率。所以做权限设计时，我强烈建议尽早和业务方一起梳理工具分级，而不是技术团队自己拍脑袋决定全部审批。

4.5 常见问题速查表

我把实际运维中遇到的高频问题整理成表，方便排查：

5. 最后说几个不写进 PPT 的经验

如果这篇只留一段话，我会说：MCP 解决的是"AI 如何标准化调用工具"的问题，但它不解决"AI 能不能被信任"的问题。后者必须在架构、权限、观测层面由工程团队兜底。

我个人的体会是，真正让 AI 自动化中台跑稳的，往往不是模型能力有多强，而是工程纪律有多严。比如所有工具输出必须有上限、所有调用必须可审计、所有权限必须最小化，这些规则听起来不如"万人同时在线"刺激，但落地之后带来的稳定性提升是最明显的。

如果你现在还在 Demo 阶段，我的建议是从第一天就给所有工具调用加一个网关层，哪怕只是一个简单的反向代理；同时尽早设计工具 schema 和权限模型，不要等工具数量多到无法收拾再重构。AI 自动化中台不是算法竞赛，而是一个长期被低估的工程治理项目。