前三篇笔记整理了Cloud Agent的架构设计、多租户隔离、动态调度的落地坑，这一篇讲最后一块核心内容：Skill（技能）层和MCP（Model Control Plane，模型控制平面）的集成方案，以及整个项目从立项到上线大半年的复盘总结。

一、先回顾一下定位：Skill和MCP各自负责什么？

我们Cloud Agent的整体架构是「Control Plane + Data Plane」分离：

MCP（Model Control Plane）：负责全局模型管理、模型负载均衡、弹性扩缩容、模型版本路由，相当于整个Agent集群的"大管家"，所有模型请求都要经过MCP转发

Skill层：是Agent具体能力的封装，每个Skill就是一个可独立部署的能力单元，比如文档解析Skill、工具调用Skill、代码执行Skill，每个Skill可以独立升级、独立扩缩容

集成的核心需求很明确：Skill要能低代码接入MCP的模型能力，同时MCP要能统一管控所有Skill的模型调用，不能每个Skill自己乱连模型，不然算力成本管不住，出问题也没法排查。

二、集成方案设计：面向接口编程，Skill零改造接入

最开始我们想让每个Skill自己实现MCP的客户端逻辑，后来发现太麻烦：每个Skill开发都要写一遍服务发现、负载均衡、超时重试，重复代码太多，而且MCP升级协议还要所有Skill跟着改。

最终我们改成了「统一中间层+协议约定」的方案，Skill只需要依赖标准的Skill SDK，不需要关心MCP的具体细节，零改造就能接入，整个流程如下：

1. 协议约定：统一模型调用入口

我们在Skill SDK里定义了统一的模型调用接口，所有Skill都用这个接口发起请求：

go

// Skill SDK统一模型调用接口

type ModelClient interface {

  // Invoke 发起模型推理请求

  Invoke(ctx context.Context, req *ModelRequest) (*ModelResponse, error)

  // GetModelEndpoint 获取指定模型的路由端点（供Skill自定义调用使用）

  GetModelEndpoint(ctx context.Context, modelID string) (*Endpoint, error)

}

// ModelRequest 统一请求结构，对齐MCP协议

type ModelRequest struct {

  ModelID   string            `json:"model_id"`   // 要调用的模型ID

  Messages  []Message         `json:"messages"`   // 对话消息

  Params    map[string]any    `json:"params"`     // 推理参数（temperature、max_tokens等）

  SkillInfo SkillMetadata     `json:"skill_info"` // Skill自身的元信息，用于MCP做权限、计费统计

}

只要Skill依赖这个SDK接口，不需要知道MCP在哪里，怎么转发，剩下的都交给中间层处理。

2. 中间件转发：Sidecar模式透明接入

我们用K8s Sidecar的方式做转发：每个Skill Pod会跟着启动一个mcp-proxy Sidecar，负责和MCP做交互：

Skill发起模型调用 -> 请求打到本地Sidecar

Sidecar负责做服务发现，从MCP拿到最优模型实例地址

把请求转发给模型实例，拿到结果返回给Skill

整个过程对Skill完全透明，Skill只需要调用本地接口，不需要做任何额外改造，MCP升级、路由逻辑变化都只改Sidecar，不需要更新Skill。

这样做的好处也很明显：

隔离变化：MCP协议升级只需要升级Sidecar，不需要重启所有Skill

统一管控：所有模型调用都经过Sidecar，MCP可以统一统计每个Skill的调用量、token消耗，做计费和限流

故障隔离：单个Sidecar出问题不会影响其他Skill，滚动升级也不影响业务

3. 元数据透传：MCP统一做权限和计费

每个Skill调用模型的时候，SDK会自动把Skill的ID、租户ID、版本这些元信息透传给MCP，MCP拿到之后做三件事：

权限校验‌：校验这个Skill/租户有没有权限调用指定模型，没有权限直接拒绝

流量管控‌：根据租户的配额做限流，超过配额直接返回报错

计量统计‌：统计每个Skill的token消耗量、调用次数，月底出账单算成本

之前每个Skill自己调用模型的时候，统计全靠Skill自己上报，经常漏报，现在统一由MCP统计，数据准确多了，成本管控也清晰了。

4. 异常处理：统一降级兜底

我们还在Sidecar里做了统一的降级逻辑：如果指定模型满负载了，Sidecar会根据MCP下发的降级策略，自动切到同类型的备用模型，比如大模型满了就切小模型，能降级处理的直接降级，不用Skill自己处理异常。

举个例子：文档解析Skill本来调用gpt-4o-mini，如果这个模型实例负载过高，Sidecar自动降级到qwen-7b，对Skill来说完全无感知，只是响应质量稍微降一点，总比整个请求超时失败好。

