AI Agent 接入工具越多越好吗?Anthropic 这篇文章讲清楚了一个关键问题

过去我们谈 AI Agent，常常会强调一句话：

智能体不只是会聊天，它还能调用工具。

比如，它可以读取文档、搜索资料、查询数据库、调用 API、操作表格、运行代码，甚至自动完成一整套业务流程。

这听起来很美好。

于是，很多人会自然产生一个想法：

既然工具越多，Agent 能做的事情就越多，那是不是应该给它接入尽可能多的工具？

比如：

接入 Google Drive；
接入 Slack；
接入 GitHub；
接入数据库；
接入企业知识库；
接入 CRM 系统；
接入代码仓库；
接入搜索引擎；
接入各种内部 API。

表面上看，这样的 Agent 似乎会越来越强。

但 Anthropic 在一篇工程博客中提醒我们：事情没有那么简单。

当 AI Agent 接入的工具越来越多时，一个非常现实的问题就会出现：

工具太多，也会把 AI“撑坏”。

更准确地说，是把模型的上下文窗口、推理成本和执行效率撑爆。

这篇文章讨论的核心问题是：

当一个 AI Agent 需要调用大量外部工具时，如何让它既高效，又省 token，还更安全？

Anthropic 给出的答案是：

不要把所有工具说明和中间数据都塞进模型上下文，而是让 Agent 通过代码执行环境去调用 MCP 工具。

这听起来有点技术化，我们下面用通俗语言展开讲。

一、MCP 是什么？可以理解为 AI Agent 的“工具插座”

要理解这篇文章，首先要知道 MCP 是什么。

MCP 的全称是 Model Context Protocol，可以简单理解为一种让 AI Agent 连接外部工具和数据源的协议。

如果把大模型比作“大脑”，那么 MCP 就像是一排标准化插座。

通过这些插座，AI 可以连接各种外部系统。

例如：

连接网盘，读取文档；
连接数据库，查询数据；
连接 Slack，读取团队消息；
连接 GitHub，查看代码和 Issue；
连接 CRM，查询客户信息；
连接企业知识库，查找内部资料。

有了 MCP，AI Agent 不再只是“脑子里想”，而是可以真正“动手做事”。

这也是现代 AI Agent 和普通聊天机器人的重要区别。

普通聊天机器人更多是回答问题。

而 Agent 可以：

理解任务 → 选择工具 → 调用工具 → 读取结果 → 继续执行。

这就是智能体的核心能力。

二、问题来了：工具越多，AI 越容易“看不过来”

既然 MCP 能让 Agent 连接工具，那是不是工具接得越多越好？

不一定。

因为每个工具在被 AI 使用前，都需要让模型知道：

这个工具叫什么；
它能做什么；
需要哪些参数；
返回什么结果；
什么情况下应该调用它。

这些内容通常会被写进工具说明里，并放进模型的上下文中。

工具少的时候，问题不大。

比如你只给 Agent 三五个工具：

读取文件；
搜索文档；
运行命令；
写入文件。

模型很容易理解。

但如果你给 Agent 接入几十个、几百个，甚至上千个工具，问题就出现了。

模型每次执行任务前，都可能要“看一遍”大量工具说明。

这就像你让一个人完成一个简单任务，却先塞给他一本几百页的工具说明书。

他当然可以看，但效率会非常低。

对于大模型来说，这会带来几个问题：

第一，token 消耗变大。

第二，响应速度变慢。

第三，上下文窗口被大量工具说明占用。

第四，模型更容易混淆工具。

第五，真正重要的任务信息反而被淹没。

所以，工具越多，并不一定代表 Agent 越强。

如果工具管理方式不合理，工具越多，Agent 反而越笨重。

三、传统工具调用方式为什么会浪费大量 token？

我们可以用一个简单例子来理解。

假设你让 Agent 做这样一件事：

“请从 Google Drive 里读取会议纪要，然后把其中的客户需求整理到 Salesforce 里。”

传统方式下，Agent 可能会这样工作：

第一步，模型读取 Google Drive 工具说明。

第二步，模型调用 Google Drive 工具。

第三步，Google Drive 返回一大段会议纪要。

第四步，这一大段会议纪要被放进模型上下文。

第五步，模型读取 Salesforce 工具说明。

第六步，模型调用 Salesforce 工具。

第七步，把整理后的内容写入 Salesforce。

看起来流程很正常。

但问题在于：

中间数据会反复进入模型上下文。

比如会议纪要很长，可能有几千字甚至几万字。

如果每次工具调用都把这些内容完整塞进上下文，token 消耗会迅速增加。

更糟糕的是，有些数据其实并不需要模型全部阅读。

比如会议纪要中有很多寒暄、背景、重复讨论、无关内容。

真正有用的可能只是其中几条客户需求。

如果把全部内容都交给模型处理，就像是让一个人为了找一句话，把整本书都读一遍。

这显然不够高效。

四、Anthropic 的思路：让 Agent 通过代码去调用工具

