我给 AI Agent 配了三十多个工具想让它无所不能,结果它反而经常选错工具、在几个功能相近的工具间反复横跳、甚至漏掉该用的那个,工具给得越多任务完成得越差:一次工具过载、误以为给的能力越多 Agent 越强的深度复盘

那个"Agent 越来越笨、明明该用 A 工具却去调了 B"的问题,是我一厢情愿"武装到牙齿"的结果。我做了个 AI Agent,本着"能力越全越好"的想法,给它配了三十多个工具:查用户、查订单、查库存、发通知、查日志、改配置……而且很多工具功能相近、命名相似(比如同时有 query_user、get_user_info、fetch_user_detail 几个其实差不多的)。我以为"工具越多,Agent 能干的事越多、越强"。可实际跑下来,Agent 表现不升反降:它经常选错工具(该用查订单的去调了查日志);在几个功能相近的工具间反复横跳、犹豫不决;有时漏掉了本该用的那个工具;甚至把一个简单任务绕成了一长串错误的工具调用。工具给得越多,它选对、用对的准确率反而越低。复盘这件事,我才真正想明白,后背发凉:问题出在我以为"给 Agent 的能力(工具)越多,它就越强",却忽略了"每多一个工具,都增加了 Agent '理解它、把它和别的工具区分开、判断该不该用它'的认知负担"。Agent 选工具,本质是 LLM 根据"当前任务"和"每个工具的描述",做一个"选哪个"的判断;工具一多(尤其功能重叠、描述相似时),这个判断空间就爆炸了:它要在几十个里挑、还要分辨那几个"看起来差不多"的到底有啥区别——选项越多越杂,选对的难度越大、出错率越高;而且这几十个工具的描述都塞进上下文,挤占了宝贵的上下文窗口(同 589),还可能互相干扰;我误把"提供更多能力"等同于了"Agent 更有能力"——可"拥有很多工具"和"能在对的时候选对工具"是两回事,后者才是真正的"能力",而前者过头了反而损害后者。根本原因是:工具过多(尤其功能重叠、命名相似)会让 Agent 的工具选择判断空间爆炸、难以区分、出错率上升,还挤占上下文;而我误以为"给的工具越多 Agent 越强",忽视了每个工具都有认知/选择成本,过载反而降低了它选对用对的能力。问题的根,是工具过载——给 Agent 配了太多功能重叠的工具,使其选择困难、选错率上升、上下文被挤占;根源是误把"提供更多能力"当成"Agent 更强",忽视了选项的认知成本。这篇就把这次"工具过载"的坑,从头到尾复盘一遍。

故障现场:工具越多,选得越差

问题在于工具过多、功能重叠,Agent 选择困惑:

# 我给 Agent 配的工具(三十多个, 还有一堆功能相近的):
tools = [
    query_user, get_user_info, fetch_user_detail,    # ✗ 三个差不多的查用户!Agent该选哪个?
    query_order, get_order, list_orders, order_detail, # ✗ 四个相近的查订单
    check_inventory, get_stock, query_warehouse,       # ✗ 三个相近的查库存
    send_notification, push_message, notify_user,      # ✗ 三个相近的发通知
    ... # 还有二十多个
]
agent = Agent(model, tools=tools)   # 一股脑全塞给Agent

# 实际表现(工具越多越差):
# - 该用 query_order 查订单, Agent去调了 query_log(选错);
# - 面对 query_user / get_user_info / fetch_user_detail, Agent反复横跳、调错那个;
# - 简单任务被绕成一长串错误的工具调用;
# - 偶尔干脆漏掉该用的工具, 自己"编"答案(更易幻觉, 同585)。

"""
为什么工具越多反而越差:
  1. 选择空间爆炸: Agent选工具 = LLM在"几十个工具描述"里, 根据任务挑一个;
     选项越多, 这个判断越难、越易错(就像给人一本100页的菜单, 反而点不好菜);
  2. 功能重叠/命名相似最致命: query_user vs get_user_info —— 它俩到底啥区别?
     Agent分不清(其实你自己可能都说不清), 只能瞎猜, 选对率暴跌;
  3. 上下文挤占: 几十个工具的描述(schema)全塞进上下文, 占用大量token(同589),
     挤掉了任务本身的空间, 还互相干扰模型注意力;
  4. "拥有工具" ≠ "会用工具": 给了一堆能力, 不代表它能在对的时候选对、用对;
     真正的能力是"在合适的时机, 准确地选用合适的工具", 工具过载恰恰损害这个。

★ 核心: 给Agent的工具不是越多越好; 每个工具都增加"理解、区分、选择"的认知成本;
  工具过多(尤其重叠、相似)→ 选择空间爆炸、难区分、出错率升、挤占上下文 → Agent反而变笨。
  少而精、职责清晰、不重叠的工具集, 远胜又多又杂的"全家桶"。
"""

