【Harness篇】07：HaaS、自适应 Harness 与人机共训练

J_Xiong0117

206人浏览 · 2026-04-29 11:45:27

J_Xiong0117 · 2026-04-29 11:45:27 发布

文章目录

1. 系列回顾：六篇之后我们站在哪里

走到这里，我们已经一起翻完了六章地图：

第 1 篇用 Karpathy 的"LLM 是新操作系统"立住了 Agent = Model + Harness 这条公式，把 harness 工程从 prompt / context 的延长线上拎出来，作为 2025–2026 年最值得投入的工程主战场。第 2 篇深入 agent 循环本体——从 ReAct 的 TAOR 雏形，到 Anthropic 的"扩展循环（augmented loop）“，把 turn / stop-condition / parallel tool-use / extended thinking 一并钉死定义。第 3 篇专攻上下文工程：CLAUDE.md 三级层叠、retrieval 与 just-in-time loading、auto-compact 算法（80% 阈值、低水位线、“重要决策保留率”）。第 4 篇是工具与权限：tool catalog 设计、bash / file / MCP 三类粒度、permission_mode 的四档（read-only / acceptEdits / standard / bypass）以及哪些动作必须 hook。第 5 篇讲长任务多代理：planner–generator–evaluator 三角、subagent 的 token 隔离、artifact carriers 的 file-backed state。第 6 篇收束成 12 条实战经验，从"先写 eval 再写 harness"一直讲到"observability is your friend”。

这六篇加起来回答了一个问题：harness 在工程上长什么样、要怎么搭。本篇不再加新积木——它要回答一个更难的问题：这条路接下来通向哪里？哪些事被认为做对了，哪些事其实根本还没解决？

2. 已经被认为相对成熟的五件事

把整张地图压缩成五条工程共识，可以说这是 2026 年初被多个独立团队（Anthropic、OpenAI、LangChain、Manus、Cognition）反复验证、可以当成默认配置的部分：

Agent loop 的形态收敛了——TAOR 循环 + 显式停止条件 + 工具并行调用 + 可选 extended thinking，已经从"研究品"变成"任何 SDK 都自带"的基础结构。loop 本身不再是创新点，而是 baseline。
CLAUDE.md / AGENTS.md 这种"分层指令文件"模式胜出——project-level / user-level / repo-local 三级层叠，加上 @import、加上"少即是多"的字数纪律（典型 200–800 行），已经成为跨团队的事实标准。LangChain 那篇 Context engineering for agents 直接把它列为 first-class pattern。
Subagent / 子代理隔离是标配——长任务必须通过子代理切 token、切上下文、切权限。父 agent 只看 artifact，不再回灌子 agent 的全部 trace。Anthropic 在 Scaling Managed Agents 中明确把"brain–hands 解耦"作为架构原则。
Auto-compact 与 file-backed state 解决了一阶 context 溢出——80% 阈值触发压缩、保留 system prompt + recent turns + 关键决策、把大块旧上下文 spill 到文件——这套组合拳基本兜住了"上下文撑爆"这一类问题。当然，二阶问题（被压缩掉的关键信息）仍然开放，下一节会讲。
三档权限模型够用——read-only / standard / bypass 三档（外加可选的 acceptEdits 中间档）+ 关键操作 hook，已被证明在生产环境里够安全又不至于反复打断用户。Anthropic 数据显示用户在 750 个 session 后 auto-approve rate 稳定在 40% 上下——既不是 0 也不是 100，意味着这套阶梯真的在工作。

注意：上面五条都是工程层的成熟。模型层（怎么训才能在 harness 里更好用）、评估层（怎么衡量一套 harness 的整体优劣）、治理层（多 agent 在组织内怎么管）——都还没收敛。下面六节就是这些"还没收敛"的领域。

3. 仍然开放的六个问题

3.1 Harness-as-a-Service（HaaS）：moat 的转移与 vendor lock-in

