驾驭 Claude 智能的三大核心模式：从“套壳”到“培育”的应用重构指南

构建基于 Claude 的应用，最核心的策略不是用复杂的智能体框架去“修补”它，而是顺应其被“培育”出来的进化特性，用最简练的工具组合释放其原生能力。生成式 AI 系统与其说是被“制造”出来的，不如说是被“培育”出来的。研究人员设定好引导它们生长的条件，但最终会演化出怎样的确切结构或能力，往往是无法准确预测的。
这种特性给开发者带来了巨大的挑战。长期以来，我们习惯于使用各种 AI 套壳或智能体框架来弥补模型自身的不足。然而，这些框架往往基于各种“假设”构建，随着 Claude 能力的不断进化，这些陈旧的假设很快就会过时，甚至反过来成为束缚模型发挥的枷锁。
本文将深入探讨构建 Claude 应用时应采用的三个核心模式。这些模式能帮助你的应用跟上其智能进化的步伐，同时兼顾延迟和系统成本。

图片来源：Unsplash

模式一：如何最大化利用 Claude 已知的技能？

精炼摘要： 放弃追求花哨的专属工具，回归 Claude 最熟悉的基础工具（如 Bash 和文本编辑器），通过模型自身的组合能力解决复杂问题。
核心问题：为什么在构建 Claude 应用时，最简单的工具反而能产生最强大的效果？
我们强烈建议，使用 Claude 已经非常熟悉的工具来构建你的应用。时间拉回 2024 年底，Claude 3.5 Sonnet 在 SWE-bench Verified（一个用于评估 AI 解决真实软件工程问题能力的权威基准测试）上达到了 49% 的得分，创下了当时的最佳纪录。
令人惊讶的是，取得这一成就的底层架构极其简单：它仅仅使用了一个 Bash 工具（一种允许 AI 在计算机命令行中执行指令的工具）和一个用于查看、创建和修改文件的文本编辑器工具。Anthropic 的官方编程助手 Claude Code 也是基于这些同样的工具构建的。
这两个基础工具最初并非为构建 AI 智能体而设计，但它们却是 Claude 深谙此道的工具，并且随着时间的推移，Claude 驾驭它们的技巧会越来越纯熟。我们发现，Claude 能够将这些通用工具组合成极其丰富的模式，以此来解决各种复杂问题。例如，编程式工具调用、技能管理和记忆工具，本质上都是由基础的 Bash 和文本编辑器工具组合衍生而来的。

各个版本 Claude 模型在 SWE-bench Verified 基准测试中的得分，直观地展现了它的进化之路。开发者不需要为它量身定制复杂的“解题器”，只需给足基础工具，它自己能演化出解题路径。

编程式工具调用、技能和记忆工具，其实都是 Bash 和文本编辑器工具的精妙组合。这种从简单到复杂的涌现能力，是“培育”理念的最好体现。

反思与见解： 在实际工程中，我们常常陷入“工具焦虑”，总以为 Claude 表现不好是因为缺少某个专属工具。但看到 SWE-bench 的数据后我意识到，很多时候是我们人类低估了基础工具的边界。与其花大量时间开发维护复杂的定制化工具接口，不如把精力放在优化上下文环境上，让模型用最顺手的“刀”去切菜。

模式二：在应用开发中，我们可以放手不管什么？

精炼摘要： 停止在外层框架中做微观管理，将流程编排、上下文管理和记忆持久化的控制权交还给 Claude 自身。
核心问题：随着 Claude 变得越来越强大，开发者应该删除智能体框架中的哪些过度保护逻辑？
我们过去常常低估 Claude 的能力，认为它这也不行，那也不行。随着模型能力的跃升，是时候去重新检验这些陈旧的假设了。

让 Claude 自主编排行动，拒绝外层框架的强制喂食

大家常犯的一个错误假设是：认为每次调用工具返回的结果，都必须立刻塞回 Claude 的上下文中，好让它决定下一步干嘛。
想象一个真实的数据处理场景：为了分析一个庞大数据表中的某一列，你把整个表格都扔给了模型。结果是整个表格塞满了上下文，而你要为 Claude 根本不需要的那些行支付高昂的 token 费用。虽然你可以在工具开发时加入参数来限制返回行数，但这治标不治本。问题的核心在于：外层的智能体框架正在替模型做编排决策，而现实是，Claude 自己才是做这个决定的最佳人选。

