Harness Engineering for Self-Improvement

learn from https://lilianweng.github.io/posts/2026-07-04-harness/

核心概念：Harness 是模型外面的“运行系统”

Harness 指包围在 base model 外面、决定模型如何运行的一整套系统。它控制模型如何观察环境、构造 context、规划、调用工具、执行 action、保存 state、调用 sub-agent，以及如何验证结果。因此今天讲 Harness Engineering，已经不太像传统 Prompt Engineering，而更接近 runtime / software system design。

传统 Agent 经常被概括为：

Agent = LLM + Memory + Tools + Planning + Action

但 Harness 还进一步加入了 workflow design、evaluation、permission control、persistent state management 等系统组件。原文用了一个很好的类比：Harness 和 Model 的关系有点像 Operating System 和 CPU。 OS 不负责制造 CPU 的核心算力，但它决定算力如何接触文件、进程、外设和其他程序；类似地，Harness 不直接增加模型参数，但决定模型如何利用 context、tools、memory 和 computation。

graph LR
    M[Base Model<br/>Core Intelligence]
    H[Harness<br/>Runtime System]
    C[Context]
    T[Tools]
    F[File System / Memory]
    S[Sub-agents]
    E[Evaluator / Verifier]
    W[Workflow / Control Flow]

    H --> M
    C --> H
    T --> H
    F --> H
    S --> H
    E --> H
    W --> H

这也解释了为什么 Harness 会和 Recursive Self-Improvement（RSI）联系起来。RSI 不一定意味着“模型直接修改自己的 weights”。更现实的近期路径可能是：模型先学会改进包围自己的 Harness；更好的 Harness 又让模型能够进行更好的自动研究、实验和系统优化；这些研究最终又帮助产生更强的模型。作者因此认为，近阶段的 RSI 很可能首先发生在 deployment system，而不是直接发生在 weights 上。

Harness Design Patterns

文章开头先总结了三个目前非常通用的 Harness Design Pattern：Workflow Automation、File System as Persistent Memory，以及 Sub-agent + Backend Jobs。它们看起来很简单，但实际上构成了很多现代 Coding Agent 的基础。

1. Workflow Automation：从一次 Prompt 变成持续 Runtime

最重要的变化是 Agent 不再执行一次 Prompt → Answer，而是在环境里持续运行。一个典型循环是：

flowchart LR
    G[Goal] --> P[Plan]
    P --> X[Execute]
    X --> O[Observe / Test]
    O --> D{Goal reached?}
    D -- No --> I[Analyze failure<br/>Improve]
    I --> P
    D -- Yes --> R[Result]

也就是说，Agent 的 intelligence 不只是体现在某一次 generation 上，还体现在它是否可以根据 tool response、test result、error log 和 execution trajectory 调整下一步行为。传统 Prompt Engineering 优化的是“第一次回答得好不好”，而 Agent Harness 优化的是“整个 trajectory 最后能不能成功”。

Coding Agent 特别适合这种结构。例如 Agent 修改代码以后，可以直接运行测试；测试失败以后读取 stack trace，再修改代码；而不是让模型凭语言推理一次性猜出最终 patch。这里环境反馈相当于给模型增加了一个外部 correction channel。

所以从系统角度看：

LLM reasoning + environment feedback + iteration

往往比：

LLM reasoning alone

强很多。

2. File System as Persistent Memory：Context Window 只是 Working Memory

Long-horizon Agent 一个非常实际的问题是：trajectory 会越来越长。experiment log、code diff、paper summary、error trace、过去尝试过的方案，很快会超过 context window。最直接的解决方法反而不是复杂的 vector DB，而是普通 File System。

graph TD
    A[Agent Working Context<br/>small + relevant]
    FS[(Persistent File System)]

    LOG[Experiment logs] --> FS
    CODE[Code / Diff] --> FS
    TRACE[Past trajectories] --> FS
    NOTE[Research notes] --> FS

    FS -->|grep / glob / read| A
    A -->|write / edit| FS

