驾驭 Claude 的智能（Harnessing Claude’s intelligence）

Harnessing Claude’s intelligence

Anthropic 的联合创始人之一 Chris Olah 表示 ，像 Claude 这样的生成式 AI 系统更多是成长而非构建。研究人员设定了引导增长的条件，但具体的结构或能力并不总是可预测的。

这给基于 Claude 的开发带来了一个挑战：智能体框架（agent harnesses）中编码了关于 Claude 自身无法完成哪些任务的假设，但随着 Claude 能力不断增强，这些假设会逐渐过时。即使是像本文这样分享的经验教训，也值得经常重新审视。
这句话的翻译如下：

在本文中，我们分享了三个模式，团队在构建应用程序时应当采用这些模式，以便跟上 Claude 不断发展的智能，同时在延迟和成本之间取得平衡：利用它已经掌握的知识，思考你可以停止做哪些事情，以及谨慎地通过智能体框架来设定边界。

利用 Claude 已知的知识

我们建议使用 Claude 熟知的工具来构建应用程序。在 2024 年底，Claude 3.5 Sonnet 仅借助一个bash 工具和一个用于查看、创建及编辑文件的文本编辑器工具，就在 SWE-bench Verified 测试中达到了 49% 的得分——这在当时是最先进的水平。Claude Code 也是基于这些相同的工具构建的。Bash 并非为构建智能体而设计，但它是 Claude 知道如何使用、并且随着时间推移会越来越擅长的工具。

不同版本的 Claude 模型在 SWE-bench Verified 基准测试中的得分，凸显了其能力的演进。

编程式工具调用、技能和记忆，都是由我们的 bash 和文本编辑器工具组合而成的。

问问自己“我可以停止做什么？

智能体框架中编码了关于 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 提供简单的方式，让它自己选择需要持久化哪些内容。
例如，压缩（compaction）功能让 Claude 能够总结自己过去的上下文，从而在长期任务中保持连续性。经过几个版本的迭代，Claude 在选择记住什么方面变得越来越擅长。以 BrowseComp（一个智能体搜索任务）为例，无论我们给 Sonnet 4.5 多大的压缩预算，它的准确率都稳定在 43%。然而在相同的设置下，Opus 4.5 的准确率提升到了 68%，而 Opus 4.6 则达到了 84%。
记忆文件夹（memory folder）是另一种方法，它允许 Claude 将上下文写入文件，并在需要时读取。我们已经看到 Claude 在智能体搜索中使用了这种方法。在 BrowseComp-Plus 上，给 Sonnet 4.5 配备一个记忆文件夹，将其准确率从 60.4% 提升到了 67.2%。

Claude 可以将上下文持久化到记忆文件夹中。

《宝可梦》这类长时程游戏，是 Claude 使用记忆文件夹能力提升的一个例证。Sonnet 3.5 将记忆当作逐字记录，写下的是非玩家角色（NPC）说的话，而不是真正重要的信息。在运行了 14,000 步之后，它生成了 31 个文件——其中有两个近乎重复的文件是关于毛毛虫类宝可梦的——而它仍然停留在第二个城镇。

caterpie_weedle_info: - Caterpie and Weedle are both caterpillar Pokémon. - Caterpie is a caterpillar Pokémon that does not have poison. - Weedle is a caterpillar Pokémon that does have poison. - This information is crucialforfuture encounters and battles. - If our Pokémon get poisoned, we should seek healing at a Pokémon Center as soon as possible.

翻译：

caterpie_weedle_info： - 绿毛虫和独角虫都是毛毛虫类宝可梦。 - 绿毛虫是一种毛毛虫类宝可梦，没有毒。 - 独角虫是一种毛毛虫类宝可梦，有毒。 - 这些信息对未来的遭遇战和对战至关重要。 - 如果我们的宝可梦中毒了，应尽快前往宝可梦中心治疗。

后来的模型则写下了战术笔记。Opus 4.6 在相同的步数下，拥有 10 个整理到目录中的文件、三枚 gym 徽章，以及一份从自身失败中提炼出的学习笔记文件：

