工具与 MCP

仅会回答问题的智能体将工作留给了您。本页介绍平台如何让智能体执行操作：调用工具时回合内发生了什么、如何防止这种情况破坏对话，以及如何连接您自己的系统。

工具循环

一个回合并非单次模型调用。模型可能会回答，也可能会请求调用工具；如果它调用了工具，结果将追加到对话中，模型带着该结果再次运行。它随后可能调用另一个工具。循环将持续，直到模型生成回答，或达到迭代限制。

该限制至关重要：如果没有它，一个不断调用工具的模型——这是一种非常常见的故障——将无限运行，消耗令牌，并让客户等待一个永远不会到来的回复。

循环不会做的是将客户的答案从它沿途积累的所有内容中写入。一旦工具完成，请求将被重新构建干净——智能体的指令、简短回顾、本回合发现的事实以及问题——然后基于此生成回复。原因是经过衡量的，这是 为什么上下文增长会导致智能体表现变差 的主题。

在模型运行之前决定使用哪个工具

上述循环假设模型会请求正确的工具。通常它不会——原因值得精确阐述，因为这并非知识问题。

人们不会以软件希望的方式表达请求。“还有其他的吗？”没有命名任何工具、主题或数量；那是两条消息之前的事。交给它的模型必须解决“类似的”指的是什么，决定是否涉及工具，确定是哪一个，填充其参数，并写出一个好的回复——一个样本中的五项工作。通常被丢弃的是工具调用，而客户得到了一段散文，而不是产品列表。

这涵盖了不止一种请求类型。“还有其他的吗？”希望显示项目；“显示按阅读水平分布的书籍”希望统计并绘制目录。如果任由第二个请求自行处理，模型将叙述工作过程而不是执行它——我们观察到一个模型说了六次“让我查询数据库”，然后将 SQL 语句打印到回复中，这是工具的输入，读者永远不应该看到。

因此，对于明显隐含工具调用的请求，平台会先采取一步。一次小型、廉价的调用读取对话并仅返回事实——正在请求什么，以及数量多少。它只看到对话，看不到其他内容：不是智能体的指令，也不是检索到的材料，因此它不会偏离到回答问题。然后：

• 平台编写指令，使用工具实际响应的措辞，并回填缺失的上下文；
• 该回合仅显示一个工具，因此没有选择余地。

前者是关键，而且很容易出错。让模型重写自己的请求在我们能衡量的范围内没有任何改变——同样的猜测，不同的措辞。由平台根据工具自身的定义编写该句子，使一个自托管的 35B 模型在相同请求上的表现从16% 提升到 70%。到达工具的措辞是软件可以计算的，因此软件进行计算——这与将图表数据和卡片内容保留在服务器上而不是模型手中的推理相同。

平台刻意不做的第三件事是：在协议层面强制调用。该选项存在，并且它确实进一步提高了数量。此外，在一个将其实现为解码约束的自托管服务器上，它将模型推入重复循环——我们测量时大约每四个回合中有一个，其中两个分钟都在发出相同的片段。一个永远不会到达的回复比一段散文形式的回复更糟。

值得注意的两个后果。即使组合的指令是英文的，回复仍然以客户的语言返回——这也由平台固定，不留给模型去注意。并且当一个回合本应移交某物却移交了散文时，平台会注意到并再次询问，指出跳过的步骤并提供诚实的出路（“如果没有任何材料合适，请说明”）——因为被施压且没有退路的模型会编造一个出路。描述八个产品但未显示任何产品的智能体，在等待的人看来，与忽略问题的智能体完全一样。

该检查查看返回的内容，而不是其外观。一个学会了结果形状的模型将写出形状而不执行工作——一个空块，或对其从未执行的查找的引用。两者都被视为未交付。

额外的步骤花费不到一秒钟，并且仅运行在看起来需要它的消息上——普通问题不付费。在运行时，对话显示其正在做什么。如果决策的任何部分不清楚，回合将完全按照没有它时的方式进行。

两个预算，而非一个

工具结果是导致对话上下文被破坏的最常见方式。单个 CRM 查询返回的文本可能超过模型整个上下文窗口。

限制每个单独的结果是显而易见的防御措施，但这还不够。结果在迭代中累积——对话只会增长——因此最坏情况是迭代限制乘以每次迭代的多个工具再乘以每个结果的限制。每个结果都通过其自身的限制，但总数仍然溢出。

因此有两个预算：每个结果的限制，以及整个回合的聚合预算。一旦聚合预算耗尽，进一步的结果将被短占位符替换，而不是追加。

占位符中的内容的重要性与截断本身相当。静默截断的结果比没有结果更糟，因为模型无法知道它正在基于半条记录进行推理。截断通知和耗尽占位符都明确说明内容不完整，并指示模型基于现有内容回答，不要编造缺失部分——这是说“我只能看到前几个订单”的智能体与自信地编造其余部分的智能体之间的区别。

截断还记录工具名称和大小，因为经常溢出预算的工具是一个应该返回更少字段的工具——这是一个值得注意的配置问题。

不发出适当工具调用的模型

并非所有模型都能可靠地生成结构化的工具调用；有些将调用作为文本嵌入回复中。循环还将工具调用从消息内容中解析出来，并在回复到达客户之前剥离格式错误的片段，而不是将其视为失败的回合——因此模型状态不佳时降级为稍慢的回合，而不是将 JSON 泄漏到对话中。

连接您自己的系统

工具来自两个来源。

内置工具随平台提供——安排后续跟进、创建提醒、捕获联系信息、调用技能、编辑文档、绘制图表、搜索网络。

大多数这些不是您做出的决定。它们对每个智能体可用，并附加到需要它们的回合，这正是拥有它们不会花费任何费用的原因：访客的消息没有理由使用的工具根本不在该回合的列表中，因此它不占用任何上下文，也不为模型提供错误选择的选项。没有需要维护的检查清单，也没有智能体 silently 缺乏接听电话号码能力的配置。

技能自身的工具是例外，且刻意为之：它们仅在该技能加载时出现，之前不会出现。能力包是一种工作方式，工具是方法的一部分——单独移交它们会让模型跳过该方法。请参阅 技能及其选择方式。

唯一是决定的是从公共来源回答——该智能体是否可以搜索网络并阅读其找到的内容，而不是仅从您自己的材料中回答。这是一个单一开关，因为这是一个单一问题：搜索和获取同时开启，因为一个能找到页面但不能阅读的智能体是可测量的三种配置中最差的。默认关闭，智能体开启时的行为——标记、审核队列——在 检索 中描述。

您的系统通过 MCP 连接。 租户注册 MCP 服务器，其工具对该租户的智能体可用。支持三种传输：stdio 用于本地子进程，streamable_http 和 sse 用于远程服务器。远程 HTTP 服务器是托管 CRM 或内部 API 的常用选择——无需在平台旁边安装任何东西，且连接是每租户的。

因为工具定义是按租户注册的，一个租户的智能体永远无法看到另一个租户的工具或端点。

实际意义

• 智能体可以在句子中间查找某些内容，并用真实值回答。
• 它可以预订、归档和记录到您已经运行的系统中，而不是告诉客户去做。
• 当工具返回的内容超过回合容量时，智能体会说它的观点是部分的，而不是用合理的虚构来填补空白。

行动而非回答的商业论点在 行动的智能体 上。