夜雨聆风↑阅读之前记得关注+星标⭐️，😄，每天才能第一时间接收到更新
大家好，我是杰克王，AI 算法 6 年老兵。
你知道给 AI Agent 配工具，最常见的错误是什么吗？
不是配错了工具——是配太多了。
2026 年 2 月，Anthropic 的工程师 Thariq 发了一篇技术文章，标题叫《Lessons from Building Claude Code: Seeing like an Agent》（从构建 Claude Code 中学到的：像 Agent 一样思考）。这篇文章推出当天，获得了 11,181 点赞、28,507 次收藏、近 400 万次浏览，在 AI 工程圈炸开了锅。
大部分人点进去，以为看的是"如何给 AI 配更好的工具"。
但 Thariq 真正说的，是这件事的反面——AI 的工具越多，反而越容易出错；随着模型变聪明，你最该做的事，是不断删掉它身上的工具。
这不是在讲 Claude Code 怎么用。这是 Anthropic 内部，真实踩过的坑。
大多数人是这样给 AI 配工具的
如果你构建过 AI Agent，你大概有过这样的直觉：工具越全，模型越能干。
这个逻辑听上去合理。人多力量大，工具多能力强，这是我们从软件工程里带来的思维惯性。
所以很多团队做 AI Agent 时，第一件事是列工具清单：搜索要有、代码执行要有、文件读写要有、HTTP 请求要有、数据库查询要有……往往一上来就配了几十个工具。
这不只是外部开发者的做法，Claude Code 团队自己也走过这条路。文章里提到，Claude Code 现在大约有 20 个工具，而设计师们"每天都在问自己：这些工具，真的都需要吗？"
工具越多，模型在每次行动前需要从更多选项里做选择。对人类来说，选项多是好事；但对语言模型来说，工具越多，等于上下文里多了更多噪音，模型更容易在不该用某个工具的时候把它用出来，也更容易在真正需要它的时候忽略掉它。
一个社区用户在回帖里说：
"我给 Agent 配了 12 个工具，结果发现它只真正用到了 3 个。现在我们的策略是从 1 个工具开始，等模型主动'需要'了再加。"
这不是特例，这是规律。
等一下，Anthropic 自己也走错路了？
是的。而且走了不止一次。
Thariq 在文章里分享了三个真实的迭代案例，每一个都说明了"我们以为对的设计，模型告诉我们是错的"。
第一坑：AskUserQuestion 工具的三次失败
Claude Code 团队最初想解决一个问题：Claude 问用户问题的方式太慢，来回对话太耗时，能不能让问问题这件事更结构化？
第一次尝试：直接往已有工具（ExitPlanTool）里加参数，附上一个"待回答问题数组"。看上去最省事，改动最小。
结果？模型完全蒙了——它不知道如果用户的回答和已有计划矛盾了怎么办。说白了，就是把两件性质不同的事强行塞进同一个工具，模型的上下文逻辑断裂了。
第二次尝试：不加工具，改输出格式，让模型按特定 Markdown 格式输出带选项的问题，再由前端解析展示。
这次问题变成：模型不够可靠。它有时候会多输出几句话，有时候少一个选项，有时候用了完全不同的格式。用自然语言约束模型的输出结构，不够稳定。
第三次，才找到正确答案：做一个专门的 AskUserQuestion 工具，可以在 Agent 流程的任何阶段调用，触发时弹出 UI 界面让用户在流程里暂停回答。
这才稳了。
关键不在于工具本身设计多精妙，而在于：这个工具的边界是清晰的，模型知道什么时候该用它，用了之后会发生什么，不用它的时候完全不干扰。
第二坑：Todo 列表，从救命稻草到绊脚石
Claude Code 刚上线时，模型的上下文保持能力不够强，团队给它加了一个 TodoWrite 工具——让模型在开始任务时写出待办清单，每完成一步就打勾。
为了防止模型跑着跑着忘了自己在干什么，系统还会每隔 5 轮对话自动提醒它当前的 Todo。
这在当时确实有用。
但随着 Claude 模型变强，这套设计开始帮倒忙：
模型收到 Todo 提醒，会误以为这是在约束它只能做 Todo 上的事，不敢灵活调整； 新出的 Claude Opus 4.5 可以很好地调度子 Agent，但子 Agent 之间怎么共享一个 Todo 列表？这个问题根本没有解。
最后，团队用 Task 工具替代了 Todo——Task 支持依赖关系、跨子 Agent 共享状态，模型可以自由修改和删除任务，不再被僵化的列表绑住。
这是这篇文章里最核心的一个反转：当年救你的工具，今天可能正在限制你。模型变聪明了，你的工具要跟着变。
第三坑：把 RAG 换成 Grep，再换成"渐进式披露"
Claude Code 最早用向量数据库做 RAG（检索增强生成）——提前给代码库建索引，查询时自动检索相关上下文。
效果不错，但有一个根本性的问题：模型是被动拿到上下文，而不是主动去找。模型不知道这些上下文是怎么来的，也不知道还有哪些相关文件没被检索到。
后来团队给 Claude 加了 Grep 工具，让它自己搜索代码库、自己构建上下文。
这一个改变，效果出乎意料地好。说白了就是：给 AI 一根钓鱼竿，比直接给它一盘鱼效果更好——模型反而更准确地找到了它需要的内容。
接着，团队把这个思路泛化成了一个设计原则——渐进式披露（Progressive Disclosure）：把庞大的知识/指令拆成层级，模型先读一个入口文件，按需递归读取更深层的文件。
不把所有信息塞进系统提示。模型只在真正需要时才加载深层上下文。
这解决了一个 Agent 开发者都会遇到的老大难问题："上下文污染"（Context Rot）——提示词里放的信息越多，模型的核心任务反而越容易被噪声干扰。
Anthropic 工程师背后：不只是技术，是一种认知范式
Thariq Shihipar，Anthropic Claude Code 团队工程师。此前是 YC W20 批次的创始人，MIT Media Lab 出身，2011 年就加入了 X（Twitter）早期阶段。60,000+ 粉丝，是 AI 编程领域被引用最多的技术作家之一。
这篇文章不是教程，是内部复盘。
和大多数公司"只讲成功，不讲失败"的技术博客不同，Thariq 在文章里详细描述了三次失败的尝试——AskUserQuestion 工具的三次设计迭代，Todo 被废弃的过程，RAG 被 Grep 替代的原因。
为什么 Anthropic 愿意公开这些"失败"？
因为这些失败背后有一个他们认为值得传播的认知框架：工具设计没有标准答案，只有持续观察模型的行为，才能知道什么工具适合它。
文章标题就是这个思想的浓缩——"Seeing like an Agent"，像 Agent 一样思考。
一位在 X 上回帖的工程师这样总结：
"每个做 Agent 的团队都会经历同样的几课：给人类设计工具 → 发现模型用起来像有 root 权限的浣熊 → 重新为 token economy 和可预测的副作用设计工具。'像 Agent 一样思考'才是解锁的钥匙。"
这篇文章的 28,507 次书签（远超转发的 1,386 次）说明了一件事：这不是读完就忘的内容，大家把它留下来是为了反复参考。
我的判断：AI Agent 正在从"配置期"进入"减法期"
看完这篇文章，我认为 AI Agent 开发正在进入一个新阶段——不再是"怎么给 AI 更多能力"，而是"怎么给 AI 更精准的边界"。
几个具体判断：
1. 工具数量将成为 Agent 评测的新指标。 用了多少工具不是能力的标志，而是设计是否成熟的标志。Anthropic 的 Claude Code 把工具数量控制在 20 以内，未来我预计成熟的 Agent 框架会把"每增加一个工具的门槛"写进设计规范。
2. "渐进式披露"会成为 2026 年 Agent 架构的标准模式。 这不是 Claude Code 专有，任何需要处理大量知识/文档的 Agent 都可以用这个模式替代"把所有东西塞进系统提示"的野蛮方式。大量中间件框架将围绕这个模式出现。
3. 模型变强，工具要跟着退场。 今天你给 Agent 加的工具，18 个月后可能就是限制它的枷锁。如果你在做 AI 产品，现在就应该给每个工具加上"退役条件"：当模型能力达到什么水平，这个工具不再需要？
4. "像 Agent 一样思考"会成为 AI 工程师的核心软技能。 不是写 prompt 的技巧，不是微调的方法，而是从模型的上下文视角出发，判断什么工具有用、什么工具有害。这个能力，靠实验，不靠背理论。
5. 对普通用户的意义：Claude Code 每一次工具迭代，都会体现在你每天使用时"它越来越少瞎猜、越来越懂得问你"。AskUserQuestion 工具背后的三次失败，换来的是你现在看到的那个"点几下就能明白你意思"的对话框。
Thariq 在文章结尾写道："如果你期待一套刚性的工具设计规则，很遗憾，这篇文章不是那个。设计工具，是艺术，不是科学。"
我觉得他说对了一半——它不是科学，但它是有规律可循的艺术。
上面几条，就是我从这篇文章和 Claude Code 的演化轨迹里，提炼出来的那几条规律。
觉得有收获，点个在看支持一下 👇 感谢阅读。我是杰克王，欢迎加微交流 🚀