/gameplay/learnings.md: - Bellsprout Sleep+Wrap combo: KO FAST with BITE before Sleep Powder lands. Don'tletitsetup!- Gen1Bag Limit:20items max. Toss unneeded TMs before dungeons. - Spin tile mazes: Different entry y-positions lead to DIFFERENT destinations. Try ALL entries and chain through multiple pockets. - B1Fy=16wall CONFIRMED SOLID at ALLx=9-28(step14557)

翻译：

/gameplay/learnings.md： - 喇叭芽的“睡眠粉+捆绑” combo：在睡眠粉命中之前，**快速用咬住**将其击倒。不要让它有机会 setup！ - 第一世代背包限制：最多20个道具。进入迷宫前扔掉不需要的招式学习器。 - 旋转地板迷宫：不同的入口 y 坐标会通往**不同的**目的地。尝试所有入口，并在多个格子间穿行。 - B1Fy=16的墙壁**确认是实心的**，覆盖所有x=9-28（步骤14557处验证）。

谨慎设定边界

智能体框架围绕 Claude 提供结构，以强制执行用户体验、成本或安全性。

设计上下文以最大化缓存命中率

Messages API 是无状态的。Claude 无法看到之前轮次的对话历史。这意味着智能体框架需要在每一轮中，将新的上下文与所有过去的操作、工具描述和指令一起打包传递给 Claude。提示词可以基于设定的断点进行缓存。换句话说，Claude API 会将直到断点处的上下文写入缓存，并检查该上下文是否与任何已有的缓存条目匹配。
由于缓存的 token 成本仅为基础输入 token 的 10%，以下是智能体框架中帮助最大化缓存命中率的几个原则：

使用声明式工具来处理用户体验、可观测性或安全边界

Claude 未必知道应用程序的安全边界或用户体验界面。Claude 发出工具调用，由框架进行处理。bash 工具为 Claude 提供了广泛的编程能力来执行操作，但给框架的只是一个命令字符串——每次操作的形式都一样。将操作提升为专用工具，就能为框架提供一个带有类型化参数的、特定于该操作的钩子，框架可以拦截、门控、渲染或审计这些参数。需要安全边界的操作自然适合做成专用工具。可逆性通常是一个很好的判断标准，而难以逆转的操作（如外部 API 调用）可以通过用户确认来进行门控。像 edit 这样的写入工具可以包含一个过时检查，以防止 Claude 覆盖自上次读取后已更改的文件。

专用工具可用于基于安全、用户体验或可观测性考虑的操作。

*当某个操作需要呈现给用户时，工具也很有用。例如，工具可以渲染为一个模态框，向用户清晰地展示问题，给用户多个选项，或者在用户提供反馈之前阻塞智能体的循环。最后，工具对于可观测性也很有用。当操作是一个类型化的工具时，框架就能获得结构化的参数，从而可以对其进行日志记录、追踪和回放。
是否将操作提升为工具这一决定，应当持续地重新评估。例如，Claude Code 的 auto 模式（在本文发布时处于研究模式）为 bash 工具提供了一个安全边界：它让另一个 Claude 读取命令字符串并判断其是否安全。这种模式可以减少对专用工具的需求，并且只应在用户信任大方向的任务中使用。但对于某些高风险的操作，专用工具仍然有其一席之地。

展望

Claude 智能的前沿始终在变化。关于 Claude 不能做什么的假设，需要随着其能力的每一次阶跃式提升而重新检验。
我们看到这种模式在不断重演。在我们为长时程任务构建的一个智能体中，Sonnet 4.5 在感知到上下文窗口接近极限时会提前草草收尾。我们添加了重置机制来清空上下文窗口，以解决这种“上下文焦虑”。到了 Opus 4.5，这个行为已经消失了。我们为弥补这一缺陷而构建的上下文重置机制，在智能体框架中反而变成了累赘。

移除这些累赘很重要，因为它们可能会成为 Claude 性能的瓶颈。随着时间的推移，我们应用程序中的结构或边界应当基于这样一个问题来修剪：我可以停止做什么？**

参考

Harnessing Claude’s intelligence