HarnessDesign进阶：如何随模型能力演进动态优化架构

大家好，我是讯享网，很高兴认识大家。这里提供最前沿的Ai技术和互联网信息。

文章总结： 本文探讨AI系统架构动态优化策略，核心观点是AI系统应视为生长而非构建的有机体。随着Claude模型能力提升，传统工程补偿（如ContextReset）可能变为累赘。提出三大模式：使用模型已知通用工具、定期质疑移除过时补偿、在安全/UX需求时设定边界。实验显示ExecutionTool模式在BrowseComp任务准确率提升16.3%，MemoryFolder提升6.8%。建议采用模块化设计，让模型自主管理上下文与操作编排。 综合评分： 85 文章分类： AI安全,安全建设,解决方案,安全开发,安全运营

cover_image

原创

秀逗猫秀逗猫

秀逗猫

2026年4月4日 14:42 北京

在小说阅读器读本章

去阅读

2026年4月2日，Anthropic 发布了《Harnessing Claude’s intelligence》，揭示了一个关键发现：随着 Claude 模型能力的提升，之前被认为”必需”的工程补偿竟然变成了”累赘”。

文章的核心观点是：AI 系统是”生长”的，不是”构建”的。关于”Claude 不能做什么”的假设会随着模型能力的提升而过时。我们需要持续问自己：”有什么是我现在可以停止做的？”

Use what Claude knows – 使用 Claude 已知且持续改进的通用工具
Ask ‘what can I stop doing?’ – 持续质疑并移除过时的工程补偿
Carefully set boundaries – 在安全、UX、可观测性需要时设定边界

在短短几个月内，Claude 的能力发生了质的飞跃：

💡 关键洞察：Context Reset 原本是 Sonnet 4.5 必需的工程补偿，但在 Opus 4.5 中已经变成了”累赘”。

Context Reset 为何变成累赘？

简单来说：Context Reset 是为了解决 Sonnet 4.5 的”上下文焦虑”问题——当上下文快满时，模型会提前结束工作。

但随着 Opus 4.5 的能力提升，它已经能够更好地管理自己的上下文，不再有这种焦虑。因此，原本必需的 Context Reset 就变成了不必要的累赘。

启示：工程补偿是为了解决特定问题，当问题消失时，补偿也应该被移除。

随着模型能力的提升，许多之前必须由 harness 完成的工作，现在可以交给 Claude 自己完成：

Execution Tool 模式的实验数据：

| 模式 | BrowseComp 准确率 | Opus 4.6 提升 | | — | — | — | | 传统模式 | 45.3% | – | | Execution Tool | 61.6% | +16.3% |

随着模型能力的提升，许多外部补偿已经不再必要：

Context Reset → Opus 4.5 不再需要
外部 Evaluator → Claude 使用子 agent 辅助评估（在 BrowseComp 上提升 2.8%）
harness 编排 → Claude 使用 Execution Tool 自行编排

优先使用 Claude 已知的通用工具（bash、编辑器），让 Claude 将它们组合成解决不同问题的模式。

“Claude 已经将这些通用工具组合成解决不同问题的模式：Programmatic tool calling、Skills、Memory 都是从 bash 和文本编辑器工具构建的。”

构建应用时应使用Claude 理解并持续改进的通用工具，而不是设计大量 Claude 不熟悉的专用工具。

实证数据：

Claude 3.5 Sonnet 在 SWE-bench Verified 上达到 49%（仅用 bash + 编辑器）
Claude 在使用这些工具方面的能力持续提升

关键洞察：不要设计 Claude 不熟悉的专用工具，而是让它使用它已经理解并持续改进的通用工具。

这是反直觉但至关重要的模式：随着 Claude 能力的提升，许多之前必须由 harness 完成的工作，现在可以交给 Claude 自己完成。

2.1 让 Claude 编排自己的操作

传统模式的问题：

每个工具结果都通过上下文窗口传递
Token 消耗高、速度慢、成本高

Execution Tool 解决方案：

给 Claude 写代码的工具
让代码编排工具调用
只有最终输出进入上下文窗口

实验数据：

Opus 4.6 在 BrowseComp 上从 45.3% 提升到 61.6%

2.2 让 Claude 管理自己的上下文

Skills 系统：

YAML 前置元数据预加载
完整内容按需加载
Claude 自己决定需要加载什么

2.3 让 Claude 持久化自己的上下文

Compaction（压缩）：

Opus 4.6 在 BrowseComp（agentic search 任务）上达到 84%（Sonnet 4.5 仅 43%）

Memory Folder（记忆文件夹）：

BrowseComp-Plus 上，给 Sonnet 4.5 记忆文件夹使其从 60.4% 提升至 67.2%（+6.8 个百分点）

实际案例：Pokémon 任务

Sonnet 3.5：记忆视为”转录”，记录所有对话
Opus 4.6（及后续更强模型）：记忆视为”知识”，记录重要信息，避免重复

有些操作仍然需要提升为专用工具（dedicated tools），而不是由 Claude 直接执行。

实例：Claude Code 的安全边界

Read-only bash + 第二个 Claude 评估命令安全性
这个模式可以减少对专用工具的需求

“将操作提升为工具的决定应该持续重新评估。”

设计上下文以最大化缓存命中

除了设定边界，还需要精心设计上下文结构以最大化缓存命中率。原文提供了 5 条关键原则：

这些原则有助于提高 Messages API 的缓存效率，降低成本并提升响应速度。

任务：测试 agent 网页浏览能力

Claude → 调用工具A → 结果进入上下文 → Claude分析 → 调用工具B → …

问题：读取大表时，整个表进入上下文，Token 消耗高。