这里非常值得记一个原则：

Context ≠ Memory。

Context 是当前 inference step 需要看到的 working set；Memory 是长期存在、未来可以重新检索的 state。Harness 不应该把“Agent 曾经见过的所有东西”持续 append 到 prompt，而应该把大量状态外置，只在需要时通过 grep / glob / read / bash 拉回来。

这其实和操作系统里的 RAM / Disk 很像：

Context Window ≈ RAM

File System ≈ Disk / Persistent State

而且 File System 有一个很现实的优势：LLM 在 pretraining 里已经见过大量 shell、filesystem、code，因此 ls / grep / cat / edit 是一个模型天然比较熟悉的 interface，不需要为了 Memory 再发明一个复杂 abstraction。

3. Sub-agent + Backend Jobs：显式并行，而不是把所有推理塞进一个 Context

主 Agent 可以把彼此独立的任务拆出去，例如同时探索多个 hypothesis、运行多个 experiment、检索不同来源，之后再汇总。

flowchart TD
    P[Parent Agent]
    P --> A1[Sub-agent 1<br/>Hypothesis A]
    P --> A2[Sub-agent 2<br/>Hypothesis B]
    P --> A3[Sub-agent 3<br/>Hypothesis C]

    A1 --> F[(Files / Logs)]
    A2 --> F
    A3 --> F

    F --> P
    P --> M[Merge / Compare / Decide]

这里作者强调的其实不只是 Multi-Agent，而是 parallelism must be explicit and inspectable。如果 sub-agent 的输出只存在于一次临时 chat response 中，parent 很难恢复状态；如果结果存在 file、log、status record 里，parent agent 就可以之后重新检查、比较甚至恢复 interrupted task。

所以一个成熟的 parent agent 实际上还需要一个很轻量的 process manager：spawn → inspect logs → wait → cancel failed jobs → merge outputs。

这也是为什么今天 Coding Agent 的 interface 正在逐渐标准化。主流系统基本都包含 File System、Shell、Git/LSP、Web/MCP、Artifact、Background Process 和 Agent Delegation。这种标准化很像早期操作系统逐渐形成统一的 filesystem/process/network abstractions。

Harness Optimization：到底在优化什么？

我觉得整篇文章最重要的一条主线是 optimization target 不断向外扩张：

flowchart LR
    P[Instruction Prompt]
    --> C[Structured Context]
    --> W[Workflow]
    --> H[Harness Code]
    --> O[Optimizer Code]

早期我们问的是：“Prompt 怎么写得更好？”之后变成：“模型应该看到什么 context？”然后变成：“模型应该按照什么 workflow 工作？”进一步变成：“整个 Harness code 应该如何组织？”最后甚至可以问：“负责优化 Harness 的 optimizer 本身能不能继续优化？”

这个 progression 是理解后面所有 paper 的最好框架。

Context Engineering：不只是放什么 Context，而是怎么生产 Context

普通 Agent 很容易采用一个 naive strategy：把所有 tool response、所有过去 generation 一直 append 进去。但随着 task horizon 增长，这种方式会让 context 越来越长、噪声越来越多。

因此 Context Engineering 的核心问题其实是：

在当前这一步，哪些信息应该进入模型的 working context？

ACE：Context 是不断成长的 Playbook

Agentic Context Engineering（ACE）把 context 看成一个 evolving playbook，而不是一个越来越长的大 Prompt。它包含 Generator、Reflector 和 Curator 三个角色：

flowchart LR
    C[(Context Playbook)]
    --> G[Generator<br/>Run task]
    G --> T[Trajectory]
    T --> R[Reflector<br/>Extract lessons]
    R --> U[Curator<br/>Update items]
    U --> C

Generator 根据当前 playbook 执行任务；Reflector 从成功与失败 trajectory 中总结 insight；Curator 再把 insight 更新进 context。