看着 Agent 对着三十多个工具"选择困难"、把简单任务办砸,我又懊恼又恍然:"我一心想着'给它越多工具它越能干',疯狂做加法……谁知道工具一多、还净是些功能差不多的,它反而挑花了眼、越选越错。原来'给它很多工具'和'它会在对的时候用对工具',根本是两码事。"这个坑最反直觉的地方在于:它违背了"能力越多越强"的朴素直觉;"多给工具"是一种"看起来很负责、很慷慨"的做法(我可是把所有能力都给它了!);而它的危害——选择过载、出错率上升——是隐性的、需要观察 Agent 的实际表现才能发现;人们容易"不断加工具",却很少想到"该减工具"。下面就来拆解,Agent 的工具集到底该怎么设计。

第一件事:搞懂工具过载与"少即是多"

我顺着这次事故,把 Agent 工具集的设计原则彻底理清了。

为什么工具不是越多越好? 工具集该怎么设计?

【核心: 每个工具都增加Agent"理解/区分/选择"的认知成本; 工具过多(尤其重叠相似)会让选择空间爆炸、
   难区分、出错率升、挤占上下文; 少而精、职责清晰不重叠、按需提供、必要时工具检索——少即是多】

1. Agent选工具的本质 = 一次"判断/决策":
   - LLM根据"当前任务"和"每个工具的描述", 判断该调用哪个(及参数);
   - 这是个"在候选里选一个"的决策, 候选越多越杂, 决策越难、越易错。

2. 工具过多的危害:
   - 选择空间爆炸: 几十个里挑一个, 难度大、出错率高(选择悖论);
   - 重叠/相似最致命: 功能相近、命名相似的工具, Agent(甚至你)都分不清区别, 只能瞎选;
   - 挤占上下文: 工具描述全塞进上下文, 占大量token(同589), 挤掉任务空间、干扰注意力;
   - 维护/认知成本: 工具越多, 你和Agent都越难掌控这个工具集。

3. "拥有工具" ≠ "会用工具":
   - 真正的能力 = "在合适时机准确选用合适工具", 不是"拥有一大堆工具";
   - 工具过载恰恰损害"选对用对"的能力——给的能力多, 发挥出来的能力反而少。

4. 工具集设计原则(少即是多):
   ① 精简: 只给"完成目标任务真正需要"的工具, 别求大求全;
   ② 职责清晰、不重叠: 一个能力一个工具, 别搞 query_user/get_user_info 这种重复; 合并相似的;
   ③ 命名和描述要"高区分度": 让Agent一眼能分清各工具的边界和适用场景(同529: 描述要清晰);
   ④ 按需/分层提供: 任务A只暴露A需要的工具子集; 复杂场景用"工具检索"(根据任务动态
      检索出最相关的几个工具放进上下文, 而非一次全给), 或分层(高层工具内部封装细节);
   ⑤ 适度抽象: 与其给十个细粒度小工具, 不如给一个"管这件事"的合适粒度工具(内部自己编排);
   ⑥ 用真实任务评测: 看Agent在工具集下选对、用对、完成任务的准确率, 据此增删工具。

5. 本质: 给决策者的"选项/能力", 有边际认知成本, 不是越多越好
   - 每多一个选项, 决策者要多花"理解它、和别的区分、判断该不该用"的认知;
   - 超过某点, 新增能力的收益 < 选择和区分的认知负担, 整体效能下降;
   - "少而精、边界清晰"往往胜过"多而杂"——对Agent如此, 对人也如此。

一句话: 工具不是越多越好, 每个都有认知/选择成本; 过多(尤其重叠相似)会让选择爆炸、难区分、出错升、
   挤上下文; 要精简、职责清晰不重叠、描述高区分度、按需提供/工具检索、适度抽象——少即是多。

这套认知,是整个坑的根。选工具的本质:LLM 在候选工具里做一次"选哪个"的决策,候选越多越杂越难、越易错。工具过多的危害:选择空间爆炸、重叠相似难区分、挤占上下文、维护认知成本高。拥有≠会用:真正的能力是"合适时机准确选用合适工具",工具过载损害"选对用对"——给的多、发挥的少。设计原则:精简、职责清晰不重叠、命名描述高区分度、按需/分层提供、工具检索、适度抽象、用真实任务评测增删。本质:给决策者的选项有边际认知成本、不是越多越好,超过某点新增收益<认知负担,少而精胜过多而杂。一句话:工具不是越多越好,每个都有认知/选择成本;过多(尤其重叠相似)会让选择爆炸、难区分、出错升、挤上下文;要精简、职责清晰不重叠、描述高区分度、按需提供/工具检索、适度抽象——少即是多。

