说实话，读完 Anthropic Claude Code 团队最近分享的这篇构建经验，我盯着屏幕想了很久。
不是因为技术多复杂。恰恰相反，整篇文章最让我震动的一句话极其朴素：
「你要学会像智能体一样看世界。」
这句话来自 Claude Code 的核心开发者。一个每天跟 AI 智能体打交道的人，他给出的最重要建议，不是什么架构方案或框架选型，而是一种认知方式的转变。
这让我想到一个更大的问题：2026 年了，我们跟 AI 协作的方式，是不是从根上就搞错了？
一、给 AI 一把锤子，它不一定能盖房子
Claude Code 团队讲了一个特别生动的类比。
想象你面前有一道很难的数学题。你希望有什么工具来帮忙？
如果你只会心算，给你纸和笔就够了。如果你会用计算器，给你一台计算器效率更高。如果你会编程，那直接给你一台电脑是最快的。
工具的上限，取决于使用者的能力。
这个道理看起来简单，但放到 AI 智能体设计上，绝大多数人都搞反了。很多人的思路是：给 AI 塞尽可能多的工具，50 个、100 个，覆盖所有可能的场景。觉得工具越多，AI 越强大。
结果呢？AI 面对一堆工具，就像你面对一个有 200 个按钮的遥控器。不是不能用，是选择成本太高，经常选错。
Claude Code 的做法完全不同。它只有大约 20 个工具，而且团队一直在问自己：是不是还太多了？
少，不是因为省事。少，是因为理解。
二、曾经救命的工具，后来变成了枷锁
这是整篇文章里我觉得最精彩的一个教训。
Claude Code 刚上线的时候，团队发现模型经常忘记自己在干什么。做着做着就跑偏了，完全丢失上下文。
怎么办？给它一个待办事项列表。开始的时候列好任务，完成了就勾掉。简单直接，效果立竿见影。
甚至光有列表还不够。团队还每隔 5 个回合插入一次系统提醒："喂，别忘了你的任务是什么。"
但随着模型变聪明了，问题来了。
模型觉得被待办清单困住了。它想灵活调整策略，但系统不断提醒它"按计划执行"。就像一个越来越能干的员工，老板却还在用实习生的管理方式盯着他。
最终团队做了一个大胆的决定：把待办事项工具干掉了。
取而代之的是一个叫"Task"的新工具。不再是"提醒你该做什么"，而是"帮你和其他智能体沟通协调"。任务支持依赖关系，可以在子智能体之间共享更新，模型自己可以修改和删除任务。
从被管理，到自管理。
这件事的启发很直接：模型在变强，你给它的工具也得跟着变。昨天好用的设计，今天可能就在拖后腿。
三、不是给更多工具，而是让它自己去找
Claude Code 最初怎么理解你的代码库？用 RAG 向量数据库。把你的代码切块、索引、存起来，AI 需要的时候从数据库里检索。
这是行业标准做法，快速、成熟、好理解。
但 Claude Code 团队发现了一个根本性的问题：AI 是被动接受上下文的。
它不是自己去理解你的项目，而是被喂了一堆可能相关的代码片段。就像你入职第一天，同事把公司所有文档甩给你，而不是让你自己去探索、去问问题、去建立理解。
于是他们换了思路：给 AI 一个 Grep 工具，让它自己搜索代码库。
效果出人意料地好。而且随着模型越来越聪明，它搜索和理解上下文的能力也越来越强。
这个思路后来演变成了一个核心设计原则：渐进披露（Progressive Disclosure）。
不是一次性把所有信息倒给 AI，而是让它按需发现。Skill 文件可以引用其他文件，模型可以递归读取，一层一层深入。实际上，很多 Skill 的用途就是教 AI 如何使用某个 API 或查询数据库，也就是「教它怎么自己找答案」。
一年时间，Claude 从几乎无法构建自身上下文，进化到能在多层嵌套文件中精准找到所需信息。
这带来了一个很实际的启发：与其不断增加工具数量，不如提升 AI 自主获取信息的能力。给它一根鱼竿，比每天给它送鱼有用得多。
四、2026 年的分水岭：从 Vibe Coding 到 Agentic Engineering
Claude Code 团队的这些经验，放在更大的行业背景下看，会更有意思。
2025 年初，Andrej Karpathy 发明了一个词叫"Vibe Coding"。意思是跟着感觉走，让 AI 生成代码，差不多能用就行，不用太较真。当时这个词火遍全网，因为它精准描述了大多数人使用 AI 写代码的状态。
但到了 2026 年 2 月，Karpathy 自己宣布这个词过时了。
取而代之的新词叫 Agentic Engineering。
区别在哪？
Vibe Coding = 随缘。AI 写什么用什么。
Agentic Engineering = AI 负责执行，人类负责架构、质量和正确性。
Karpathy 说得很明确："你 99% 的时间不再直接写代码，但你需要更强的工程能力来监督和验证 AI 的输出。"
Claude Code 团队的经验说的其实就是这回事。他们发现，设计智能体的工具"既是一门艺术，也是一门科学"。靠直觉乱塞工具不行，照搬教科书也不行。你得观察模型的行为，读它的输出，做大量实验。
开发者的价值不再是打字速度或背 API 参数，而是你能不能把问题定义清楚，以及看一眼就知道 AI 的输出对不对。
五、像智能体一样思考，到底意味着什么？
说了这么多，回到那句核心的话：像智能体一样看世界。
这不只是一条给 AI 工程师的建议。我觉得它对每个跟 AI 协作的人都适用。
首先，你得知道 AI 的能力边界在哪。你不能给一个刚入职的实习生一台超级计算机，然后期待他搞出惊天动地的成果。给 AI 工具之前，先花时间观察和实验，别看几篇教程就下结论。
然后，管理的尺度很微妙。待办事项的教训已经说明了，管太多会限制 AI 的潜力，完全不管也不行。给个方向、给点资源，让它自己跑，最后你来看结果就行。
最后，别指望一套方法用到老。你今天觉得完美的工作流，三个月后可能就需要推翻重来。Claude Code 团队说"我们倾向支持一小批能力比较类似的模型"，就是因为每次模型升级，他们都要重新评估整个工具设计。你跟 AI 的协作方式，也得跟着迭代。
写在最后
McKinsey 最近的一份报告说了一句话，我觉得说得特别好：
"培养 AI 智能体更像是入职一个新员工，而不是部署一套软件。"
如果你把 AI 当软件，你会期待它即插即用、永远稳定、越多功能越好。
如果你把它当新员工，你会花时间了解它的能力，给它匹配的工具和职责，设定清晰的目标，然后留出成长空间。
Claude Code 团队花了一年时间，从"给模型塞更多工具"走到"学会像模型一样思考"。这个转变听起来简单，做起来需要打破很多直觉。
2026 年，AI 能力在指数级增长，但大多数人使用 AI 的方式还停留在"给它下指令，等它出结果"。
也许是时候换个视角了。
不是让 AI 来适应你的思维方式，而是你先学会像智能体一样看世界。
本文基于 Anthropic Claude Code 团队的构建经验分享，结合 2026 年 AI 智能体行业趋势撰写。
参考来源：
Anthropic Engineering Blog: Building Effective Agents
Karpathy 关于 Agentic Engineering 的定义（2026 年 2 月）
McKinsey: One Year of Agentic AI - Six Lessons
MIT Sloan: Agentic AI Explained