ACE 一个很聪明的设计是：Curator 不反复 rewrite 整个 Prompt，而是维护类似 (identifier, description) 的 structured items。原因是反复让模型“重新总结整个 prompt”很容易产生 context collapse / brevity bias：每次 rewrite 都会丢掉一些细节，最后 context 越来越短但信息也越来越少。

所以 ACE 做的是 incremental update，而不是 full rewrite。这一点很像数据库：

append / update structured records

比：

每次重新生成整张 database

可靠得多。

不过 ACE 仍然有一个限制：如何更新 Context 的规则本身还是人工设计的。 Generator / Reflector / Curator 这些结构都是人为规定的。于是下一步自然变成：能不能连“Context Engineering 的方法”也自动学习？

Meta Context Engineering：优化“产生 Context 的函数”

Meta Context Engineering（MCE）把问题拆成两个层次。Base level 优化具体任务需要什么 Context；Meta level 优化“应该采用什么 Context Engineering strategy”。

一个 skill (s) 定义一个 context function：

$c = F_s(x; ρ_s)$

其中 $ρ_s$ 是 static components，例如 prompt、knowledge base、code library；$F_s$ 是 dynamic operators，例如 search、selection、filtering、formatting。

所以一个 Skill 可以理解成：

graph LR
    X[Task Input x]
    R[Static Resources ρ<br/>Prompt / KB / Code]
    F[Dynamic Operators F<br/>Search / Select / Filter / Format]
    C[Generated Context c]

    X --> F
    R --> F
    F --> C

真正有意思的是它的 bi-level optimization：

flowchart TD
    MA[Meta Agent]
    -->|evolve skill| S[Skill / Context Strategy]
    S --> BA[Base Context Engineer]
    BA -->|construct context| C[Task Context]
    C --> E[Run + Evaluate]
    E --> H[(History:<br/>skill, context, train score, val score)]
    H --> MA

Inner loop 问：“给定一个 skill，当前任务的 context 应该怎么优化？”

Outer loop 问：“什么 skill 才是一种更好的 Context Engineering 方法？”

也就是说优化对象已经从 context artifact 提升到了 context-generation mechanism。

这是一个非常关键的 abstraction shift：

What context should I use?

→

What function should generate my context?

而且 MCE 的 context function 实际上也被实现成 files，包括静态 skill.md 和动态 rollout/context data。这样 Agent 就可以直接通过 Read/Write/Edit/Bash/Glob/Grep 修改自己的 context engineering machinery。

Meta-Harness：直接把 Harness Code 变成 Search Space

Meta-Harness 又往外走了一层：现在优化的不再只是 Context Function，而是 决定信息如何存储、检索和呈现的 Harness Code 本身。

这里最重要的思想其实非常工程化：

一旦 Harness 可以表示成 executable code，它就成为一个可以自动搜索的 program space。

流程大概是：

flowchart TD
    H0[Existing Harnesses]
    --> P[Coding Agent Proposer]
    P --> H1[New Harness Code]
    H1 --> R[Run Benchmark]
    R --> S[Score + Trajectory + State]
    S --> Q{Qualified?}
    Q -- Yes --> A[(Harness Archive)]
    Q -- No --> X[Reject]
    A --> P

每个 candidate harness 自己就是一个 directory，里面包含 source code、scores、rollout trajectories 和 state updates。整个 execution history 也在 filesystem 中，因此 coding agent 不需要把所有历史塞进 prompt，而可以通过 grep/cat 自己浏览过去实验。

最终 Meta-Harness 不一定只留下“一个最好的 Harness”，而是可能得到 Pareto frontier 上的一组 candidates，因为 Harness 可能存在不同 trade-off，例如 accuracy、latency、token cost、complexity。

这其实已经非常像 AutoML，只不过 AutoML 搜的是 model architecture / hyperparameters，而 Meta-Harness 搜的是 agent runtime programs。

Workflow Design：把 Agent Architecture 也当成可搜索对象

