一、案例背景：一个典型的 Agent 系统
在之前的章节中，我们用了大量篇幅讨论理论、原则和机制。现在是时候把这些知识应用到实际案例中了。本章将呈现一个完整的实战案例：用一个真实的 Agent 系统，展示从"没有 MCP"到"有 MCP"的重构过程。
这个案例虽然是虚构的，但它综合了我们之前讨论过的所有问题。智享科技是一家电商公司，他们开发了一个智能客服 Agent，帮助商家自动处理客户咨询。这个 Agent 基于 OpenClaw 框架构建，拥有大约三十个 Skill，每天处理数万次请求。
在前几周，系统运行良好。但随着 Skill 数量增加和请求量增长，一系列问题开始暴露。智享科技的 CTO 陈浩决定引入 MCP 来重构系统。本章将详细描述这个重构过程。
二、重构前的系统状态
在重构之前，智享科技的 Agent 系统处于典型的"能跑但不可控"状态。
在架构层面，系统采用纯 OpenClaw 架构。Agent 直接调用三十个注册的 Tool，每个 Tool 是一个 Python 函数。Prompt 中包含了大量的规则描述，试图约束 Agent 的行为。API 密钥以明文形式写在环境变量中，Agent 运行时直接读取使用。没有统一的审计日志，每个 Tool 各自记录一些信息，格式不统一。没有权限控制，Agent 可以调用任何已注册的 Tool。没有人工审批，高风险操作由 Agent 直接执行。
在运行过程中，系统暴露出一系列问题。Tool 调用准确率下降到约七成，Agent 经常选错 Skill。发生过多次安全事件，包括数据泄露和误删订单。每次出问题后，团队需要花费数小时甚至数天来追溯原因，因为日志分散且格式混乱。安全团队要求系统下线整改，因为无法满足合规要求。
陈浩意识到，继续打补丁已经无法解决问题。他需要一个根本性的解决方案。
三、重构决策：为什么选择 MCP ？
在评估了多种方案之后，陈浩选择了 MCP。他的决策基于以下考量。
第一，MCP 不是要替换 OpenClaw，而是在 OpenClaw 外面加一层协议。这意味着团队可以保留现有的 Agent 逻辑和 Skill 实现，只需要增加 MCP 协议层和控制平面。这种渐进式的重构方式风险较低。
第二，MCP 提供了开箱即用的治理能力。认证、授权、审计、审批、限流------这些能力不需要从零开发，Peta 这样的控制平面产品已经提供了生产级的实现。
第三，MCP 是一个开放标准，不是某个厂商的锁定方案。即使未来需要更换控制平面产品，Skill 的 MCP 接口是标准化的，迁移成本可控。
第四，MCP 的设计原则与智享科技面临的问题高度匹配。可观测性解决日志混乱问题，可控性解决权限失控问题，可回滚性解决错误无法纠正问题。
四、重构过程的五个阶段
陈浩将重构过程分为五个阶段，每个阶段有明确的目标和验收标准。
第一阶段： Skill 的 MCP 化封装
第一阶段的目標是将现有的三十个 Tool 封装为 MCP Skill。这个阶段不改动业务逻辑，只增加 MCP 协议接口。
团队为每个 Skill 编写了结构化的规范，包括身份标识、输入输出规范、副作用声明、权限声明、错误声明、观测指标。其中副作用声明将 Skill 分为三类：只读类，包括 query_order、query_product、query_user 等，这些Skill 只读取数据，不修改状态。写操作类，包括 update_order、create_refund 等，这些 Skill 会修改系统状态。高风险类，包括 delete_order、send_refund、cancel_order 等，这些 Skill 执行敏感操作，需要审批。
团队将每个 Skill 部署为独立的 MCP 服务器，暴露 MCP 协议接口。原有的 Python 函数代码基本保持不变，只移除了内部的权限验证逻辑，因为这部分逻辑将移到 MCP 控制平面。
第一阶段完成后，Agent 仍然可以通过原有的方式直接调用 Tool，同时也可以通过 MCP 协议调用 Skill。这种双轨运行的方式允许团队逐步切换，降低风险。
第二阶段： MCP 控制平面的部署
第二阶段的目标是部署 MCP 控制平面。陈浩选择了 Peta 作为控制平面产品，因为它提供了完整的凭证管理、策略引擎、审计日志、审批工作流。
部署过程包括以下步骤。首先，在公司的云环境中部署 Peta 控制平面实例，包括网关、Vault、策略引擎、审计存储。然后，将所有 MCP 服务器注册到 Peta 控制平面，每个 Skill 的规范被导入到策略引擎。接着，将原有的API 密钥迁移到 Peta Vault 中，Agent 不再直接持有密钥。最后，配置基础的策略规则，例如只读 Skill 允许所有 Agent 调用，写操作 Skill 需要审计，高风险 Skill 需要审批。
第二阶段完成后，MCP 控制平面已经就绪，但 Agent 还没有切换到 MCP 调用方式。
第三阶段： Agent 的 MCP 客户端集成
第三阶段的目标是修改 Agent，使其通过 MCP 客户端调用 Skill，而不是直接调用 Tool。
团队修改了 OpenClaw Agent 的配置。Agent 不再直接注册 Tool 函数，而是注册一个 MCP 客户端，连接到Peta 网关。Agent 在配置时声明它可以调用的 Skill 列表，这个列表与之前注册的 Tool 列表基本相同，但调用方式发生了变化。
为了降低风险，团队采用了渐进切换的策略。首先让 Agent 在处理低风险请求时使用 MCP 调用，高风险请求仍然使用原有的直接调用。观察一段时间，确认没有问题后，将全部流量切换到 MCP 调用。
第三阶段完成后，所有的 Skill 调用都经过了 MCP 网关。这意味着认证、授权、审计、审批等治理能力开始生效。
第四阶段：策略的精细化配置
第四阶段的目标是根据实际运行数据，精细化配置权限策略。
在第三阶段，团队使用的是粗粒度的策略。随着系统运行，团队积累了大量的审计日志。通过分析这些日志，他们发现了许多可以优化的地方。例如，客服 Agent 不需要调用财务相关的 Skill，可以在策略中明确禁止。查询Skill 应该只能查询当前用户自己的数据，需要在策略中添加参数约束。某些 Skill 在特定时间段调用频率异常高，需要配置限流策略。
团队根据分析结果，逐步细化了策略规则。这个过程是持续迭代的，随着业务变化和数据积累，策略会不断优化。
第五阶段：可观测性和可回滚性的完善
第五阶段的目标是完善可观测性和可回滚性能力。
在可观测性方面，团队将 Peta 网关暴露的指标接入到现有的监控系统 Prometheus 和 Grafana 中。他们创建了多个仪表盘，实时展示每个 Skill 的调用次数、错误率、延迟分布。配置了告警规则，当错误率超过百分之一或延迟超过三秒时，自动发送告警到企业微信群。
在可回滚性方面，团队为关键的写操作 Skill 定义了补偿操作。例如，create_refund 的补偿操作是cancel_refund，update_order 的补偿操作是 restore_order。当 Agent 执行事务性任务时，如果任何一个步骤失败，Peta 控制平面会自动执行补偿操作，回滚到任务开始前的状态。
第五阶段完成后，智享科技的 Agent 系统从"能跑"状态升级到了"能上线"状态。
五、重构前后的对比
重构完成后，陈浩组织了一次复盘，对比重构前后的系统状态。
在可观测性方面，重构前日志分散在五个服务中，格式混乱，查询困难，追溯一个问题需要数小时。重构后所有调用记录在 Peta 审计日志中，格式统一，查询秒级响应，追溯一个问题只需要几分钟。
在可控性方面，重构前权限靠 Prompt 劝说，Agent 可以调用任何 Tool，发生过多次安全事件。重构后权限由策略引擎控制，违规调用被自动拦截，重构后未发生过安全事件。
在可回滚性方面，重构前错误操作无法撤销，用户投诉后只能手动补偿，耗时长且容易出错。重构后关键操作有补偿机制，事务性任务支持自动回滚，错误发生后可以快速纠正。
在开发效率方面，重构前新增一个 Skill 需要实现权限验证、审计日志、错误处理等重复代码，大约需要两天。重构后新增一个 Skill 只需要编写业务逻辑和规范，MCP 自动提供治理能力，大约需要半天。
在运维负担方面，重构前团队需要手动处理各种故障和投诉，一个全职运维工程师疲于奔命。重构后大部分问题由系统自动处理，运维工程师可以专注于优化和改进。
六、经验教训
通过这次重构，陈浩的团队总结了几条经验教训。
第一条，MCP 不是银弹。它不能自动修复业务逻辑的错误，不能自动优化模型的准确率。MCP 解决的是治理问题，不是智能问题。在引入 MCP 之前，你的 Agent 应该已经能够基本正确地完成任务。
第二条，渐进式重构比推倒重来更安全。团队采用了双轨运行和渐进切换的策略，每一步都有明确的回滚方案。这大大降低了重构的风险。
第三条，规范比代码更重要。在重构过程中，最耗时的工作不是写代码，而是为每个 Skill 编写规范。但正是这些规范，使得自动化治理成为可能。
第四条，策略需要持续优化。第三阶段配置的粗粒度策略只是起点。随着系统运行，团队需要不断分析审计日志，发现异常模式，优化策略规则。
第五条，人的因素很重要。MCP 引入了新的概念和工作方式，团队成员需要时间学习和适应。陈浩组织了多次培训，帮助团队理解 Action、Context、Permission 等核心概念。
七、小结：从 " 能跑 " 到 " 能上线 " 的完整路径
本章通过一个完整的实战案例，展示了用 MCP 重构 Agent 系统的全过程。
第一，重构前的系统处于"能跑但不可控"的状态。它有三十个 Skill，每天处理数万次请求，但存在严重的可观测性、可控性、可回滚性问题。
第二，重构决策基于四个考量：MCP 不是替换而是增强，MCP 提供开箱即用的治理能力，MCP 是开放标准，MCP 的设计原则与问题高度匹配。
第三，重构过程分为五个阶段：Skill 的 MCP 化封装、MCP 控制平面的部署、Agent 的 MCP 客户端集成、策略的精细化配置、可观测性和可回滚性的完善。
第四，重构后系统在可观测性、可控性、可回滚性、开发效率、运维负担五个维度上都有显著提升。
第五，团队总结了几条经验教训：MCP 不是银弹，渐进式重构更安全，规范比代码更重要，策略需要持续优化，人的因素很重要。
在下一章，我们将讨论一个决策层面的问题：什么时候你真的需要 MCP？什么时候反而是过度设计？这将帮助读者在自己的项目中做出正确的技术选型。