如何为一个 Agent 设计一个有效的工具集

如何为一个 Agent 设计一个有效的工具集

1️⃣ 考察意图

面试官想看你的工具设计哲学——不是"能加多少工具"而是"如何让 Agent 高效地选择和使用工具"。刁钻点在于：很多人只答"工具要原子化"，但说不清工具描述怎么写、工具数量太多时怎么办、以及如何防止工具误调用。答好了能展示你的 API 设计 + prompt engineering 的综合能力。

2️⃣ 标准答

工具集设计遵循"原子化、清晰描述、负向约束、动态加载"四原则。

1. 工具原子化（Atomic Design）

每个工具只做一件事，职责单一：

• ✅ read_file(path) + write_file(path, content) + delete_file(path) （3 个原子工具）
• ❌ manage_file(action, path, content) （1 个复合工具，action 有 read/write/delete）

原子化的好处：(1) Agent 更容易选择——"我要读文件"直接选 read_file，而非在 manage_file 的 action 参数中选；(2) 权限控制更精细——可以只给 Agent read_file 权限而不给 delete_file；(3) 错误隔离——read_file 失败不影响 write_file

例外：高频组合操作可以封装为复合工具。如 search_and_summarize(query) = search(query) + summarize(results)，每次都一起调用，封装后减少一轮 LLM 推理（省 2000 tokens）。

2. 工具描述（Tool Description）

工具描述是 Agent 选择工具的唯一依据，必须包含：