Workflow 本身也是 Harness 的一部分。最初 workflow 可以人工设计，例如 AI Scientist 会把研究拆成 idea generation、coding、experiments、analysis、paper writing、review 等步骤。但 workflow design space 非常巨大，于是自然会产生一个问题：

为什么一定要由 human engineer 手工设计 workflow？

Autodata：自动寻找“恰好有学习价值”的数据

Autodata 的目标是生成 synthetic training/evaluation data。它包含 Challenger、Weak Solver、Strong Solver 和 Verifier。

flowchart LR
    C[Challenger<br/>Generate Problem]
    --> W[Weak Solver]
    C --> S[Strong Solver]

    W --> V[Verifier]
    S --> V

    V --> D{Difficulty}
    D -->|Weak ✅ Strong ✅| EASY[Too Easy]
    D -->|Weak ❌ Strong ❌| HARD[Too Hard]
    D -->|Weak ❌ Strong ✅| GOOD[Useful Training Data]

    GOOD --> C

最有价值的是 Strong Solver 能解、Weak Solver 解不了 的题，因为它刚好落在 weak model 的 learning frontier 上。太容易的数据没有 learning signal；太难的数据又没有可靠 teacher signal。

Challenger 会根据 Solver + Verifier 的反馈继续更新自己的 prompt，从而逐渐生成更合适的数据分布。

不过作者也提醒：Autodata 生成的数据最终用于 fine-tune weak solver，但 strong solver 没有在这个 loop 里持续增强，所以它更像一种自动化 distillation，而不是最纯粹的 recursive self-improvement。

ADAS：让 Meta-Agent 直接写新的 Agent Workflow

Automated Design of Agentic Systems（ADAS）进一步把 agent design 本身定义成 optimization problem。

flowchart TD
    A[(Archive<br/>Existing Agents)]
    --> M[Meta-Agent]
    M --> D[Describe New Workflow]
    D --> C[Implement Workflow in Code]
    C --> R1[Self-Refine]
    R1 --> R2[Self-Refine Again]
    R2 --> E[Evaluate]
    E --> Q{Good Candidate?}
    Q -- Yes --> A
    Q -- No --> X[Discard]

开始时 archive 里面只有一些简单 agent，例如 CoT、Self-Refine。Meta-agent 会读取已有方案，先写一个新的 high-level workflow description，再实现为 code，然后执行两轮 self-refine，检查并修改设计，最后进行 benchmark。

这里最值得注意的是 Archive。系统不是 hill climbing：只维护“当前最优 agent”。它保留了一组过去成功的 agent design，新的设计可以从不同 parent 获取 inspiration。因此它更像 evolutionary search，而不是单一路径优化。

AFlow：把 Workflow Optimization 显式变成 MCTS

AFlow 又更明确一步：它把 agentic workflow 表示成 Graph，其中 node 是调用 LLM 的 action，edge 是 code 实现的 logic/control flow。然后直接使用 Monte Carlo Tree Search 搜索 workflow。

graph TD
    W0[Workflow W0]
    W0 --> W1[Variant W1]
    W0 --> W2[Variant W2]
    W1 --> W3[Variant W3]
    W1 --> W4[Variant W4]
    W2 --> W5[Variant W5]

    W3:::best
    classDef best stroke-width:4px

每次 iteration 做的事情本质上是：

flowchart LR
    S[Select Workflow]
    --> E[Expand<br/>LLM proposes modification]
    --> R[Run]
    --> V[Evaluate]
    --> K{Improved?}
    K -- Yes --> T[Add to Search Tree]
    K -- No --> X[Discard]
    T --> S

Selection 不单纯选 score 最高的 node，而是在 exploitation 和 exploration 之间做 soft mixture。否则很容易一直围绕当前 best workflow 做局部修改，错过完全不同的 architecture。

停止条件通常是 top-k average score plateau，或者 search budget 用完。

这让我觉得很有意思的一点是：过去 MCTS 搜的是 Chess/Go action，现在搜索对象直接变成了 Programs that control LLMs。