Anthropic 在文章中提出了一个很有启发性的思路：

与其让模型直接调用所有工具，不如让 Agent 写代码，通过代码执行环境去调用 MCP 工具。

这句话听起来有点抽象，我们换一个说法：

不要让大模型每次都亲自“阅读全部工具说明”和“搬运全部数据”。

而是给它一个代码执行环境，让它像程序员一样写代码。

它可以在代码里：

按需查找工具；
调用需要的 API；
过滤无关数据；
提取关键字段；
对数据进行聚合；
保存中间结果；
只把最终有价值的信息返回给模型。

这样一来，模型不需要每一步都吞下全部原始数据。

大量机械性处理可以交给代码执行环境完成。

模型只负责判断：

当前任务需要什么；
应该调用哪个工具；
结果是否符合目标；
下一步该怎么做。

这就是“Code Execution + MCP”的核心思想。

五、一个通俗比喻：不要让老板亲自搬仓库

我们可以用一个办公室场景来类比。

假设老板需要知道：

“过去一个月客户反馈中，最常见的三个问题是什么？”

公司仓库里有一大堆资料：

客户邮件；
会议纪要；
工单记录；
销售备注；
售后反馈。

一种低效做法是：

把所有资料都打印出来，堆到老板桌上，让老板自己一页一页看。

这就像把所有工具结果都塞进模型上下文。

另一种高效做法是：

让助理先把资料分类、筛选、统计、提炼，然后只给老板一页总结。

这就像让代码执行环境先处理数据，再把结果交给模型。

老板真正需要的是最终判断，而不是亲自搬运所有资料。

大模型也是一样。

它适合做理解、推理、决策和总结。

但大规模筛选、循环处理、数据聚合、字段转换这些事情，代码更擅长。

所以，好的 Agent 系统不是让模型什么都亲自干，而是要合理分工：

模型负责思考，代码负责执行。

六、大数据不要直接塞给模型，要先过滤

这篇文章里一个非常重要的观点是：

大数据不要直接进入模型上下文。

例如，一个 Agent 需要处理一个包含 10000 行记录的表格。

如果直接把 10000 行全部塞给模型，不仅 token 消耗巨大，而且模型也未必能稳定处理。

更合理的方式是：

先在代码执行环境中完成筛选。

比如：

只保留最近 30 天的数据；
只提取某个字段；
只统计异常记录；
只筛选金额超过某个阈值的项目；
只返回前 10 条最相关结果。

然后再把这些精简后的结果交给模型。

这样做有三个好处。

第一，省 token。

第二，速度更快。

第三，结果更准确。

因为模型看到的是高度相关的信息，而不是一堆杂乱的原始数据。

这对企业知识库、科研文献分析、代码仓库分析、销售数据整理、自动化办公等场景都非常重要。

七、复杂流程交给代码，而不是让模型一步步“硬想”

有些任务本身包含复杂的控制流程。

例如：

循环处理多个文件；
判断不同条件；
遇到错误后重试；
等待某个任务完成；
对大量数据做统计；
调用多个系统并合并结果。

这些事情，其实是代码非常擅长的。

但如果全部交给模型来一步步决定，就会变成很长的 Agent 循环：

模型思考一次，调用一个工具。

工具返回结果，模型再思考一次。

再调用另一个工具。

再返回结果。

再思考。

这样做不仅慢，而且 token 消耗很大。

Anthropic 的建议是：

对于复杂控制流，可以让 Agent 写一段代码来完成。

比如，让代码完成循环、筛选、重试、聚合和保存。

模型只需要查看最终结果，决定下一步。

这就像让一个人用 Excel 函数或 Python 脚本处理数据，而不是手工一行一行算。

效率差别非常明显。

八、为什么这样做也更安全？

这篇文章还提到一个容易被忽视的好处：

通过代码执行环境处理中间数据，可以减少敏感信息进入模型上下文的机会。

比如，一个企业 Agent 需要处理客户资料。

原始数据中可能包含：

客户姓名；
电话号码；
邮箱；
地址；
合同金额；
业务备注。

如果把这些数据全部放进模型上下文，就会增加隐私暴露风险。

但如果先在代码执行环境中处理，只提取必要统计结果，比如：

“本周有 27 个客户反馈交付周期问题。”

那么模型并不需要看到每个客户的具体姓名和联系方式。

这就更安全。

也就是说，Code Execution + MCP 不只是为了省 token，也有助于隐私保护。

尤其在医疗、金融、教育、企业办公等场景中，这一点非常重要。

AI Agent 越能连接真实系统，就越需要重视权限、边界和数据安全。

九、这对 Claude Code、Codex、OpenClaw、Hermes 有什么启发？

虽然这篇文章讨论的是 MCP 和代码执行，但它对各种智能体工具都有启发。

比如 Claude Code、Codex、OpenClaw、Hermes 等工具，本质上都在向一个方向发展：