2025 年最后一个季度起，一个论调被反复提出：模型本身正在快速商品化，真正的护城河转移到了 harness。Aakash Gupta 在 2025 Was Agents, 2026 Is Agent Harnesses 里给出了最直接的表述：

The model is commodity. The harness is moat.

逻辑链条是这样的：当 GPT-5、Claude Opus 4.7、Gemini 3 Pro 在前沿能力上的差距收窄到个位数百分点，决定一个产品"能不能跑通真实任务"的不再是模型本身，而是它被裹进了一个怎样的 harness——工具集、权限策略、压缩与子代理调度、人审拐点。Vercel 的一个被反复引用的例子就是证据：把 agent 的工具数从几十个砍到 20%，可靠性反而显著提升。这不是模型的功劳，是 harness 设计的功劳。

于是顺理成章的下一步就是 Harness-as-a-Service：Anthropic 的 Claude Agent SDK、OpenAI 的 Agents SDK、Codex SDK——它们都把过去要工程师自己拼出来的"循环 + 工具 + 权限 + 子代理 + 可观测"打包成开箱即用的服务。Anthropic 的 Scaling Managed Agents 文章里的关键架构动作——把 brain（Claude + harness）和 hands（sandbox + tools）解耦成独立的接口——就是为了让同一套 harness 能挂在任意基础设施上，让同一套基础设施能挂任意 harness。p50 TTFT 下降 60%、p95 下降 90% 的性能数字也来自这次解耦。

但 HaaS 也带来三个尚未被讨论清楚的代价：

第一个代价：抽象会限制创新。当 SDK 把 4 大配置维度（system prompt / tools / context policies / subagent topology）变成新的"Spring Framework"——任何创业团队按官方教程 30 分钟拼出来的 agent 都长得差不多——奇怪的、不规则的、可能更优的设计就被劝退了。Manus 团队公开过自己半年内把 harness 重写了 5 次，每次都更简单。在 SDK 体系内能做到这种"自己重写自己"吗？很难。

第二个代价：vendor lock-in。模型本身是 commodity，但"模型 + 它的官方 harness"不是——一旦你的 prompt 库、工具 schema、子代理拓扑全部按 Claude Agent SDK 写过一遍，迁去别的基础设施代价是非平凡的。Decoding AI 那篇 Agentic Harness Engineering 把这点讲得很直接：harness 像 OS，理论上模型可以热插拔，实际上整套生态绑得很紧。

第三个代价（也是最深的）：模型与 harness 的耦合训练。我们会在 3.5 节专门讲，但这里先点明——当一个模型被 post-train 成"在 X harness 里好用"，它在 Y harness 里的能力就会出现非线性的下降。HaaS 提供商当然有动机让"自家模型 × 自家 harness"成为局部最优组合。这就把模型选择问题悄悄变成了 harness 选择问题。

趋势很清楚：2026 年里，"会做 prompt"已经不再是稀缺技能，"会配 harness"才是。但整个行业还没建立起"哪种 HaaS 抽象长期来看是好的"的判断标准——这正是接下来 3–4 年的争论焦点。

3.2 Self-Improving / Adaptive Harness：从静态配置到运行时编译器

第 6 篇我们说过："发现失败模式 → 改 harness → 再跑"是当下的工程节奏。但仔细看这条循环你会发现一个尴尬：发现失败模式的人是工程师，改 harness 的人也是工程师，唯独 harness 自己什么都没做。

Addy Osmani 的 Agent Harness Engineering 给出了一个让人振奋的设想：

Harnesses stop being static config and start becoming something closer to a compiler.
Harnesses 不再是静态配置，而开始变成更接近编译器的东西。

具体长什么样？自适应 harness（adaptive / self-improving harness）：在每一轮执行结束后，harness 自己读取自己的 trace，识别"工具被反复重试"“子代理超时”“压缩抹掉了关键决策"这类模式，自己调整下一轮的 hooks、max_turns、max_budget_usd、子代理拓扑。把"由人在两个 deploy 之间做的事"压缩到"在两个 turn 之间做完”。

