当企业从传统 Web 系统迈向 AI 原生应用时，最常遇到的不是“模型选型”，而是“系统边界”问题：

• 业务能力到底封装成 Agent Skills，还是暴露成 MCP 工具？
• 对话、流程、知识、权限、审计应该放在哪一层？
• 如何避免“Demo 很惊艳，上线即失控”？

这篇文章不讲空泛概念，而是给你一套可落地的混合架构方法：用 Skills 保障业务编排，用 MCP 打通外部工具，用工作流控制可靠性，用治理层确保可运营。

---

一、从 Web 架构到 AI 架构：变化发生在哪里？

传统 Web 架构核心是“请求-响应”：
前端发请求，后端处理，数据库读写，返回结果。行为路径稳定、可预测。

AI 架构核心是“意图-规划-执行”：
用户给出目标，Agent 需要理解、拆解、调用能力、迭代验证后产出结果。行为路径动态、概率性强。

因此，Web 时代“接口设计”是中心；AI 时代“能力组织+执行治理”才是中心。
你需要同时处理三类复杂性：

1. 语义复杂性：同一句话在不同上下文意义不同。
2. 工具复杂性：工具多、协议杂、权限边界不一致。
3. 运行复杂性：LLM 非确定性，必须靠流程和策略兜底。

---

二、先把两个概念讲清楚：Skills 与 MCP

1）Agent Skills 是什么？

Skills 可以理解为“面向业务目标的能力块”，通常具备：

• 明确的输入输出契约
• 内部可能包含多步逻辑（校验、调用服务、重试、回退）
• 对上层 Agent 表现为“可调用能力”

例子：创建工单、生成周报、对账分析。
它偏“业务语义层”。

2）MCP 是什么？

MCP（Model Context Protocol）更像“模型与工具/数据源的标准连接层”，解决：

• 模型如何发现可用工具
• 如何传参与返回结构化结果
• 如何让不同客户端/服务端互操作

例子：通过 MCP 接 CRM、Git、数据库查询、搜索服务。
它偏“工具接入层/协议层”。

3）一句话区别

• Skills：做什么（业务能力）
• MCP：怎么连（工具协议）

---

三、为什么企业最终都走向混合架构？

只做 Skills：

• 优点：业务抽象清晰、可控性高
• 缺点：接外部系统成本高，重复造轮子，扩展慢

只做 MCP：

• 优点：接入快、生态多、标准化
• 缺点：业务语义薄、流程不可控、稳定性依赖模型临场发挥

所以最优解是：
“Skills 管业务，MCP 管连接，Workflow 管流程，Policy 管治理。”

---

四、参考架构：四层模型

建议采用以下四层：

L1 交互层（Channels）

Web/App/企业微信/飞书/邮件机器人等。
职责：会话管理、用户身份、基础限流。

L2 Agent 编排层（Orchestration）

意图识别、任务拆解、路由策略、上下文管理、记忆策略。
职责：决定调用哪个 Skill，何时调用 MCP 工具。

L3 能力层（Skills + MCP）

• Skills：高价值业务能力（可复用、可测试、可审计）
• MCP：标准工具连接（搜索、知识库、内部 API、第三方 SaaS）

L4 治理与观测层（Governance & Observability）

权限、审计、成本、质量评估、风险策略、回放与追踪。

---

五、核心设计模式（实战最常用）

模式1：Skill 包裹 MCP（推荐默认）

做法：Skill 内部调用多个 MCP 工具，对上暴露单一业务能力。
适用：关键业务流程（下单、退款、审批、工单）。
价值：稳定、可回归测试、可灰度发布。

例：报销审核Skill 内部调用：票据识别 MCP + 制度查询 MCP + OA 审批 MCP。

---

模式2：MCP 直连探索（适合创新场景）

做法：Agent 根据任务直接选择 MCP 工具。
适用：数据探索、研发辅助、一次性分析。
风险：结果波动大，需要加“执行预算+结果校验”。

---

模式3：双通道路由（生产常见）

做法：

• 高风险任务 → Skill 通道
• 低风险任务 → MCP 直连通道
  通过策略引擎自动分流。

例如“修改客户合同”必须走 Skill，“查公开资料”可走 MCP 直连。

---

模式4：人机协同闭环（必须有）

做法：在关键节点加入 Human-in-the-loop：
高金额、高权限、低置信度输出必须人工确认。
这是 AI 应用上线后避免事故的生命线。

---