Claude 调用工具，随后这些工具在特定的环境中执行。把所有的工具结果都转化成词元给模型处理，不仅速度慢、成本高，而且往往毫无必要。
只要给 Claude 开放一个代码执行工具（比如 REPL 或 Jupyter Notebook），难题就迎刃而解：它允许 Claude 自己写代码来执行工具调用，并亲自处理这些工具之间的数据流转逻辑。与其让框架强制把所有结果都喂给上下文，不如让 Claude 决定哪些结果直接略过、哪些进行过滤，或者哪些直接像流水线一样输入给下一次调用。全程无需弄脏宝贵的上下文窗口，只有最终代码执行得出的精简结果，才会真正进入 Claude 的视野。

Claude 能够亲自编写代码，来控制工具的调用并串联它们之间的逻辑。在这个过程中，流程编排的指挥棒从外层框架交还给了大语言模型本身。
在 BrowseComp（一个测试智能体浏览网页能力的基准测试）中，当我们赋予 Opus 模型过滤自身工具输出的能力后，它的准确率直接从 45.3% 狂飙到了 61.6%。这证明一个强大的编程模型，自然也就是一个强大的通用 AI 智能体。

图片来源：Unsplash

让 Claude 管理自己的上下文，告别填鸭式提示词

针对特定任务的上下文提示，能指引 Claude 更好地使用基础工具。过去我们总以为，必须针对每个任务，手工雕琢极其详细的提示词。然而，这种提前把指令“填鸭式”塞进提示词的做法，在面对海量任务时根本行不通：你增加的每一个 token，都在无情消耗模型的注意力（相当于模型的脑力，塞入太多无用信息会导致模型抓不住重点），提前加载那些百年不用一次的指令，纯粹是浪费资源。
赋予 Claude 访问技能库的能力，完美破解了这个僵局：现在，只需把每个技能简短的 YAML 头部信息（类似目录摘要）预先加载到上下文窗口中，让 Claude 知道有哪些技能可用即可。如果当前任务需要，Claude 会主动调用读取文件的工具，将完整的技能内容进行“渐进式展开”（按需加载）。

Claude 会借助技能库，根据任务需求逐步展开相关的上下文。如果说技能让 Claude 拥有了自由拼装上下文的能力，那么上下文修剪则是相反的艺术：它提供了一种机制，允许模型选择性地删掉那些过时或不再相关的废话，比如陈旧的工具执行结果，或者自己早期的思考草稿。
不仅如此，有了子智能体的协助，Claude 越来越懂得何时应该“另起炉灶”——开启一个干干净净的全新上下文窗口，来隔离并专注处理某项特定任务。这种召唤子智能体的机制，让其在 BrowseComp 测试上的成绩，比表现最好的单智能体方案还提升了 2.8%。

让 Claude 持久化自己的上下文，替代复杂的外部 RAG

对于需要长时间运行的智能体，很容易耗尽单一上下文窗口的容量。业界普遍以为，这时候必须在模型外部搭建一套复杂的检索架构（例如 RAG）来充当记忆系统。但我们的大量研究表明：更聪明的做法是给 Claude 提供简便的工具，让它自己决定哪些内容值得保存下来。
上下文压缩技术允许 Claude 自己对过去的上下文进行浓缩总结，从而在马拉松式的长周期任务中不至于“断片”。经历了几轮模型迭代，Claude 挑选记忆内容的眼光越来越准。在自主探索型的搜索任务中，以前无论给早期模型多少压缩预算，准确率死活卡在 43%。但在同样的配置下，后续的强大模型跃升到了 68%，而最新版本更是飙升至了 84%。
引入记忆文件夹则是另一种妙招。它允许 Claude 像记笔记一样，把重要的上下文写成文件存起来，需要的时候再去读取翻看。在智能体搜索任务中见证了它的威力：在 BrowseComp-Plus 测试中，仅仅是给了模型一个记忆文件夹，就让它的准确率实现了显著提升。

