这是一篇由原始材料转换而来的阅读页，保留了源文件的主要结构，并补充了可追溯的来源说明与链接。

X 阅读笔记：Agent Harness is the Real Product

• 原帖：https://x.com/Hxlfed14/status/2028116431876116660
• 作者：Himanshu（@Hxlfed14）
• 发布时间：2026-03-01 22:33（页面显示）
• 整理时间：2026-03-12

TL;DR

这篇长文的核心论点很鲜明：模型正在商品化，真正决定 agent 上限的，是包在模型外面的 harness（执行循环、工具系统、上下文组织、错误恢复、状态管理）。

作者进一步强调，当前最被低估、但几乎所有优秀 agent 系统都在收敛使用的模式，是 progressive disclosure（渐进式信息披露）：不要把所有上下文一次性塞给模型，而是让 agent 按需发现、按阶段加载、按重要性暴露信息。

如果只看工程启发，这篇文章最值得记住的是三句话： 1. The model is interchangeable. The harness is the product. 2. 优秀 agent 往往不是“工具越多越强”，而是“信息和工具暴露得越克制越强”。 3. 很多性能提升，来自删东西、延迟加载、压缩观察，而不是继续堆复杂度。

文章主线整理

1) 作者的总论：模型不是差异化，harness 才是

作者把 Claude Code、Cursor、Manus、Devin、SWE-Agent 等放在一起看，得出的结论是：

• 大家都在收敛到一个非常简单的主循环：
• 模型输出工具调用
• 执行工具
• 把结果追加进上下文
• 再次调用模型
• 真正拉开差距的，不是这个 loop 本身，而是 loop 外面的东西：
• 给模型看什么
• 什么时候看
• 给哪些工具
• 出错后怎么恢复
• 如何维持长期任务的一致性

作者对 harness 的定义可以概括成：

harness = everything around the model that makes it useful

也就是：模型负责“做决定”，harness 负责“看见什么、能做什么、失败后怎么办”。

2) 文章反复强调的核心模式：Progressive Disclosure

作者认为，真正把 production agent 和 demo agent 区分开的，不是模型名，而是是否掌握了“渐进式信息披露”。

它解决的是什么问题？

• 长上下文并不等于高质量注意力
• 信息越多，越容易出现：
• 注意力分散
• 信噪比下降
• 中间信息被忽略（lost in the middle）
• 工具选择混乱
• 推理路径漂移

作者给出的直觉

不要在一开始把所有 repo、所有工具、所有文档、所有历史都塞进去。 更好的方式是： - 先只给最小必要上下文 - 需要时再读文件/读工具定义/读文档 - 老观察做压缩，保留最近高价值信息 - 计划显式化，让 agent 自己知道当前阶段

文中举的典型实现方式

• Claude Code：skill 按需加载，不是全量预加载
• Cursor：MCP 工具描述 lazy loading
• Manus：把很多信息卸载到文件系统，按需读回
• SWE-Agent：旧 observation 压缩，只保留最近 5 条细节

一句话概括：progressive disclosure 本质上是在做“上下文带宽管理”。

3) 各家 harness 的差异化做法

Claude Code

作者把 Claude Code 描述为一种“让模型控制 loop”的极简架构。

抓手

• 单一平面消息列表（flat message list）
• 大约 18 个 primitive tools
• 工具分组大致是：
• 命令行发现：Bash / Glob / Grep / LS
• 文件操作：Read / Write / Edit / MultiEdit
• Web：WebSearch / WebFetch
• 编排：TodoWrite / Task

文中最重要的观察

• TodoWrite 是典型 harness trick： 它不是业务功能工具，而是一个“强迫 agent 显式维护计划”的锚点。
• 工具结果里插入固定系统提醒，比只靠 session 初始 system prompt 更稳。
• regex/ripgrep 优先于复杂检索系统，因为 Claude 本身就能较好地驾驭代码搜索。

