本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
工具范围
开发工具有两种方法：颗粒和粗粒度。
颗粒状
在精细化方法中，您可以按照 API、操作或查询创建一个工具。例如，您可以为 Git 仓库创建create_issueget_issueadd_labelassign_issue、、、和close_issue工具。这将允许 LLM 对每个 API 进行精细调用，并在必要时编排每个 API。考虑以下提示：“为产品服务创建一个名为'查询仅返回部分结果'的问题，将其标记为错误和高优先级，然后将其分配给 Alice。” 下图显示了 tool-per-API方法如何响应此提示。
在这种方法中，系统提示符和每个注册的工具定义都会在每次呼叫时提供给 LLM。这会消耗额外的上下文并导致延迟损失，因为每个工具调用都代表对 LLM 的单独调用。它还增加了处理工作流程中错误的复杂性。
粗粒度
粗粒度或工作流程驱动的方法是面向工作流程的工具。该工具侧重于 end-to-end用户意图而不是 API 结构。取而代之的是 tool-per-API，你有一个工具可以确定地调用多个。 APIs使用前面的 Git 存储库示例，您可以创建一个由代理调用一次的create_and_setup_issue工具。工具实现根据提供给工具的参数创建问题、添加标签并将其分配给用户。下图显示了粗粒度方法将如何处理相同的提示。
这种方法显示了如何将所有复杂性隐藏在 LLM 层之外。当编排逻辑嵌入到工具实现中时，所有顺序步骤、日志记录、重试逻辑、断路器和速率限制都将在工具中确定性地执行。工作流程驱动的方法使得 LLM 可以更轻松地使用正确的参数调用正确的工具。值得注意的是，某些 API 可能已经提供了工作流程意图，例如 Amazon EC2 RunInstances API。在这些情况下， tool-per-API可能会提供您想要的面向工作流程的设计。
但是，工具也可能变得过于粗糙。如果你的单个工作流程工具尝试做太多事情并且有许多可能的参数，那么法学硕士可能很难推理如何正确使用该工具。它还可能给参数选择和错误处理带来挑战。因此，工具开发必须保持与用户意图相一致的平衡，并避免在单个工具中使用太少或过多的功能。我们建议您围绕完整的用户工作流程设计工具，将通常发生在一起的操作（例如三个或更多 API 调用）捆绑在一起。我们还建议您分解超过八个或更多参数的工具，或者处理多个不同的用户意图。 使用真实提示进行测试，以验证代理是否可以正确使用每种工具。
如果您的工作流程复杂且动态且无法轻易封装为确定性工具，则可以考虑使用该模式。agent-as-tool 专业代理可以充当工具，而不是您的主要代理尝试在工作流程中协调复杂的任务。这些类型的工具可以实现高级决策和分支，它们可以处理在确定性代码中无法轻松管理的错误和重试逻辑。这与 A gent2Agent (A2A
我们建议您从工作流程分析开始，映射最常见的用户工作流程，以确定每个代理所需的核心功能。这为您确定了最低可行的工具集。根据我们在大规模开发 MCP 服务器方面的经验，我们建议采用以下做法。当这些做法发生冲突时，请优先考虑用户意图和工作流程。
MCP 工具范围界定的最佳实践
-
在用户故事中思考并捆绑常见操作 — 工具应直接映射到完整的用户交互，而不是需要协调多个操作。如果工作流程通常需要三个或更多单独的调用，请将它们组合成一个工具。这减少了 LLM 的认知负担，最大限度地减少了工具调用的次数，减少了完成任务所需的上下文消耗和延迟，并提高了准确性和延迟。
-
将参数限制为八个或更少- 如果刀具超过八个参数，则将其分解为多个工具。 LLMs 随着复杂性的增加，很难选择参数。
注意
如果捆绑操作需要的参数超过八个，请优先考虑绑定而不是参数数量，因为简化工作流程比严格的参数限制更有价值。
-
单独的读取和写入操作- 提供不同的工具来读取和修改数据。这种分离明确了代理何时执行潜在的破坏性操作，启用了不同的授权策略，并降低了信息收集期间意外修改的风险。
-
提供合理的默认值 — 设计工具，这样 LLM 只需指定特定于单个请求的参数。默认值通过最小化 LLM 必须推理的信息来降低参数的复杂性并提高工具选择的准确性。
-
首选确定性执行 — 尽可能使工具执行和输出具有确定性。确定性工具更可靠，更易于测试。对于需要智能编排、分支逻辑或无法在确定性代码中轻松管理的高级错误处理的复杂工作流程，可以考虑使用专门的代理作为工具。但是，请选择性地使用此模式，因为它会增加复杂性。
