给 AI Agent 塞太多信息，它反而会变笨。我们最初没意识到这点，直到看见模型在无用的上下文里迷失。
早先的方案是 RAG（检索增强生成），直接找出相关片段，一股脑儿注入上下文。但后来我们改为让 Cloud 自己调用'搜索代码库'的工具。模型清楚自己缺什么，搜到的内容能接上当前的推理链路。此外加入了 skills 机制：当读一个文件发现引用另一个文件时，自动递归展开。现在 Cloud 能多层嵌套搜索、精准定位。别再替 Agent 决定它应该看到什么——给它搜索工具、入口文件和权限，让它自己去挖掘。
每多加一个工具，模型每次推理时的决策负担会指数级上升。把文档直接塞进系统提示词还会造成严重的上下文污染。我们最终的方案是搞了一个子代理（sub-agent）：专门用来指导工作，只有用户问相关问题时才启动。子代理有专门的搜索指令，找到答案就返回，不会把原始文档全部加载进来。所以当你纠结'要不要加一个新工具'时，不妨先想想能不能用子代理、文件引用，或者让 Agent 在需要时自己发现能力。
早期为了弥补记性差，我们设计了待办清单工具，每隔五轮对话插一条系统提醒。模型升级后，这种死板的规矩反而限制了灵活性。更强的模型不需要这种提醒，甚至觉得过于苛刻。后来改用了 task 工具：能设置依赖关系，多个子代理之间共享进度，模型自己也能修改任务。
这引出一个习惯：定期审视你的工具库。随着模型能力增强，曾经需要的工具可能变成束缚。
一些实操建议：
- 工具要少而精。只给核心工具，再加一个搜索或发现机制。采用'延迟加载'设计：工具里只放轻量级钩子，需要时再加载完整定义。
- 想扩展能力，优先考虑子代理和文件引用，让 Agent 在需要时自己读文件。
- 每季度翻一翻工具列表，确认是否必要，有无限制灵活性。
- 优化 .claude.md 文件——这是你能直接控制的系统提示词。只放骨架核心（项目简介、技术栈、关键规则），详细规范独立到其他文件，路径留在 .claude.md 中。提问时给方向和入口，让 Agent 自己去定位。
给 Agent 设计工具没有万能公式，要多试、多观察、多迭代。但渐进式披露是目前验证下来最有效的主线：你塞得越多，Agent 反而越受限；你给得越克制，它发挥得反而越好。