第二件事:正解——精简工具集、按需提供、工具检索

知道了工具过载的危害,正解就清楚了:给 Agent 少而精、职责清晰的工具,按需提供。

# 正解1: 合并重叠工具, 一个能力一个工具(职责清晰不重叠)——本次该做的
# ✗ 过载: query_user / get_user_info / fetch_user_detail (三个差不多)
# ✓ 合并成一个, 用参数区分细节:
def get_user(user_id: str, fields: list[str] = None) -> dict:
    """查询用户信息。fields指定返回哪些字段, 不传则返回基本信息。"""
    ...
# 一个清晰的工具, 胜过三个让Agent犯迷糊的相似工具。

# 正解2: 只给"当前任务真正需要"的工具子集(按需提供)
# 不要把"系统所有能力"一股脑全给; 按Agent的职责/当前任务, 只暴露相关的几个:
order_agent = Agent(model, tools=[get_order, create_order, cancel_order])  # 只给订单相关
# 而非把查日志、改配置、发通知等无关工具也塞给它。

# 正解3: 工具多时用"工具检索"(动态选出最相关的几个放进上下文)
def select_tools(task: str, all_tools: list, top_k: int = 5) -> list:
    # 用向量检索/分类, 根据当前任务, 从全部工具里挑出最相关的top_k个;
    # 只把这几个的描述放进上下文, 而非一次性把几十个全塞(同589思想: 按需、精炼);
    return retrieve_relevant_tools(task, all_tools, top_k)
# Agent每轮只面对"和当前任务相关的少数几个工具", 选择压力小、准确率高。

# 正解4: 适度抽象 —— 高层工具封装细节, 别暴露一堆细粒度小工具
# ✗ 给十个: db_connect / db_query / db_format / db_close ...(让Agent自己编排, 易错)
# ✓ 给一个: query_business_data(question) —— 内部自己连库/查询/格式化, Agent只管"要什么"
# 把"怎么做"的细节封装进工具内部, Agent在更高的抽象层决策, 选择更简单、更不易错。

# 正解5: 命名和描述高区分度(同529), 让Agent能一眼分清
#   - 工具名体现"用在什么场景": get_order_by_id vs search_orders_by_filter(一看就知道何时用哪个);
#   - 描述写清"何时该用我、何时不该用我", 减少混淆。

# 正解6: 用真实任务评测, 据此增删工具
#   - 看Agent在一组真实任务上"选对工具、完成任务"的准确率;
#   - 加了某工具准确率反降, 就该删/合并; 让工具集"小而准", 而非"大而全"。

# 核心: 工具集要少而精——合并重叠、一个能力一个工具、按需提供子集、工具多时动态检索、适度抽象、
#   命名描述高区分度、用真实任务评测增删; 别求大求全, 给Agent"刚好够用且清晰"的工具。

这套正解的关键,是给 Agent"刚好够用、职责清晰"的工具,而非"大而全"的全家桶。合并重叠工具:一个能力一个工具、用参数区分细节,别搞三个差不多的——这正是本次的祸根。按需提供子集:按 Agent 职责/任务只暴露相关工具,别一股脑全给。工具检索:工具多时根据当前任务动态选出最相关的几个放进上下文(同 589 思想)。适度抽象:高层工具封装细节,Agent 在更高层决策、选择更简单。命名描述高区分度 + 真实任务评测:让 Agent 一眼分清,加了反降准确率的工具就删/合并。

第三件事:其他几个"做加法过头反而更糟"的坑

顺着这次工具过载,我把"一味做加法、忽视其代价"的几类坑也一并理了:

几类"做加法过头反而更糟"的坑(核心都是"加法有代价, 少即是多"):

坑1: 给用户的功能/选项太多——产品堆砌一堆功能, 用户反而找不到、不会用(选择悖论);
   正解: 聚焦核心、合理收纳, 别什么都往界面上堆。

坑2: 配置项太多——为"灵活"加无数配置, 结果没人搞得清该配啥(同598过度配置);
   正解: 合理默认 + 少量关键配置。

坑3: 依赖/库引入太多——为省事引一堆库, 体积大、冲突多、维护和安全负担重;
   正解: 按需引入, 评估每个依赖的代价。

坑4: 给提示词塞太多指令/示例——prompt里规则越堆越多, 模型反而抓不住重点、互相打架;
   正解: 精炼关键指令, 别什么都往prompt里塞(同573上下文)。