工程启发

Claude Code 的思路不是“做一个更聪明的框架”，而是： 给模型少量高质量 primitive，再用 harness 约束节奏。

Cursor

作者把 Cursor 的代表性思路总结为：Files as the fundamental primitive。

抓手

• 一切尽量映射到 file primitive
• 针对不同 frontier model 调整 harness 细节
• MCP/tool definitions 不全量塞进上下文，而是按需取

文章里特别值得记的一点

Cursor 不是假设“一个 prompt 适配所有模型”，而是明确承认： - 不同模型适合不同工具命名 - 不同模型适合不同推理提示方式 - 不同模型适合不同 harness 包装

工程启发

这意味着：模型适配层本身，就是 harness 的一部分。 不是换个 model ID 就完事。

Manus

作者把 Manus 的重点放在 KV-cache 友好 和 极致简化 上。

抓手

• 不频繁改动上下文前部的工具定义
• 工具常驻，但用 logit masking 控制可用性
• 三层动作空间：
• L1：原子工具
• L2：通过 shell 调用的 sandbox utilities / MCP
• L3：动态脚本

文中的关键信号

作者引用 Manus 的经验： - 真正的大提升往往来自删除复杂设计 - 更复杂的 manager / orchestration，未必更有效 - 如果模型更强了，而 harness 还在持续膨胀，方向可能错了

工程启发

复杂度预算要给信息流设计，不要给架构花活。

SWE-Agent

作者把 SWE-Agent 的代表性做法总结为 Agent-Computer Interface（ACI）。

抓手

• 编辑动作后自动跑 linter
• 语法不合法就拒绝修改，迫使 agent 重试
• observation 做压缩，只保留最近几步完整细节

工程启发

这是一类非常典型的 harness guardrail： - 不是提升模型智力 - 而是降低它犯低级错误的自由度

换句话说，好的 harness 不是“让 agent 更自由”，而是“让它只在有效空间里自由”。

4) 作者引用的“证据”想说明什么

文中最醒目的数据/说法主要服务于一个结论： 只改 harness，不改模型，也能出现非常大的性能差异。

作者列举的代表性 claim 包括： - Claude Opus 4.5 在 CORE-Bench 上，换 scaffold 后从 42% 到 78% - Cursor lazy tool loading 可降低 46.9% token 使用 - Vercel 删除 80% agent tools 后，任务从失败转成功 - LangChain deepagents-cli 在 TerminalBench 2.0 上通过 harness 改进提升 13.7 分

我的判断

这些数字如果都成立，结论很清楚： - agent 设计已经进入 context/harness engineering 主导阶段 - 单纯追逐更强模型，不足以解释生产系统差异

但要注意： - 这里很多数字是作者二次汇总 - 有些来自博客、案例文、反向工程文章，而不是统一 benchmark paper - 因此更适合把它们当作 强信号，不是最终定论

5) 这篇文章对 harness engineering 的实际启发

如果把它转成工程 checklist，大致可以落成下面几条：

A. 先收缩，再扩展

默认只给： - 当前任务 - 最小必要文件/工具 - 最近关键状态

不要默认给： - 全工具全集 - 全量 repo 地图 - 冗长历史消息 - 大段无选择的文档粘贴

B. 让“读取信息”变成显式动作

比如： - read file - open spec - load skill - inspect tool schema - fetch MCP details on demand

这类动作本身就是 harness 的关键设计。

C. 给 agent 一个计划锚点

无论叫： - todo.md - task list - plan state - checkpoint

本质都一样： 防止长任务漂移。

D. 保留错误，不要美化错误

作者提到多家系统都不是“替模型擦屁股”，而是把失败原样反馈给模型，让它自恢复。 这是 production agent 非常关键的一点。

E. 对旧上下文做压缩，而不是无限累积

可采用： - summarize older observations - preserve only latest detailed steps - keep recoverable references（URL/file path/command） - 把不常用信息卸载到文件系统