{ "name": "read_file", "description": "读取指定路径的文件内容。支持文本文件（.txt, .md, .py, .json等），不支持二进制文件（.png, .pdf等）。最大读取 1MB。路径必须是绝对路径（如 /workspace/data.txt）。", "parameters": { "path": { "type": "string", "description": "文件的绝对路径，如 /workspace/report.md", "pattern": "^/workspace/", // 限制只能读 workspace 目录 "maxLength": 200 } }, "returns": "文件内容字符串。如果文件不存在返回错误。", "examples": [ {"path": "/workspace/data.txt"} // 正确用法 ], "negative_examples": [ {"path": "/etc/passwd"} // 错误：不在 workspace 目录 ] }描述设计要点：

• 功能边界明确："支持文本文件，不支持二进制"——让 Agent 知道什么时候不该用
• 参数约束：pattern 正则限制路径范围，maxLength 防止超长输入
• 正反例：positive example 告诉 Agent 怎么用，negative example 告诉 Agent 不能怎么用
• 返回值说明：Agent 需要知道返回什么格式才能正确处理

3. 负向约束（Negative Constraints）

在工具描述或 system prompt 中明确"什么时候不能调用"：

• "不要在未读取文件内容的情况下调用 write_file 覆盖文件"
• "不要在循环中连续调用 send_email 超过 3 次"
• "不要用 execute_code 执行涉及网络请求的代码，网络请求用 http_get 工具"

负向约束比正向描述更有效——LLM 对"不要做X"的理解比对"只做Y"更准确（因为"只做Y"隐含"不做Z"，但 LLM 可能推断不到）。

4. 工具数量管理

Agent 可用工具过多（>20 个）会导致选择困难——LLM 需要在 20+ 个工具描述中选对，准确率下降 30%。

解决方案：

• 动态加载：根据当前任务阶段只暴露相关工具。如"编码阶段"只暴露 read_file/write_file/execute_code/run_tests，"测试阶段"才暴露 run_tests/check_coverage/generate_report
• 工具分组：将工具按类别组织（File类/Network类/Code类），先让 Agent 选类别再选具体工具
• 工具路由：用一个轻量 LLM 先做工具选择（"这个请求需要哪个工具？"），再调用主 LLM 执行

5. 工具版本管理

工具 API 变更时需要向后兼容：

• 版本号：read_file_v2（新版）与 read_file（旧版）共存
• 废弃策略：旧版标记 deprecated，Agent 调用时返回 warning，3 个月后移除
• 参数迁移：新参数有默认值，旧调用方式仍然有效

3️⃣ 答题模板（30 秒电梯版）

"工具集设计四原则：原子化——每个工具只做一件事，职责单一，便于选择和权限控制。清晰描述——name+description+parameters+returns+正反例，功能边界明确。负向约束——'不要在循环中调 send_email 超 3 次'比正向描述更有效。动态加载——工具>20 个时按任务阶段只暴露相关工具，减少选择困难。版本管理——新版本共存+废弃策略+参数迁移。总结一句：好的工具集不是'工具多'而是'Agent 能选对、用对、不误调用'。"

4️⃣ 高频追问 & 应对

追问 1：工具描述写多长合适？太长会不会影响 LLM 推理？

经验值：50-150 字最佳。太短（<30 字）Agent 不知道什么时候用，太长（>300 字）占用 context window 且 LLM 可能忽略细节。优化：(1) 关键信息前置——功能描述在前，参数约束在中，异常情况在后；(2) 用 schema 而非自然语言描述参数——{"type": "string", "pattern": "^/workspace/"} 比一段文字更精确；(3) 正反例用 JSON 而非文字——{"example": {"path": "/workspace/data.txt"}} 比"例如读取 /workspace/data.txt"更清晰。

追问 2：Agent 选错了工具怎么办？比如该用 read_file 却调用了 write_file？

三层防御：(1) 参数校验——write_file 要求 content 参数，如果 Agent 只传了 path 没传 content，工具层直接返回错误"缺少 content 参数"。Agent 收到错误后通常会自动修正；(2) 操作预览——write_file 执行前先返回"即将写入以下内容到 /workspace/data.txt，确认？"等待 Agent 确认。类似 Human-in-the-Loop 但由 LLM 自己确认；(3) 回滚机制——write_file 执行前备份原文件，如果后续发现错误可以 undo_write 恢复。关键设计：错误信息要具体——"write_file 需要两个参数：path 和 content，你只提供了 path"比"参数错误"更能帮助 Agent 修正。

追问 3：自定义工具和 MCP（Model Context Protocol）工具怎么共存？

共存方案：(1) 统一接口——自定义工具和 MCP 工具都实现相同的 Tool 接口（name/description/parameters/execute），Agent 不需要知道工具来源；(2) 优先级——同名工具时自定义工具优先（避免 MCP 工具覆盖内部逻辑）；(3) 隔离执行——MCP 工具在独立进程中执行（安全隔离），自定义工具在主进程中执行（性能优先）。MCP 的优势是生态——可以直接用第三方提供的工具（如 GitHub MCP、Slack MCP），不需要自己实现。劣势是延迟——IPC 通信增加 5-20ms。

5️⃣ 避坑 · 常见错误答法

• ❌ "给 Agent 越多工具越好，功能更全" → ✅ "工具过多导致选择困难，准确率下降 30%。应该按任务阶段动态加载工具，保持可用工具在 5-10 个。"
• ❌ "工具描述简单点就行，Agent 能理解" → ✅ "工具描述是 Agent 选择工具的唯一依据。缺少功能边界、参数约束、正反例的描述会导致误选择。50-150 字的精确描述比一句话的模糊描述效果好 3 倍。"
• ❌ "工具调用失败就返回 'error'" → ✅ "错误信息要具体可操作——'file not found at /workspace/data.txt, please check the path'比'error'更能帮助 Agent 修正。好的错误信息能把重试成功率从 40% 提升到 80%。"

6️⃣ 简历呼应

• 如果你有 Agent 工具开发经验：从"工具集设计优化"切入，描述你如何通过工具原子化、描述优化、动态加载将工具选择准确率从 75% 提升到 92%
• 如果你只做过 API 设计：用"API 设计原则迁移"切入，说明 RESTful API 的设计原则（单一职责、清晰文档、版本管理）直接适用于 Agent 工具设计
• 如果你是校招无项目：为 LangChain Agent 设计一个 10 工具的工具集，对比"无描述/简单描述/详细描述+正反例"三种情况下的工具选择准确率，写一篇博客
• "Toolformer: Language Models Can Teach Themselves to Use Tools" (Schick et al., 2023)
• "MCP: Model Context Protocol Specification" (Anthropic, 2024)
• "Designing Effective Tool Interfaces for LLM Agents" (Ji et al., 2024)