Yoonho Lee 等人的 Meta-Harness 把这件事真做出了一个原型：proposer agent 用 grep / cat 之类的标准工具读上一轮的执行 trace、源码、得分，然后生成下一版 harness——它能在单次优化迭代里访问最多 1000 万 token 的诊断上下文（对照过去方法的 ~26k token 上限）。结果在 TerminalBench-2 上：Claude Opus 排名 #2、Claude Haiku 排名 #1——只动 harness 不动模型就能拿到这种位次。

但真要把"自己改自己"推到生产，瓶颈不在算力，在可靠的根因归因（root-cause attribution）：

一次失败到底是模型推理错了？还是工具 schema 写歪了？
是上下文压缩把关键事实抹了？还是子代理没有把 artifact 写出来？
是 max_turns 设小了？还是 max_budget_usd 切早了？

每一层都可能"看起来"是错因。在没有一个干净的 attribution 协议之前，让 harness 自己改自己，相当于让一个新手工程师没有日志只看屏幕截图就去 debug——可能改对，更可能引入更多 regress。Addy 自己也强调：“a harness is a living system, not a config file”——但 living 不代表 self-modifying。在能可靠归因之前，人 + harness 的 co-evolution 节奏仍是更稳的工程实践。

3.3 Natural-Language Agent Harness（NLAH）：让非工程师也能改 harness

更激进的一条路是把 harness 本身用自然语言写。arXiv 2603.25723 的 Natural-Language Agent Harness 论文给出了完整的架构：

Contracts：必需输入/输出、格式约束、validation gate、permission boundary、retry / stop 规则——以受约束的自然语言写出，但可被运行时强制执行。
Artifact Carriers：file-backed、path-addressable 的状态对象（manifest、ledger、文件树），跨步骤持久化，context 截断后还能恢复。
Stage Structure：显式的工作流拓扑，比如 plan → execute → verify → repair。
Roles & Adapters：solver / verifier / researcher 这种命名角色，以及确定性 hook（test、linter、文件验证）。
IHR（Intelligent Harness Runtime）：包含 in-loop LLM（解释自然语言 harness 逻辑）、backend（终端工具 + 多 agent 接口）、Runtime Charter（共享语义）。

为什么这件事重要？因为它把 harness 的可写群体从"会写 TypeScript 的工程师"扩到"能写清楚需求的领域专家"。NLAH 论文里的关键论断之一是——

NLAHs under IHR are behaviorally real controls on coding and computer-use benchmarks, not mere prompt decoration.
在 IHR 之下，自然语言 harness 是真实生效的行为控制，而非 prompt 装饰。

也就是说，自然语言写出的 contract 不是"建议"，而是 runtime 强制执行的边界。论文还指出一个反直觉发现：额外的编排层只在与评估器的 acceptance criteria 对齐时才有用——多加一个 verifier 反而可能漂移到错误的成功信号。这一点和 LangGraph / CrewAI 的设计哲学差异很大：那两者倾向于把控制逻辑写进 Python / DSL，而 NLAH 把控制逻辑外化为可读、可改、可比较的自然语言对象。

另一个值得注意的边界正在重叠的现象：人类正在用自然语言改 harness，LLM 正在把工具调用写成自然语言函数。两边都在朝中间靠——硬编码的胶水代码这个生态位，正在被自然语言挤掉。

下一步开放问题：

NLAH 怎么版本化、diff、code review？ 自然语言难以做 line-by-line patch，但又需要 audit trail。
IHR 跨厂商的标准化——谁会做这件事？OpenAI MCP 的 prompts/resources 接口算半步，但还远不够。
怎么避免"用自然语言写出隐式的死代码"——一个看似无害的 contract 可能让 agent 永远走不到某条分支。

3.4 Harness 形式化与基准化：从工艺到科学

