Cloud Code开发者揭秘：AI Agent设计的核心密码——渐进式披露

如果你用过Cloud Code（或者Cline、Cursor等AI编程助手），你一定好奇过：这些工具背后的团队是怎么设计它们的？为什么它们有时候聪明得惊人，有时候又笨得让人着急？最近，Cloud Code的核心开发者Tariq连发两篇技术博客，把他们在打造Cloud Code过程中踩过的坑、走过的弯路全都抖了出来。我读完直呼过瘾——这哪是技术文档，简直是AI Agent设计的“避坑指南”。

今天咱们用文字深度复盘。尤其是那个贯穿全文的原则——渐进式披露（Progressive Disclosure），如果你正在搭建自己的智能体（Agent），或者只是想更好地使用Cloud Code，这篇文章的价值会放大十倍。

一、什么是渐进式披露？

Tariq开篇打了个比方：想象你面前有一道很难的数学题，你会用什么工具去解决它？纸和笔最基础，但算力有限；计算器好一点，但需要你懂操作；电脑最强，但你得会写代码。

这个比喻想表达什么？工具必须匹配使用者的能力。 如果使用者（这里就是AI模型）的能力还没到那个层次，你给它再强的工具也是白搭；反过来，如果模型的能力已经足够强，那些过于简单的工具反而会成为累赘。

而渐进式披露，就是解决这个矛盾的核心原则。用一句话解释：别一次性把所有信息都塞给智能体，让它按需获取、分层展开。 这个原则听起来简单，但Cloud Code团队在三个方向上反复验证，踩了无数坑才真正悟透。

二、方向一：上下文获取——别再替Agent“投喂”了

早期的Cloud Code也用RAG（检索增强生成），这是当时最标准的做法：先给代码库建向量索引，用户提问时检索相关片段，然后一股脑儿塞进上下文里。但后来他们把这个功能砍了。为什么？

Tariq的原话说得很犀利：“如果Cloud自己都能去搜索网络了，为什么不能让它自己去搜索你的代码库？” 换句话说，既然模型已经具备调用工具的能力，我们为什么还要替它把饭嚼碎了喂到嘴边？

于是他们改成让Cloud自己调用一个“搜索代码库”的工具。结果效果反而更好——因为模型自己清楚自己缺什么，搜到的内容天然能接上当前的推理链路。后来他们还加入了skills机制：当Cloud读一个文件时，如果发现里面引用了另一个文件，它会自动跳过去读；如果那个文件还有引用，就继续递归展开。一年前，Cloud还完全不会自己找上下文，现在却能多层嵌套搜索、精准定位。

核心启发： 如果你正在搭智能体，千万别替Agent决定它应该看到什么。给它搜索工具，给它入口文件，给它权限，让它自己帮你去挖。你替它找的资料，它未必能理解；但它自己找的推理链路，才是最完整的。

三、方向二：拓展能力——不加工具也能扩展行动空间

用户可能会问Cloud Code这样的问题：“如何配置MCP server？”问题是，Cloud模型本身并不知道怎么使用Cloud Code的各种功能。那要不要给它加一个“读取官方文档”的工具呢？

Tariq透露了一个关键数字：目前Cloud Code官方大概有20个工具，团队对新工具的加入卡得非常严格。为什么？因为每多加一个工具，模型每次推理时就要多权衡一个选项，决策负担会指数级上升。

那能不能把使用文档直接塞进系统提示词里？肯定不行。因为99%的时候没人会问文档相关问题，但文档一旦被塞进系统提示词，每轮对话都会加载，造成严重的上下文污染，干扰模型干正事。

最终的方案是搞了一个子代理：专门用来指导Cloud Code工作，只有用户问相关问题时才启动它。子代理有专门的搜索指令，找到答案就返回，不会把原始文档全部加载进来。Tariq写了一句极有启发性的话：“我们现在无需添加任何工具，就可以向Cloud的操作空间里添加内容。”不加工具、不改提示词，照样拓展了Agent的行动空间。