Claude 可以将重要的上下文持久化保存到记忆文件夹中。
实际案例：让 Claude 玩《宝可梦》的启示
让 AI 玩《宝可梦》这样的长周期游戏，是展示 Claude 记忆文件夹利用能力飞跃的绝佳案例。
早期的 Claude 3.5 Sonnet 简直把记忆当成了会议速记，只会傻乎乎地记录游戏里 NPC 说了什么废话，根本抓不住重点。玩了 14,000 步之后，它生成了 31 个凌乱的文件——甚至包括两份几乎一模一样的关于毛毛虫宝可梦的无聊笔记——而且游戏进度悲催地卡在第二个城镇：

// 早期模型的低效记忆示例
caterpie_weedle_info (绿毛虫和独角虫信息): 
- 绿毛虫 和独角虫 都是毛毛虫形态的宝可梦。
- 绿毛虫是没有毒性的。
- 独角虫是有毒性的。
- 这些信息对未来的相遇和战斗至关重要。
- 如果我们的宝可梦中毒了，我们需要尽快去宝可梦中心治疗。

而当我们派上后期的强大模型时，画风突变，它开始记起“硬核战术笔记”。同样的 14,000 步，新模型只生成了 10 个井井有条、按目录分类的文件。它不仅横扫拿下了 3 枚道馆徽章，甚至还从自己踩过的坑里，提炼出了一份专门的“经验教训”文档：

// 强大模型的高效战术记忆示例
/gameplay/learnings.md (游戏/经验教训.md): 
- 喇叭芽的催眠粉+紧束连招：必须在它催眠粉命中前，用“咬住”快速击倒它。绝对不能让它布置战术！
- 第一世代背包限制：最多只能放 20 个道具。进迷宫前一定要把没用的技能机器 扔掉。
- 旋转地砖迷宫：不同的入口 y 坐标会导致完全不同的终点。尝试所有入口，并在多个口袋空间中穿梭。
- B1F y=16 墙壁确认是实体的，范围覆盖所有 x=9-28（第 14557 步记录）

图片来源：Unsplash

反思与见解： 这个《宝可梦》的案例深深震撼了我。从“记录废话”到“提炼战术规则”，这不仅仅是记忆能力的提升，更是模型认知维度的进化。过去我们总想着在外部用向量数据库去“喂”信息，现在看来，最高效的记忆系统，其实是模型自身具备的“信息降噪与抽象能力”。给模型一个简单的文件夹，它还你一套战术百科。

模式三：如何为 Claude 框架谨慎设定边界？

精炼摘要： 外层框架用于保障安全、控制成本和优化体验，但必须通过精细的上下文工程和声明式工具设计来实现，避免粗暴干预。
核心问题：在赋予 Claude 极大自主权的同时，如何通过框架设计守住安全底线并优化系统性能？
外层的智能体框架相当于给 Claude 穿上了一层约束衣，目的通常是为了保障用户体验、控制花销，或者是守住安全底线。

巧用上下文工程，将缓存命中率拉满

Claude 是无状态的。这意味着 Claude 本身就像拥有“金鱼的记忆”，它看不到之前的对话历史。因此，在每一轮对话中，外层框架都必须像个尽职的快递员，把新的上下文连同之前所有的动作记录、工具说明以及给 Claude 的指令，一并打包重新发送过去。
为了避免重复劳动和高昂成本，我们可以通过设置断点来缓存提示词。Claude API 会把断点之前的所有上下文内容写进缓存里，并在下一次请求来的时候，检查当前内容是否与之前的缓存相匹配。要知道，命中缓存的 token 价格仅仅是正常价格的十分之一！
为了帮你的应用既省钱又提速，以下是在智能体框架中最大化缓存命中率的几条黄金原则：

原则	具体描述与操作指南
静态内容在前，动态内容在后	安排请求顺序时，必须将稳定的内容（如系统提示词、工具列表）放在最前面。
用消息来更新	如果需要提醒模型，请在消息末尾追加一个 <system-reminder>，绝不能去修改原始的提示词（修改前面会导致整个缓存失效）。
别中途换模型	避免在同一个会话中切换不同的模型。缓存是跟着特定模型走的；一旦切换，缓存全盘作废。如果需要一个更便宜的模型处理简单任务，请使用子智能体。
谨慎管理工具	工具列表位于缓存的头部。增加或删除任何一个工具都会使其失效。对于动态发现新工具的场景，请使用工具搜索功能，这只会向后追加内容而不会破坏缓存。
及时更新断点	对于多轮对话应用，应将断点移至最新的一条消息上，以保持缓存的新鲜度。强烈建议使用自动缓存来处理此事。
图片来源：Unsplash

