Claude团队分享构建AI应用时应遵循的三个模式｜Anthropic

Created time

Apr 3, 2026 08:29 AM

1. 利用 Claude 已有的知识

我们建议：用 Claude 本就熟悉的工具来构建应用。

2025 年初，Claude 3.5 Sonnet 在 SWE-bench Verified 基准测试中以 49% 的得分创下当时最优纪录——而它当时仅使用了 bash 工具，以及用于查看、创建和编辑文件的文本编辑工具。Claude Code 也是基于这套工具构建的。Bash 并非专为智能体设计，但它是 Claude 熟知且能持续优化使用的工具。

Claude 模型版本在 SWE-bench Verified 基准测试中的得分，清晰呈现了其进化轨迹。

我们观察到，Claude 会将这些通用工具自由组合，形成解决不同问题的模式。例如，智能体技能（Agent Skills）、程序化工具调用和记忆工具，本质上都是 bash 与文本编辑工具的不同组合方式。

程序化工具调用、技能和记忆，都是 bash 与文本编辑工具的组合形式。

2. 询问"哪些工作我可以停止？"

智能体框架对 Claude 独立工作的能力做了诸多假设。随着 Claude 能力不断提升，这些假设都应该被重新测试。

一个常见假设是：每个工具的运行结果都必须返回到 Claude 的上下文窗口，才能指导下一步行动。 然而，将工具结果逐一处理成 Token，既慢又贵。如果结果只是传递给下一个工具，或者 Claude 只关心输出的一小部分，这种处理开销完全是多余的。

Claude 调用工具，工具在环境中执行。

设想一个场景：为了分析某一列数据，Claude 读取了一张大表——整张表都会进入上下文，那些用不到的行也在白白消耗 Token 预算。虽然可以在工具设计中加入硬编码过滤器来规避，但这治标不治本，因为框架正在替 Claude 做编排决策，而 Claude 本身更适合承担这件事。

给 Claude 一个代码执行工具（如 bash 或特定语言的 REPL）可以从根本上解决这个问题。它允许 Claude 用代码来表达工具调用及其中间逻辑——由 Claude 自己决定哪些结果需要传递、过滤或管道转发，无需经过上下文窗口。只有代码执行的最终输出才会进入 Claude 的上下文。

Claude 可以编写代码来表达工具调用及其间的逻辑。

这意味着，编排决策从框架转移到了模型本身。由于代码是 Claude 编排行动的通用方式，一个强大的编程模型，同时也是一个强大的通用智能体。Claude 在非编程评估中同样印证了这一点：在测试智能体网页浏览能力的 BrowseComp 基准测试中，让 Opus 4.6 能够过滤自己的工具输出，使其准确率从 45.3% 提升到了 61.6%。

特定任务的上下文，引导着 Claude 使用 bash 等通用工具。通常认为，系统提示词应包含针对特定任务的手写指令。但问题在于，预加载指令的方式无法规模化扩展：每增加一个 Token 都在消耗 Claude 的注意力预算，而预加载那些很少用到的指令更是一种浪费。

让 Claude 访问"技能（skills）"是解决方案之一。每个技能的 YAML 前置内容都是一段简短描述，预加载到上下文窗口中，提供技能内容的总览。当任务需要时，Claude 可以主动调用文件读取工具，按需获取完整的技能内容。

Claude 通过技能机制，按需逐步加载与任务相关的上下文。

技能让 Claude 能自由组装上下文；而"上下文编辑（context editing）"则提供了另一个维度——选择性删除已过时或不再相关的内容（如旧的工具结果或思考块）。

通过子智能体（subagents），Claude 越来越擅长判断何时需要开启一个全新的上下文窗口，来隔离处理特定任务。在 Opus 4.6 中，生成子智能体的能力使 BrowseComp 的结果比最优单智能体运行提升了 2.8%。

长时间运行的智能体可能会超出单个上下文窗口的承载上限。通常的思路是依赖模型外部的检索基础设施来支撑记忆。而我们的重点是：让 Claude 拥有简单的方式，由它自主决定保留哪些内容。

"压缩（compaction）"功能允许 Claude 对过去的上下文进行总结，从而在长周期任务中保持连续性。经过多个版本迭代，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%。

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

