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

> 作者：晨旭｜发布：2026-03-09｜系列：入门系列文章
> 来源：https://chenxu.xin/writing/claude-code-see-like-an-agent
> 首发：首发于公众号，原文 https://mp.weixin.qq.com/s/xN3JpFGCYB1RHxaQwUaqpQ；此页为作者本人维护的存档

从 AskUserQuestion、Tasks、Grep 取代 RAG、Guide 子代理四个踩坑案例，看 Claude Code 背后的 Model-Centric 产品哲学：简约克制、动态解绑、渐进式披露。

---

最近 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 一样思考）。工具的设计，必须完美匹配模型当前的能力边界。如果把完成任务比作解数学题，那么给模型什么工具，取决于它现在有多聪明。

![三行表格，工具、能力要求、效果三列：纸笔要求最低但受限于手工计算，计算机要求中等但需要知道高级功能，电脑要求最高、最强大但要会写代码](./_images/claude-code-see-like-an-agent/01.png)

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

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

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

![AskUserQuestion 三个版本的对比图](./_images/claude-code-see-like-an-agent/02.jpg)

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

![终端里的提问界面，顶部是 Paradigm、Theme、Snacks、Indentation 四个标签页，正文问「这个项目你偏好哪种编程范式」，下面列出 Functional、Object-Oriented、Procedural、Mixed 等选项](./_images/claude-code-see-like-an-agent/03.jpg)

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

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

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

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

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

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

![从待办事项到任务的演进图，左边单个代理下挂着设置项目、编写测试、实现功能、部署四条清单，右边代理 A 与代理 B 分别派出任务 1、任务 2，汇入任务 3 再指向任务 4](./_images/claude-code-see-like-an-agent/04.jpg)

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

![三行表格，模型阶段、需要的辅助、产品形态三列：早期模型需要频繁提醒、对应 TodoWrite 加 5 轮提醒，Opus 4.5 自主性更强、对应无需提醒的 Tasks，未来一栏留问号、写着持续演进](./_images/claude-code-see-like-an-agent/05.png)

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」的暴力做法。

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

## 最后

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

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

## 核心结论

- 给 Agent 什么工具，取决于模型现在有多聪明。工具太简单会限制模型发挥，太复杂模型又无法理解，要精准测算它当前的能力边界。（判断 · 把握较大）
  永久链接：https://chenxu.xin/writing/claude-code-see-like-an-agent#tool-design-matches-model-capability
- 哪怕设计再精妙的工具，只要模型在推理链条中不理解、不爱调用，就是无效设计。AskUserQuestion 最终版成功的原因就是「模型喜欢调用它」。（判断）
  永久链接：https://chenxu.xin/writing/claude-code-see-like-an-agent#model-must-like-the-tool
- 随着模型能力提升，曾经需要的工具可能变成束缚。为弥补过去缺陷而设的限制性设计，该拆除脚手架时绝不手软。（判断 · 把握较大）
  永久链接：https://chenxu.xin/writing/claude-code-see-like-an-agent#remove-scaffolding-as-models-improve
- 被动 RAG 很脆弱——切片策略、向量索引、环境依赖任何一环出问题，整个上下文召回就崩了。给模型 Grep 让它主动搜索反而更可靠。（判断）
  永久链接：https://chenxu.xin/writing/claude-code-see-like-an-agent#grep-beats-passive-rag
- 扩展系统能力不一定要生硬地增加工具。通过渐进式披露和专用子代理，同样能优雅解决问题，还避免了上下文腐烂。（判断）
  永久链接：https://chenxu.xin/writing/claude-code-see-like-an-agent#expand-via-progressive-disclosure

---

本文出自晨光里的AI（https://chenxu.xin），作者晨旭。
引用时请保留来源链接。文中标注「判断」「假设」的部分是作者的个人看法，不是事实。