Claude → 写代码 → 代码编排工具调用 → 工具A → 工具B → 工具C → 仅最终输出进入上下文

实验数据：

| 模型 | 无 Execution Tool | 使用 Execution Tool | 提升 | | — | — | — | — | | Opus 4.6 | 45.3% | 61.6% | +16.3% |

成果：

成本降低：只有最终输出消耗 tokens
速度提升：减少了上下文窗口的开销
准确率提升：+16.3%

如果你的系统是基于3月24日第一篇文章设计的，别担心，一切正常。只需要考虑以下简单的优化：

先测试再调整：在一个小功能中测试新模式（如 Execution Tool）
逐步优化：确认有效后再扩展到其他模块
保持稳定：如果现有系统运行良好，不需要急于调整

不用恐慌：你的架构没有错，只是可以优化
慢慢来：模型能力在提升，但不需要立即重构
保持关注：每次模型发布后，看看有什么新的优化机会

| 模式 | BrowseComp 准确率 | Token 消耗 | 速度 | | — | — | — | — | | 传统模式 | 45.3% | 高 | 慢 | | Execution Tool | 61.6% | 低 | 快 |

| 模型 | BrowseComp-Plus 准确率 | 提升 | | — | — | — | | Sonnet 4.5（无 Memory） | 60.4% | – | | Sonnet 4.5（有 Memory） | 67.2% | +6.8 个百分点 |

不要假设架构是固定不变的
使用模块化设计，便于移除或添加组件
提供配置选项来启用/禁用某些功能

每次模型发布后，重新审视之前的假设
询问：”有什么是我现在可以停止做的？”
移除不再必要的工程补偿

优先使用 Claude 已知的通用工具（bash、编辑器）
通过 Skills 系统封装可复用的功能
仅在必要时使用专用工具

强大的编码模型就是强大的通用 agent
让 Claude 自己编排操作、管理上下文、选择持久化内容
减少不必要的中间层

在构建基于 Claude 的应用时，不要假设一种架构永远是**的。

定期观察 Claude 的能力变化
动态调整 harness 的结构
拥抱演进，而非恐惧变化

不要将”**实践”视为不可改变的教条。

每次模型发布后，测试之前的假设是否仍然成立
询问：”有什么是我现在可以停止做的？”
移除不再必要的工程补偿

Harness Design 进阶的核心思想是：从”构建固定架构”到”设计可演进架构”。

AI 系统是”生长”的，不是”构建”的
Assumptions 会过时，需要持续重新审视
让 Claude 自己做更多事情
优先使用通用工具（bash、编辑器）
Harness 的演进是必然的，而且速度越来越快

“Claude 智能的前沿总是在变化。关于 Claude 不能做什么的假设需要在每次能力跳跃时重新测试。”

“随着时间的推移，我们的应用中的结构或边界应该根据以下问题进行修剪：’有什么是我现在可以停止做的？’”

注：以下内容为解读作者基于两篇文章延伸的分析与思考。

从这两篇文章的发布时间来看（仅间隔9天），我们可以观察到以下趋势：

1. 模型能力演进加速

趋势：模型能力提升的速度越来越快，架构需要更频繁地调整。

2. 发布频率提升

Anthropic 从2026年3月到4月，连续发布了两篇关键文章：

3月24日：Harness Design（架构基础）
4月2日：Harnessing Claude’s Intelligence（架构演进）

趋势：技术迭代速度加快，开发者需要更敏捷的学习和适应能力。

3. 架构模式的快速迭代

之前被认为是”**实践”的模式，可能在几周内就变得过时：

Context Reset：从”必需”到”累赘”
外部 Evaluator：从”必需”到”可选”
专用工具：从”推荐”到”谨慎使用”

趋势：架构模式的生命周期越来越短，需要持续学习和更新。

挑战1：如何跟上快速演进？

问题：模型能力快速提升，架构更新频繁，开发者如何跟上？

解决方案：

建立可演进的架构设计原则
关注核心哲学而非具体实现
建立自动化测试和监控

挑战2：如何平衡稳定性与演进？

问题：既要保持系统稳定，又要快速演进，如何平衡？

解决方案：

使用特性开关（Feature Flags）
渐进式迁移策略
保留可选的兼容层

机遇1：更强大的 AI 能力

随着模型能力的提升，之前需要复杂架构才能解决的问题，现在可能变得简单。

例子：

复杂的多智能体协作 → 可能被更强的单智能体取代
精细的上下文管理 → 可能被模型自我管理取代

机遇2：更低的成本和更高的效率

让 Claude 自己做更多事情，可以：

减少 harness 的复杂度
降低开发和维护成本
提升整体性能和效率

1. 关注核心哲学，而非具体实现

核心哲学：

AI 系统是”生长”的，不是”构建”的
assumptions 会过时
让 Claude 自己做更多事情

具体实现会变，但核心哲学不变。

2. 建立可演进的架构

模块化设计
特性开关
自动化测试
持续监控

3. 保持学习心态

定期阅读官方博客
参与社区讨论
测试新模型和新模式
持续质疑之前的假设

4. 不要过度依赖特定模式

今天被认为是”**实践”的模式，明天可能就过时了。

理解原理，而非死记模式
根据实际情况选择和调整
保持灵活性和适应性

标题: Harnessing Claude’s intelligence
链接: https://claude.com/blog/harnessing-claudes-intelligence
发布日期: 2026-04-02
作者: Lance Martin

💡 提示: 本文是对 Anthropic 文章的深度解读，建议配合原文一起阅读以获得更完整的理解。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：秀逗猫秀逗猫

 秀逗猫《Harness Design进阶：如何随模型能力演进动态优化架构》