Anthropic 最近在 Claude 官方博客上发了一篇技术文章，讲的是怎么构建基于 Claude 的应用。作者是 Claude 平台团队的工程师 Lance Martin。文章不长，但信息密度很高，里面藏着好几个非常有价值的观点，值得仔细聊聊。
1、AI 是“长”出来的，不是“造”出来的
文章开头引用了 Anthropic 联合创始人 Chris Olah 的一句话：像 Claude 这样的生成式 AI 系统，更像是被培育出来的，研究人员设定好生长条件和方向，但最终会涌现出什么能力，谁也没法完全预料。
这个说法很有意思。我们平时理解软件开发，都是先设计、再编码、最后测试，一切都在掌控之中。但 AI 模型的成长过程更像养一棵树，你能决定土壤、阳光和水分，但它长成什么样，会结出什么果子，有很大的不确定性。
这种不确定性直接带来了一个实际问题：开发者在构建应用的时候，会在代码里写下很多关于 Claude 做不到什么的假设。比如觉得它处理不了复杂的多步骤任务，就在外面加一层编排逻辑来帮它。但随着 Claude 越来越聪明，这些假设会逐渐过时，你之前写的那些“辅助代码”反而变成了累赘。
这个道理其实放到生活中也一样。我们对一个人、一个工具、一件事的判断，往往是基于过去的经验。但事物在变化，如果不定期更新自己的认知，就会被过时的假设困住。
2、核心观点一：用它已经熟悉的工具
文章的第一个建议是，用 Claude 理解得很透的工具来构建应用。
2024 年底，Claude 3.5 Sonnet 在一个叫 SWE-bench 的软件工程基准测试上拿到了 49% 的得分，当时是全行业最高。而它用到的工具只有两个：一个命令行工具（bash）和一个文本编辑器。Claude Code 这个产品的底层也是这两个工具。
bash 本来不是为构建 AI Agent 设计的，但 Claude 非常熟悉它，而且随着模型迭代，用得越来越好。Anthropic 观察到，Claude 会自己把这些通用工具组合出各种模式来解决不同的问题。比如 Agent Skills、程序化工具调用、记忆工具，底层都是 bash 和文本编辑器的组合。
这里面有一个很朴素的道理：与其给一堆花哨的专用工具，不如给几个它真正吃透的通用工具。一个人如果把锤子用到了极致，能解决的问题可能比拿着一整箱没怎么练过的工具还多。选择少而精，反而能激发更大的创造力。
3、核心观点二：不断问自己“哪些事可以不做了”
这是文章里最有启发性的一个观点。
开发者在构建 Agent 框架的时候，习惯性地替 Claude 做很多事情。比如每次工具调用的结果都要回传到 Claude 的上下文窗口里，让它看完再决定下一步。但这样做既慢又贵，而且很多时候根本没必要。
文章举了一个例子：假设你让 Claude 读一张大表格，只是为了分析其中一列。按照传统做法，整张表都会塞进上下文，Claude 要为每一行不需要的数据付出计算成本。你可以在工具层面加过滤器来解决，但这没有触及问题的根本。框架在替 Claude 做一个“编排决策”，而 Claude 自己其实更适合做这个决策。
解决方案是给 Claude 一个代码执行工具，让它自己写代码来编排工具调用。它自己决定哪些结果要处理、哪些要过滤、哪些直接传给下一步。这样一来，编排决策就从框架转移到了模型手中。
效果很明显。在一个叫 BrowseComp 的网页浏览测试上，让 Opus 4.6 自己过滤工具输出后，准确率从 45.3% 飙升到了 61.6%。
4、让它自己管理上下文
另一个常见做法是在系统提示词里塞满各种任务指令。问题在于，每多一个 token 都在消耗 Claude 的注意力预算，把很少用到的指令预先塞进去纯属浪费。
Anthropic 的做法是用 Skills 机制。每个 skill 只在上下文里放一段简短描述，相当于一个目录。只有当任务确实需要时，Claude 才会主动加载完整内容。这就像你不需要把整本字典背下来，只需要知道字典在哪，用到的时候翻一下就好。
5、让它自己决定记住什么
长时间运行的 Agent 会超出上下文窗口的容量。传统做法是在模型外面搭一套检索系统来管理记忆。但 Anthropic 的思路是给 Claude 简单的工具，让它自己选择要保留什么。
文章用了一个特别生动的例子来说明这种能力的进化：让不同版本的 Claude 玩宝可梦。
早期的 Sonnet 3.5 把记忆当流水账来记，NPC 说了什么就记什么。跑了 14000 步之后，它攒了 31 个文件，其中还有两个内容几乎重复的关于毛毛虫宝可梦的笔记，而它还卡在第二个城镇。
后来的 Opus 4.6 完全不一样。同样的步数下，它只有 10 个文件，按目录分好了类，已经拿到三个道馆徽章，还有一个从自己的失败中提炼出来的经验总结。比如“喇叭芽的催眠加紧束组合技，用咬咬赶紧秒掉，别让它放出催眠粉”，还有“初代背包上限 20 个道具，进迷宫前把没用的技能机器扔掉”。
从记流水账到写战术笔记，这个进化过程特别有意思。它说明“记住什么”这件事本身就是一种智能。我们每天接收海量信息，真正拉开差距的，往往是你能不能从经历中提炼出有用的东西，而不是记住所有细节。
在 BrowseComp 基准测试上，这种能力的差距体现得更直接：Sonnet 4.5 不管给多少压缩预算，准确率都停在 43%。Opus 4.5 提升到了 68%，Opus 4.6 更是达到了 84%。同样的机制，不同的模型，结果天差地别。
6、核心观点三：谨慎设定边界
虽然文章的主旨是“少管 Claude”，但它也强调了一点：该管的地方还是要管。
Agent 框架需要在用户体验、成本和安全三个维度上设定边界。
在成本方面，文章详细讲了怎么设计上下文结构来最大化缓存命中率。因为 Claude 的 API 是无状态的，每一轮交互都要把所有历史信息重新打包发过去。缓存 token 的成本只有普通输入的 10%，所以合理利用缓存能省下大量开支。几个关键原则包括：把稳定不变的内容放在前面，不要在会话中途切换模型，谨慎增删工具定义，等等。
在安全方面，文章建议把高风险操作提升为专用工具。bash 工具给了 Claude 很大的自由度，但对框架来说，它拿到的只是一个命令字符串，每个操作看起来都一样，没法区分风险高低。把特定操作做成专用工具后，框架就能拿到结构化的参数，可以拦截、审批或审计。
判断标准也很简单：看操作是否可逆。难以撤销的操作（比如调用外部 API）应该加上用户确认环节。写入类的工具可以加过期检查，防止覆盖掉已经被别人修改的内容。
不过文章也提醒，这些边界本身也需要持续评估。比如 Claude Code 的自动模式用了一个巧妙的方案：让另一个 Claude 来审查命令是否安全。这种模式可以减少对专用工具的需求。但对于某些高风险操作，专用工具仍然不可替代。
7、核心观点四：过时的假设会成为性能瓶颈
文章最后讲了一个很有说服力的例子。Anthropic 为长周期任务构建了一个 Agent，发现 Sonnet 4.5 会在感知到上下文快要用完时提前收工，有一种“上下文焦虑”。于是他们加了上下文重置机制来应对。但到了 Opus 4.5，这个焦虑行为自己消失了。之前写的重置逻辑变成了框架里的死代码，不仅没用，还在拖累性能。
文章引用了一篇经典论文《The Bitter Lesson》的观点：这些过时的补偿机制会成为瓶颈，限制 Claude 发挥真正的能力。
这个道理放到更大的范围来看也成立。我们在工作和生活中积累了很多流程、规则和习惯，它们在当初都有存在的理由。但环境在变，能力在长，如果不定期清理那些已经过时的“补丁”，它们就会变成前进的阻力。
8、写在最后
读完这篇文章，最大的感受是：Anthropic 对 Claude 的开发哲学，核心就是一句话，随着模型变强，开发者应该持续做减法。
这听起来有点反直觉。我们习惯了“做加法”的思维方式，觉得多做一层保护、多加一个功能总归是好的。但在 AI 应用开发中，过度的“帮助”反而会限制模型的发挥。最好的框架，是那个能随着模型进化而不断精简自身的框架。
文章反复提到的那个核心问题，值得每个开发者，甚至每个人都时不时问问自己：哪些事，可以不做了？
#科技先锋官##How I AI#
