本页目录5
- “Agent Harness”指 Claude 之外的脚手架代码：循环、工具、上下文管理与守卫，设计的核心是随模型变强而不断做减法
- 范式一：优先使用 Claude 天然擅长的通用工具（如 bash、文本编辑器），而非自建专属基础设施——Claude 3.5 Sonnet 仅靠 bash 和文本编辑器就在 SWE-bench Verified 上拿到 49%
- 范式二：三个“做减法”的方向——让 Claude 用代码执行（bash/REPL）自行编排工具调用而非事事经过上下文；用 Skills 渐进式加载、上下文编辑、子代理做隔离；用压缩（compaction）和记忆文件夹做长任务的上下文持久化
- 范式三：谨慎设边界——把静态内容放在提示词前部以命中 Prompt Caching（缓存 token 成本约为基础 input token 的 10%），用 `<system-reminder>` 追加动态信息而非改写提示词；对高敏感或难以回退的操作使用专属声明式工具便于拦截、审计和人工确认
- 文章用 Pokémon 智能体案例说明：模型越强，越懂得判断“该记什么”——旧模型堆了 31 个冗余记忆文件，新模型只留 10 个精炼文件
- 结论：脚手架设计要持续复查“现在还需要做这件事吗”，例如某代理曾因旧模型的“上下文焦虑”而提前收尾，升级模型后这类保护逻辑反而成了拖累性的死重
本文是对 Anthropic 官方文章 Agent Harness Design: 3 Patterns for Harnessing Claude's Intelligence 的中文要点摘要，完整内容以原文为准：https://claude.com/blog/harnessing-claudes-intelligence
什么是 Agent Harness
文章把包裹在 Claude 外层的循环、工具、上下文管理和守卫逻辑统称为「agent harness」（智能体脚手架）。设计 harness 的本质，是决定哪些东西该放进这层脚手架——以及随着模型能力提升，哪些东西可以从中拿掉。问题在于：harness 里往往编码了对 Claude 局限性的假设，而这些假设会随模型进化很快过时，变成拖累性能的冗余保护逻辑。
文章围绕三条设计范式展开。
范式一：多依赖模型自身能力，少造专属基础设施
优先选择 Claude 已经很擅长使用的通用工具（比如 bash、文本编辑器），而不是为每个场景单独定制工具接口。文章举例：Claude 3.5 Sonnet 仅凭 bash 和文本编辑器两个通用工具，就在 SWE-bench Verified 上取得 49% 的成绩——尽管 bash 这类工具本来就不是为智能体设计的，但 Claude 会随着能力提升，逐渐学会更高效地驾驭这些朴素工具。
由此延伸出的组合能力包括 Agent Skills、programmatic tool calling（以代码方式调用工具）和 memory tools（记忆工具）——都说明简单工具经过组合可以支撑相当复杂的功能，不必事事定制。
范式二：剥离不必要的脚手架
这一部分是全文重点，给出三条具体的“做减法”方向：
让 Claude 自己编排动作。不要把每一步工具调用结果都塞进上下文来回传递，而是给 Claude 代码执行能力（bash 或某种语言的 REPL），让它自己写逻辑把多个工具调用串起来。这样能显著降低 token 消耗和延迟。文章给出数据：在 BrowseComp 基准上，采用这种方式后 Opus 4.6 的准确率从 45.3% 提升到 61.6%。
渐进式管理上下文。用带 YAML 描述的 Skills 做「渐进式披露」（按需加载细节而非一次性塞满上下文）、用 context editing 清除过时信息、用 subagents 隔离子任务。在 BrowseComp 上，引入 subagents 让 Opus 4.6 的准确率提升了 2.8 个百分点。
策略性地持久化上下文。对于长周期任务，用 compaction 让 Claude 自行总结压缩过去的上下文；用「记忆文件夹」（memory folders）让 Claude 按需读写文件，而不是把所有历史都留在上下文窗口里。在 BrowseComp-Plus 基准上，引入记忆文件夹使 Sonnet 4.5 的准确率从 60.4% 提升到 67.2%。
文章用一个 Pokémon 智能体的例子说明模型判断力的进步：Sonnet 3.5 生成了 31 个记忆文件，里面塞满了冗余的 NPC 对话记录；而 Opus 4.6 只维护 10 个组织良好的文件，记录的是提炼过的战术要点——说明新模型对「该记什么、不该记什么」有了更好的判断力，harness 不必再替它做这个筛选。
范式三：谨慎设定边界
并非所有脚手架都该拆掉，有些边界反而要认真保留：
- 最大化利用 Prompt Caching：把静态内容（系统提示词、工具定义）放在动态内容之前；需要追加动态信息时，用消息里的
<system-reminder>，而不是直接改写系统提示词；尽量保持模型版本一致（缓存是按模型区分的）。命中缓存的 token 成本约为基础 input token 的 10%。 - 策略性使用声明式工具：相比 bash 这种「万能但难以约束」的通用工具，带类型化参数的专属工具便于拦截、设置门禁、定制渲染或做审计留痕。对于安全敏感操作或难以回退的动作，更适合走专属工具这条路径。文章提到，工具可以把问题以模态框形式展示给用户，或在需要人工反馈时挂起循环等待；还提到「Auto 模式」（一项研究特性）可以用第二个 Claude 实例专门读取安全信息来对 bash 命令做门禁。
文章还给出了一份「如何最大化缓存命中率」的实践清单：稳定内容放最前面、动态更新通过消息追加、避免在会话中途切换模型、谨慎管理工具定义的变更、及时更新缓存断点（breakpoints）以保持缓存新鲜度。
结论：持续复查，而非一次性设计
Harness 设计不是一锤定音的事，需要随着 Claude 能力提升不断复查此前的假设是否仍然成立。文章提到一个具体案例：早期某个智能体在使用 Sonnet 4.5 时，会在接近上下文窗口上限前表现出「上下文焦虑」——提前草草收尾以避免超限；而换用 Opus 4.5 后，这种行为消失了，原本为此设计的上下文重置逻辑反而成了没有意义的死重（dead weight），应当被移除。
文章给出的核心方法论是：定期问自己「现在还有什么是可以不做的？」（what can I stop doing？），避免脚手架本身成为性能瓶颈。文中提到相关实践可参考一个 claude-api skill 仓库中的实现示例。