为什么你的AI Agent总在”装傻”？答案藏在工具设计里
为什么你的 AI Agent 总在”装傻”？答案藏在工具设计里
最近跟不少开发者聊 Agent 开发，发现一个特别有意思的规律——很多人把 Agent 表现拉胯归咎于模型不够强，但实际上，90% 的 Agent 失败案例，根子都在工具设计，而不是模型本身。
这句话不是我说的，是今天要介绍的这个 Skill——agent-tool-builder，作者 davila7 在 SKILL.md 里写下的核心洞察：
“The LLM never sees your code. It only sees the schema and description.”
翻译过来就是：LLM 从来看不到你的代码，它只看到 Schema 和描述。
一个反直觉的事实
你花了一周写了一个功能完备的工具，结果 LLM 根本不会正确调用它。而另一个只写了 20 行代码的简单工具，LLM 用起来得心应手。
原因很简单：工具好不好用，跟代码实现关系不大，跟描述和 Schema 设计关系极大。
这个 Skill 总结了 6 大核心能力：
- tool-schema-design：设计清晰无歧义的 JSON Schema
- tool-error-handling：返回 LLM 能理解和恢复的错误
- tool-validation：验证工具输入输出
- function-calling：函数调用模式优化
- mcp-tools：MCP 协议工具支持
- agent-tools：Agent 工具链设计
三个最常见的坑
Skill 里特别点名了三类反模式，值得所有 Agent 开发者对号入座：
❌ Vague Descriptions（模糊描述）：描述写得像产品经理的需求文档，”实现用户管理功能”——LLM 根本不知道这个工具能做什么。
❌ Silent Failures（静默失败）：出错了返回空值或通用异常，LLM 以为成功了，继续往下跑，等发现的时候已经偏到姥姥家了。
❌ Too Many Tools（工具过载）：一个 Agent 配了几十个工具，LLM 光选择用哪个就要消耗大量 token，效果反而不如精简后的 5-8 个核心工具。
一个具体建议
如果你正在做 Agent 开发，试着用这个 Skill 的标准去审查你的工具：
把你的工具描述，想象成在给一个从没接触过你这个系统的人类新人写说明书——他能看懂吗？他知道什么时候该调用这个工具吗？他知道调用失败该怎么办吗？
如果答案是否，说明这个工具的设计需要重新审视了。
适合谁用
这个 Skill 主要面向：
- 正在搭建 Agent 系统、后端工程师
- 有多个 MCP 服务需要集成的开发者
- 想系统性提升 Agent 可靠性的团队
GitHub 仓库里有完整的 SKILL.md 和示例代码，可以直接作为工具设计的参考模板。
评论区
登录后可评论。