核心启发： 如果你在搭智能体，遇到“要不要加一个新工具”这种问题时，先想想能不能用子代理？能不能用文件引用？能不能让Agent在需要时自己发现能力？而不是一开始就把所有选项摆在它面前。

四、方向三：工具的淘汰——模型变强了，旧工具就成了枷锁

这个坑是最隐蔽的。早期Cloud Code记性差，团队专门给它做了一个待办清单工具（todo list），每隔五轮对话还插一条系统提醒：“别忘了你还有这些待办事项。”但模型升级以后，这个设计反而害了它。

Tariq的原话是这样：“随着模型的改进，它们不再需要被待办事项提醒，反而觉得这种提醒过于苛刻。收到提醒会让Cloud认为必须严格遵守清单，而不能灵活调整。” 更强的模型根本不需要这种死板的规矩，而且这种提醒会让它不敢变通。

后来团队改用了task工具，能设置依赖关系，多个子代理之间可以共享进度，模型自己也能修改任务、删除任务。Tariq总结道：“随着模型能力增强，模型曾经需要的工具，现在反而会变成限制它们发展的障碍。模型的能力在涨，但给的工具没跟上，那这些工具就从辅助变成了枷锁。”

核心启发： 定期审视你的工具库。三个月前模型可能需要某个工具辅助，但现在对它来说可能完全是负担。别让工具成为束缚。

五、给开发者和用户的实用建议

看完这三个方向，咱们回到自己身上。如果你正准备搭建智能体，或者正在用Cloud Code写代码，下面这几点建议值得你记下来：

1. 工具要少而精

Cloud Code团队有20个工具都觉得太多。与其一开始塞50个、100个工具去覆盖所有场景，不如只给核心工具，再加一个搜索或发现机制。他们团队做了个“延迟加载”（lazy loading）的设计：工具里只放一个轻量级钩子，智能体需要时再通过搜索发现并加载完整定义。

2. 优先考虑子代理和文件引用，而不是堆工具

想扩展能力？先想能不能用子代理，能不能让Agent在需要时自己读文件，而不是盲目加工具。子代理和文件引用是更优雅的渐进式披露。

3. 定期审视你的工具

每个季度翻一翻你给Agent配的工具列表，问问自己：这些工具现在还必要吗？有没有哪个反而限制了Agent的灵活性？

4. 如果你在用Cloud Code写代码，优化你的.claude.md文件

这个文件就是你能控制的系统提示词。别写成繁琐的操作手册，只放骨架核心：项目简介、技术栈、三五条最关键的规则。然后把详细规范独立到其他文件里，把文件路径留在.claude.md中。比如你可以写一句“提交规范详见docs/commit.md”，Cloud真正要提交时，它会自己去读那份文件。

同样，提问时也别把你觉得相关的所有文件都贴进窗口，而是给方向和入口：“现在刷新失败，报错是XXX，你从哪个模块开始查？”让Agent自己去定位。

六、既是科学，也是艺术

Tariq在文章结尾说了一段话，我觉得所有做AI Agent的人都应该刻在脑子里：“给Agent设计工具，既是一门科学，也是一门艺术。没有一套公式能覆盖所有场景，你要多试、多观察、多迭代，找到你自己的感觉和品味。而渐进式披露，是我们团队目前验证下来最有效的那根主线——你塞得越多，Agent反而越受限；你给得越克制，它发挥得反而越好。”

下次你用Cloud Code时，不妨想想它背后的这套设计哲学；下次你搭智能体时，也试着用渐进式披露的眼光去审视每一个工具。也许你会发现，少即是多，克制才是真正的智慧。

如果你也被这篇技术文章启发到了，欢迎在评论区聊聊你的看法。觉得这篇文章有用的话，点个赞、分享给身边搭智能体的朋友，咱们下期见！