Harness Engineering：从 Prompt/Context 到“可交付 Agent”的四层系统

Harness Engineering：从 Prompt/Context 到"可交付 Agent"的四层系统

受众假设：你已经用过 Prompt、RAG/记忆或 IDE 编程助手，但在长任务里经常遇到"做着做着跑偏""上下文被噪声淹没""会说不会做""做完也不敢信"的问题。

本文聚焦：把 AI 从"只能聊天"装配成"可执行任务"的 Agent 时，工程系统（Harness）到底在补哪几块能力。

摘要（先看结论）

• Harness Engineering 的本质是给大模型加一套工程化外壳：把"文本生成能力"变成"可闭环执行任务的系统"。
• 关系可以理解为包含而非替代：Prompt ⊂ Context ⊂ Harness。
• Harness 的最小可复用结构可以拆成四层：记忆层、执行层、反馈层、编排层。
• 这四层分别对付三类长任务失控：目标偏移、上下文腐化、执行失控。
• 一个典型落地形态是"规则文件 + 按需加载"：核心规则单独存放，其他背景按任务路由加载，减少噪声对关键约束的侵蚀。
• Spec Driven Development (SDD) 的价值在于把"目标/约束/计划/验证"显式化成阶段工件，让 Agent 每一步都能对齐同一套验收标准。

快速导航（按困惑定位）

你可能在困惑什么	看哪节	一句话解释
"Harness Engineering 到底是什么？"	1	它是模型外面的运行系统，不是模型本身。
"Prompt/Context/Harness 怎么区分？"	2	Prompt 管"怎么说"，Context 管"给它看什么"，Harness 管"如何持续做成"。
"四层架构分别解决什么问题？"	3	记忆/执行/反馈/编排分别解决：不忘、能做、做对、推进。
"为什么长任务容易翻车？"	4	目标偏移、上下文腐化、执行失控会被多步链路放大。
"Cloud Code/规则文件在这里扮演什么角色？"	5	它们是记忆层的具体工件：把约束写进可复用的外部制品。
"SDD 是不是新名词？"	6	它更像把 Harness 的约束与验证变成阶段流程。

1. 关键概念：Harness Engineering 是什么

如果只看大模型本身，它擅长的是"在给定上下文里生成文本"。但要让它在真实任务里稳定交付，你还需要一套围绕它的系统：

• 让它在正确的时间看到正确的信息
• 让它能调用外部工具把"建议"变成"动作"
• 让它能被确定性地验收（而不是"自己觉得完成了"）
• 让它能在多步任务中持续对齐目标并推进

这套"模型外部的工程系统"，就是这里说的 Harness。

一个非常实用的最小公式是：

Agent = 大模型 + Harness

意思不是把模型贬低，而是把边界讲清楚：模型提供"能力上限"，Harness 把能力兑现成"交付下限"。

2. 三层演进：Prompt -> Context -> Harness

把三者放在一张表里更直观：

层级	主要解决的问题	典型手段	和其他层级关系
Prompt Engineering	没引导就乱说、格式不稳	角色设定、指令、格式约束	Context 的子集
Context Engineering	有限窗口下的信息管理	召回/记忆、压缩、组装	Harness 的基础组件
Harness Engineering	让系统持续按规范执行任务	记忆+执行+反馈+编排	包含前两者

包含关系可以用一句话记住：

Prompt  ⊂  Context  ⊂  Harness

这里有个对"上下文工程"的细化直觉，常被概括为"三板斧"：

召回（相关性筛选） -> 压缩（信息精简） -> 组装（结构优化）

这三步直接影响"模型看到什么"，而 Harness 进一步要解决"模型如何做、如何验证、如何推进"。

3. 核心机制：Harness 的四层能力

四层结构是理解 Harness 最省心的方式：你不必先理解所有工具/框架名词，只要先把"缺什么能力补什么层"想清楚。

四层结构（从可持续到可交付）

