夜雨聆风学习资料网

ARTICLE · 1144848

AI Agent专题06:工具设计与MCP

发布时间：2026-10-09 10:55:30 最近访问：2026-10-09 10:55:30
AI Agent专题06:工具设计与MCP

你让 Agent 把周会改到周三下午。它调用了一个名叫 calendar 的工具，然后问：改哪场会、改到几点、要不要通知参会人？

这些问题本该在工具设计时说清。接入工具不难，让模型选对工具、传对参数、知道结果是否成功，才是工程工作。

01 工具名字太含糊：模型怎么知道该不该用

一个可用工具至少要写明四件事：

  • 名称：动作清楚，例如 reschedule_meeting。
  • 说明：什么时候使用，什么时候不能使用。
  • 输入 Schema：需要哪些参数，类型和范围是什么。
  • 返回结构：成功、失败和业务状态怎样表达。

下面这类说明就太含糊：

calendar：处理日历

模型不知道它能查空闲时间、创建会议，还是删除日程。更清楚的接口会拆开读写动作：

find_free_slots(date, participants, duration_minutes)
reschedule_meeting(event_id, new_start, notify_participants)

工具粒度也不能无限细。把“年份、月份、日期、小时”各做一个工具，只会让调用变长；把整套日历都塞进一个万能工具，又会让参数和权限失控。边界应围绕一个完整、可验证的动作来定。

02 参数写对了：为什么操作仍然可能失败

Schema 能检查 duration_minutes 是不是整数，却不能证明会议真的改成功。

一次调用要经过：

  1. 模型选择工具并生成参数。
  2. 程序校验字段、权限和资源范围。
  3. 工具调用日历服务。
  4. 外部系统返回技术状态和业务结果。
  5. Agent 核对结果是否满足原任务。

接口返回 HTTP 200，只能说明请求被服务接收。会议可能因为时间冲突而没有改动。工具结果最好同时返回：

{
  "status": "conflict",
  "event_id": "weekly-103",
  "requested_start": "2026-09-24T15:00:00+08:00",
  "conflicts": ["产品评审"],
  "changed": false
}

模型拿到结构化结果，才能决定换时间还是询问用户。

03 读取和写入不是一个风险等级

list_events 只读日历，delete_event 会改变真实状态。两类工具不该共享同一套默认权限。

写操作要增加：

  • 明确的资源范围。
  • 用户身份与授权检查。
  • 高风险动作前确认。
  • 唯一请求编号，防止重试产生重复操作。
  • 操作日志和可恢复方案。

“发送邮件”“付款”“删除文件”尤其不能因为模型说“已确认”就直接执行。确认应由 Host 或业务系统记录，不能只存在模型生成的文字里。

04 工具越来越多：MCP 解决的是接入方式

每个 AI 应用都单独对接日历、网盘和数据库，会重复编写连接、能力发现和消息交换逻辑。

MCP（Model Context Protocol） 提供一套开放协议，让 AI 应用以统一方式连接提供工具和数据的服务。[1]

它采用 Host—Client—Server 架构：

  • Host：承载 AI 应用，管理权限、用户同意、生命周期和上下文汇总。
  • Client：由 Host 创建，与一个 Server 保持一对一连接，负责协议协商和消息路由。
  • Server：暴露专门能力，可以运行在本地，也可以是远程服务。

假设桌面助手连接三个 Server：文件、日历、公司知识库。Host 会创建三个 Client，各自维护连接。文件 Server 不能因为接入了同一个 Host，就天然看到日历 Server 的数据。

05 Tools、Resources、Prompts：三个入口分别给谁用

MCP Server 可以提供三类常见原语：

原语作用常见控制方
Tools执行动作或动态查询模型选择调用
Resources提供文件、记录等上下文数据应用选择附加
Prompts提供可复用交互模板用户主动选择

举例：

  • reschedule_meeting 是 Tool，因为它会执行日历操作。
  • calendar://events/today 可以是 Resource，应用把当天日程作为上下文读取。
  • “生成会议准备清单”可以做成 Prompt，用户从菜单里主动使用。

控制方是设计原则，不是绝对禁止。真正实现仍应以当前协议版本和 Host 行为为准。[2]

06 Function Calling 和 MCP 有什么不同

Function Calling / Tool Use 描述模型怎样发起一次工具调用：选择名称，生成参数，等待结果。

MCP 描述应用怎样发现并连接外部能力：谁是 Host，怎样与 Server 建立会话，支持哪些工具、资源和提示。

一个 MCP Tool 最终仍可能通过模型的 Tool Use 被调用。两者处在不同层：

Function Calling 管“一次怎么叫”；MCP 管“能力怎么接进来”。

MCP 也不会自动修好坏工具。工具名含糊、参数混乱、权限过大，即使接入方式标准化，模型照样会选错。

07 连接建立时发生什么：能力协商

Client 与 Server 初始化时会交换各自支持的能力。Server 需要声明是否支持工具、资源订阅或提示模板；Client 也要声明自己支持的功能。[1]

这一步避免双方凭空假设。例如 Server 没有声明工具能力，Client 就不能直接调用工具；Client 不支持某项通知，Server 也不应强行发送。

协议和 SDK 会升级。项目必须记录使用的规范版本，并在升级时重新测试认证、参数、返回值和错误处理，不能看到“MCP”三个字就默认兼容。

08 工具如何验收：让错误也有固定形状

一个日历工具至少要测试：

  1. 正常改期。
  2. 缺少会议编号。
  3. 时间格式错误。
  4. 目标时间有冲突。
  5. 当前用户没有权限。
  6. 外部服务超时。
  7. 重复请求是否创建两次变更。

每种结果都要能区分。模型才能知道何时修参数、何时重试、何时询问用户，何时立即停止。

这一篇把 Agent 的外部接口接好了。工具真正进入代码库以后，Coding Agent 仍然不能收到需求就直接开写，还要先理解项目、确认边界并留下验收证据。

关注一霁月，继续拆开 Agent 与真实世界的连接方式。

资料参考：

[1] Model Context Protocol, Architecture: https://modelcontextprotocol.io/specification/2025-11-25/architecture

[2] Model Context Protocol, Server primitives overview: https://modelcontextprotocol.io/specification/draft/server/index

[3] Anthropic, Writing effective tools for agents: https://www.anthropic.com/engineering/writing-tools-for-agents

[4] 李博杰，《深入理解 AI Agent：设计原理与工程实践》v2.0，第 4 章。

相关学习资料