利用声明式工具打造用户体验与安全边界

Claude 并不天然懂得你应用的“安全底线”在哪，也不知道你的产品界面长啥样。它只会闷头发出“调用工具”的指令，剩下的脏活累活全由外层框架接手。
虽然 Bash 工具给了 Claude 在代码世界里翻江倒海的超能力，但对于外层框架而言，Bash 工具抛出来的只是一串干巴巴的命令行字符——不管 Claude 执行什么危险动作，格式全是一样的，这让框架很难做精准管控。
此时，将某些关键动作晋升为专属的声明式工具就显得尤为重要。这给了外层框架一个特定的、带有明确参数类型的“抓手”，让它能游刃有余地进行拦截审查、设置权限闸门、渲染前端界面，或者进行安全审计。

那些容易触碰安全红线的动作，天生就该被做成专属工具。
如何判断哪些动作需要做成声明式工具？
“是否可逆”是一个极佳的判断标准。

• 不可逆操作： 对于像调用外部 API 这种泼水难收的操作，你可以设置一道门槛，强制要求“用户确认”后才能放行。
• 覆盖性操作： 对于像编辑文件这样的写入工具，你可以内置一个“文件陈旧度检查”机制，防止 Claude 稀里糊涂地覆盖掉别人刚刚修改过的文件。
• 交互性操作： 当某个动作需要直观地展示给终端用户时，专属工具可以被渲染成一个前端弹窗，清晰地向用户提问、抛出多个选项，或者干脆暂停智能体的运行循环，等待用户反馈。
• 排查性操作： 专属工具对于系统的可观测性大有裨益。当动作是一个格式严谨的工具时，外层框架就能拿到结构化的参数数据，随后的日志记录、链路追踪和场景回放都会变得轻而易举。
  进阶模式：用魔法打败魔法
  “要不要把这个动作做成专属工具”绝不是一锤子买卖，需要持续重新评估。以 Claude Code 的 Bash 审查模式为例，它为 Bash 工具套上了一层极其硬核的安全边界：它会召唤“第二个 Claude”来阅读这串命令行字符，让 AI 来审查 AI 的操作是否安全。
  这种模式实际上减少了对传统专属工具的依赖。不过，这种做法只适用于用户对大方向足够信任的任务。对于那些一着不慎满盘皆输的高危操作，老老实实写一个专属工具依然拥有不可撼动的地位。
  
  图片来源：Unsplash

反思与见解： 安全架构的设计往往在“灵活性”和“管控力”之间摇摆。以往我倾向于在框架层做大量的正则匹配来拦截危险命令，结果误杀率极高。声明式工具的设计思路本质上是一种“白名单”思维，而“AI 审查 AI”的 Bash 模式则让我看到了动态安全审计的雏形。未来的安全边界可能不再是硬编码的规则，而是另一个具备理解能力的模型。

反思与展望：时刻准备砍掉历史包袱

核心问题：为什么过去为了弥补模型缺陷而写的代码，反而成了今天拖累性能的元凶？
Claude 智能的边界一直在狂奔拓荒。每当它完成一次能力上的跃迁，我们过去对它“做不到什么”的成见，都必须重新推翻再验证。
我们一次次见证了历史的重演。在长周期的智能体测试中，早期的 Claude 模型一旦察觉到上下文快要塞满了，就会出现“恐慌”，然后草草结束任务。为了缓解它的“上下文焦虑症”，我们在代码里硬加了强行清理上下文窗口的“重置”逻辑。
结果到了新一代的强大模型，这个毛病竟然自己不治而愈了！于是，我们当年煞费苦心写出来的“上下文重置”代码，瞬间变成了智能体框架里毫无用处的历史包袱。
痛快地砍掉这些包袱极其重要，因为它们往往会反过来成为束缚 Claude 发挥实力的瓶颈。这也印证了 AI 界著名的“苦涩的教训”：过度依赖人类经验的手工规则，最终往往会拖累模型自身依靠算力进化出的能力。
在未来漫长的岁月里，我们应当不厌其烦地审视应用中的结构和边界，并反复拷问自己那个灵魂问题：“这一次，我又可以放手不管什么了？”

一页速览

