---
title: "AI 智能体如何选择工具：智能体发现机制"
description: "Claude、ChatGPT 和 Cursor 如何决定调用哪个 MCP 服务器。哪些信号有意义，以及如何成为智能体会选择的工具。"
canonical_url: "https://getminds.ai/blog/zh/how-ai-agents-choose-tools-mcp-discovery-mechanics"
last_updated: "2026-06-22T02:09:23.225Z"
---

# AI 智能体如何选择工具

当一位营销人员让 Claude "找到面向德国 B2B SaaS 的合成客户面板"时，模型不会打开搜索引擎。它会读取当前会话所连接的每一个 MCP 工具的描述，对它们进行排序，然后挑出一个。这个排序是工具发现的新互联网首页，但几乎没有人为它做优化。

本文揭开盖子，讲清楚 2026 年这个排序到底是怎么运作的，哪些信号能撼动它，以及对任何一支推出 MCP 服务器的团队有什么实用启示。

## 在智能体语境下，"发现"到底是什么

有两层发现需要分开看待。

*第 1 层，注册表层。* 用户（或智能体本身）在目录中找到一个 MCP 服务器，并把它接入客户端。这是浏览器风格的发现：智能体友好的注册表、OAuth 流程、"添加这个连接器"的按钮。MCP 注册表、Anthropic 的目录、OpenAI 的 Apps SDK 目录以及 `mcpmarket.com`，都扮演这个角色。一旦用户点了 Connect，服务器就出现在智能体的工具列表里。

*第 2 层，会话内发现。* 每当用户发一条消息，智能体必须决定调用哪一个工具，或者是否调用任何工具。这一层才是真正驱动使用的地方。一个服务器可以连着但几个月都不被调用，因为智能体永远选择别的。真正的排序发生在这里，但几乎没有人讨论它。

本文剩下的部分都是关于第 2 层。

## 智能体真正看到的东西

当一个 MCP 服务器接入时，它发送一个 handshake，描述它暴露的每一个工具。对每个工具，智能体收到：

- 一个名字（例如 `create_panel`）
- 一段简短描述（1 到 3 句，由服务器作者撰写）
- 输入参数的 JSON schema
- 可选的结构化元数据（注解、示例、返回类型）

这就是全部表面。智能体看不到你的网站、定价、文档或博客。你整个产品里杠杆率最高的一段文字，就是工具注册中的那段描述字符串。

含义有点扎心：一个出色的工具，配上模糊的描述，每次都会输给一个平庸的工具加一段锐利的描述。

## 排序过程，逐步拆解

当用户发出一条消息，智能体大致会做这件事：

1. *过滤到看起来相关的工具。* 模型读取它自己的上下文（迄今为止的对话、用户最新的消息），并圈定一个候选集。工具集小（不到 20 个）时，通常会全部考虑。工具集大时，会先过滤。
2. *按描述匹配度打分。* 对每个候选工具，模型评估描述与用户意图的吻合程度。这是软的、语义层面的匹配，不是关键词匹配。同义词管用。领域语言管用。模糊描述失败。
3. *拼装一个调用。* 一旦选中某个工具，模型会从对话上下文中填充参数。schema 中存在含糊字段（例如未参数化的 "options" 对象）的工具会被惩罚，因为模型对自己能否正确调用它的信心更低。
4. *可选地串联调用。* 多步任务里，模型挑出第一个工具、执行、读取结果、然后继续。返回结构化、智能体可读输出的工具能赢得后续调用。返回长篇墙体文本的工具会卡住链条。

整件事在一次推理过程中完成。没有独立的排序模型。没有（目前）遥测反馈循环。决定是基于描述和 schema 做出的，仅此而已。

## 真正能撼动排序的因素

从观察到的智能体行为反推，有四件事能可证明地撼动工具选择：

*描述的具体程度。* "Run market research" 输给 "Run a synthetic customer panel against an audience persona and return summarized findings"。更长的描述匹配更多查询，因为它给模型暴露出更多可抓的把手。这里有预算（多数智能体会截断超过约 500 字符的描述），但大多数服务器离这个上限还很远。

*动词-主语-宾语结构。* 智能体倾向选择描述中动词与用户使用的动词匹配的工具。"问问我的客户"匹配 `ask_panel` 优于 `query_panel_responses`。命名和描述都应以动作打头。