Self-Improving Harness：从优化一部分变成优化整个 Runtime

Context Engineering 只是 Harness 的一部分，Workflow Design 也只是其中一部分。完整 Harness 还包括 tool interfaces、permissions、memory、middleware、sub-agent config 等。既然这些最后都可以表示成 code，那么理论上 Coding Agent 就可以修改整个 Harness。

所以这里发生了一个重要变化：

LLM solves task

变成：

LLM modifies the program that determines how LLM solves tasks

这就是为什么 Harness Engineering 开始接近 RSI。

STOP：不是 Improve Solution，而是 Improve the Improver

Self-Taught Optimizer（STOP）是一个很早的 recursive scaffolding improvement 例子。

普通 optimizer：

flowchart LR
    I[Improver I]
    --> S[Solution]
    S --> U[Utility]

STOP 做的是：

flowchart TD
    I0[Improver I₀]
    --> S0[Improve Solutions]
    S0 --> U0[Measure Meta-Utility]
    U0 --> I1[Improve Improver → I₁]
    I1 --> S1[Improve Solutions Better]
    S1 --> U1[Measure Again]
    U1 --> I2[Improve Improver → I₂]

定义一个 improver：

I(u, s; M) → s'

输入 utility function u、initial solution s 和 model M，得到新的 solution。STOP 不直接优化 s，而是定义一个 meta-utility，衡量“这个 improver 在一组 downstream tasks 上平均能把 solution 改好多少”，然后再让 improver 去修改自己。

实验里比较有趣的一点是，它自己发现了一些经典 optimization strategies：genetic algorithm、beam/tree search、simulated annealing、multi-armed bandit、temperature variation、decompose-and-improve。这说明 LLM 不一定需要人显式告诉它“使用某某搜索算法”；当 optimization objective 足够明确时，它有可能重新发现这些 structure。

但这里有一个非常关键的 negative result：GPT-4 可以随着 iteration 改进 improver，而 GPT-3.5、Mixtral 等更弱模型反而可能退化。

所以：

Recursion ≠ Intelligence。

Self-improvement loop 本身不会凭空产生 intelligence。Base model 必须已经足够聪明，才能可靠地修改“让自己变聪明的方法”。

Harness Updating 和 Harness Benefit 是两个不同能力

后续研究进一步把这个问题拆成两个 axis：

Harness Updating Capability：模型能不能提出好的 Harness 修改。

Harness Benefit Capability：模型能不能正确利用这个修改后的 Harness。

它们并不是同一个能力。

quadrantChart
    title Harness Capability
    x-axis Weak Updating --> Strong Updating
    y-axis Weak Utilization --> Strong Utilization
    quadrant-1 Ideal Harness User + Builder
    quadrant-2 Good User / Poor Builder
    quadrant-3 Weak on Both
    quadrant-4 Good Builder / Poor User

一个模型可能能写出很好的 skill/tool instructions，但自己不擅长在正确时机调用这些 skill；反过来，也可能自己非常擅长按照复杂 Harness 执行，却不善于设计 Harness。

实验甚至发现 Harness Benefit 并不是随着模型 intelligence 单调增加：中间档模型有时获得最大收益。一个合理解释是：弱模型连 Harness 都不会正确执行；最强模型本身已经能解决大量问题，Harness 的 marginal gain 反而比较小；中间模型正好处于“能力足够使用 Harness，但又仍有大量 weakness 可以被 Harness 补偿”的区域。

Self-Harness：Weakness Mining → Proposal → Validation

Self-Harness 的设计非常像自动化 Software Engineering。它不是让 Agent 泛泛地问“我怎么才能更好”，而是严格执行：

flowchart LR
    H[Current Harness h_t]
    --> R[Run Tasks]
    R --> T[Collect Traces]
    T --> W[Weakness Mining]
    W --> P[Harness Proposals]
    P --> V[Regression Validation]
    V --> A{Accept?}
    A -- Yes --> H2[New Harness h_t+1]
    A -- No --> L[Log Rejected Edit]
    H2 --> R