构建 Claude 应用的核心理念已经从“框架管控”转向“模型自治”。开发者应避免使用臃肿的外部框架去限制模型，而是提供基础工具（Bash、文本编辑器），让模型通过写代码来编排自身的工作流。在上下文管理上，彻底抛弃“填鸭式”提示词，改用技能库按需加载、上下文修剪和子智能体隔离；在记忆管理上，用模型自有的上下文压缩和文件记忆替代复杂的外部 RAG 架构。最后，在设定边界时，利用缓存机制降低 90% 的成本，并用声明式工具精准把控不可逆操作的安全审查，保持框架的轻盈与克制。

实用摘要 / 操作清单

• [ ] 精简工具箱：移除复杂的定制化工具，确保应用底层仅依赖 Bash 和文本编辑器。
• [ ] 下放编排权：删除框架中强制将所有工具结果注入上下文的逻辑，改为提供代码执行环境（如 REPL），让 Claude 自行过滤和传递数据。
• [ ] 重构提示词架构：拆除超长的系统提示词，建立技能库，仅在上下文头部加载 YAML 摘要。
• [ ] 启用自我管理机制：在长周期任务中，为 Claude 配备上下文修剪工具和子智能体调用能力。
• [ ] 搭建内部记忆系统：放弃自动化的外部 RAG 管道，提供一个本地“记忆文件夹”和上下文压缩工具，让模型自主决定存储什么。
• [ ] 重排 API 请求：检查请求体，确保绝对静态的内容（系统提示、工具定义）在最前，动态对话历史在最后。
• [ ] 锁定 API 缓存：禁止在同一会话中切换模型，使用 <system-reminder> 追加指令，开启自动缓存。
• [ ] 审查安全边界：梳理所有通过 Bash 执行的操作，将涉及外部 API 调用、文件覆盖等不可逆操作提取为需要用户确认的声明式工具。

常见问答 (FAQ)

Q1：为什么 Claude 只用 Bash 和文本编辑器就能在代码基准测试中拿高分？
因为这两个工具是 Claude 在训练数据中最熟悉的基础设施。它能够通过编写脚本将这两个简单工具组合成极其复杂的处理逻辑，这种通用的编程能力远比为其定制专属的“解题工具”更具扩展性。
Q2：不让框架把工具结果塞进上下文，Claude 怎么知道下一步该干嘛？
通过赋予 Claude 代码执行工具（如 Jupyter），它可以自己编写代码来接收工具返回的原始数据。Claude 会在代码层面完成数据过滤、提取和传递，仅将最终精简的计算结果输出到上下文中进行下一步决策。
Q3：技能库是如何节省上下文空间的？
技能库不在启动时加载全部指令，而是只加载包含技能名称和简短描述的 YAML 头部信息。当 Claude 判断当前任务需要某项技能时，它会主动调用读取文件工具，将该技能的完整指令“按需展开”到上下文中。
Q4：在长周期任务中，为什么要用记忆文件夹而不是传统的 RAG 系统？
传统的 RAG 系统通常依赖外部的向量化检索，容易引入噪声且缺乏对任务全局的理解。记忆文件夹让 Claude 像人类记笔记一样，主动将有价值的上下文写成结构化文件保存。随着模型进化，它提炼“高价值战术笔记”的能力远超被动的向量检索。
Q5：为什么在多轮对话中中途切换模型会导致成本暴增？
Claude API 的缓存机制是与特定模型版本绑定的。如果你在对话中途从强模型切换到弱模型以节省成本，API 会认为请求结构发生了根本变化，导致之前所有的上下文缓存全部失效，下一轮请求必须按全量 token 价格重新计算。
Q6：什么类型的操作必须从 Bash 中剥离出来做成声明式工具？
判断标准是“是否可逆”以及“是否需要用户干预”。例如调用外部付费 API（不可逆，需确认门槛）、覆盖已存在的文件（可能破坏他人修改，需陈旧度检查）、向用户收集信息（需要渲染前端弹窗），这些都不应作为简单的 Bash 命令执行。
Q7：什么是“上下文焦虑症”，为什么后来不需要治了？
早期的 Claude 模型在发现上下文窗口快满时，会表现出异常的保守，倾向于立刻停止任务或放弃复杂操作，开发者曾被迫在框架层写代码强行重置上下文。但随着模型推理能力的进化，新模型已经能够从容应对满载的上下文，过去的“治疗代码”反而成了干扰模型正常发挥的累赘。