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

Harnessing Claude’s intelligenceAnthropic 的联合创始人之一 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 SleepWrap combo: KO FAST with BITE before Sleep Powder lands. Dontletitsetup!- 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. - B1Fy16wall CONFIRMED SOLID at ALLx9-28(step14557)翻译/gameplay/learnings.md - 喇叭芽的“睡眠粉捆绑” combo在睡眠粉命中之前**快速用咬住**将其击倒。不要让它有机会 setup - 第一世代背包限制最多20个道具。进入迷宫前扔掉不需要的招式学习器。 - 旋转地板迷宫不同的入口 y 坐标会通往**不同的**目的地。尝试所有入口并在多个格子间穿行。 - B1Fy16的墙壁**确认是实心的**覆盖所有x9-28步骤14557处验证。谨慎设定边界智能体框架围绕 Claude 提供结构以强制执行用户体验、成本或安全性。设计上下文以最大化缓存命中率Messages API 是无状态的。Claude 无法看到之前轮次的对话历史。这意味着智能体框架需要在每一轮中将新的上下文与所有过去的操作、工具描述和指令一起打包传递给 Claude。提示词可以基于设定的断点进行缓存。换句话说Claude API 会将直到断点处的上下文写入缓存并检查该上下文是否与任何已有的缓存条目匹配。由于缓存的 token 成本仅为基础输入 token 的 10%以下是智能体框架中帮助最大化缓存命中率的几个原则原则描述静态内容在前动态内容在后对请求进行排序使稳定的内容系统提示、工具放在前面。通过消息进行更新在消息中追加system-reminder而不是直接编辑提示词。不要切换模型在一个会话期间避免切换模型。缓存是模型特定的切换会破坏缓存。如果需要一个更便宜的模型请使用子智能体。谨慎管理工具工具位于缓存前缀中。添加或移除工具会使缓存失效。对于动态发现可使用工具搜索这种方式是追加操作不会破坏缓存。更新断点对于多轮应用例如智能体将断点移动到最新消息处以保持缓存为最新状态。可使用自动缓存来实现这一点。使用声明式工具来处理用户体验、可观测性或安全边界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