┌──────────────────────────────────────────────┐
│ 4) 编排层：全局任务规划与流程管控              │
├──────────────────────────────────────────────┤
│ 3) 反馈层：自动检测与修复（验证闭环）          │
├──────────────────────────────────────────────┤
│ 2) 执行层：外部工具与环境（把文本变动作）      │
├──────────────────────────────────────────────┤
│ 1) 记忆层：规则/约束的稳定存放（抗上下文腐化） │
└──────────────────────────────────────────────┘

3.1 记忆层：对抗"上下文腐化"

长任务里最常见的失败之一，是关键约束被噪声淹没。记忆层的目标就是"让核心信息稳定存在，并能按需取回"。

一种常见实现是"规则文件 + 动态路由（按需加载）"：

（规则文件 + 拆分文件 + 按需加载）

core-rules.md   <- 核心规则（风格/禁区/验收）
bg.md           <- 背景信息
stack.md        <- 技术栈与约定

任务开始：先加载 core-rules
任务推进：按需要再加载 bg/stack 等

这种设计的关键不是"存更多"，而是"把最不能丢的东西独立出来，降低被噪声冲刷的概率"。

如果把它落到 Trae 的日常使用里，记忆层往往不是一个"数据库"，而是一组明确的外部工件：

• 仓库级规则与边界：AGENTS.md（写作/改码的硬约束、如何验证、哪些操作危险）
• 可复用的工作流：.trae/skills/*/SKILL.md（把"怎么做事"固化成可反复激活的 procedure）
• 可追溯的"阶段结论"：docs/superpowers/specs/（先把设计写清楚）+ docs/superpowers/plans/（再把执行步骤写清楚）

直觉上，这些文件的作用类似 Cloud Code 的 cloud.md：它们不是"背景材料"，而是"任务的操作手册 + 验收口径"，要比聊天记录更稳定、更可复用。

3.2 执行层：把"会说"变成"会做"

执行层提供模型操作外部世界的能力：文件系统、命令、编辑器集成、沙箱等。

很多系统会用类似 ReAct 的循环，把"思考-行动-观察"闭起来：

ReAct 风格闭环（思考-行动）

Prompt/规则 -> 模型推理 -> 调用外部程序/工具 -> 得到结果 -> 回灌上下文 -> 下一轮

这里的重点不是某个具体工具名，而是：没有执行层，模型最多只能"建议"；有了执行层，系统才真正开始"执行"。

3.3 反馈层：把质量判断变得更确定

反馈层的目标是自动检测并修复错误。常见的路径包括：

• Linter 校验
• 单元测试输出
• 报错信息回灌上下文（促使下一轮修复）

你可以把它理解为：让 Agent 的每一次动作都有"可验证的回声"，而不是停在"我觉得我做完了"。

Trae 的反馈层可以非常朴素，但必须"可执行"：

• 写作类：跑 python3 scripts/validate_repo.py，强制索引/链接/结构一致
• 代码类：跑测试、构建，或至少看 IDE 的诊断（例如 GetDiagnostics）
• 流程类：在准备结束时用 verification-before-completion 这类门禁，把"证据"作为完成条件

3.4 编排层：防止无效循环，确保目标一致

编排层处理的是"任务怎么推进"：

• 大任务拆成子任务
• 每一步明确执行标准（验收口径）
• 分步执行与管控，避免陷入无效死循环

当任务本身需要很多步骤时，编排层实际上在帮系统持续对齐目标，而不是让模型在局部细节里越走越远。

如果结合 superpowers 的工作方式来看，编排层最生动的体现是：把"长任务"强制拆成三个阶段工件，避免凭感觉推进：

（superpowers 的最小编排链路）

brainstorming  -> 先把目标/边界/验收讲清楚（不急着写）
writing-plans  -> 把执行拆成可验证的小步骤（每步有产物/命令/预期）
executing-plans / subagent-driven-development
              -> 按步骤执行，出错就回到反馈层

这条链路的核心价值是"可恢复"：你随时能从 plan/spec 继续，而不是依赖某一次对话里模型是否记得你们说过什么。

4. 为什么会这样：长任务的三类失控

把上面的结构和真实失败对齐，你会发现四层并不是"架构洁癖"，而是针对性地补洞：

• 目标偏移：做到一半开始围绕局部问题打转
• 上下文腐化：关键约束/进度逐步被噪声覆盖
• 执行失控：能给方案，但缺少稳定工具链、验证链与回退机制

简化成一句话就是：

长任务里，问题往往不是"想不出来"，而是"无法持续对齐 + 无法可靠验证 + 无法稳定推进"。

5. 一个具体落地点：Cloud Code 与"规则文件"长什么样

把 Harness 从概念落到手上，最常见的第一步是"规则文件"（记忆层工件）。Cloud Code 这类工作流的代表性做法，是用一个中心规则文件把"项目怎么做才算做对"说清楚，例如：

• 项目背景与目标
• 技术栈需求
• 代码风格规范
• 禁止事项
• 测试与 CI 执行标准

你可以把它理解成给 Agent 的"项目说明书 + 质量门禁说明"，重点在于：它是外部化、可复用、可更新的，不依赖某次对话是否还记得。

为了避免和上面"记忆层"概念重复，这里用 Trae 做一个更贴地的对照：Cloud Code 的"中心规则文件"，在 Trae 里通常会拆成多份更工程化的工件，各司其职。

在 Cloud Code 里	在 Trae 里更常见的形态	它解决的事情
"项目说明书/规则文件"	AGENTS.md	仓库级边界：目录约定、写作/改码流程、验证门禁、危险操作禁区
"规则 + workflow"	.trae/skills/*/SKILL.md	把高频任务做成可重复激活的流程（procedure），减少每次从头组织上下文
"验收标准"	scripts/validate_repo.py（或测试/构建命令）	让"对不对"变成可运行的检查，而不是主观判断
"阶段化约束更新"	docs/superpowers/specs/ + docs/superpowers/plans/	把长任务拆成可恢复的阶段工件：先定目标与边界，再定步骤与预期