三、集成过程踩的坑

看着方案很顺，实际落地踩了好几个坑：

坑1：Sidecar端口转发超时，本地请求 unnecessarily 绕网

最开始我们用host网络，Sidecar绑定127.0.0.1，结果Skill容器访问Sidecar要走宿主机网络，本来本地调用变成了跨网络，延迟高了一倍还多。后来改成用K8s的localhost网络共享，Skill和Sidecar共享网络命名空间，Skill直接访问localhost:port，延迟直接降回原来的水平，问题解决。

坑2：流式响应断流

我们很多Skill需要模型的流式输出，最开始Sidecar做转发的时候，缓冲开太小，遇到长流式响应就会卡住，断流。后来改成了chunked转发，Sidecar不缓存内容，收到一个chunk就转发一个chunk，开长连接保持，断流问题就解决了。

坑3：模型路由更新不及时

MCP的模型实例会弹性扩缩容，地址变了之后，Sidecar不能及时拿到最新的路由，就会把请求发到已经下线的实例，导致报错。后来我们给Sidecar加了‌实时路由订阅‌：MCP的路由变化了，主动推送给所有Sidecar，Sidecar更新本地路由缓存，3秒内就能完成全量更新，找不到地址的问题基本解决了。

项目后记：大半年开发踩过的整体总结

从去年年底立项，到今年年初上线，再到现在稳定运行三个月，整个项目走下来，有几个感受挺深的，分享给做企业级Agent平台的朋友：

1. 企业级Agent的核心不是模型能力，是管控能力

我们最开始立项的时候，把大部分精力放在优化Agent的推理效果上，后来发现企业客户最关心的根本不是这个：客户关心的是「我有100个部门用，能不能做租户隔离？能不能统计每个部门用了多少token？花了多少钱？能不能限制部门只能调用指定模型？安全不合规的模型能不能一键下线？」

这些都是管控层面的问题，和Agent的推理效果没关系，但恰恰是企业能不能落地的关键——我们把MCP管控做好之后，客户最满意的反而不是Agent能力有多强，是成本算得清，权限控得住，出问题能快速定位。

2. Skill模块化是对的，但不要过度拆分

最开始我们把Skill拆得特别细：文档解析拆成文字识别、表格提取、内容摘要三个Skill，结果调用链路变长，一次请求要跨三个Skill调用，延迟高了好多，而且错误概率也变高了。后来我们把相关性强的Skill合并成一个粗粒度的Skill，链路短了，延迟降了30%，稳定性也提高了。

总结下来就是：‌按能力边界拆分，按调用链路合并‌，相关性强、一定要一起调用的技能就合并成一个，不要为了模块化过度拆分。

3. 云原生架构适合企业级Agent，但不要为了云原生而云原生

我们整个项目都跑在K8s上，弹性扩缩容、Sidecar代理这些云原生方案确实给我们省了很多事，但是最开始我们也想搞Service Mesh那一套，全链路用Istio做流量管理，后来发现Istio的性能开销太大，Sidecar额外占了1核1G的资源，对我们这种本身就是算力密集型的业务来说，成本太高了。

最后我们自己写了轻量的mcp-proxy，只有几十M内存，性能开销只有Istio的十分之一，完全满足需求，所以适合自己的才是最好的，不要盲目跟风上复杂的开源组件。

4. 可观测性一定要提前做，不要上线了再加

我们最开始开发的时候，把可观测性放在上线之后做，结果联调的时候，一个请求挂了，不知道是Skill的问题，还是MCP的问题，还是模型的问题，查了一下午才找到问题。后来我们提前把全链路追踪做了，每个请求从Skill -> Sidecar -> MCP -> 模型实例，全链路打trace，出问题一分钟就能定位到哪里错了，效率高太多了。

企业级平台，可观测性比功能更重要，功能错了可以改，出问题找不到在哪，才是真的噩梦。

最后

整个Cloud Agent项目做下来，最大的感受就是：‌企业级智能体平台，本质还是基础设施，不是AI算法Demo‌。你不用把Agent的效果吹得天花乱坠，只要能稳定运行、成本可控、可管可视，就能满足企业的核心需求。

Skill和MCP的集成，本质就是把模型能力变成标准化的基础设施，让Skill开发不用关心底层模型的部署、扩容、管控，专注在业务能力上，这就是我们做这个架构的核心目标。现在平台已经接入了27个Skill，支撑了12个租户的线上业务，运行稳定，接下来我们打算把部分方案开源，给需要做企业级Agent平台的朋友做参考。