---

name: tool-design description: "构建智能体可高效使用的工具，包括架构精简模式。适用于为智能体系统创建新工具、调试工具相关故障或误用、优化现有工具集以提升智能体性能。" risk: safe source: "https://github.com/muratcankoylan/Agent-Skills-for-Context-Engineering/tree/main/skills/tool-design" date_added: "2026-02-27"

何时使用此技能

构建智能体可高效使用的工具，包括架构精简模式。

当你需要构建智能体可高效使用的工具（包括架构精简模式）时，请使用此技能。

智能体工具设计

工具是智能体与外部世界交互的主要机制，定义了确定性系统与非确定性智能体之间的契约。与为开发者设计的传统软件 API 不同，工具 API 必须为语言模型设计——它们需要推理意图、推断参数值，并从自然语言请求生成调用。糟糕的工具设计会产生再多提示工程也无法修复的故障模式。有效的工具设计遵循特定原则，充分考虑智能体如何感知和使用工具。

何时使用

在以下场景激活此技能：

• 为智能体系统创建新工具
• 调试工具相关故障或误用
• 优化现有工具集以提升智能体性能
• 从零设计工具 API
• 评估第三方工具的智能体集成
• 在代码库中标准化工具约定

核心概念

工具是确定性系统与非确定性智能体之间的契约。合并原则指出：如果人类工程师无法明确判断在给定场景中应使用哪个工具，那么智能体也不可能做得更好。有效的工具描述本质上是塑造智能体行为的提示工程。

关键原则包括：清晰的描述（回答做什么、何时用、返回什么）；平衡完整性与 token 效率的响应格式；支持恢复的错误消息；以及降低认知负荷的一致约定。

详细主题

工具-智能体接口

工具即契约 工具是确定性系统与非确定性智能体之间的契约。人类调用 API 时理解契约并发出合适的请求，而智能体必须从描述中推断契约，并生成符合预期格式的调用。

这一根本差异要求重新思考 API 设计。契约必须无歧义，示例必须展示预期模式，错误消息必须引导纠正。工具定义中的每一处歧义都会成为潜在的故障点。

工具描述即提示 工具描述被加载到智能体上下文中，共同引导行为。描述不仅仅是文档——它们是塑造智能体推理工具使用方式的提示工程。

糟糕的描述如搜索数据库配合晦涩的参数名会迫使智能体猜测。优化的描述包含使用场景、示例和默认值。描述应回答：工具做什么、何时使用、产出什么。

命名空间与组织 随着工具集合增长，组织变得至关重要。命名空间将相关工具归入公共前缀下，帮助智能体在正确时机选择合适的工具。

命名空间在功能之间创建清晰边界。当智能体需要数据库信息时，路由到数据库命名空间；需要网络搜索时，路由到网络命名空间。

合并原则

单一综合工具 合并原则指出：如果人类工程师无法明确判断应使用哪个工具，智能体也不可能做得更好。这导致优先选择单一综合工具而非多个狭窄工具。

与其实现 list_users、list_events 和 create_event，不如实现一个 schedule_event 来查找可用时间并安排日程。综合工具在内部处理完整工作流，而非要求智能体链式调用多个工具。

为何合并有效 智能体的上下文和注意力有限。集合中的每个工具在工具选择阶段都争夺注意力，每个工具的描述 token 都消耗上下文预算，功能重叠会造成使用哪个工具的歧义。

合并通过消除冗余描述减少 token 消耗，通过让一个工具覆盖每个工作流消除歧义，通过缩小有效工具集降低工具选择复杂度。

何时不应合并 合并并非普遍正确。行为根本不同的工具应保持分离；在不同上下文中使用的工具受益于分离；可能被独立调用的工具不应被人为捆绑。

架构精简

架构精简是将多步骤工具交互简化为更少、更强大的操作的过程。目标是减少智能体需要做出的决策数量，同时保持系统的完整能力。通过将复杂工作流封装到单一工具调用中，可以显著降低智能体出错的概率，提升整体系统可靠性。