坑5: 给人/团队的目标/KPI太多——目标一多就没重点, 什么都想抓结果什么都抓不好;
   正解: 聚焦少数关键目标。

坑6: 抽象层/中间层太多——为"灵活"加一堆层, 调用绕、理解难(同598过度设计);
   正解: 必要的抽象, 别过度。

共同的根: "增加(能力、选项、功能、配置、指令)"几乎总被视为"更好、更强、更负责";
   但每一次增加, 都有它的代价(认知成本、选择成本、维护成本、注意力分散);
   超过某个点, 加法的收益 < 它的代价, 整体反而变差; "做减法、保持精简、聚焦关键"
   常常比"不断做加法"更需要智慧, 也更有效——少即是多(less is more)。

这些坑看似不同,根却是同一个:"增加(能力、选项、功能、指令)"几乎总被视为"更好、更强、更负责";但每一次增加都有代价(认知/选择/维护/注意力成本);超过某点,加法的收益 < 它的代价,整体反而变差——"做减法、保持精简、聚焦关键"常常比"不断做加法"更有效。认清这个根("加法有代价、少即是多"),才不会陷入"不停堆砌、越堆越糟"的陷阱。

第四件事:工具过载 vs 精简 / 设计要点——两张对照表

我把工具过载和精简工具集的对比、以及设计要点,整理成对照表,贴在了团队的 Agent 开发规范里:

这两张表的核心,第一张是精简工具集在"选对率、完成率"上全面优于过载——更多工具不等于更强,常常更弱;第二张是设计要点都指向"少而精、清晰、按需"。记住一条:给 Agent 加工具前,先问"这个工具和已有的重叠吗?加了它,Agent 选对工具的准确率会升还是降?"

第五件事:关于 Agent 工具集的几组容易想当然的认知

这次事故也让我厘清了几组关于 Agent 工具的、容易想当然的概念:

这张表里,我栽的是第一行和第二行:抱着"工具越多越强、有备无患"的想法疯狂加工具,没意识到每个工具都在增加 Agent 的选择负担,最终把它搞得选择困难、越用越差。厘清这些,核心是一个意识:Agent 的能力,不在于"它拥有多少工具",而在于"它能不能在对的时候选对、用对工具";给工具是做加法,但加法有边际成本,过了甜点区就会损害选择质量;给 Agent(以及任何决策者)工具/选项,要"少而精、清晰、按需",而非"多多益善"。

第六件事:给 Agent 配工具时,我现在的自检习惯

现在每当我要给 Agent 加一个工具,我都会先按这张图问自己:

这张图的精髓,是"重叠就合并、不需要就别加、太多用检索、加完用真实任务评测"。先问是否重叠(重叠就合并)、当前任务是否需要、总数会不会太多、描述能否分清、最后评测选对率。这套习惯,让我从"疯狂给 Agent 加工具"变成了"克制地给少而精的工具"——核心始终是:工具不是越多越好、每个都有认知成本;过多会让选择爆炸、难区分、出错升、挤上下文;要精简、职责清晰不重叠、按需提供/检索、适度抽象——少即是多。

我立下的几条规矩

这场"工具给太多反而把 Agent 搞笨"的事故,换来了我做 AI Agent 时,刻进骨子里的几条铁律:

1. 给 Agent 的工具不是越多越好;每个工具都增加它"理解、区分、选择"的认知成本。
2. 工具过多(尤其功能重叠、命名相似)会让选择空间爆炸、难区分、选错率上升、挤占上下文。
3. "拥有很多工具"≠"会在对的时候选对用对工具";后者才是真能力,过载损害它。
4. 合并功能重叠的工具:一个能力一个工具,用参数区分细节。
5. 按需提供:只给当前任务相关的工具子集;工具多时用工具检索动态选相关的几个。
6. 适度抽象(高层工具封装细节)、命名描述高区分度、让 Agent 一眼分清何时用哪个。
7. 用真实任务评测选对率增删工具;加了反降准确率的就删/合并,保持小而精。

附:一个按任务动态选工具的封装

借这次的坑,我把"工具检索"封装成了一个可复用的组件:Agent 每一步只面对"和当前任务最相关的少数几个工具",而不是几十个工具的全集。

# 工具检索: 维护全部工具, 但每次只给Agent暴露与当前任务最相关的top_k个
from dataclasses import dataclass

@dataclass
class Tool:
    name: str
    description: str
    func: callable