6. SDD：把 Harness 的约束与验证变成阶段流程

Spec Driven Development (SDD) 可以理解为：把 Harness 里的"记忆层 + 编排层"进一步显式化。它不让 Agent 一上来就直接干活，而是先把目标、边界、步骤和验收标准写成阶段工件，再进入执行。

如果用 Trae / superpowers 的工作方式来理解，它更像这样：

brainstorming
  -> 先澄清目标、边界、成功标准
writing-plans
  -> 把执行拆成可验证的小步骤
executing-plans / subagent-driven-development
  -> 按计划执行，遇到失败再回到反馈层修正

如果不想用 skill 名称，也可以把它抽象成更通用的工程链路：

需求拆解 -> 固化约束 -> 制定计划 -> 分步执行 -> 验证与修正

它的直觉收益不是"流程更完整"这么简单，而是三件更具体的事：

• 每一阶段注入上下文的都是核心信息，而不是让聊天记录无限堆长
• 任务随时可以从 spec/plan 继续，降低对单次会话记忆的依赖
• 失败会落回某个明确阶段去修，而不是在长对话里边做边漂移

7. 常见误区

• 误区 1：Harness 只是"多接几个工具"
  • 工具主要属于执行层；如果没有记忆/反馈/编排，工具只会把失控放大得更快。
• 误区 2：只要上下文塞得足够多就行
  • 信息管理本身也需要工程化：召回、压缩、组装的质量会直接影响输出。
• 误区 3：Agent 的问题都能靠更强模型解决
  • 模型负责能力上限，但"持续按规范执行任务"的下限，很大一部分来自 Harness 的机制。

8. 总结：程序员在干什么，会越来越像"写规则/写技能"

当系统从"单轮回答"走向"多步交付"，工程重心会自然变化：

• 工作内容从"直接写代码/写内容"，更多转向"设计规则文件（Rules）与技能定义（Skill）"
• 核心竞争力也更像是在构建一套能让 Agent 稳定交付的框架：记忆、执行、反馈、编排

最终你会发现，Harness Engineering 并不是一个玄学名词，它更像是在回答一个朴素问题：

如何把"能说"的模型，装配成"能交付"的系统？