《宝可梦》这类长周期游戏，直观展示了 Claude 在记忆文件夹使用上的代际进化。

Sonnet 3.5 将记忆用作转录本，记录 NPC 说了什么，而非真正重要的信息。走了 14,000 步之后，它生成了 31 个文件（包括两个关于毛球宝可梦的重复文件），却仍停留在第二个城镇：

而后续版本则会编写战术笔记。同样步数下，Opus 4.6 拥有 10 个按目录组织的文件夹、三个道馆徽章，以及一份从失败中提炼出的经验文件：

3. 谨慎设定边界

智能体框架在 Claude 周围构建结构，以强制执行 UX、成本或安全策略。

Messages API 是无状态的——Claude 看不到历史轮次的对话记录。这意味着框架每一轮都需要把新的上下文，连同过去所有的行动、工具描述和指令，一并打包发给 Claude。

提示词可以根据设定的断点（breakpoints）进行缓存。Claude API 会将断点之前的上下文写入缓存，并与之前的缓存条目进行匹配校验。缓存 Token 的成本仅为基础输入 Token 的 10%。 以下是框架中最大化缓存命中率的几个原则：

原则	描述
静态在前，动态在后	调整请求顺序，让稳定的内容（系统提示词、工具）排在前面。
使用消息进行更新	在消息中附加 `<system-reminder>`，而不是直接修改提示词。
不要更换模型	避免在会话中切换模型。缓存是特定于模型的，切换会导致缓存失效。如果需要更便宜的模型，请使用子智能体。
谨慎管理工具	工具位于缓存前缀中。添加或删除工具会使缓存失效。对于动态发现，请使用工具搜索，它可以在不破坏缓存的情况下进行追加。
更新断点	对于多轮应用（如智能体），将断点移动到最新消息，以保持缓存更新。建议使用自动缓存功能。

Claude 并不一定了解应用的安全边界或 UX 界面。Claude 发出工具调用，由框架负责处理。Bash 工具赋予了 Claude 强大的执行能力，但对框架而言，每种操作的形态都一样——只是一个命令行字符串。 将操作提升为专用工具，可以为框架提供特定于操作的钩子（hook）和类型化参数，从而支持拦截、管控、渲染或审计。

需要安全边界的操作，是专用工具的理想场景。 可逆性通常是一个好的衡量标准：对于难以逆转的操作（如外部 API 调用），可以通过用户确认来加以管控。像 edit 这样的写入工具，可以内置陈旧性检查，防止 Claude 覆盖自上次读取以来已被修改的文件。

专用工具可用于需要安全管控、UX 呈现或可观测性追踪的操作。

当操作需要向用户展示时，工具同样大有用处——它们可以渲染为模态框，清晰呈现问题，提供多个选项，或阻塞智能体循环直到用户给出反馈。此外，当操作以类型化工具的形式呈现时，框架可以获得结构化参数，从而方便地进行日志记录、链路追踪和回放，大幅提升可观测性。

是否将操作提升为专用工具，这个决策应该持续重新评估。 例如，Claude Code 的自动模式（发布时仍处于研究阶段）为 bash 工具提供了安全边界：它让第二个 Claude 读取命令行字符串并判断其是否安全。这种模式可以减少对专用工具的依赖，但应仅用于用户信任整体方向的任务。对于某些高风险操作，专用工具的价值依然不可替代。

展望未来

Claude 的智能边界一直在移动。每当其能力出现阶跃式提升，所有关于 Claude "不能做什么"的假设都需要重新接受检验。

这种模式在不断重演。在我们为某个长周期任务构建的智能体中，Sonnet 4.5 一旦感知到上下文接近上限，就会提前结束任务。为了解决这种"上下文焦虑"，我们专门添加了重置功能来清空上下文窗口。但到了 Opus 4.5，这一行为彻底消失了——我们为了弥补缺陷而构建的那套重置机制，反而成了框架里多余的累赘。

清理这些累赘至关重要，因为它们可能反过来成为 Claude 性能的瓶颈。我们应该随着时间推移，持续用"哪些工作我可以停止？"这个问题，不断精简应用中多余的结构和边界。

要使用此处讨论的所有工具和模式，请查看我们的 claude-api 技能。