驾驭 Claude 的智能 — 构建应用的 3 个关键模式
来源：Anthropic 工程博客，Lance Martin
核心前提
像 Claude 这样的生成式 AI 系统，与其说是被"制造"出来的，不如说是被"培育"出来的。研究人员设定好引导它们生长的条件，但最终会演化出怎样的确切结构或能力，往往是无法准确预测的。
这给使用 Claude 开发应用带来了挑战：开发者使用的 AI 套壳或智能体框架（agent harnesses）基于各种"假设"构建，但随着 Claude 能力的不断进化，这些假设很快就会过时。
三大核心模式：
- 善用它已知的技能
- 思考"我可以放手不管什么"
- 谨慎设定智能体框架的边界
模式一：善用 Claude 已知的技能
推荐做法
使用 Claude 已经非常熟悉的工具来构建应用。
案例：SWE-bench Verified
2024 年底，Claude 3.5 Sonnet 创下行业最高水平（49% 得分）：
- 仅使用了一个 bash 工具
- 一个用于查看、创建和修改文件的文本编辑器工具
- Claude Code 也是基于这些同样的工具构建
关键发现： Claude 能够将这些通用工具组合成极其丰富的模式，以此来解决各种复杂问题。
衍生工具：
- 智能体技能（Agent Skills）
- 编程式工具调用（programmatic tool calling）
- 记忆工具（memory tool）
本质上都是由基础的 bash 和文本编辑器工具组合衍生而来的。
模式二：思考"我可以放手不管什么"
让 Claude 自主编排行动
常见错误假设： 认为每次调用工具返回的结果，都必须立刻塞回 Claude 的上下文窗口中，好让它决定下一步干嘛。
问题：
- 把所有的工具结果都转化成 tokens 给模型处理
- 不仅速度慢、成本高
- 往往毫无必要——尤其是当这个结果仅仅是为了传递给下一个工具
解法： 给 Claude 开放一个代码执行工具（如 bash 工具或 REPL）：
- 允许 Claude 自己写代码来执行工具调用
- 亲自处理这些工具之间的数据流转逻辑
- 让 Claude 决定哪些结果直接略过、哪些进行过滤，或者哪些直接像流水线一样输入给下一次调用
效果： 在 BrowseComp 基准测试中，赋予 Opus 4.6 过滤自身工具输出的能力后，准确率从 45.3% 提升到 61.6%。
让 Claude 管理自己的上下文
过去的问题： 必须针对每个任务，手工雕琢极其详细的系统提示词（system prompts）。
问题：
- 每增加一个 token，都在消耗 Claude 的注意力预算
- 提前加载那些百年不用一次的指令，纯粹是浪费资源
解法： 赋予 Claude 访问技能（skills）库的能力：
- 只需把每个技能简短的 YAML 头部信息预先加载到上下文窗口中
- 让 Claude 知道有哪些技能可用
- 如果当前任务需要，Claude 会主动调用读取文件的工具，将完整的技能内容进行"渐进式展开"（按需加载）
上下文编辑（context editing）： 提供一种机制，允许模型选择性地删掉那些过时或不再相关的内容。
子智能体（subagents）： Claude 越来越懂得何时应该"另起炉灶"——开启一个干干净净的全新上下文窗口，来隔离并专注处理某项特定任务。
在 Opus 4.6 中，这种召唤子智能体的能力让其在 BrowseComp 测试上的成绩，比表现最好的单智能体方案还提升了 2.8%。
让 Claude 持久化自己的上下文
业界普遍做法： 在模型外部搭建一套复杂的检索架构（如 RAG）来充当记忆系统。
更聪明的做法： 给 Claude 提供简便的工具，让它自己决定哪些内容值得保存下来。
压缩（compaction）： 允许 Claude 自己对过去的上下文进行浓缩总结，从而在马拉松式的长周期任务中不至于"断片"。
BrowseComp 测试结果：
| 模型 | 准确率 |
|---|---|
| Sonnet 4.5 | 43%（卡住） |
| Opus 4.5 | 68% |
| Opus 4.6 | 84% |
记忆文件夹（memory folder）： 允许 Claude 像记笔记一样，把重要的上下文写成文件存起来，需要的时候再去读取翻看。
BrowseComp-Plus 测试结果： 给 Sonnet 4.5 一个记忆文件夹，准确率从 60.4% 提升到 67.2%。
宝可梦游戏案例
早期 Sonnet 3.5：
- 把记忆当成了会议速记
- 只会傻乎乎地记录游戏里 NPC 说了什么废话
- 玩了 14,000 步，生成 31 个凌乱的文件
- 包括两份几乎一模一样的关于毛毛虫宝可梦的无聊笔记
- 游戏进度卡在第二个城镇
后期 Opus 4.6：
- 记起"硬核战术笔记"
- 同样的 14,000 步，只生成 10 个井井有条、按目录分类的文件
- 横扫拿下 3 枚道馆徽章
- 从自己踩过的坑里，提炼出了一份专门的"经验教训"文档
模式三：谨慎设定边界
巧妙设计上下文工程，让缓存命中率拉满
Messages API 是无状态的，每一轮对话都必须把新的上下文连同之前所有的动作记录、工具说明以及给 Claude 的指令，一并打包重新发送过去。
Prompt Caching 机制： 通过设置断点（breakpoints）来缓存提示词，命中缓存的 token 价格仅是基础输入 token 价格的 10%。
最大化缓存命中率的黄金原则：
| 原则 | 描述 |
|---|---|
| 静态内容在前，动态内容在后 | 将稳定的内容（如系统提示词、工具列表）放在最前面 |
| 用消息来更新 | 如果需要提醒模型，在消息末尾追加，而不是修改原始提示词（修改前面会导致整个缓存失效） |
| 别中途换模型 | 缓存是跟着特定模型走的；一旦切换，缓存全盘作废 |
| 谨慎管理工具 | 工具列表位于缓存的头部。增加或删除工具都会使其失效 |
| 及时更新断点 | 对于多轮对话应用，应将断点移至最新的一条消息上，以保持缓存的新鲜度 |
利用声明式工具打造 UX、可观测性与安全边界
声明式工具（dedicated tools）的价值：
| 场景 | 做法 |
|---|---|
| 安全红线 | "是否可逆"是一个极佳的判断标准。对于像调用外部 API 这种泼水难收的操作，设置门槛强制要求"用户确认"后才能放行 |
| 文件写入 | 内置"文件陈旧度检查"，防止 Claude 稀里糊涂地覆盖掉别人刚刚修改过的文件 |
| 用户体验 | 渲染成前端弹窗，清晰地向用户提问、抛出多个选项，或者暂停智能体的运行循环等待用户反馈 |
| 可观测性 | 动作是格式严谨的工具时，外层框架能拿到结构化的参数数据，日志记录、链路追踪和场景回放都会变得轻而易举 |
Claude Code 的自动模式（auto-mode）：
- 为 bash 工具套上了一层极其硬核的安全边界
- 召唤"第二个 Claude"来阅读命令行字符，让 AI 来审查 AI 的操作是否安全
- 这种"用魔法打败魔法"的模式，减少了对传统专属工具的依赖
展望未来
Claude 智能的边界一直在狂奔拓荒。每当它完成一次能力上的跃迁，我们过去对它"做不到什么"的成见，都必须重新推翻再验证。
历史重演： Sonnet 4.5 一旦察觉到上下文快要塞满了，就会出现"恐慌"，然后草草结束任务。为了缓解它的"上下文焦虑症"，代码里硬加了强行清理上下文窗口的"重置"逻辑。
结果到了 Opus 4.5，这个毛病竟然自己不治而愈了！于是，当年煞费苦心写出来的"上下文重置"代码，瞬间变成了智能体框架里毫无用处的历史包袱（dead weight）。
苦涩的教训（the Bitter Lesson）： 过度依赖人类经验的手工规则，最终往往会拖累模型自身依靠算力进化出的能力。
灵魂问题：
"这一次，我又可以放手不管什么了？"
关联
- claude-code/overview — Claude Code 概览
- harness-engineering/overview — Harness Engineering
- claude-code/lessons-building-skills — 构建 Claude Code 的经验
Sources
- 驾驭 Claude 的智能 构建应用的 3 个关键模式【译】 — Anthropic 官方
- 编程智能体的核心组件【译】 — Sebastian Raschka