技术 · 熟练
工具不是菜单，是六种认知动作
先列动作，再填工具
给 agent 加工具的最常见做法是「按功能列菜单」：能查数据库、能读文件、能发消息、能部署…… 结果是一屏几十个工具，名字相近、描述雷同，模型挑错、连调六次才做完一件事。这一页换一种分法：先列 agent 在调查过程中会做的六种认知动作（检查一个目标 / 发现候选 / 跨证据追踪 / 成对比较 / 重复出现的组合 / 观察运行时），再看每一类里缺什么、多了什么。判据只有一句：这个工具，回答的是哪一类问题？答不上来就先别加。
方法 · 一图看懂
1
先列动作，不列功能 — 六类：inspect 检查单个目标 · search/list 发现候选 · trace 跨证据追踪 · compare 成对比较 · workflow 重复组合 · observe 运行时行为
2
把现有工具逐个归位 — 归不进任何一类的，要么是重复、要么是「组合」被当成了「原语」
3
找缺口 — 哪一类一个工具都没有（常见是 trace 与 compare），就补那一类，而不是再堆 inspect
4
原语优先，组合后置 — 只有当某个组合被反复使用、且原语确实拼不出来，才封装成 workflow 并标注它是组合结果
原理 · 为什么有效
模型选错工具，很少是因为「工具不够多」，而是因为工具之间的差别不在它要解决的问题上。按功能菜单分类时，十个工具都在回答「看看这个」，模型只能靠名字里的名词去猜；按认知动作分类时，每一个工具都对应调查链条上的一步 —— 它先知道「我现在该干什么」，再去找那一类里唯一的那个工具。这就是为什么原语要优先：原语之间的边界清楚，组合可以现场拼；把组合提前固化成工具，等于替模型做了一次它本来能做、而且做得更贴合现场的判断。
适用场景
适用：自己在给 agent 配工具 / 写 MCP server / 维护技能包的人；也适用于「工具越加越笨」的团队。⛔ 不适用：只用现成产品、不碰工具定义的人（那时该看的是权限与额度，不是工具形状）。
自测 · 5 问
你的每个工具，能一句话说清它回答六类里的哪一类吗？
有没有两个工具其实在做同一类事（只是对象不同）？
trace 与 compare 这两类，你各有几个工具（多数人是 0）？
有没有一个「组合」被做成了工具，而它的每一步原语都已经存在？
工具名能不能看出「什么时候该用它、什么时候不该用」？
怎么上手 · 验证步骤
今晚就能做：把现有工具列成一列，逐个在后面写六类里的一个词。写不出词的先标「?」，写完再数 —— 通常会发现三类挤了八成工具，另外三类是空的。第二步只做一件事：把「?」里重复的那些合并或删掉。
把工具清单交给一个不了解你系统的人（或另一个会话），只给名字和描述，让它为「查一下这个报错最早出现在哪次发布」挑一个工具 —— 挑错或挑不出，说明分类还没立起来。