企业官网建设流程全解析

上个月我做了个挺作死的决定：把 47 个 AI 工具塞进一个小程序里，让大模型自己挑着用。

结果不出意外地翻了车。用户问"帮我写个周报"，Agent 先调了思维导图工具，又摸了一下二维码生成器，最后试图用"人生进度计算器"来算 KPI——那画面，就像你把全公司 47 台机器的开关面板交给一个实习生，让他"看着开"。

折腾了一个多月，我算是把"Agent 选错工具"这件事的根因摸透了。今天这篇，咱们就把这层窗户纸捅破——为什么工具挂得越多，Agent 反而越笨，以及怎么治。

先看三组扎眼的数：工具多到什么程度会翻车

别急着看我的案例，先看看这个领域的三个实测数据，你就知道我不是一个人在翻车：

1. 上下文被工具定义吃掉七成

有工程师做过实测：往 Agent 里挂了 172 个 MCP 工具，光工具定义就烧掉14.1 万 Token——20 万的上下文窗口，70% 没干正事，全花在"背说明书"上了。留给模型真正理解你任务的空间，只剩三成。【数据源1】

这就好比你给新员工发了一本 500 页的操作手册，规定：上岗前先全背下来。背完了，脑子也满了，活儿反而不会干了。

2. 工具超过 20 个，选对率不到一半

Alpic 的基准测试给出了更狠的结论：当工具数量超过20 个，Agent 选对工具的概率低于 50%。注意，这不是模型不行——换个更强的模型，正确率提升非常有限。问题出在"货架上东西太多"，而不是"顾客眼神不好"。【数据源2】

3. 同一个操作，MCP 比 CLI 多花 4~32 倍 Token

有团队对比过：让 Agent 干同一件事，走 MCP 比走命令行多烧4 到 32 倍的 Token。差在哪？43 个工具定义全量塞进上下文，实际只用到一两个。【数据源3】

业界现在的经验法则很一致：同时挂 10~15 个工具，就到头了。

而我，挂了 47 个。所以翻车翻得如此标准、如此有理论依据。

为什么工具一多，Agent 就"手忙脚乱"

翻车之后我去翻了资料，发现这事在学界和工程界早有定性，两个词：膨胀（bloat）和混淆（confusion）。

膨胀：还没干活，先把内存背满了

MCP 的机制是：任务开始前，所有已连接的工具定义预先倾倒进模型上下文。不管这次任务用不用得上，先塞为敬。

你想想这个场景：你只是想让秘书帮你订个机票，结果他先把公司通讯录、财务制度、打印机使用规范、消防逃生路线全部背了一遍——"以防万一"。

Token 是有限的，注意力也是有限的。上下文被无关工具定义塞满后，模型的推理能力肉眼可见地下降——学术点的说法叫"context dilution"（上下文稀释），人话就是：脑子里的杂物太多，正事反而想不清了。

混淆：不是不听话，是真分不清

第二个问题更隐蔽：工具一多，语义边界就开始打架。

• "文章生成器"和"文案优化器"，改一段营销文案该用哪个？
• "数据提取"和"格式转换"，把 JSON 转成表格算哪类？

工具之间的功能重叠度越高、命名越相近，Agent 的选择就越像掷骰子。更糟的是：选错之后它会重试，重试又烧一遍 Token，膨胀和混淆互相喂，形成恶性循环。【数据源4】

我那 47 个工具里，光"处理文本"的就有 6 个。用户看着是"功能丰富"，Agent 看着是"六个长得差不多的门，随便进一个吧"。

我的解法：不换模型，换货架

道理搞明白之后，解决思路反而简单了——问题不在模型，在货架的摆法。

第一刀：把"全量供应"改成"按需上菜"

原来我的做法是把 47 个工具一股脑挂在系统里。改版后：

• 入口层只保留 8~10 个高频工具，直接暴露给模型
• 其余的收进"工具仓库"，模型遇到匹配不上的任务时，通过一个检索接口按需加载——你要用什么，再拿什么

这个思路其实就是业界说的Tool Search / 渐进式加载（progressive disclosure）。前面那位烧掉 14.1 万 Token 的工程师实测：开启 Tool Search 后，172 个工具的初始消耗降到0，实际执行任务时也只花了 2600 Token——降了 50 多倍。【数据源1】

第二刀：给工具写"岗位说明书"，而不是"产品说明书"

工具的 description 是写给模型看的，但很多人（包括改版前的我）写的是给人类看的产品文案。

改法：每个工具的描述里明确三件事——

1.什么场景用我（触发条件）

2.什么场景别用我（排除条件，这条最省心）

3.和其他相近工具的边界（"改写已有内容找我；从零创作找写作器"）

第三条是关键。工具之间的边界，得由你亲手划清楚，不能指望模型自己悟。

第三刀：小模型干杂活，大模型干正事

47 个工具里，一大半是"格式转换""内容提取"这类确定性任务。这类活儿交给旗舰模型，属于杀鸡用牛刀——而且牛刀还经常砍偏。

改版后的路由逻辑：

• 分类、摘要、格式转换 →轻量模型（快、便宜、够用）
• 多步推理、内容创作、复杂决策 →主模型
• 这样一刀切下去，杂活儿的成本和延迟都立竿见影地降了下来——毕竟轻量模型跑格式转换，属于杀鸡用了合适的刀。

效果与遗留问题

改版之后，工具误选的情况肉眼可见地少了。最直观的感受是：以前要盯着它有没有"摸错门"，现在基本不用管了。

但我不想把话说满，还有两个遗留问题：

1.检索式加载多了一跳：按需取工具意味着多一次往返，简单任务反而变慢了一点点。这是"省 Token"和"省时间"的 trade-off，我目前对高频工具做了白名单直连来缓解。

2.工具越多，维护描述的成本越高：47 个工具的"岗位说明书"是活文档，新增工具、调整边界都要同步改。工具治理不是一次性工程，是持续运营。

写在最后

这段时间最大的感触是：Agent 时代的产品设计，一半在设计 AI，一半在设计 AI 看到的世界。

模型能力再强，你递给它的如果是 47 个搅在一起的线头，它也只能揪出一根错的。上下文工程（Context Engineering）这个东西，说玄不玄——本质就是给模型一个整洁的工位。

工具不是挂得越多越强。就像团队不是人越多越能打，清晰的分工才是战斗力的来源。

如果你也在做 Agent 类产品，不妨先数数你挂了多少工具——超过 15 个，就该考虑收一收货架了。

---

*数据来源：*

• *【数据源1】Jeff Butts 实测：172 工具消耗 14.1 万 Token；开启 Tool Search 后降至 2.6 千（Yahoo 科技报道，2026-09）*
• *【数据源2】Alpic 基准测试：20+ 工具时选对率 <50%（Agent Community 周报，2026-09）*
• *【数据源3】Chico Gong《MCP 生态这半年》：同一操作 MCP 比 CLI 多花 4~32 倍 Token（2026-09）*
• *【数据源4】AWS《MCP 工具设计：实用方法与权衡取舍》：膨胀与混淆两大问题（2026）*