Claude Skills 与 MCP：用 SOP 构建垂类 Agent 的工程化方法

企业里真正有价值的智能体（Agent），通常不是一个什么都能聊的通用助手，而是能稳定完成某个封闭业务流程的专用系统。

比如合同审核、采购比价、报销稽核、客服质检、投标文件检查。这些任务看起来很复杂，但拆开后往往都有明确的 SOP（Standard Operating Procedure，标准作业程序）：先检查什么，再核对什么，发现异常后怎么标记，哪些情况必须升级给人工。

Claude Skills 和 MCP（Model Context Protocol，模型上下文协议）的价值，就在于把这两件事分开处理：

• Claude Skills 负责封装业务流程和领域知识：模型在特定任务中应该怎么做。
• MCP 负责连接外部数据和系统工具：模型需要查哪些数据、调用哪些服务。

这不是单纯把提示词写长，而是把提示词工程拉回到软件工程：业务规则放进可维护的文件结构里，外部连接变成标准协议，确定性计算交给脚本完成。

从“合同审核 AI”看问题本质

业务部门提出“做一个合同审核 AI”时，真实需求通常不是聊天，而是替代一部分重复检查工作。

以采购合同审核为例，系统需要完成这些动作：

如果所有规则都塞进一个巨大的 System Prompt，系统很快会变得难维护：规则越来越长，任务越来越多，模型上下文里充满和当前任务无关的信息，最后容易出现上下文污染。模型本来只需要审核付款条款，却同时看到报销流程、Java 代码规范、客服话术和数据库字段说明，判断质量自然会下降。

更合理的方式是让模型在需要某项能力时再加载对应资料，这就是 Claude Skills 中很关键的机制：渐进式披露（Progressive Disclosure）。

flowchart TD
    A[用户提交任务：审核采购合同] --> B[Agent Host 接收请求]
    B --> C{匹配需要的 Skill}
    C -->|合同审核| D[加载 contract-reviewer/SKILL.md]
    C -->|报销稽核| E[加载 expense-auditor/SKILL.md]
    D --> F[把合同审核规则放入上下文]
    F --> G{是否需要外部数据}
    G -->|需要供应商信用| H[通过 MCP 调用供应商系统]
    G -->|不需要| I[直接执行审核流程]
    H --> J[生成风险结论与审核报告]
    I --> J

模型平时只需要知道“系统有合同审核能力”，不需要把所有合同审核细则都常驻在上下文中。真正遇到合同审核任务时，再读取对应 Skill 中的说明、脚本和模板。

Claude Skills 是什么

Claude Skills 可以理解为一个面向模型的能力包。它不是一个独立运行的应用，也不是完整的智能体运行时，而是一组结构化文件，用来告诉宿主系统：遇到某类任务时，应该加载哪些指令、资源和工具。

一个典型 Skill 目录可以长这样：

contract-reviewer/
├── SKILL.md
├── scripts/
│   ├── check_payment_terms.py
│   └── calculate_risk_score.py
├── templates/
│   └── risk_report.md
└── examples/
    └── purchase_contract_sample.md

各部分分工很清楚：

SKILL.md 是核心，它更像一份给模型看的操作手册，而不是普通说明文档。比如合同审核 Skill 可以这样写：

# Contract Reviewer Skill

## 目标

审核采购合同中的财务和合规风险，并输出结构化风险报告。

## 处理流程

1. 识别合同基本信息：
   - 合同编号
   - 供应商名称
   - 合同金额
   - 付款方式
   - 付款账期
   - 违约责任条款

2. 检查付款账期：
   - 账期短于 30 天，标记为高现金流压力风险
   - 账期在 30 到 60 天之间，标记为中等风险
   - 账期超过 60 天，标记为低风险
   - 如果合同中缺少账期信息，必须标记为“信息缺失”

3. 检查金额审批阈值：
   - 金额超过 100 万元，需要总监审批
   - 金额超过 500 万元，需要法务和财务共同复核

4. 输出格式：
   - 风险等级
   - 风险原因
   - 需要人工复核的条款
   - 建议修改意见

这类内容如果直接塞进 System Prompt，会和其他任务规则混在一起。放进 Skill 后，业务规则可以单独维护、单独版本管理，也可以由懂业务的人参与编写。