第 6 篇那 12 条实战经验其实暴露了一个尴尬事实——今天的 harness 工程更像工艺（craft）而非科学。我们说"先写 eval 再写 harness"是对的，但"评的是哪个 harness"却没有任何形式化的定义。同一个 Claude Opus 4.5 模型，在 Cursor 的 harness 里跑 SWE-bench 是 a 分，在 Codex 里跑是 b 分，在自研 harness 里跑是 c 分——读者拿到这三个数字，没有任何工具去说"哪一段差距来自模型，哪一段来自 harness"。

Meta-Harness 的论文给了一个工程化办法：固定 LLM core，只让 harness 代码作为变量——这样测出来的差异就是 harness 贡献。同样思路在 Terminal-Bench 2.0 也被采用：89 个任务，每任务都有人写的 reference solution + 自动测试，因此 SWE-bench / Terminal-Bench 两个 benchmark 现在已经可以做"harness ablation"——同模型不同 harness 的得分差。

但这只是工程层的可重复，不是科学层的可形式化。Preprints.org 上的 Agent Harness for LLM Agents: A Survey 提了一个更激进的方向：用带标号迁移系统（labelled transition system, LTS）语义为 harness 建立形式化定义。一旦你能把一个 harness 写成 (S, A, →, s_0, F) 五元组——状态、动作、迁移、初态、终态——那么经典并发理论里的 safety 性质（坏事不会发生） 和 liveness 性质（好事终将发生） 就可以被严格刻画：

性质类别	例子	为什么 harness 关心
Safety	“永远不会把 production DB 删掉”	permission 系统的形式化目标
Liveness	“用户提的任务最终会拿到一个 final answer 或一个明确的 abort”	防止 agent 进入"假装在思考"的死循环
Fairness	“所有子代理的请求最终都会被父 agent 看到”	多 agent 调度的正确性
Termination	“max_turns 之内一定会进入终态”	预算 / 资源保证

一旦有了这些形式化定义，"这套 harness 是否安全"就不再是一句广告语，而是可被模型检验（model checking）的命题。

但离一个真正的 harness benchmark suite 还差什么？至少四件事：

任务覆盖度的多样性——目前的 benchmark 偏 coding（SWE-bench、Terminal-Bench、HWE-Bench），computer-use（OSWorld、WebArena）已经被证明都能被 exploit 拿满分。在 benchmark gaming 解决之前，harness 评测的"信号-噪声比"很低。
harness 维度的解耦——一个 harness 同时改了 prompt、工具集、压缩策略、权限策略，benchmark 怎么把贡献拆开归因？
跨模型的可比性——同一个 harness 配在 GPT-5 / Claude / Gemini 上的表现都不一样，结果是 model × harness 的二维矩阵，不是一维 leaderboard。
真实任务的数字 vs 静态 benchmark 的数字——线上失败率 / 用户重试率 / 人工接管率，这些 production 信号才是终极标准，但当前没有公开数据集。

我个人的判断：2026 年里最有价值的工作之一，就是把 harness 评测从"工艺感的实战记录"推进到"科学感的可重复实验"。

3.5 模型–Harness 共训练：编译器与硬件的共进化

这是六个开放问题里最深、最危险、也最让人兴奋的一个。

事实先说清：post-training 已经在 harness 之内发生了。Anthropic 公开承认 Claude 模型被训练成"在 Claude Code 工具集里好用"——agent SFT、tool-use RL、CLAUDE.md 风格的 instruction following，都是在特定的 harness 假设下做的。这不是 bug，是 feature：把模型和 harness 当成耦合的一对一起优化，能榨出模型能力的最后一截。Daily Dose of DS 那篇 The Anatomy of an Agent Harness 给了一个简练判断：

Models are post-trained within specific harness environments, creating tight coupling that paradoxically enables harness simplification.
模型在特定 harness 环境内做 post-training，这种紧耦合反而使 harness 得以简化。

但这条路有三个非平凡的风险：