Weakness Mining

这是我觉得非常值得记住的一点：Verifier Outcome 不等于 Root Cause。

两个 task 可能都显示：

timeout

但一个可能是 Agent 陷入无限 debug loop；另一个可能是某个 backend job 没有被正确 monitor。

也可能都显示：

missing artifact

但一个是 Agent 忘了 save；另一个是 tool output path 错了。

因此 failure record 必须包含多层信息：

flowchart LR
    E[Verifier Error]
    --> B[Relevant Agent Behavior]
    --> M[Underlying Mechanism]
    --> R[Root Cause]

这跟普通软件 debugging 非常像：exception type 只是 symptom，不是 root cause。

Harness Proposal

Proposer 看到的也不是无限 context，而是一个 bounded proposal context，包括：当前允许修改的 Harness surfaces、已经归纳的 failure patterns、必须保留的 passing behaviors，以及以前尝试过但失败的 edits。

这样可以防止 proposal 变成“大改整个系统”。好的 candidate 应该优先处理：

recurrent + addressable + narrow

的问题，而不是偶发 error 或纯粹因为 task 太难导致的 failure。

Proposal Validation

候选修改必须同时跑两类测试：

Held-in：原来发现的 weakness 是否真的修好了？

Held-out：有没有引入新的 regression？

flowchart TD
    P[Candidate Harness Edit]
    --> IN[Held-in Eval]
    --> OUT[Held-out Eval]
    OUT --> Q{Fixes weakness<br/>AND no regression?}
    Q -- Yes --> M[Merge]
    Q -- No --> R[Reject + Record]

这实际上已经完全变成：

Bug → Root Cause → Patch → Regression Test → Merge

只不过“Bug”来自 Agent trajectory，“Patch”修改的是 Harness。

还有一个非常重要的 safety boundary：作者提醒，允许 Agent 修改自己的 Harness 有点像“程序可以修改 OS”。因此 editable surface 必须严格限制，permission/security layer 不能放在 self-edit loop 里面，否则 Agent 很容易通过关闭 verifier、修改 model、增加 reasoning budget 等方式 reward hack。

Agentic Harness Engineering：真正的瓶颈可能是 Observability

AHE 的观点我觉得是目前这部分最成熟的：Harness evolution 最大的问题也许不是 Agent 不会改 Harness，而是我们不知道应该改哪里。

它把 Observability 拆成三个层级：

graph TD
    O[Harness Observability]
    --> C[Component Observability<br/>哪里出了问题？]
    --> E[Experience Observability<br/>什么 evidence 支持？]
    --> D[Decision Observability<br/>为什么改？预测什么？]

1. Component Observability

AHE 把 Harness 明确拆成 7 个 editable components：

mindmap
  root((Harness))
    System Prompt
    Tool Description
    Tool Implementation
    Middleware
    Skill
    Sub-agent Configuration
    Long-term Memory

每一个 failure pattern 都应该 map 到一个具体 component。这样 edit 才能 targeted，而不是“模型失败了，所以重写整个 system prompt”。

举个简单例子：如果 Agent 总是选择错误工具，问题可能是 Tool Description；如果选择正确工具但调用结果不正确，可能是 Tool Implementation；如果它知道什么时候调用工具但长期任务忘记过去 state，可能是 Long-Term Memory；如果 task decomposition 一直不好，可能是 Sub-agent Configuration 或 System Prompt。

这种 decomposition 的价值就是把一个模糊的：

Agent 不够好

变成：

哪个 runtime component 导致什么 observable failure？

2. Experience Observability

真正的 Agent benchmark 可能产生几百甚至几千条 trajectory，不可能全部塞进 context。因此 AHE 把 evidence 做成 hierarchy：

