Claude code 构建启示：See like an agent（像Agent一样思考）

最近 Anthropic 创始团队成员 Thariq 在 X 上分享了一篇深度长文：《Lessons from Building Claude Code: Seeing like an Agent》。

很多时候，我们在看一个 Agent 到底牛不牛，第一反应是去看它能调用多少个工具。但在这篇文章中，Claude Code 设计理念表现出的却是极度的克制。

原文非常硬核且精彩，这篇文章是我对它进行了重新的梳理和转译，试图回答三个问题：像 Agent 一样思考，到底是指什么？顶级 AI 团队在设计工具时踩过哪些坑？背后又折射出了怎样的产品哲学？

设计 Agent 的「动作空间」：像模型一样思考

给 Agent 什么工具最合适？是给一个万能工具，还是 50 个专用工具呢？

Claude 团队给出的答案是：See Like an Agent（像 Agent 一样思考）。工具的设计，必须完美匹配模型当前的能力边界。如果把完成任务比作解数学题，那么给模型什么工具，取决于它现在有多聪明。

文章分享了构建 Claude Code 的四个踩坑与迭代案例。

案例一：AskUserQuestion 工具——意图越清晰，模型越爱用

为了让 Claude 在遇到不确定的事情时主动向用户提问（而不是瞎猜），团队尝试了三个版本：

1. 在现有工具里加参数：在输出计划的 ExitPlanTool 中加了一个提问参数。结果失败，模型经常混淆「输出计划」和「提问」两个意图。 2. 要求特定格式输出：让模型用特定的 Markdown 格式提问。结果失败，大语言模型的输出格式依然存在不稳定性。 3. 独立化工具：创建了专属的 AskUserQuestion 工具。成功，结构化输出极其稳定，且模型非常喜欢调用它。

哪怕设计再精妙的工具，只要模型在推理链条中不理解、不喜欢调用，就是无效设计。

案例二：从 Todos 到 Tasks——不只是改个名字

早期为了防止模型遗忘长线任务，通常会配备 TodoWrite 工具，并设置每 5 轮对话就由系统强行提醒一次待办列表。

但这带来了新的问题：随着 Opus 4.5 等模型能力的提升，频繁的系统提醒反而让模型觉得必须死守 todo 列表，不敢根据实际情况灵活修改。而且一旦涉及长周期、跨代理协作，简单的 Todo 工具根本无法承接。

于是，Claude 将其升级为全局的 Tasks（任务系统）：

- 支持依赖关系：任务之间可以设置阻塞点，存储在元数据中。 - 跨代理协作：存在本地 ~/.claude/tasks 文件系统中，多个子代理或会话可以实时同步、共同操作。

随着模型能力提升，曾经需要的工具可能变成束缚。必须不断重新审视过去的假设，该拆除脚手架时绝不手软。

Tasks 的出现，意味着 Agent 从「单机会话」走向了「平台化协作」。更重要的是，把数据存在本地文件系统并开放格式，这是一种极具生态视野的架构决策。

案例三：搜索接口设计——从 RAG 到 Grep

在给 Agent 提供项目上下文时，早期依赖被动塞入的 RAG 方案。但在实际项目中，RAG 并没有想象中那么美好：底层的文本切片和分块策略稍有不慎，或者向量索引、环境依赖出点问题，整个上下文召回就会变得极其脆弱。

Claude Code 的解法是：放弃被动 RAG，给模型提供 Grep（文本搜索）工具，让它主动搜索构建上下文。

进一步，他们演化出了 Skills 系统，采用渐进式披露：模型读取 skill 文件，顺藤摸瓜引用其他文件，递归探索。

在一年内，Claude 从「不会构建上下文」进化到了「能通过多层嵌套搜索找到精确信息」。

案例四：Claude Code Guide 子代理

当用户提问「如何添加 MCP」或「slash command 是什么」，Claude 本身是不知道这些产品特有概念的。如何教它呢？

1. 写进系统提示？ 不行，这样会导致严重的上下文腐烂，且干扰写代码的主要任务。 2. 给个 Docs 链接让它自己查？ 也不行，这样会加载太多无关的网页结果，效率低下。 3. 最终方案：引入专用的 Guide 子代理。只需要告诉主模型「有问题去找子代理」，子代理拥有专门的搜索指令，只返回精准答案。

扩展系统能力不一定要生硬地增加工具，通过渐进式披露和子代理，同样能优雅地解决问题。

Claude Code 的 Model-Centric 范式

拆解完以上四个案例，再回过头来看 Claude Code 的设计，会发现其背后隐藏着一套 Agent 产品哲学。

它的成功标准不再仅仅是「人类用户觉得多好用」，而是「大模型喜不喜欢用、能不能用好」。这就是 Claude Code 展现出的 Model-Centric（以模型为中心）范式。

具体来说，这种范式包含了三个核心产品方法论。

1、简约克制：做模型的能力放大器

Claude Code 目前仅维持在 20 个左右的工具，新增门槛极高。

- 少即是多：每多一个工具，模型的决策空间就大一分，意图混淆和出错的概率也随之增加。 - 能力匹配原则：工具太简单会限制模型发挥，太复杂模型又无法理解。要精准测算模型当前的能力边界，提供恰好能让它发挥最大功效的「动作空间」。

想给模型什么工具，取决于模型自身的能力。AskUserQuestion 工具迭代了三版，最终版本之所以成功，是因为 "Claude seemed to like calling this tool"——模型觉得好用。

2、动态解绑：该拆除的脚手架绝不手软

在传统的软件工程中，功能是累加的。但在 AI 时代，产品形态必须跟随模型的能力动态演进。

今天的最佳实践，可能就是明天的束缚。就像早期为了弥补模型记忆力差而设计的 todo list，在模型变聪明后，反而成了限制其灵活性的枷锁。

必须时刻保持警惕，持续观察模型的行为链路。当模型能力跃升时，要勇于删减那些为了弥补过去缺陷而设立的限制性设计，真正解放大模型。

3、渐进式披露：从「系统预设」走向「主动探索」

不管是面对庞大的项目上下文，还是处理复杂的产品概念，Claude Code 都放弃了「把所有信息一股脑塞进 System Prompt」的暴力做法。

按需加载——无论是通过主动检索来构建上下文，还是引入专用的子代理来解答特定问题，都是在实践渐进式披露。这不仅避免了上下文腐烂，还保证了主干任务的高效运行。

最后

技术日新月异，不去追求大而全的功能，去持续观察模型的行为，理解它的推理链路，并用实验去驱动每一次设计，或许会有意想不到的收获。

理解模型，保持耐心，并与它共同进步。