驾驭 Claude 的智能：构建 AI Agent 的三大核心模式
快速阅读
Anthropic 联合创始人 Chris Olah 曾指出，像 Claude 这样的生成式 AI 系统与其说是“构建”出来的，不如说是“生长”出来的。这就给开发者带来了一个挑战：随着 Claude 能力的不断进化，我们在设计 Agent 架构时所做的“Claude 自己做不到”的假设很快就会过时。为了在智能、延迟和成本之间取得最佳平衡，本文分享了构建 AI Agent 应用时的三大核心模式：
- 利用 Claude 已掌握的工具（如 bash 和文本编辑器）。
- 问自己“有哪些工作可以交还给 Claude 自己完成？”（让它自己编排任务、管理上下文和持久化记忆）。
- 谨慎设置边界（利用提示词缓存机制，并通过声明式工具建立安全和 UX 边界）。
Anthropic 联合创始人 Chris Olah 认为，生成式 AI 系统与其说是“被构建”的，不如说是“被培育”的。研究人员设定了系统成长的条件，但其最终呈现的确切结构或能力并不总是可预测的。
这就给基于 Claude 进行应用开发带来了挑战：现有的 Agent 架构常常预设了“Claude 无法独立完成某些事情”，但随着模型能力的飞速进化，这些假设很快就会过时。因此，开发团队需要不断审视过去的经验。
本文分享了三种核心设计模式。它们能够帮助你在利用 Claude 不断进化的智能时，兼顾延迟和成本。
1. 利用 Claude 已掌握的工具
我们建议使用 Claude 已经非常熟悉的工具来构建应用。
在 2024 年底，Claude 3.5 Sonnet 在 SWE-bench Verified 榜单上达到了 49% 的当时的 SOTA 成绩。而它所依赖的，仅仅是一个基础的 bash 工具和一个用于查看、创建及编辑文件的文本编辑工具。Claude Code 同样也是基于这些基础工具构建的。
虽然 Bash 最初并非为构建 Agent 而设计，但它是 Claude 懂得如何使用的工具，并且随着时间推移，Claude 使用它的水平也在不断提高。
我们观察到，Claude 能够将这些通用工具组合成各种模式来解决不同的问题。例如，Agent Skills (智能体技能)、编程式工具调用以及记忆工具，本质上都是基于 bash 和文本编辑工具组合衍生出来的。
2. 问自己“有哪些工作可以交还给 Claude 自己完成？”
Agent 架构往往固化了我们对模型能力边界的认知。随着 Claude 变得更加强大，我们应当重新测试这些假设。
让 Claude 自行编排行动
一个常见的假设是：每一个工具调用的结果都必须流转回 Claude 的上下文窗口，以决定下一步动作。然而，如果某个工具的输出只是为了传递给下一个工具，或者 Claude 仅仅关注输出中的极小一部分，那么把所有结果都作为 Token 处理既缓慢、昂贵又不必要。
想象一下让模型读取一个巨大的数据表，仅仅为了分析其中的某一列：整个表都会进入上下文，导致在所有不需要的行上浪费 Token。在架构层面，把编排的权力交给最适合做决定的对象才是正解。
为 Claude 提供一个代码执行工具（比如 bash 工具或特定语言的 REPL）就能解决这个问题：它允许 Claude 编写代码来表达工具调用以及它们之间的逻辑关系。这样一来，不再是由系统强制要求所有工具结果都转化为 Token，而是由 Claude 自己决定过滤什么、传递什么，且这个过程完全不占用上下文窗口。只有最终需要的结果才会被输出到上下文里。
让 Claude 自行管理上下文
对于复杂任务，手写特定指令的“系统提示词”很难大规模扩展，因为每增加一个 Token 都在消耗 Claude 的注意力预算，预加载极少使用的冗长指令是一种浪费。
让 Claude 能够访问“技能（Skills）”解决了这一问题：在上下文窗口中只加载技能的简短描述（例如 YAML Frontmatter），当任务需要时，Claude 可以主动调用读取文件的工具，按需加载完整的技能指令。
与逐步添加上下文相对的是“上下文编辑”。它提供了一种方法，选择性地移除已经过时或不再相关的上下文（如早期的工具结果或思考过程）。此外，通过**子智能体（Subagents）**机制，Claude 越来越懂得在何时派生出一个全新的隔离上下文窗口，专门用于执行特定的子任务。
让 Claude 自行持久化记忆
运行周期较长的 Agent 往往会超出单个上下文窗口的限制。以前的普遍做法是在模型外部构建复杂的 RAG（检索增强生成）基础设施。但我们发现，给 Claude 提供简单的方法，让它自己决定要保留哪些信息，效果往往更好。
例如：
- 压缩（Compaction）：让 Claude 能够对过去的上下文进行总结，从而在长期任务中保持连贯性。
- 记忆文件夹（Memory Folder）：允许 Claude 将重要上下文以文件形式写入磁盘，并在未来需要时自主读取。
早期的模型可能只会把它当成会议记录，像流水账一样记录 NPC 说了什么；而更新版本的 Claude（如 Opus 4.6）则能够主动在目录中组织文件、记录战术笔记，并从失败中提炼出结构化的“经验教训”。
3. 谨慎设置系统边界
Agent 的系统架构应主要围绕用户体验 (UX)、成本和安全等要素为 Claude 提供外围框架。
优化上下文以最大化缓存命中率
由于 Messages API 是无状态的，Agent 框架需要在每次对话时将历史动作、工具描述和系统提示词全部重新打包发送。利用提示词缓存（Prompt Caching）机制，可以大幅降低这部分成本（缓存 Token 成本仅为基础输入 Token 的 10%）。
为最大化缓存命中率，Agent 架构应遵循以下原则：
- 静态在前，动态在后：请求内容排序时，保持稳定的部分（系统提示词、可用工具）在前。
- 通过消息追加更新：在消息对话中追加
<system-reminder>，而不是直接修改顶部的系统提示词。 - 不要在会话中途切换模型：缓存是针对特定模型的，切换模型会导致缓存失效。如果需要使用成本更低的模型处理特定子任务，请使用子智能体。
- 谨慎管理工具列表：工具往往位于缓存的前缀部分。增减工具会使缓存失效。对于动态需求，可以提供“工具搜索”功能，而不是频繁修改工具列表。
- 更新断点：针对多轮对话，启用自动缓存，保持将缓存断点移动到最新的消息上。
使用声明式工具划分安全与 UX 边界
Claude 发出的是纯粹的工具调用指令，而实际执行在应用端。像 bash 这样广泛的工具赋予了 Claude 强大的编程杠杆，但框架只能拿到一串命令字符。通过将关键动作抽象为专用工具（Dedicated Tools），不仅可以在框架层提供强类型的参数输入，还能方便地进行拦截、审计和用户交互。
- 安全边界：对于难以撤销的危险操作（例如调用外部 API 支付或发送邮件），应当设计为专用工具，并阻断 Agent 循环，强制等待用户确认。
- 用户体验 (UX)：某些工具的调用可以直接在前端渲染为弹窗、图表或交互式表单，向用户清晰呈现信息。
- 可观测性：基于明确参数定义的工具调用，让开发者更容易记录日志、进行追踪和后续回放。
总而言之，是否需要将某个动作剥离成专用工具，需要不断评估。比如，Claude Code 的 auto-mode 会让另一个 Claude 实例去审计 bash 命令是否安全，从而减少了对专用工具的强依赖。
展望未来
随着 Claude 智能边界的不断扩展，每一个版本的升级都会打破过去的限制。过去为了弥补模型缺陷而加入到 Agent 框架里的复杂逻辑（例如为了缓解“上下文焦虑”而加入的自动重置机制），可能会变成拖累模型性能的累赘。
随着时间的推移，我们最应该不断问自己的问题是：“我现在有哪些工作可以停下来，直接交给模型去做？”