从“会回答问题的模型”，变成“会调用工具、会执行任务、会处理复杂流程的智能体”。

但当工具越来越多、任务越来越复杂时，仅靠 Prompt 是不够的。

我们需要设计更合理的 Agent 架构。

几个重要启发包括：

第一，不要盲目接入大量工具。

工具不是越多越好，而是要能被 Agent 高效理解和调用。

第二，工具说明要按需加载。

Agent 当前任务用不到的工具，不应该占用上下文。

第三，中间数据要尽量留在执行环境中。

不要把所有原始数据都交给模型。

第四，复杂流程应尽量代码化。

循环、条件、统计、过滤、重试等逻辑，交给代码更可靠。

第五，常用流程应封装为 Skill。

把成熟工作流沉淀下来，而不是每次重新写 Prompt。

第六，敏感数据要有权限控制。

AI 可以调用工具，但不能无限制访问一切数据。

这些原则对构建科研 Agent、代码 Agent、企业知识库 Agent、办公自动化 Agent 都非常有价值。

十、未来的 Agent，不只是“会用工具”，而是“会组织工具”

很多人理解 Agent 时，会停留在一句话：

“Agent 就是会调用工具的大模型。”

这个理解没有错，但还不够。

更成熟的 Agent 应该具备另一种能力：

会组织工具。

也就是说，它不仅知道有哪些工具，还知道：

什么时候用哪个工具；
哪些工具不需要加载；
哪些数据不需要进上下文；
哪些步骤应该用代码处理；
哪些结果应该保存成中间文件；
哪些信息需要交给模型判断；
哪些敏感数据必须隔离。

这才是 Agent 工程真正困难、也真正有价值的地方。

未来的 AI Agent 系统，不会只是简单地把“模型 + 工具”拼在一起。

它更像是一个有分工的团队：

大模型负责理解和决策；
MCP 负责连接外部系统；
代码执行环境负责处理复杂流程；
文件系统负责保存中间结果；
权限系统负责安全边界；
Skill 负责复用成熟经验。

这样，Agent 才能从一个“能聊天的助手”，成长为一个真正能处理复杂任务的工作系统。

十一、一个简单示例：科研资料整理 Agent 应该怎么设计？

假设我们要做一个科研资料整理 Agent。

目标是：

“从一批论文 PDF 中提取研究方法、数据集、模型结构和实验结果，并生成综述表格。”

低效做法是：

把所有论文全文都塞给模型，然后让模型总结。

这样 token 消耗巨大，而且模型容易遗漏细节。

更合理的做法是：

第一步，代码读取 PDF 文件。

第二步，代码提取标题、摘要、方法、实验结果等部分。

第三步，代码过滤掉参考文献、页眉页脚等无关内容。

第四步，把每篇论文的关键信息整理成结构化表格。

第五步，只把结构化结果交给模型。

第六步，模型再负责归纳研究趋势、比较方法差异、总结创新点。

这个流程就体现了 Anthropic 文章中的核心思想：

不是所有信息都要进入模型。

应该先用代码处理，再让模型做高级总结。

这对科研写作、文献综述、项目申报、专利分析等任务都非常有帮助。

十二、一个简单示例：企业销售 Agent 应该怎么设计？

再看一个企业场景。

假设 Agent 要完成任务：

“分析过去一个月客户反馈，并把高优先级需求同步到 CRM。”

低效做法是：

把所有聊天记录、邮件、会议纪要都交给模型阅读。

更合理的做法是：

第一步，Agent 通过 MCP 连接邮件、会议纪要和 CRM 系统。

第二步，代码执行环境先筛选最近一个月的数据。

第三步，代码根据关键词、客户等级、时间等条件筛选高优先级记录。

第四步，模型只阅读筛选后的少量关键内容。

第五步，模型判断哪些是真正需求，哪些只是普通反馈。

第六步，再通过 MCP 把结果写入 CRM。

这样，模型不需要阅读全部原始资料，却可以完成更准确的判断。

这就是高效 Agent 系统的基本思路。

结语：Agent 工程的重点，正在从“写 Prompt”转向“设计系统”

这篇 Anthropic 文章最值得我们关注的，不是某个具体工具命令，而是一种思维方式的变化。

过去我们使用大模型，重点是：

“如何写一个好 Prompt？”

后来我们使用 Agent，重点变成：

“如何让模型调用工具？”

而现在，更关键的问题正在变成：

“如何设计一个高效、安全、可扩展的 Agent 系统？”

当 Agent 接入的工具越来越多、处理的数据越来越复杂时，单纯依赖长 Prompt 已经不够了。

我们需要让模型、工具、代码执行环境、文件系统、权限机制协同工作。

一句话总结：

未来真正强大的 Agent，不是把所有工具和数据都塞进模型，而是让模型学会通过代码高效组织工具、处理数据和完成任务。

AI Agent 的能力，不只取决于模型有多聪明，也取决于系统设计是否足够合理。

这也是从“玩 AI”走向“做 AI 工程”的关键一步。