风险一：over-fit 到训练 harness。一个模型被训得"在自家 SDK 的工具调用 schema 下表现很好"，换到第三方 harness 上掉 5–15 分非常常见。这让"模型 benchmark 数字"和"模型实际泛化能力"出现系统性脱节。Meta-Harness 论文里有一组数字：5 个未见过的模型在数学推理任务上都拿到平均 4.7 分提升——只动 harness。这同时是好消息（harness 能补模型的洞）和坏消息（模型的洞被 harness 隐藏了，没人知道"裸模型"现在到底什么水平）。

风险二：harness 的 prune 滞后。理想情况下，每代模型变强，harness 应该变薄——把 planning 步骤、reflection 步骤、verifier 步骤逐步收回给模型自己做。但实际工程节奏里，没人愿意先拆 harness 再升级模型——要先确认新模型不掉线，才敢拆旧脚手架。结果是 harness 在 ratchet 的方向上单调增厚，直到积累到不可维护。Manus 半年内重写 5 次，是少见的勇敢例子。

风险三：harness 不会针对模型的"洞"生长。理想是这样的：在 eval 中发现模型在某类任务（比如长代码 refactor）上失败率高 → harness 长出一段 verifier 来兜底；下一代模型把这类任务做对了 → harness 把这段 verifier 回收。现实是：harness 长得多、收得少。整体复杂度的方向是单调上升的，逐渐失去"可解释性"。

长远图景应当是：

模型 ←——— co-evolve ———→ harness
  ↑                          ↑
  按 harness 的 hole 训练    按模型的 hole 长 / prune

——像编译器与硬件的共进化。CPU 加了 SIMD 指令，编译器用上 SIMD 自动向量化；编译器优化器变好了，CPU 可以省掉某些复杂分支预测器。但这件事的难点在于双方各自的演化节奏不同：模型几个月迭代一次，harness 几乎每天在改。共进化需要稳定的契约（contract）层——目前 MCP 是 tool 接口的初步契约，但工具之外（context policies、subagent topology、permission semantics）还没有跨厂商的契约。

3.6 长期人类能力问题：harness 的"第六维"

前面五维是 Dive into Claude Code 这篇论文给出的 harness 评价标准：

Human Decision Authority（人类决策权）
Safety, Security, Privacy（安全、保密、隐私）
Reliable Execution（可靠执行）
Capability Amplification（能力放大）
Contextual Adaptability（上下文适应性）

但论文还指出一个让人不安的发现：

Developers in AI-assisted conditions score 17% lower on comprehension tests.
AI 辅助状态下的开发者，在代码理解测试上得分低 17%。

而 Anthropic 自己的内部研究也观察到了所谓"paradox of supervision（监督悖论）"——人对 AI 的依赖越深，监督 AI 的能力反而越弱。同一篇研究里另一个标志性数字是：用户对 permission prompt 的批准率高达 ~93%——这是 approval fatigue 在起作用。

这就是 harness 的第六维：长期人类能力（long-term human capability）。一个 harness 短期把任务做完了，但如果它让人类逐步丧失理解、审查、判断这件任务的能力，那它在三年时间尺度上就是负价值。

工程对策有三条已经在被试验：

Transparency（可观测的 reasoning trace）——不只是"agent 做了什么"，更是"agent 为什么这么做"。这与 3.1 节的 trace-driven self-improvement 共享同一套基础设施。
Graduated trust（分级信任 / 人审升级路径）——不是一刀切的 auto-approve，而是按任务的可逆性、影响半径、历史成功率动态调档。Anthropic 的 7 档 permission spectrum 是早期尝试。
Deliberate friction（刻意摩擦）——在某些步骤强制人介入。听起来违反"提升效率"的初衷，但这正是反 approval fatigue 的关键设计。比如：每 N 个 commit 强制一次人工 code review、每个 prod deploy 强制 5 秒冷静期、每周一次"human-only debug day"。

这条线的研究还很早。但 2026 年内会有越来越多的工作把"用了 X 个月之后，人类能力变化曲线"作为评价 harness 的硬指标——而不仅是任务通过率。

4. 已解决 vs 开放问题：一张大表

