过去一年多，各类智能体产品——尤其是桌面端和编程类的——都在做同一件事：接入更多的工具。支持的协议越来越全，能挂接的服务越来越多，能力清单越来越长。在不少产品页面上，「支持多少种工具」被当作成熟的标志写了出来。
但真正用起来，感受常常相反。一个本来一句话就能问清楚的问题，智能体要先在长长的工具清单里挑一遍，判断该用哪一个、怎么串联，再一步步调用；中途任何一步走偏，最后给出的答案就变得不伦不类。相比之下，直接在对话框里问一个大模型，答案反而更快、更准。
这不是个别产品的毛病，而是这类系统共同的通病。
能力清单的竞赛
工具数量的竞争，背后有一套看起来很合理的逻辑：能力越多，能覆盖的场景越广。于是「生态」成了衡量成熟度的尺子——接了多少服务、支持多少插件、能连多少数据源，都变成宣传口径。
问题是，能力清单的长度和实际使用率之间，关系并不紧密。一个功能被列进清单，意味着它每次都要参与判断；但绝大多数能力，在绝大多数任务里都不会被用到。清单越长的系统，真正高频使用的那几项反而越容易被淹没。
工具越多，选择越难
从智能体的角度看，原因其实很直接。
每一个工具，都要先把自己的名字、用途、参数写进模型的工作空间里，模型才能知道「有这么一件工具」。工具越多，这些说明占的地方越大——而它和模型用来理解你这句话、记住上文、推敲任务的空间，是同一份额度。
额度被占走，后果是可预期的：模型要在一堆似是而非的选项里做判断，容易挑错、容易漏掉你的原始要求，也更容易在中间步骤上反复。任务链越长，误差越会叠加。一个三步就能做完的事，可能因为选错一次，往后全跟着偏。
业界给这种现象起了个名字，叫「上下文腐化」（context rot）。围绕它的公开讨论，从去年年底延续到今天，已经不再是技术圈内部的话题——它指向的是一个产品判断：能力不是越多越好，超过某个量级之后，新增的工具带来的干扰，可能大于它带来的便利。
企业要的不是工具箱，是场景方案
回到真正的工作现场，结论会更清楚。
企业里大部分活是重复而且明确的：写一篇产品文案、整理一份周报、查一位客户的历史记录、把一份数据导成图表。这些事并不需要智能体去「思考该用哪个工具」——它们需要的是把工具收起来，只留必要的几件，然后给出一条预设好的、干净的流程。
工具箱的思路是反过来做的：把所有工具摆出来，让使用者自己挑。对熟练的人来说，这像是灵活；对绝大多数要完成工作的人来说，这是噪音。工具越多，噪音越大，人越不知道从哪下手。
把选择权全交给用户，不等于灵活
真正好用的工具，应该像老司机开车——该快就快，该拐就拐，不用每次出发前先把车里所有按钮研究一遍。
现在的很多产品，把「用哪个工具」这个决定整个抛给使用者，并且称之为灵活。但用户要的从来不是选择权本身，而是把事办完。当选择被抛回来的时候，用户得到的是额外的负担，而不是更多的能力。
所以「噪音」这件事，说到底是个设计问题：该做的场景封装没有做，本该由产品替用户完成的收束，被转嫁给了用户。
我们自己的取向
花里云做企业数字平台，也对外提供 MCP 工具和开放接口。我们很清楚这套能力有多容易被拉长清单，所以在这件事上给自己定了几条线：
- 底层要全，交付要收。数据模型、接口、权限管理都在平台上备齐，能力不缺口；但交付到具体岗位、具体任务时，只给这一件事需要的那几件工具。
- 按场景组合，而不是按能力罗列。内容生产、数据查询、客户跟进这类高频工作，各自对应一套确定的通路，打开就能用，不需要先学怎么用。
- 只读与写入分开，权限按人分配。能查的和能改的不混在一起，既降低判断成本，也降低误操作的风险。
- 让工具数量保持克制。每增加一个能力，先问它能不能被收进已有的场景里；收不进去的，宁可不加。
这套想法并不新鲜，它只是把一件事说清楚：企业不需要一个什么都能做的助手，需要的是把手头这件事做利落的助手。
写在最后
技术最好的样子，是让人感觉不到它的存在。用户不需要知道背后接了多少工具、串了多少步，只需要把事做完。
对企业服务来说，尤其如此。少即是多，场景为王——这不是一句口号，而是一条要落到产品结构里的原则。