Anthropic 联合创始人之一 Chris Olah 表示，像 Claude 这样的生成式 AI 系统更多是“生长”而非“构建”出来的。研究人员设定了引导其发展的条件，但具体涌现出的结构或能力往往不可预测。
这给基于 Claude 的应用开发带来了挑战：代理框架（agent harness）编码了对 Claude 自身能力不足的假设，但随着 Claude 能力的提升，这些假设会逐渐过时。即使是本文这类文章中的经验教训，也需要定期重新审视。
在本文中，我们将分享三个适用于构建能够跟上 Claude 不断演进智能、同时兼顾延迟与成本的应用的设计模式：善用其已有知识、思考“可以停止做什么”、以及谨慎地为代理框架设定边界。
1. 善用 Claude 的既有知识
我们建议利用 Claude 理解良好的工具来构建应用。
截至 2024 年底，Claude 3.5 Sonnet 在 SWE-bench Verified 基准测试中达到 49% 的成绩——当时属于 业界顶尖水平——仅依靠一个 Bash 工具 和一个 文本编辑器工具 即可查看、创建和编辑文件。Claude Code 正是基于这些相同工具构建的。尽管 Bash 并非专为构建智能体而设计，但它是一个 Claude 擅长使用的工具，并且随着时间推移越来越熟练。
SWE-bench Verified 基准测试上各版本 Claude 模型得分的演变趋势
我们发现 Claude 能将这些通用工具组合成解决不同问题的模式。例如，Agent Skills、程序化工具调用 和 记忆工具 均是由 Bash 工具和文本编辑器工具组合而成。
程序化工具调用、技能和记忆功能都是我们 Bash 工具和文本编辑器工具的复合应用
2. 思考“我可以停止做什么？”
代理框架编码了对 Claude 无法独立完成任务的假设。随着 Claude 能力的增强，这些假设应被持续验证。
让 Claude 自主编排其操作
一个常见假设是每个工具的结果都应流经 Claude 的 上下文窗口 以指导下一步行动。将工具结果处理为 token 的过程可能缓慢、昂贵且没有必要——如果 Claude 只需将其传递给下一个工具，或者只关心输出的一小部分。
Claude 调用工具，这些工具在一个环境中执行
考虑读取大型表格以分析单列数据：整个表格都会被加载到上下文中，而 Claude 会为每一行不需要的数据支付 token 成本。虽然可以通过工具设计中的 硬编码过滤器 来解决这个问题，但这并未触及一个关键事实：代理框架正在做出一项 编排决策，而 Claude 实际上更适合做出这项决策。
赋予 Claude 代码执行 工具（例如 Bash 工具 或 特定语言的 REPL）可解决此问题：它允许 Claude 编写代码来表达工具调用及其间的逻辑。这样就不必由框架决定每个工具调用的结果都必须作为 token 处理，而是让 Claude 自行决定哪些结果需要通过上下文窗口传递、过滤或直接输入到下一次调用中。只有代码执行的结果才会进入 Claude 的上下文窗口。
Claude 可以编写表达工具调用及其间逻辑的代码
编排决策从框架转移到了模型本身。由于代码是 Claude 协调动作的一种通用方式，因此强大的编码模型也意味着强大的 通用 智能体。Claude 在此模式中表现出色：在 BrowseComp（一项测试智能体网页浏览能力的 基准测试）上，给予 Opus 4.6 自主过滤其工具输出的能力后，准确率从 45.3% 提升至 61.6%。
让 Claude 自主管理其上下文
特定任务的上下文可引导 Claude 对通用工具（如 Bash 和文本编辑器工具）的使用。一个常见假设是 系统提示词 应针对具体任务手工定制。问题是：预先加载带有指令的提示词难以扩展至大量任务——每增加一个 token 都会消耗 Claude 的注意力预算，而预加载很少使用的指令则是一种浪费。
赋予 Claude 访问 技能 的能力可解决此问题：每个技能的 YAML 前置元数据会被预先加载到上下文窗口中，提供技能内容的概览。当任务需要时，Claude 可通过调用读取文件工具逐步披露完整技能内容。
Claude 可利用技能逐步披露与任务相关的上下文
虽然技能赋予 Claude 自由组装其上下文窗口的权利，但 上下文编辑 则是反向操作，提供了一种选择性移除陈旧或不相关上下文的方法，例如过时的工具结果或思考块。
借助 子智能体，Claude 正变得越来越擅长判断何时应开启新的上下文窗口以隔离特定任务的工作流程。📚 在 Opus 4.6 中，子智能体的能力使 BrowseComp 上的表现比最佳单智能体运行提升了 2.8%。
让 Claude 自主持久化其上下文
长时间运行的智能体可能超出单个 上下文窗口 的限制。一个常见假设是记忆系统应依赖围绕模型的检索基础设施。我们的许多工作都聚焦于为 Claude 提供简单的方式，使其能 自行选择 需要持久化的内容。
例如，压缩机制 允许 Claude 总结其过往上下文，从而在长周期任务中保持连续性。经过多个版本的迭代，Claude 已能更好地判断哪些内容值得记住。📚 在 BrowseComp 任务中，Sonnet 4.5 无论分配多少压缩预算，准确率始终稳定在 43%；然而 Opus 4.5 在同一设置下可扩展至 68%，Opus 4.6 更是达到了 84%。
另一种方法是使用 记忆文件夹，允许 Claude 将上下文写入文件并在后续按需读取。我们在代理搜索任务中观察到 Claude 使用此功能。在 BrowseComp-Plus 上，为 Sonnet 4.5 配备记忆文件夹后，📚 准确率从 60.4% 提升至 67.2%。
Claude 可将上下文持久化到记忆文件夹
▶ 长周期游戏（如 Pokémon）展示了 Claude 改进的记忆文件夹使用能力。Sonnet 3.5 将记忆视为对话记录，记录 NPC 所说的一切而非关键信息。经过 14,000 步后，它创建了 31 个文件——包括两个关于毛毛虫宝可梦的近乎重复的信息——仍停留在第二个城镇：
caterpie_weedle_info:
- Caterpie 和 Weedle 都是毛毛虫宝可梦。
- Caterpie 是毛毛虫宝可梦，没有毒性。
- Weedle 是毛毛虫宝可梦，具有毒性。
- 这些信息对未来遭遇战和战斗至关重要。
- 若我方宝可梦中毒，应尽快前往宝可梦中心治疗。
后续模型开始撰写战术笔记。Opus 4.6 在相同步数下拥有 10 个文件，并组织了目录结构，记录了三个道馆徽章及一份从自身失败中提炼的学习总结：
/gameplay/learnings.md:
- Bellsprout Sleep+Wrap 组合技：在 Sleep Powder 生效前用 BITE 快速 KO
- 第一代背包容量限制：最多 20 项物品。进入地牢前丢弃无用 TM。
- 旋转瓷砖迷宫：不同入口的 y 坐标会导致完全不同的目的地。尝试所有入口并串联多个口袋。
- B1F y=16 处的墙在 x=9-28 范围内（第 14557 步）被确认为实体墙
3. 谨慎设定边界
代理框架为 Claude 提供了结构化支持，以实现用户体验、成本控制或安全管控。
设计上下文以最大化缓存命中率
Messages API 是无状态的。Claude 无法看到之前轮次的对话历史。这意味着在每个回合中，代理框架都需要将新上下文与所有过往操作、工具描述和指令一并打包提供给 Claude。
提示词可根据设定的 断点 进行缓存。换言之，Claude API 会将上下文内容写入缓存，直到遇到断点为止，并检查该上下文是否与任何先前缓存条目匹配。
由于缓存 token 的成本仅为基础输入 token 的 10%，以下是帮助代理框架最大化缓存命中率的几个原则：
| 原则 | 说明 |
|---|
| 静态优先，动态在后 | 将请求排序，使稳定内容（系统提示词、工具定义）靠前排列。 |
| 消息更新 | 使用 messages 追加更新，而非直接修改提示词。 |
| 勿切换模型 | 避免在会话期间切换模型。缓存是模型特定的，切换会破坏缓存。如需更便宜模型，请使用子智能体。 |
| 谨慎管理工具 | 工具位于缓存前缀中，添加或删除任一工具都会使缓存失效。对于动态发现，请使用 tool search，它不会破坏缓存。 |
| 更新断点 | 对于多轮应用（如智能体），将断点移至最新消息以保持缓存最新。可使用自动缓存实现此目的。 |
使用声明式工具实现 UX、可观测性或安全边界
Claude 通常不了解应用程序的安全边界或用户界面。它发出工具调用，由代理框架处理。Bash 工具赋予 Claude 广泛的编程能力来执行操作，但仅向框架传递命令字符串——这对所有操作都是相同的格式。将操作升级为专用工具可为框架提供带类型参数的特定操作钩子，使其能够拦截、管控、渲染或审计这些操作。
需要安全边界的操作自然适合升级为专用工具。可逆性通常是良好标准，而难以逆转的操作（如外部 API 调用）可通过用户确认加以管控。诸如 edit 类的写入工具可包含陈旧性检查，防止 Claude 覆盖自上次读取以来发生变更的文件。
专用工具可用于基于安全、UX 或可观测性考量的操作
当需要将操作呈现给用户时，工具也非常有用。例如，它们可作为模态框显示清晰的问题、为用户提供多种选项，或阻塞智能体循环直至用户反馈。
最后，工具对可观测性也很有价值。当操作为带类型的工具时，代理框架可获得结构化参数，便于日志记录、追踪和回放。
是否应将操作升级为工具的决定应持续重新评估。例如，Claude Code 的 auto-mode（发布时为研究模式）为 Bash 工具设置了安全边界：它引入第二个 Claude 审查命令字符串并判断其安全性。这种模式可 减少 对专用工具的需求，但仅应在用户信任总体方向的任务中使用。某些高风险操作仍需专用工具发挥作用。
展望未来
Claude 的智能前沿始终处于变化之中。每次能力跃迁后，对其能力局限的假设都必须重新验证。
我们观察到这一模式反复出现。在我们为长周期任务开发的 智能体 中，Sonnet 4.5 会在感知到接近上下文限制时 prematurely 结束任务。我们通过添加重置机制清空上下文窗口来解决这种“上下文焦虑”。但在 Opus 4.5 中，该行为已消失。我们为补偿此问题构建的上下文重置功能已成为代理框架中的冗余负担。
移除这种冗余负担很重要，因为它可能成为瓶颈 制约 Claude 的性能。随着时间的推移，我们的应用中结构和边界应基于一个问题进行修剪：我可以停止做什么？
要使用本文讨论的所有工具和模式，请查看我们的 claude-api 技能。
致谢
本文由 Claude 平台团队技术成员 Lance Martin 撰写。特别感谢 Thariq Shihipar、Barry Zhang、Mike Lambert、David Hershey 和 Daliang Li 就所述主题提供的有益讨论。感谢 Lydia Hallie、Lexi Ross、Katelyn Lesse、Andy Schumeister、Rebecca Hiscott、Jake Eaton、Pedram Navid 和 Molly Vorwerck 的编辑审阅与反馈。