6) 我对这篇文章的总体评价

值得保留的部分

这篇文章最强的地方，不是“发明了新概念”，而是把过去分散在各家 blog / paper / reverse engineering 里的东西，串成了一个统一叙事：

agent 的真正竞争力，不在单次推理，而在 harness 如何调度上下文、工具和反馈回路。

这个判断我认为是成立的，而且对工程实践有直接价值。

需要保留怀疑的部分

但也要看到它有明显“论战型写法”的特征： - 观点很鲜明，甚至有点绝对化 - 各家案例放在一起时，口径未完全统一 - 一些数据是文章作者的整理转述，未在这里逐条复核

因此更稳妥的表述是： - “Harness is the product” 是一个很强的工程判断，不应机械理解成“模型不重要”。 - 更准确地说：模型决定能力上限的底盘，harness 决定能力能否稳定兑现为生产表现。

7) 对我们做 harness engineering 的直接参考价值

如果是拿来指导内部设计，我认为最值得落地的是这几条：

1. 把信息暴露顺序当成一等公民来设计 - 不是“给什么上下文”而已，而是“先给什么、后给什么、什么时候给”。

2. 优先 primitive tools，谨慎引入复杂专用工具 - bash / grep / read / write / browser / fetch 这类 primitive 往往更稳。

3. 把计划、检查点、恢复点做成显式结构 - 防止长任务跑偏。

4. 工具和上下文都要支持 lazy loading - 特别是大工具集、MCP、大型知识库场景。

5. 观察压缩与长期记忆卸载要配套 - 不是让上下文无限变长，而是让信息可恢复、可回读、可追溯。

6. 把 harness 评估单独做成指标体系 - token 消耗 - 首次成功率 - 平均步骤数 - 错误恢复率 - 上下文读取命中率 - latency

8) 建议的后续动作

如果要继续往下推进，这篇材料适合衍生出 3 个方向：

方向 A：做一份“harness patterns 对照表”

把 Claude Code / Cursor / Manus / SWE-Agent / Devin / Replit 的设计拆成矩阵： - loop - context loading - tool exposure - memory - error recovery - planning - evals

方向 B：做一份“适用于我们系统的 harness checklist”

聚焦实际建设： - 哪些上下文应该默认加载 - 哪些必须 lazy load - 哪些工具应该收缩为 primitive - 哪些 guardrails 应该在 harness 层做

方向 C：把文中引用逐条验源

尤其值得单独核验的 claim： - CORE-Bench 42% → 78% - Cursor 46.9% token reduction - Vercel 删除 80% tools 后成功率变化 - TerminalBench 2.0 的 13.7-point 提升

原帖提到的主要参考来源（待逐条复核）

• Anthropic — Effective Context Engineering for AI Agents
• Anthropic — Effective Harnesses for Long-Running Agents
• Cursor — Dynamic Context Discovery
• Cursor — Improving Agent with Semantic Search
• Cursor — Improving Cursor's Agent for OpenAI Codex Models
• Manus — Context Engineering for AI Agents: Lessons from Building Manus
• LangChain — Deep Agents
• LangChain — Improving Deep Agents with Harness Engineering
• SWE-Agent paper
• Lost in the Middle paper
• Phil Schmid — Context Engineering for AI Agents: Part 2
• Cognition — Devin’s 2025 Performance Review
• Horthy — 12 Factor Agents
• PromptLayer / Vrungta / Honra / Karpathy / Jannesklaas 等二级分析文

我的一句话结论

这帖最有价值的地方，不是“喊口号说 harness 很重要”，而是把一个越来越清晰的行业现实讲透了：

下一阶段 agent 工程的主战场，不只是更强模型，而是更克制的上下文设计、更节制的工具暴露、更稳定的恢复回路。

换成工程语言就是： context orchestration > prompt 堆料；harness discipline > tool 堆叠。