flowchart TD
    T1[Raw Trace 1]
    T2[Raw Trace 2]
    T3[Raw Trace ...]
    T1 --> D1[Per-task Debug Report]
    T2 --> D2[Per-task Debug Report]
    T3 --> D3[Per-task Debug Report]

    D1 --> B[Benchmark-level Overview]
    D2 --> B
    D3 --> B

    B --> E[Evolve Agent]
    E -. drill down if needed .-> T1

Agent Debugger 先对每个 task trajectory 做 root-cause analysis，产生 per-task report；然后再把所有 report 聚合成 benchmark overview。Evolve Agent 默认只看 overview，需要证据时才 drill down 到 raw trace。

这个结构同时解决两个问题：Observability 和 Token Efficiency。

本质上非常像 production debugging：

logs → traces → incident summaries → aggregate dashboard

而不是让 engineer 直接从几十 GB logs 开始读。

3. Decision Observability

最后一个层次我觉得最好：每次 Harness Edit 必须是一个 falsifiable hypothesis。

每个 edit 都要附带类似 manifesto：

Evidence → Root Cause → Targeted Fix → Predicted Impact → Regression Risk

flowchart LR
    E[Observed Evidence]
    --> R[Root Cause Hypothesis]
    --> F[Targeted Harness Fix]
    --> P[Predicted Impact]
    --> X[Next-round Evaluation]
    --> C{Prediction confirmed?}

这样下一轮 evaluation 的意义就不是单纯看 score 有没有涨，而是在检验：

我们对 failure mechanism 的理解到底对不对？

这使 Harness Engineering 很接近 Scientific Method：

Observation → Hypothesis → Intervention → Experiment → Evidence

而不是：

Try random prompt → score up/down → try another prompt

而且 AHE 把一些关键部分设置成 read-only，例如 verifier、runs directory、tracer、LLM config。这样如果 performance 变好了，我们才能归因于 Harness edit，而不是 Agent 偷偷把 evaluator 关掉、换更强 model 或增加 inference budget。

到目前为止，我对整篇文章的核心理解

真正值得记的其实不是十几个 paper 名字，而是一条连续的 abstraction ladder：

flowchart TD
    A[Prompt Engineering<br/>改 instruction]
    --> B[Context Engineering<br/>改模型看到的信息]
    --> C[Workflow Engineering<br/>改模型工作的流程]
    --> D[Harness Engineering<br/>改完整 runtime]
    --> E[Meta-Harness<br/>搜索 Harness programs]
    --> F[Self-Improving Harness<br/>Harness 改自己]
    --> G[Optimizer Evolution<br/>改“如何改自己”的方法]

这背后的共同趋势是：随着 Base Model 变强，人类手写 heuristic 的比例越来越低，而更多系统结构本身开始成为 optimization target。

所以 Agent Engineering 的重点正在从：

“我要写什么 Prompt 才能让模型聪明一点？”

转向：

“我要构造一个什么 runtime，让模型能够观察、实验、记忆、并行、验证和修改自己？”

再进一步：

“这个 runtime 本身能不能通过 evaluation 自动搜索和进化？”

这也是 Harness 和传统 Prompt Engineering 最大的区别。Prompt Engineering 把模型看成一个 function：

output = LLM(prompt)

Harness Engineering 更像是在设计一个 dynamical system：

flowchart LR
    S[State_t]
    --> C[Construct Context]
    --> M[Model Decision]
    --> A[Action]
    --> ENV[Environment]
    --> O[Observation]
    --> V[Evaluation]
    --> S2[State_t+1]
    --> C

最后真正决定 Agent performance 的，不只是一次 generation 的 intelligence，而是这个长期 closed loop 有没有把模型已有的 intelligence 有效地转化成可靠行为。

我现在最想记住的一句话是：

Harness Engineering 的目标不是让模型“一次想得更聪明”，而是设计一个系统，让模型能够在长期执行中不断获得正确的信息、执行正确的动作、保存有价值的状态、发现错误，并根据反馈改变自己的行为。

而 Self-Improving Harness 又进一步把这个闭环往外套了一层：Agent 不仅优化 task state，还开始优化产生这些行为的 runtime 本身。