为什么不能只靠 Prompt

Prompt 适合描述任务意图，但不适合承载大量长期维护的业务规则。

把所有能力都写进 System Prompt，会遇到几个问题：

特别是金融、法务、采购这类场景，不能让模型“凭感觉”算账。金额、日期、比例、阈值判断这类任务应该交给脚本完成。

例如付款账期检查可以写成确定性代码：

from datetime import datetime

def check_payment_terms(sign_date: str, payment_date: str) -> dict:
    """
    sign_date 和 payment_date 格式：YYYY-MM-DD
    """
    start = datetime.strptime(sign_date, "%Y-%m-%d")
    end = datetime.strptime(payment_date, "%Y-%m-%d")
    days = (end - start).days

    if days < 0:
        return {
            "valid": False,
            "risk": "HIGH",
            "reason": "付款日期早于签约日期"
        }

    if days < 30:
        risk = "HIGH"
        reason = "付款账期短于 30 天，存在现金流压力"
    elif days <= 60:
        risk = "MEDIUM"
        reason = "付款账期在 30 到 60 天之间"
    else:
        risk = "LOW"
        reason = "付款账期超过 60 天"

    return {
        "valid": True,
        "payment_days": days,
        "risk": risk,
        "reason": reason
    }

模型负责理解合同文本、抽取字段、解释风险；脚本负责算账期和风险等级。这样的分工比让模型直接心算可靠得多。

MCP 解决的是连接问题

Skill 解决“怎么做”，MCP 解决“去哪查、怎么调”。

企业里的智能体很少只靠模型上下文完成任务。合同审核需要查供应商信用，报销稽核需要查发票真伪，客服助手需要查订单状态，运维助手需要查监控指标。这些数据散落在 ERP（企业资源计划）系统、CRM（客户关系管理）系统、数据库、内部 API 和文档仓库里。

如果每个 Agent 都单独写一套连接逻辑，系统很快会失控：

flowchart LR
    A1[合同审核 Agent] --> B1[供应商系统接口]
    A2[报销稽核 Agent] --> B2[财务系统接口]
    A3[客服 Agent] --> B3[订单系统接口]
    A4[运维 Agent] --> B4[监控系统接口]

MCP 的做法是把外部能力包装成标准 Server。Agent Host 通过 MCP Client 调用这些 Server，不需要关心每个业务系统的底层差异。

flowchart LR
    U[用户] --> H[Agent Host]
    H --> S[Skill: 业务流程与规则]
    H --> C[MCP Client]

    C --> M1[MCP Server: 供应商信用]
    C --> M2[MCP Server: ERP 合同数据]
    C --> M3[MCP Server: 发票校验]

    M1 --> D1[(供应商数据库)]
    M2 --> D2[(ERP 系统)]
    M3 --> D3[(税务/发票服务)]

一个供应商信用查询 MCP Server 可以暴露类似这样的工具描述：

{
  "name": "get_supplier_credit",
  "description": "根据供应商名称或统一社会信用代码查询供应商信用等级",
  "inputSchema": {
    "type": "object",
    "properties": {
      "supplier_name": {
        "type": "string",
        "description": "供应商名称"
      },
      "credit_code": {
        "type": "string",
        "description": "统一社会信用代码"
      }
    },
    "required": ["supplier_name"]
  }
}

Agent 在审核合同时发现需要供应商信用信息，就可以通过 MCP 调用这个工具。业务规则仍然放在 Skill 里，数据查询能力放在 MCP Server 里，两者不要混在一起。

Skill、脚本、MCP 的边界

把三者边界划清，系统才容易维护。

合同审核场景中，一次完整执行过程可以拆成这样：

sequenceDiagram
    participant User as 用户
    participant Host as Agent Host
    participant Skill as contract-reviewer Skill
    participant Script as 本地脚本
    participant MCP as MCP Server
    participant ERP as ERP/供应商系统

    User->>Host: 上传采购合同并要求审核
    Host->>Skill: 匹配并加载合同审核规则
    Skill-->>Host: 返回审核流程、风险标准、输出模板
    Host->>Host: 抽取金额、账期、供应商名称
    Host->>Script: 计算付款账期和金额风险
    Script-->>Host: 返回确定性校验结果
    Host->>MCP: 查询供应商信用
    MCP->>ERP: 请求供应商数据
    ERP-->>MCP: 返回信用等级和异常记录
    MCP-->>Host: 返回查询结果
    Host-->>User: 输出结构化审核报告

