驾驭 Claude 的智能 | 构建应用的 3 个关键模式
来源: claude.com/blog | 作者: Lance Martin（原文）/ 宝玉（翻译） | 日期: 2026-04-03 原文链接: https://claude.com/blog/harnessing-claudes-intelligence
一句话总结
构建 Claude 应用的核心策略是：用 Claude 熟悉的通用工具（bash + 文本编辑器），把编排、上下文管理和记忆的控制权交还给模型本身，只在安全/UX/可观测性需要时才设定框架边界。
速览
- 用 Claude 熟悉的工具构建应用——bash 和文本编辑器是 Claude 最擅长的工具，所有高级能力（技能、编程式工具调用、记忆）都是它们的组合衍生
- 让模型自主编排工具调用——通过代码执行工具让 Claude 自己写代码串联工具，避免无用数据塞满上下文窗口
- 让模型管理自己的上下文——用技能库按需加载指令，用上下文编辑删除废旧信息，用子智能体隔离任务
- 让模型持久化自己的记忆——压缩技术和记忆文件夹让 Claude 自主决定保存什么，比外部 RAG 更高效
- 模型越强，框架越应精简——随着 Claude 进化，过去的”能力假设”会过时，框架中的补丁代码会变成负担
- 缓存命中率决定成本和延迟——静态内容前置、不中途换模型、谨慎增删工具、用 system-reminder 而非修改提示词
- 高危操作必须做成声明式专属工具——“是否可逆”是判断标准，不可逆操作需要用户确认闸门
- 持续反问”我可以放手不管什么”——每次模型升级后重新检验框架中的假设，砍掉过时的约束
核心内容
用 Claude 熟悉的工具，而非为它造新的
Lance Martin 指出，Claude 在 SWE-bench Verified 上创下 49% 行业最高分时，仅用了 bash 和文本编辑器两个工具。Claude Code 也基于同样的工具构建。这些工具并非为 AI 智能体设计，但 Claude 深度训练过它们，随着模型迭代会越来越熟练。
更关键的是，Claude 能将这两个通用工具组合出丰富的高级模式：智能体技能（Skills）本质是用文件系统存取指令集，编程式工具调用是用 bash 执行代码来串联 API，记忆工具是用文本编辑器读写文件。与其给 Claude 一堆它不熟悉的专用工具，不如让它用自己最擅长的积木搭出解决方案。
把编排权交还给模型，而非框架替它做决定
开发者常犯的错误是把每次工具调用的完整结果都塞回上下文窗口。Lance Martin 举例：为分析一个大表的某列，把整个表都给模型，既浪费 token 又拖慢速度。用硬编码过滤治标不治本——问题的根源是框架在替模型做编排决策。
解决方案是给 Claude 一个代码执行工具（bash 或 REPL），让它自己写代码来调用工具、过滤结果、串联流水线。只有最终精简结果才进入上下文窗口。这个模式的效果惊人：在 BrowseComp 测试中，赋予 Opus 4.6 过滤自身工具输出的能力后，准确率从 45.3% 飙升到 61.6%。
这意味着一个强大的编程模型天然就是一个强大的通用智能体——写代码是最灵活的编排方式。
让模型自己管理上下文的加载和清理
过去的做法是把所有可能用到的指令预先塞进系统提示词，但这消耗”注意力预算”——塞入太多信息会导致模型抓不住重点。
技能库（Skills）提供了更好的方案：只把每个技能的简短 YAML 摘要预加载到上下文，Claude 按需读取完整内容，实现”渐进式展开”。反方向的能力是上下文编辑（Context Editing），允许模型主动删除过时的工具结果或早期思考草稿。子智能体则让 Claude 能开启全新的干净上下文来隔离特定任务——Opus 4.6 使用子智能体后，BrowseComp 成绩比最好的单智能体方案还高 2.8%。
压缩和记忆文件夹让长任务不再”断片”
长时间运行的智能体容易耗尽上下文窗口。业界惯性思维是搭建外部 RAG 系统，但更有效的做法是让 Claude 自己决定保存什么。
压缩（Compaction）技术让 Claude 自主浓缩过去的上下文。模型迭代带来了显著提升：同样的 BrowseComp 任务，Sonnet 4.5 准确率卡在 43%，Opus 4.5 跃升到 68%，Opus 4.6 飙升至 84%。
记忆文件夹让 Claude 像记笔记一样存取关键信息。BrowseComp-Plus 测试中，仅给 Sonnet 4.5 一个记忆文件夹，准确率就从 60.4% 提升到 67.2%。
宝可梦游戏案例生动展示了记忆能力的进化：早期 Sonnet 3.5 生成 31 个凌乱文件，记录”绿毛虫没有毒性”这类无用信息，卡在第二个城镇。Opus 4.6 只生成 10 个按目录分类的文件，包含战术分析和经验教训文档，拿下 3 枚道馆徽章。
上下文工程：让缓存命中率拉满以控制成本
Messages API 无状态，每轮对话都要重新发送全部上下文。缓存断点（Breakpoints）可以避免重复计算，命中缓存的 token 价格只有基础价的 10%。
最大化缓存命中率的原则：静态内容（系统提示词、工具列表）放最前面；用 system-reminder 追加提醒而非修改原始提示词；不在会话中切换模型（缓存跟着模型走）；不随意增删工具（工具列表在缓存头部）；多轮对话中及时更新断点位置。
高危操作做成声明式专属工具，但不要过度
bash 工具的输出是不透明的命令行字符串，框架无法区分安全和危险操作。将关键动作做成专属的声明式工具，框架就能拿到结构化参数，实现拦截审查、权限闸门、UI 渲染和安全审计。
“是否可逆”是最佳判断标准：不可逆操作（如外部 API 调用）需要用户确认闸门；写入操作需要文件陈旧度检查；需要用户交互的动作可渲染为前端弹窗。
但这不是一锤子买卖。Claude Code 的自动模式用”第二个 Claude”审查 bash 命令的安全性，这种”AI 审查 AI”的模式减少了对传统专属工具的依赖。不过对于高危操作，专属工具仍然不可替代。
不断砍掉过时的框架约束
Lance Martin 分享了一个案例：Sonnet 4.5 会在上下文快满时”恐慌”并草草结束任务，团队为此写了强制重置上下文的代码。到了 Opus 4.5，这个问题自愈了，那段代码变成了无用的历史包袱。
这印证了 AI 界的”苦涩的教训”：过度依赖人类手工规则，最终会拖累模型自身进化出的能力。开发者应当不断审视框架中的约束，反复拷问：“这一次，我又可以放手不管什么了？“
名言金句
- “像 Claude 这样的生成式 AI 系统，与其说是被’制造’出来的，不如说是被’培育’出来的。” —— Chris Olah
- “一个强大的编程模型，自然也就是一个强大的通用 AI 智能体。”
- “你增加的每一个 token，都在无情消耗 Claude 的注意力预算。”
- “这一次，我又可以放手不管什么了？”
- “过度依赖人类经验的手工规则，最终往往会拖累模型自身依靠算力进化出的能力。” —— 苦涩的教训
可行建议
- 优先使用 bash + 文本编辑器工具构建 Claude 应用，而非引入 Claude 不熟悉的专用工具
- 给 Claude 代码执行工具，让它自己编排工具调用和数据流转，避免框架替模型做决定
- 用技能库替代冗长的系统提示词，按需加载上下文，节省注意力预算
- 为长任务启用压缩和记忆文件夹，让 Claude 自主管理长期记忆
- 缓存优化：静态内容前置、不中途换模型、用 system-reminder 追加而非修改提示词
- 只对不可逆的高危操作创建声明式专属工具，其余交给 Claude 自主处理
- 每次模型升级后审查框架约束，砍掉因模型变强而过时的补丁代码