class ToolRegistry:
    def __init__(self, tools: list[Tool]):
        self.tools = tools
        # 预先把每个工具的描述向量化, 用于按相关性检索
        self.embeddings = {t.name: embed(t.description) for t in tools}

    def select_for_task(self, task: str, top_k: int = 5) -> list[Tool]:
        """根据当前任务, 检索出最相关的top_k个工具"""
        q = embed(task)
        ranked = sorted(self.tools, key=lambda t: -cosine(q, self.embeddings[t.name]))
        return ranked[:top_k]    # 只返回最相关的几个, 而非全部

# 用法: Agent每轮(或每个任务)只看到精选后的少数工具
registry = ToolRegistry(all_30_tools)
relevant = registry.select_for_task(current_task, top_k=5)   # 从30个里选最相关的5个
agent = Agent(model, tools=relevant)                          # Agent只面对这5个, 选得准
# 既保留了"系统拥有很多能力", 又避免了"一次把几十个全塞给Agent"的选择过载。

# 原则: "拥有很多工具"和"每次只暴露少数相关工具"可以兼得——
#   用检索把"全集"收敛成"当前最相关的小集合", 让Agent每一步都在一个"小而准"的选择空间里决策;
#   这正是 less is more 的工程化: 不是真的让系统能力变少, 而是让"每次面对的选择"变少。

这个封装的精髓,是让"系统拥有很多能力"和"Agent 每次只面对少数相关工具"兼得:全部工具仍然存在(系统能力没缩水),但通过检索,Agent 每一步都在一个"小而准"的选择空间里决策。这正是"少即是多"的工程化——不是真的削减能力,而是收敛"每次要做的选择";它和第 589 篇"按需给上下文"、第 600 篇"精确区分"一脉相承:好的系统,总是替决策者把"当下真正需要面对的东西"收敛到恰到好处。

写在最后

回头看,这场由"给 Agent 配了太多工具"引发的、它反而越用越差的事故,真正教给我的,远不止"精简工具集"这一个技巧。它让我对"'给一个行动者更多的选项/能力/资源' 和 '让它更有效', 并不是单调正相关的; 超过某个点, 选项本身的'选择与区分成本'会反过来拖累行动的质量——'更多'会变成'更乱', '武装到牙齿'会变成'挑花了眼'",有了一次刻骨的体会。我栽跟头,是因为我朴素地信奉"多 = 强"——我以为把所有能干的事都做成工具塞给 Agent, 就是给了它最大的能力;可我忽略了: "拥有一项能力" 和 "在对的时刻准确地调用这项能力" 之间, 隔着一个"选择"; 而选择是有成本的——选项越多、越相似, "选对"这件事就越难;我以为我在"增强"它, 实际我是在不断加重它"做选择"的负担, 直到这个负担压垮了它本该有的判断力——我给的是"能力的数量", 损害的却是"运用能力的质量"。这让我领悟到一个关于"多与少、能力与负担"的深刻认知:"提供更多(选项、能力、工具、信息、自由度)" 不是无代价的恩赐——每一个"多出来的东西", 都给使用它的人/系统, 增加了一份"理解它、在它和别的之间做区分和选择"的认知负担;当这份负担累积到超过"多出来的东西所带来的收益"时, "更多"就开始反噬——选择瘫痪、抓不住重点、出错率上升(从超市货架到 Agent 工具到人生选择, 皆是如此);所以"克制地提供"、"精心地做减法"、"把'少而精、清晰'当成一种设计美德", 往往比"慷慨地堆砌一切"更高级、也更有效——真正的善待一个决策者, 不是给它无穷的选项, 而是替它把选项收敛到'恰好够用且清晰'。这给了我一种"提供东西"时的克制:每当我想"多给点(工具、选项、功能、信息)总没错"时,要提醒自己"每多给一个, 接收方就要多付一份选择和区分的成本; 这一个, 真的让它更有效, 还是只是让它更难选?"——把"做减法、保持精简、收敛选项"当成和"增强能力"同等重要(甚至更难)的功课, 给出"恰好够用且清晰"而非"多多益善"的东西;"认清提供选项有边际认知成本、克制地做减法、以'少而精'善待决策者",是设计一切供他人/系统使用之物的关键智慧。认清提供更多选项不等于更有效、选项本身有选择和区分的成本、少而精常胜过多而杂——这,是我用一次 Agent 工具过载的事故,换来的、关于 AI Agent、也关于如何对待"多与少"的、最朴素也最深刻的领悟。如果这篇复盘,能让你下次想给 Agent(或给用户、给系统)"再多加一个"之前,先掂量一下这个"多"带来的选择成本,甚至反过来想想"能不能减一个",那我对着那个在三十多个工具间挑花了眼的 Agent 复盘的这段时间,就值了。

—— 别看了 · 2026