这个流程里，模型不是被要求“凭空变聪明”，而是在一个受控环境里完成擅长的部分：理解文本、选择流程、调用工具、组织报告。

一个 Skill 算不算垂类 Agent

从技术定义看，Skill 本身不算完整 Agent。它没有独立运行时，不会自己接收请求、管理状态、调用工具，也不能脱离宿主系统运行。它更像 Agent 的能力配置包。

但从产品交付角度看，一个加载了 Skill、脚本和 MCP 能力的对话入口，已经可以被当作垂类 Agent 使用。

所以更准确的说法是：

Skill 不是完整的垂类 Agent，但它可以成为垂类 Agent 的核心能力单元。

当一个合同审核入口具备这些能力时，用户并不关心它底层是不是由 Skill、脚本和 MCP 组成：

• 能理解采购合同里的专业条款；
• 能按既定 SOP 检查金额、账期和违约责任；
• 能调用 ERP 或供应商系统查外部信息；
• 能输出稳定格式的风险报告；
• 能把高风险项交给人工复核。

对业务部门来说，这就是一个能处理合同审核任务的专用智能体。

适合用 Skills + MCP 的场景

这种架构适合规则明确、边界清楚、需要连接企业系统的任务。

企业落地时，不要一开始就追求“全能 Agent”。更稳的方式是挑一个封闭业务域，把 SOP 写清楚，把外部系统接好，把关键计算脚本化，再逐步扩大能力范围。

工程落地时要注意的坑

规则不要写成散文

Skill 面向模型，但它仍然应该像工程配置一样清晰。好的 Skill 应该有明确的任务目标、输入要求、处理步骤、异常处理和输出格式。

不建议这样写：

请认真审核合同，注意风险，尽量给出专业意见。

更好的写法是：

如果合同缺少付款账期，必须输出：
- risk_level: HIGH
- issue_type: MISSING_PAYMENT_TERMS
- message: 合同缺少付款账期，无法判断现金流风险

关键判断要可测试

业务规则写进 Skill 后，也需要测试样例。每次修改规则，都应该用样例合同跑一遍，确认输出没有偏离预期。

examples/
├── normal_contract.md
├── missing_payment_terms.md
├── high_value_contract.md
└── bad_supplier_contract.md

MCP 要处理权限和审计

MCP Server 一旦接入企业系统，就不能只考虑“能不能调通”。至少要处理这些问题：

不要让 MCP 承担业务 SOP

MCP Server 应该提供稳定、通用的外部能力，比如“查询供应商信用”“读取合同主数据”“校验发票状态”。至于“什么信用等级算高风险”“金额超过多少需要复核”，这些应该放在 Skill 中。否则业务规则会散落在多个 MCP Server 里，后期很难排查。

不要让模型做确定性计算

凡是涉及金额、日期、税率、汇率、百分比、阈值判断，都应尽量通过脚本或外部服务处理。模型可以负责解释结果，但不要负责生成最终数字。

更合理的分工方式

在这种模式下，企业 AI 应用的开发分工会发生变化：

Skill 降低了业务知识进入 AI 系统的门槛，但不代表工程工作消失了。真正难的部分会转移到这些地方：

• SOP 能不能写得足够清楚；
• 外部系统连接是否稳定；
• 权限和审计是否可控；
• 规则变更能否回归测试；
• 高风险结果是否有人机协同流程。

结论

Claude Skills 和 MCP 的组合，本质上是一种更工程化的 Agent 构建方式。

Skill 把业务 SOP、领域知识、输出模板和确定性脚本打包成可维护的能力单元；MCP 把企业系统、数据库和外部服务包装成标准接口；Agent Host 负责在任务发生时加载合适的 Skill，并按需调用 MCP 工具。

真正可落地的垂类 Agent，不一定要从复杂编排平台开始。一个清晰的业务 SOP、一个结构化 Skill、几个可靠脚本，再加上一组受权限控制的 MCP Server，就能构成很多企业场景里的最小可用智能体。