把整个图景压成一张对照表，方便你 scan：

维度	相对成熟（2026 年初）	仍然开放 / 争议中
Loop（循环）	TAOR 形态、stop-condition、parallel tool-use、extended thinking	turn budget 的自适应分配；动态停止条件
Context（上下文）	三层 CLAUDE.md / AGENTS.md、auto-compact 的 80% 阈值、file spill	二阶失真（被压缩抹掉的关键决策）、跨会话语义化压缩
Tools（工具）	MCP 协议、工具数纪律（≤20 个常用）、bash / file / MCP 三类粒度	tool catalog 的语义化检索、tool 版本演化兼容
Permissions（权限）	三档（read-only / standard / bypass）+ 关键 hook	approval fatigue 的对策；细粒度 capability-based security
Memory（记忆）	session 内 file-backed state、artifact carrier	跨会话持久化、人–agent 长期 colleague 关系
Multi-agent（多代理）	planner–generator–evaluator、subagent token 隔离	无限层 subagent 的成本爆炸、跨 agent 的事务一致性
Observability（可观测）	trace 日志、turn-level metric	silent failure 检测；root-cause attribution 协议
Governance（治理）	单 agent 的 audit trail	组织级 multi-agent 行为审计、policy enforcement at scale
Harness benchmark	TerminalBench、SWE-bench 上的 harness ablation	跨任务的 benchmark suite、formal LTS-based 评估
Co-training（共训练）	post-training in harness 已成为默认	over-fit 风险量化；解耦的"裸模型"评估协议
Human capability	transparency / graduated trust / deliberate friction 三条对策的初步设计	长期使用对人类能力曲线的影响测量；harness 第六维评测标准

5. Harness Engineering 的时间轴：2022–2026 + 未来 5 年

把整个领域的过去与未来画成一张 ASCII 路线图：

        过去 (2022–2026)                          未来 5 年 (2026–2031)
┌──────────────────────────────────┐      ┌──────────────────────────────────┐
│  2022  ReAct (TAOR loop)         │      │  2026  HaaS 普及 / 4 维 SDK 确立 │
│  2023  Tool-use 标准化            │      │  2027  Adaptive harness 生产可用 │
│        (function calling)        │      │        (在线 root-cause 归因)    │
│  2024  Agent framework 大爆发     │      │  2028  NLAH 进入主流              │
│        (LangChain, AutoGen,      │      │        (非工程师改 harness)      │
│         CrewAI, Manus)           │      │  2029  Harness benchmark suite   │
│  2025  Karpathy 的 OS 类比        │      │        (LTS 形式化评估)          │
│        Anthropic SDK / Codex     │      │  2030  模型–harness 共训练协议    │
│  2026  Harness Engineering       │      │        (跨厂商契约层)            │
│        作为独立学科                │      │  2031  Harness 第六维评测进入     │
│        (Martin Fowler 等)         │      │        组织级合规标准             │
└──────────────────────────────────┘      └──────────────────────────────────┘
                              \             /
                               \           /
                                现在 (2026 Q2)
                            分水岭：从工艺到科学

注意这条时间轴的特征：前段在收敛，后段在分化。前 4 年大家在朝同一个 abstract（agent loop + tool use + context window）汇聚；接下来 5 年会朝多条独立的轴展开——评测、形式化、共训练、人类能力——每条轴都需要它自己的研究社区。

6. 给从业者的 3 条建议

如果你已经在做 agent 系统，下面三条是接下来 12 个月最值得对照检查的：

第一条：把 harness 当成主战场，不要再等下一代模型。 当前阶段，模型每次升级带来的边际收益已经不如 harness 的一次重写。Manus 半年 5 次重写、Vercel 把工具数砍掉 80%、Meta-Harness 只动 harness 就在 TerminalBench-2 拿到 #1——这些都不是巧合。如果你团队的争论永远是"等 GPT-6 出来就好了"，请把 harness 重写一次再说这句话。