六、一个可直接复用的落地路线图（90天）

第1阶段（1-3周）：能力盘点

• 列出 Top20 高频业务任务
• 标注风险等级（高/中/低）
• 拆分“可 Skill 化”与“可 MCP 化”能力

产物：能力地图、优先级矩阵。

第2阶段（4-6周）：最小可用架构

• 先建 5-8 个核心 Skills
• 接 3-5 个高价值 MCP 工具（知识库、工单、CRM、搜索）
• 引入统一日志与调用链追踪

产物：MVP 可上线版本。

第3阶段（7-10周）：治理补齐

• 加权限模型（RBAC/ABAC）
• 输出审计事件（谁在何时调用了什么）
• 设定成本预算和失败重试策略

产物：可运营版本。

第4阶段（11-13周）：质量闭环

• 建离线评测集（准确率、幻觉率、任务完成率）
• 建线上指标（P95 延迟、调用成功率、人工接管率）
• 持续优化 Prompt、Skill 契约和路由规则

产物：可持续优化版本。

---

七、关键技术细节：很多团队会踩坑的地方

1）Skill 契约必须“强类型”

至少定义：

• 输入 Schema（必填、可选、枚举）
• 输出 Schema（结构化字段）
• 错误码（可重试/不可重试/需人工）

没有契约，后续观测和治理都会失效。

2）上下文不要“全量塞给模型”

应使用分层上下文：

• 会话短期记忆
• 用户画像长期记忆
• 任务临时工作区
  并设置 TTL 与脱敏策略。

3）MCP 工具要有“最小权限”

给模型的不是“系统管理员权限”，而是“任务所需最小权限”。
同时引入：签名、令牌过期、调用白名单。

4）结果必须可验证

对关键输出做二次校验：

• 规则校验（金额、日期、状态机）
• 多源比对（知识库 vs 业务库）
• 置信度阈值+人工复核

---

八、示例：客服系统 Web 转 AI 的混合改造

原有系统：FAQ + 工单 + CRM。
目标：构建 AI 客服助手，提升首解率并降低人工压力。

设计方案

• Skills问题归类Skill订单查询Skill退换货处理Skill工单创建Skill
• MCP 工具知识库检索 MCPCRM 查询 MCP物流状态 MCP工单系统 MCP

路由策略

• 查询类（低风险）→ Agent 直连 MCP
• 执行类（高风险）→ 必须走 Skill
• 金额相关 → 人工确认后提交

指标变化（典型目标）

• 首次响应时间：下降 60%
• 人工转接率：下降 25%
• 错误执行率：控制在 0.5% 以下

---

九、治理框架：上线后能不能“稳”就看这部分

建议至少建立五类看板：

1. 质量看板：任务成功率、幻觉率、回退率
2. 效率看板：平均轮次、响应延迟、自动化率
3. 成本看板：Token 成本、工具调用成本、单任务成本
4. 风险看板：越权调用、敏感词命中、高风险操作数
5. 运营看板：用户满意度、留存、人工接管占比

没有治理，AI 系统只是“会说话的黑盒”。

---

十、反模式警示（务必避开）

• 把所有内部 API 直接暴露给模型
• 不做 Skill 层，完全依赖模型自由发挥
• 没有回放日志，问题无法复盘
• 只看 Demo 效果，不做离线评测
• 不设人工兜底，直接自动执行高风险操作

---

十一、给架构师的决策清单（可打印）

在你决定一个能力放 Skill 还是 MCP 之前，先问 6 个问题：

1. 这个能力是否高风险/高价值？（是→Skill）
2. 是否需要跨多个工具编排？（是→Skill 包裹 MCP）
3. 是否强调快速接入与试错？（是→先 MCP）
4. 是否有严格审计要求？（是→Skill + 审计）
5. 是否需要稳定 SLA？（是→Workflow 控制）
6. 是否可人工接管？（必须可以）

---

结语：Web 转 AI，不是替换，而是重构“能力组织方式”

真正成熟的 AI 架构，不是模型最强，而是系统最稳。
Agent Skills vs MCP 不应是二选一，而应是分层协同：

• 用 MCP 获得连接力
• 用 Skills 获得业务控制力
• 用 Workflow 获得确定性
• 用 Governance 获得可运营性

如果你正处在 Web 转 AI 的阶段，建议从一个高频、可量化、可闭环的场景先做混合架构试点。先跑通，再复制。
这比盲目追逐“大模型能力上限”，更能带来真实业务结果。