AI 工具与知识库 · 第 6 篇

Skill、MCP 与工具调用

理解能力如何被封装、连接和授权，避免把接入等同于信任。

28 分钟工具进阶

学完能做什么

你会把 Skill 的做事方法、工具的可执行能力、MCP 的连接约定和 Agent 的运行决策分开，并为一个真实任务设计清楚的输入、权限和确认点。

四层结构

text

任务目标
  ↓
Agent：现在该做哪一步，何时停止
  ↓
Skill：这类任务应该按什么方法做
  ↓
MCP / 工具目录：现在有哪些能力可以调用
  ↓
工具实现：真正读取、查询或执行动作

Skill 可以存在而没有工具，例如一套文章校对流程。工具也可以被直接调用，不一定需要 Skill。

Skill 应该包含什么

一份可执行的 Skill 至少说清：

什么情况使用，什么情况不使用；
必需输入和缺失信息如何处理；
执行顺序和每步交付；
可用工具及使用条件；
事实、格式和风险检查；
哪些动作必须由用户确认；
完成、失败和中止时分别输出什么。

工具说明是程序合约

工具名称要表达动作，描述要说明使用时机，参数要有类型、范围和必填项。

json

{
  "name": "find_customer_order",
  "description": "只根据已验证的订单号查询当前订单状态，不修改订单",
  "parameters": {
    "type": "object",
    "properties": {
      "order_id": {"type": "string", "pattern": "^[A-Z0-9-]{6,32}$"}
    },
    "required": ["order_id"],
    "additionalProperties": false
  }
}

Schema 只是第一层。程序还必须检查当前用户是否有权查该订单，并限制频率和日志内容。

MCP 统一发现和调用，不替你做权限决策

MCP 客户端可以从服务器获取工具和资源目录，再使用统一消息形式调用。但“能发现”不等于“允许执行”。

权限至少分三层：

层次	问题	控制方式
连接	客户端能否连上服务器	身份验证、网络边界
工具	当前身份能看到哪些工具	服务器端白名单、角色
动作	本次对象、参数和后果是否允许	资源归属、参数校验、人工确认

只读工具和有副作用工具必须分开

例如：

draft_message：生成草稿，不发送；
preview_recipients：返回将接收的对象，不发送；
send_message：真实发送，需要确认令牌。

不要做一个同时“预览并发送”的工具。预览和执行分开，用户才知道自己在批准什么。

工具结果是数据，不是新指令

网页、文件和外部 API 都可能包含恶意文字。将结果交回模型时明确：它只是待分析数据，不能修改系统规则、请求新权限或触发未批准动作。

设计练习：“整理会议并创建待办”

请设计：

一份 Skill：说明输入、分类标准、缺失信息和验收；
三个只读工具：读取转写、查询人员、预览待办；
一个有副作用工具：创建待办；
每个工具的参数 Schema 和业务权限检查；
确认页展示的具体对象、日期和动作；
工具失败、部分成功和重试时的输出。

完成标准是：不看实现代码，只看 Skill 和工具合约，就能说清什么可以自动、什么必须确认。

完成检查清单

Skill 只规定做事方法，不伪装成已获得权限。
工具名称、使用时机、参数和错误结果清楚。
MCP 连接、工具可见性和本次动作权限分别控制。
只读、预览和真实执行已分开。
外部结果不会被当成高优先级指令。
副作用动作有可观察的确认和审计记录。

《搭建个人知识库：从资料整理到 RAG》——让工具不只能连接，还能基于可追溯资料回答。