如何跟上 Claude 的进化速度：构建 Agent 的三个关键模式

大多数构建 AI Agent 的人，都在一个错误的假设上花冤枉钱：他们默认模型能力是静态的，于是用复杂的编排层去弥补模型“做不到”的事。但模型能力在飞速进化，昨天的瓶颈可能今天就不存在了。Anthropic 这篇文章直指一个核心矛盾——你为 Claude 早期版本设计的那些“安全网”和“引导逻辑”，在更强大的模型上反而成了拖累，既浪费 latency 又增加成本。

解法其实很反直觉：信任 Claude 的自我编排能力。与其在 harness 层手写死逻辑去决定每个工具调用的结果怎么流、上下文怎么管理，不如给它一个 bash 工具和代码执行环境，让模型自己用代码做决策。比如，不让 harness 把每个工具输出都塞回 token 里，而是让 Claude 写一段 Python 脚本，把要过滤、要传递的数据直接 pipe 到下一步，只有最终结果才进上下文。这种模式在 BrowseComp 上把 Opus 4.6 的准确率从 45.3% 直接拉到 61.6%。同样，让 Claude 自己管理记忆——用 compaction 总结历史、用 skills 按需展开上下文、用记忆文件夹持久化关键信息。实验对比很直观：Sonnet 3.5 玩 Pokémon 只会机械记录 NPC 对话，14,000 步后还困在第二个城镇；而 Opus 4.6 已经能在相同步数内拿到三个徽章，并且把失败教训写成学习笔记。

这篇文章最值钱的观点是：不要在 harness 层替模型做它自己能做得更好的事。比如你以为系统提示词要写满任务细节，结果每个任务都得重新写一套，还白白占用了 attention budget。让 Claude 用 skills 按需读取上下文，既灵活又省 token。同样的道理，缓存策略也值得重新思考——静态内容放前面，工具描述、系统提示词保持稳定，最大化 cache hit，因为缓存 token 只要原价 10%。还有那些为了补偿早期模型“上下文焦虑”而写的 reset 逻辑，在 Opus 4.5 上反而成为性能瓶颈。核心原则就一条：定期问自己“哪些边界可以拆掉”。这篇文章给所有做 Agent 工程的人提了个醒——别再用旧地图导航新车了。