Agent Harness设计哲学:Claude潜力释放终极指南
Anthropic联合创始人Chris Olah曾用一个精妙的类比概括生成式AI的特性:像Claude这类模型,与其说是“构建”而成,不如说是“培育”出来的。研究者设定初始条件引导其成长,但最终涌现的结构和能力,往往超出预期。
这对开发者而言构成一个切实的挑战:我们搭建的智能体框架(agent harness)底层嵌入了大量关于“Claude目前无法胜任什么”的隐性假设。然而,随着Claude自身能力的飞速进化,这些假设正不断失效。即便是今天分享的方法论,也需要定期拿回聚光灯下重新审视。
那么,如何构建一个既能跟上Claude迭代节奏,又能平衡延迟与成本的实用应用?以下三种模式值得深挖。
1. 优先使用Claude原生理解能力
一个务实的原则:优先选用Claude本身就精通的那些工具来组装你的应用。
回顾2024年底,Claude 3.5 Sonnet在SWE-bench Verified基准测试中拿下49%的成绩,刷新业界纪录。而它当时仅依赖两个工具:一个bash工具,一个文本编辑器工具(用于查看、创建和修改文件)。后来的Claude Code也基于这两个核心工具构建。Bash并非专为智能体设计,但Claude深谙其用法,且随着模型迭代,运用得越发娴熟。
SWE-bench Verified基准测试直观呈现了各版本Claude的进化轨迹
实践中你会发现,Claude能将这类通用工具灵活组合,形成解决不同问题的模式。例如所谓的“智能体技能”(Agent Skills)、程序化工具调用、记忆工具,本质都是bash和文本编辑器这两个基础工具的组合与演化。
程序化工具调用、技能和记忆,均是基于bash与文本编辑器叠加组合而成
2. 追问自己:哪些步骤可以省去?
智能体框架常常预设“Claude自己搞不定的环节”。随着Claude越来越能干,这些假设需要被持续验证。
把动作编排交给Claude
一个常见假定是:每次工具调用的结果都应回流至Claude的上下文窗口,由它决定下一步行动。但这种方式既慢又费token。如果结果仅仅是原封不动传递给下一个工具,或者Claude只关心输出中的一小部分,这种开销纯属浪费。
举例:为分析一张大表格中的某一列,你需要将整张表读入上下文,所有无关行都会白占token。虽然可通过工具设计(如硬编码过滤器)缓解,但这本质上是让框架替Claude做编排决策——而这个决策,Claude自己来做显然更合适。
给Claude一个代码执行工具(如bash工具或特定语言的REPL)能优雅解决此问题:Claude可编写代码来表达工具调用及调用间的逻辑,自行决定哪些结果需传递、哪些需过滤、哪些可直接管道传输至下一个调用,全程无需经过上下文窗口。只有代码执行的最终输出才进入上下文。
如此一来,编排决策便从框架转移到模型本身。编码能力强的模型,天然就是强大的通用智能体。这一模式的作用不止于编码:在测试智能体网页浏览能力的BrowseComp基准上,为Opus 4.6增加过滤自身工具输出的能力后,准确率从45.3%跃升至61.6%。
让Claude自行管理上下文
任务相关的上下文会引导Claude使用bash、文本编辑器这类通用工具。另一个常见假定是:系统提示应预先塞满针对任务的详细指令。问题在于,预加载的提示无法跨多任务扩展——每多一个token都在消耗Claude的注意力预算,而大量极少用到的指令预加载进来纯属浪费。
“技能”(Skills)机制巧妙解决了此问题:每个技能的YAML头部包含一段简短描述,会被预加载进上下文,相当于技能内容的概览。若某个任务确实需要该技能,Claude再通过读文件工具按需获取完整内容。
技能赋予了Claude自行组装上下文的自由度,而“上下文编辑”(context editing)则是反向操作——允许选择性地移除已过时或无关的内容,例如旧的工具调用结果或思考块。
借助子智能体(subagents),Claude在判断何时需要分叉出新的上下文窗口来隔离特定任务方面也越来越精准。Opus 4.6能生成子智能体,在BrowseComp上的表现比最强单智能体方案高出2.8%。
让Claude自行持久化上下文
长时间运行的智能体可能超出单个上下文窗口的限制。常见的假定是记忆系统应依赖模型外部的检索基础设施。但许多工作的核心其实是给予Claude简单的方式,让它自主决定哪些内容值得留存。
例如“压缩”(compaction)机制,让Claude对历史上下文进行总结,以在长周期任务中保持连贯性。随着版本迭代,Claude在“记什么”上的判断力越来越强。在BrowseComp(以网页搜索为核心的智能体任务)上,Sonnet 4.5无论给多少压缩预算,准确率都稳定在43%不变;而Opus 4.5在相同设置下可扩展至68%,Opus 4.6更是达到84%。
“记忆文件夹”是另一种思路,让Claude把上下文写入文件,后续按需读取。在BrowseComp-Plus上,给Sonnet 4.5加上记忆文件夹后,准确率从60.4%提升至67.2%。
用长周期游戏(如宝可梦)来观察这一能力的演进,直观明了。Sonnet 3.5把记忆当成流水账,记录NPC说了什么,而非真正重要的信息。跑了14000步后,留下31个文件——其中还有两个关于毛毛虫宝可梦的几乎重复的文件——角色还停在第二个城镇:
caterpie_weedle_info:
- Caterpie和Weedle都是毛毛虫宝可梦。
- Caterpie是毛毛虫宝可梦,不含毒素。
- Weedle是毛毛虫宝可梦,含有毒素。
- 这条信息对未来遭遇战至关重要。
- 若宝可梦中毒,应尽快前往宝可梦中心治疗。
而后续版本的模型写的是战术笔记。Opus 4.6在相同步数时,仅有10个文件,按目录整理,已获得三个道馆徽章,还有一个从自身失败经历总结出的心得文件:
/gameplay/learnings.md:
- Bellsprout睡眠+缠绕组合:在睡眠粉命中前用咬住速杀。切勿让它成型!
- 初代背包限制:最多20个物品。进入地牢前丢弃不需要的技能机。
- 旋转地砖迷宫:不同入口纵坐标会通往不同目的地。尝试所有入口并串联多个口袋。
- B1F y=16墙壁在x=9-28范围内确认全部实心(步骤14557)
一个连“总结失败”都掌握的智能体,与只会记流水账的版本,差距显而易见。
3. 谨慎划定边界
智能体框架的另一个核心作用,是在Claude外部建立约束,以满足用户体验、控制成本或保障安全的需求。
上下文设计要最大化缓存命中
Messages API是无状态的。Claude看不到之前轮次的对话历史,这意味着框架每次都需要将新的上下文、所有历史动作、工具描述和指令打包传给Claude。
提示词可以基于设定的断点进行缓存——即Claude API会将截止到某个断点的上下文写入缓存,并检查是否与之前的缓存条目匹配。由于缓存token的费用只有基础输入token的10%,遵循以下原则能帮助最大化缓存命中率。
用声明式工具处理UX、可观测性与安全边界
Claude不一定清楚应用的安全边界或UX层位置。Claude输出工具调用,由框架执行。bash工具赋予了Claude极大的编程灵活性,但对框架来说,每个调用的形态都一样——只是一串命令字符串。将某些动作提升为专属工具,就能给框架提供一个带类型参数的、针对特定动作的钩子,可用于拦截、门控、渲染或审计。
需要安全边界的动作天然适合做成专属工具。“可逆性”是一个很好的判断标准——难以撤销的动作,如调用外部API,可设置需用户确认的门控。写文件这类工具可加入陈旧性检查,避免Claude覆盖掉它上次读取后已被修改的文件。
当一个动作需要展示给用户时,工具同样有用——可渲染成弹窗,清晰展示问题,提供多个选项,或阻塞智能体循环直至用户给出反馈。
在可观测性层面,类型化的工具调用让框架能获得结构化参数,便于日志记录、链路追踪和回放。
当然,是否将某个动作提升为专属工具,需要持续重新评估。例如Claude Code的auto-mode在bash工具外包了一层安全边界:让第二个Claude读取命令字符串,判断是否安全。这种模式在一定程度上能减少对专属工具的需求,但仅适用于用户信任整体方向的任务场景。对于某些高风险动作,专属工具依然有其价值。
展望未来
Claude的能力边界始终在移动。每一次能力跃升后,那些关于“Claude搞不定什么”的假设都需要重新测试。
这一模式一再重演。在某个为长周期任务构建的智能体中,Sonnet 4.5会在感知到上下文快满时提前收工,表现出“上下文焦虑”,于是我们加入了上下文重置机制来清空窗口。等Opus 4.5问世,这个行为消失了。当初为了应对它而加入的重置机制,反而变成了框架里的冗余负担。