第二条：投资可观测性比投资工具数更划算。 多加一个工具，最多解决一个 use case；多加一层 trace + diff 的可观测，你能看见所有 use case 上的失败模式。Meta-Harness 之所以能让 LLM 自己改 harness，前提是它有 1000 万 token 的 trace 可读。observability 是 self-improving harness 的入场券，也是 root-cause attribution 的唯一基础。今天少投这一块，明天的 self-improving / NLAH / formal verification 全部进不去。

第三条：读至少一篇 harness 形式化论文，再读一遍 LangChain 的 Context engineering for agents。 工程层的实战只能让你做出"和别人差不多的 harness"。要做出"显著更好的 harness"，必须把视野提到上一层——形式化语义、契约边界、信息论意义上的 context loss。即使你不是研究员，读完一遍这些材料也能让你在工程决策上少走 6 个月弯路。非工程出身的读者尤其建议读 Context engineering for agents——它不需要任何编程背景，但能给你一套精确的语言去描述 agent 系统里的问题。

7. 系列总结：harness engineering 是 LLM 时代的 systems engineering

走完这 7 篇，最关键的一句话只有一句：

Harness engineering 是 LLM 时代的 systems engineering——它不会因为模型变强而消失，只会变形。

变形的方向 7 篇都讲了：

从静态 config 到运行时 compiler（self-improving）
从 Python / TS DSL 到自然语言（NLAH）
从工艺到形式化（LTS、benchmark suite）
从模型与 harness 各自演化到共训练
从 5 维评价（authority / safety / reliability / amplification / adaptability）扩到 6 维（+ long-term human capability）
从单 agent 到 managed agents 到组织级 governance

但它不会消失这件事很关键。每一代有人说"模型够强就不需要 harness 了"——5 年来这句话从来没对过。Karpathy 把 LLM 类比成 OS 的逻辑同样适用于这里：CPU 越强，OS 不会消失，只会从批处理走向分时、走向虚拟化、走向容器、走向 serverless。harness 也一样。

最后送给读这 7 篇的你一句话：把这 7 篇当成一张地图，不是说明书。地图的作用是让你知道自己在哪、可以往哪走、有哪些区域还没人走过；说明书的作用是让你按步骤做完一件事。harness engineering 还在野蛮生长——你的下一个工程决策，可能就是地图上某个还没填的空白。

关键 Takeaway（系列级）

Agent = Model + Harness——这条公式贯穿 7 篇。模型变强，harness 不会消失，只会变形。
2026 年 moat 在 harness，不在 model——loop、context、tools、permissions、memory、multi-agent 五个维度都已经是工程主战场。
当前最大的工程瓶颈不是能力，是可观测性——root-cause attribution 解决之前，self-improving 和 NLAH 都跑不快。
Harness 第六维已经浮出水面：长期人类能力——transparency / graduated trust / deliberate friction 是已知对策，但远远不够。
形式化 + benchmark suite 是 2026–2028 的关键基础设施——离开它，整个领域无法从工艺升级成科学。

下一步阅读：把这 7 篇按重读优先级排序

如果只能再读 3 篇：

第 1 篇《什么是 Harness 工程》——最常需要回看的概念锚点，团队对齐用。
第 6 篇《12 条实战经验》——做项目时直接对照的 checklist。
第 3 篇《上下文工程深入》——CLAUDE.md / 压缩 / 持久化是实际 debug 时最频繁触发的章节。

完整重读优先级：

优先级	篇章	重读触发场景
★★★★★	第 1 篇概念与起源	概念混乱时；新人 onboarding
★★★★★	第 6 篇实战 12 条	启动新项目；做 code review
★★★★	第 3 篇上下文工程	上下文相关 bug；设计长任务
★★★★	第 7 篇未来与展望（本篇）	做技术选型；季度规划
★★★	第 2 篇 Agent 循环	Debug stop-condition / turn
★★★	第 4 篇工具与权限	设计工具集；权限事故复盘
★★★	第 5 篇长任务多代理	任务超出单 agent 边界时