*具体的输出形态。* "返回一个 JSON 对象，包含 `panel_id`、`responses`、`summary` 字段"胜过"返回面板结果"。当智能体能预测对输出该怎么处理时，更有可能调用这个工具。

*Schema 可解析性。* 必填字段可以从上下文填充的 schema（文本描述、数值计数）会被调用。必填字段需要在调用中途获取用户输入的 schema（auth token、内部 ID）会被跳过，转而选择能端到端运行的工具。

## 现在还（暂时）撼动不了排序的因素

一些被讨论得好像有用、但 2026 年其实没用的东西：

- *注册表里的星标数。* 在第 1 层影响发现性，在第 2 层无关紧要。
- *SEO 风格的关键词堆砌。* 模型做语义匹配，不做关键词匹配。把"agentic research AI panels MCP"塞进描述里没用。
- *品牌知名度。* 在会话内层，模型对成熟品牌相对未知品牌没有偏好。描述质量为王。
- *500 毫秒以下的延迟。* 模型在排序时不计时工具调用。慢但有用的工具仍会被调用。

这些都会变。Eval 分数、调用后满意度信号、反垃圾排序，都在主要 host 的路线图上。今天，描述就是杠杆。

## 反垃圾问题

所有这些自然导致一个结果：任何人都可以靠写一段非常长、关键词非常密集的描述来钻排序的空子。Host 们知道这一点。Anthropic、OpenAI 和 MCP 注册表维护者，都在 2026 年末开始弃用描述堆砌。

两套反垃圾机制正在出现：

*Schema 校验。* 声明的 schema 与实际响应形态不一致的工具会被降级或下架。

*跨 host 的 eval 评分。* MCP 注册表正在试点一个公开 eval 套件，针对注册的服务器跑提示，并报告正确性分数。eval 失败的服务器先收到警告，然后被移除。

到 2026 年中，两者都还没完全上线，但都会来。该采取的姿态：写一段在按质量评分的世界里也能赢的描述，而不是只在关键词匹配的世界里赢。

## 给服务器作者的实用建议

如果你在推出 MCP 服务器，下列改动会显著改善会话内选择：

1. *重写每一个工具描述，让它以用户会用的动词开头。* 不是"Panel runner"，而是"Run a customer research panel against a target audience and return summarized responses"。
2. *在描述里写清输出形态。* "返回一个 JSON 对象，包含 `responses` 数组、`themes` 字段和 `summary` 字段。" 这能让智能体足够有信心去链接后续调用。
3. *让必填字段可以从上下文填充。* 如果某个字段需要内部 ID，那就接受名字，由服务端解析。智能体会跳过那些自己无法预测必填字段的工具。
4. *每个工具描述用 200 到 400 字符。* 100 以下太薄。500 以上会被多数客户端截断。
5. *审计你的工具数量。* 工具超过 30 个的服务器会在智能体排序前就被过滤掉。能合并的相关工具就合并。我们见过 60 工具的服务器选择率反而不如 12 工具的服务器，因为模型根本看不到长尾。

把这些描述当作最重要文案的团队正在被调用。把它们当作注册表水管的团队没有。

## 走向

未来 12 个月里机制会硬化。预期三个变化：

*基于 eval 的排序上线。* 自动化 eval 的质量分会开始出现在注册表列表里，并至少在一家主要 host 上影响会话内选择。

*智能体遥测反馈循环。* 第一家上线"过去会话中产生满意结果的工具排得更靠前"的主流 host，会甩开其他人。这是智能体世界的 click-through-rate，并改变优化目标。

*垂直智能体生态。* 营销智能体、销售智能体、研究智能体，每一类都会发展出自己的规范工具栈。在你的垂直里成为默认选项，比出现在每一个目录里更重要。

在这个过渡里赢的工具，是那些把 MCP 描述当作产品首页对待的工具。不这么做的工具，无论底层服务多好都不会被调用。

---

要看智能体为何成为新的买家这个更大的图景，参见[AI 智能体是新一代营销买家](/blog/ai-agents-new-marketing-buyer-agentic-discovery)。要看实操配置，参见[如何在 Claude、ChatGPT 或 Cursor 中运行客户调研面板](/blog/run-customer-panels-from-claude-chatgpt-cursor-mcp-guide)。要看一个描述良好的 MCP 服务器在生产环境是什么样，参见 [Minds MCP](/mcp/overview)。