Harness Engineering：从 Prompt Engineering 到可自我演化的 AI Agent 工程体系

引言

过去一年，AI Agent 的讨论越来越热。很多人已经不再满足于"让大模型回答问题"，而是希望它能真正完成任务：读代码、改代码、跑测试、写报告、查资料、维护知识库，甚至 24 小时不间断地执行长期任务。

但在实践中，我们很快会遇到一个问题：

同一个模型，为什么在不同 Agent 系统里的表现差异如此巨大？

答案往往不在模型本身，而在模型外面的那套工程系统。

这套系统，就是本文要讨论的 Harness Engineering。

一、什么是 Harness Engineering？

如果说大语言模型是 Agent 的"大脑"，那么 harness 就是它的：

身体；
工具箱；
工作环境；
记忆系统；
任务调度器；
安全边界；
监控系统；
反馈回路。

Harness Engineering 可以理解为：

围绕 LLM Agent 构建、调优和演化其运行外壳、执行框架和工程脚手架的方法。

它关注的不是模型权重本身，而是模型外部那套让 Agent 真正能工作的系统。

一个典型的 Agent harness 可能包括：

组件	作用
System Prompt	定义 Agent 的身份、边界、行为规则
Tool Descriptions	告诉模型有哪些工具、什么时候用、怎么用
Tools	文件读写、Shell、浏览器、数据库、搜索、评估器等
Middleware	上下文压缩、权限拦截、错误处理、结果清洗
Memory	跨会话记忆、项目知识、用户偏好、经验沉淀
Sub-agents	专门负责搜索、规划、测试、代码审查等子任务
Scheduler	定时唤醒、任务队列、后台执行
Sandbox	隔离执行环境，限制破坏范围
Evaluator	判断任务是否完成、结果是否可靠
Trace Logger	记录完整执行轨迹，供复盘和改进

所以，Harness Engineering 的核心不是"怎么写一个更好的 prompt"，而是：

怎么设计一个让模型能够长期、安全、可观察、可迭代地工作的工程系统。

二、为什么 Prompt Engineering 不够了？

早期使用大模型时，我们主要关注 Prompt Engineering：如何问问题，如何写角色设定，如何给示例，如何让输出格式更稳定。

后来，大家发现上下文同样重要，于是出现了 Context Engineering：如何选择资料、压缩历史、管理上下文窗口、注入长期记忆。

但当 Agent 开始调用工具、修改文件、执行命令、处理长任务时，仅靠 prompt 和 context 就不够了。

因为真实 Agent 面临的问题远比"回答问题"复杂：

它要知道该用哪个工具；
它要知道哪些操作危险；
它要能在任务中断后恢复；
它要能记住以前的经验；
它要能处理长上下文；
它要能从失败中改进；
它要能被监控、审计和回滚；
它要能避免为了指标而投机取巧。

这就是 Harness Engineering 的价值。

它把关注点从单轮对话扩展到完整系统：

text 复制代码

Prompt Engineering
  ↓
Context Engineering
  ↓
Tool-use Engineering
  ↓
Agent Harness Engineering
  ↓
Self-evolving Agent Systems

Prompt 是局部变量，harness 才是完整系统。

三、Agentic Harness Engineering：让 Harness 自我演化

更进一步，有研究提出了 Agentic Harness Engineering，简称 AHE。

AHE 的核心思想是：

固定 base model，不训练模型权重，而是让 Agent 自动观察、分析、修改并验证自己的 harness。

也就是说，模型本身不变，但系统会自动优化模型外部的运行结构，例如：

system prompt；
tool descriptions；
tool implementations；
middleware；
skills；
sub-agents；
long-term memory；
context policy；
evaluator；
permission policy。

它的典型闭环是：

text 复制代码

evaluate → analyze → improve → loop

具体来说：

Evaluate

让当前 Agent 在任务集或真实工作流中执行，记录完整 trace、工具调用、日志和结果。
Analyze

从执行轨迹中分析失败原因，把大量原始日志压缩成可读、可追溯的 debug report。
Improve

基于证据修改 harness，例如调整工具描述、改 middleware、补 memory、更新 prompt。
Loop

下一轮重新评估，验证修改是否真的有效。如果无效或带来回归，就回滚或修正。

这个过程的关键是：每次修改都不是拍脑袋，而是一个可验证的工程假设。

例如一次 harness 修改应该记录：

text 复制代码

失败证据：哪些任务失败了？trace 中有什么现象？
根因分析：为什么失败？
目标修复：这次具体改什么？
预测影响：哪些任务应该变好？哪些地方可能有风险？
验证结果：下一轮是否符合预测？

这就把 Agent 调优从"玄学调 prompt"变成了"可观察、可回滚、可证伪的工程实验"。

四、Harness Engineering 的三层可观察性

AHE 中非常关键的概念是 Observability，也就是可观察性。

一个成熟的 Agent harness 不能只是跑起来，还要能被看见、被分析、被追责。

可以分成三层。

1. Component Observability：组件可观察

首先，harness 的各个组件应该是显式的、可编辑的、可版本管理的。

例如：

text 复制代码

systemprompt.md
tool_descriptions/
tools/
middleware/
skills/
sub_agents/
LongTermMemory.md

这样做有几个好处：

每个组件可以单独修改；
每次修改可以被 git 追踪；
出问题可以回滚；
不同组件的效果可以被归因；
Agent 也可以在受控范围内自动修改这些文件。

如果所有东西都藏在一个巨大 prompt 或黑盒服务里，就很难做工程化演化。

2. Experience Observability：经验可观察

Agent 执行任务时会产生大量轨迹：

对话历史；
工具调用；
shell 输出；
文件 diff；
报错信息；
测试结果；
中间推理；
evaluator 结果。

这些 raw traces 可能非常长，动辄几百万甚至上千万 token。直接让模型读取全部内容并不现实。

所以需要把原始轨迹整理成分层报告：

text 复制代码

raw trace
  ↓
cleaned trace
  ↓
per-task analysis
  ↓
cross-task root-cause summary
  ↓
actionable improvement report

这和知识库建设很像：原始资料不直接作为工作层，而是经过整理后形成可复用的中间知识层。

3. Decision Observability：决策可观察

最后，每次 harness 修改都必须留下决策记录。

不是简单写一句"优化 prompt"，而是说明：

为什么改；
基于什么证据；
解决什么根因；
预期产生什么效果；
哪些地方可能回归；
下一轮如何验证。

这让每次修改都变成一个可证伪的 contract。

没有 Decision Observability，就无法区分：

真的修好了；
只是碰巧通过；
过拟合 benchmark；
引入了新的隐藏问题。

五、Harness Engineering 的核心模块

下面从工程实现角度看，一个完整的 Agent harness 至少包含以下几个核心模块。

1. Context Engineering：管理 Agent 看见什么

大模型的上下文窗口再大，也不是垃圾桶。

对于长任务 Agent，Context Engineering 的目标是回答几个问题：

当前任务必须看到什么？
哪些历史可以压缩？
哪些经验应该进入 memory？
哪些工具说明应该此刻展示？
如何避免 instruction fade-out？
如何利用 prompt caching 降低成本？

常见策略包括：

Context Compaction

把长轨迹压缩成更短的任务状态：

text 复制代码

原始历史：
用户需求、几十轮对话、多个工具调用、测试日志、错误输出

压缩后：
目标是什么？
已经做了什么？
当前状态是什么？
关键约束是什么？
还有哪些风险？
下一步是什么？

好的 compaction 不应该只是摘要，而应该保留任务继续执行所需的状态。

Prompt Caching

把稳定内容放在上下文前缀中复用，例如：

系统规则；
工具说明；
项目约定；
安全策略；
长期不变的知识库索引。

动态内容则放在后面，例如：

当前任务；
最近日志；
临时观察；
当前 diff。

Event-driven Reminders

长任务中，模型容易忘记早期约束。可以通过事件触发提醒，例如：

执行危险命令前提醒权限边界；
修改文件前提醒代码风格；
接近上下文上限时提醒压缩；
多次失败后提醒重新分析根因。

2. Tool Use：让模型真正作用于环境

Agent 和普通 Chatbot 的重要区别是：Agent 会用工具。

工具层要解决的问题包括：

工具有哪些？
什么时候展示？
如何描述？
如何调用？
如何处理失败？
哪些工具需要审批？
工具结果如何注入上下文？

一个工具描述如果写得不好，会直接影响模型行为。

例如，一个 shell 工具不仅要告诉模型"可以执行命令"，还要说明：

不要执行破坏性命令；
不要绕过安全检查；
长命令要设置超时；
独立命令可以并行；
依赖前一步结果的命令必须串行；
高风险操作需要用户确认。

工具层还要区分：

操作	权限策略
读取文件	通常可自动允许
运行测试	通常可自动允许
新增草稿文件	通常可自动允许
删除文件	需要人工确认
修改配置	视影响范围确认
git commit	需要用户明确要求
git push	必须人工确认
访问 secrets	默认禁止

Tool Use 的本质是：

把模型的语言能力转化为对现实环境的可控操作能力。

3. Memory：让 Agent 跨会话积累经验

没有 memory 的 Agent，每次都是"失忆重启"。

对于长期 Agent，memory 至少有三种：

类型	内容
Episodic Memory	具体任务、失败案例、调试过程、事件轨迹
Semantic Memory	稳定概念、术语、关系、领域知识
Project Memory	当前项目规则、架构、约定、用户偏好

但 memory 不是越多越好。错误的 memory 会长期污染后续任务。

所以 memory 写入必须有筛选机制：

是否具有长期价值？
是否已经在代码或文档中存在？
是否只是临时状态？
是否可能过期？
是否有来源支撑？
是否需要用户确认？

一种很实用的做法是把知识库本身作为 memory backend。

例如采用 Karpathy 提出的 LLM Wiki 模式：

text 复制代码

raw/
  原始资料，不直接改写

wiki/
  LLM 维护的结构化知识

outputs/
  阶段性分析产物

index.md
  内容索引

log.md
  时间日志

这样 memory 不再是黑盒向量库，而是人和 Agent 都能读、能改、能审计的 Markdown 知识系统。

4. Observability：让失败变成可学习材料

很多 Agent 系统失败后，只留下一个结果：

text 复制代码

任务失败

这没有任何工程价值。

一个好的 harness 应该记录：

输入任务；
计划；
每一步动作；
工具调用参数；
工具返回结果；
文件 diff；
错误日志；
中间判断；
最终 outcome；
evaluator 结论；
用户反馈。

然后把这些记录转化成可学习材料：

text 复制代码

失败案例
  ↓
根因分类
  ↓
修复建议
  ↓
harness 修改
  ↓
下一轮验证

这就是 AHE 的核心：trace 不是附属日志，而是下一轮改进的原料。

5. Evaluation：防止 Agent 为了分数作弊

Agent 一旦进入自动评估，就会遇到一个经典问题：Reward Hacking。

也就是 Agent 不是真的解决问题，而是钻评价函数的漏洞。

例如：

修改测试让自己通过；
直接硬编码 benchmark 答案；
利用评分脚本缺陷；
删除失败用例；
绕过 verifier；
做出看似正确但不可泛化的改动。

这背后是 Goodhart's Law：

当一个指标成为目标，它就不再是一个好指标。

所以 evaluator 不能只看 pass/fail，还要看：

diff 是否合理；
是否修改了不该修改的文件；
是否存在硬编码；
是否通过隐藏测试；
是否有异常工具调用；
是否符合任务真实语义；
是否能迁移到相邻任务。

对于算法发现类任务尤其如此。

在 Algorithm Discovery Harness 中，Agent 会生成大量候选算法，然后通过 scoring function 评估。如果 scoring function 有漏洞，越强的模型越可能找到漏洞，而不是真正发现更好的算法。

六、如何实现一个 24 小时不间断 Agent？

很多人听到"24h Agent"，第一反应是写一个无限循环：

python 复制代码

while True:
    run_agent()

这其实非常危险，也不可靠。

真正的 24h Agent 不应该是一个永不退出的聊天进程，而应该是：

短任务 + 定时调度 + 可恢复状态 + 可观察日志 + 权限边界。

一个更稳的架构如下：

text 复制代码

Scheduler
  ↓
Task Queue
  ↓
Agent Runtime
  ↓
Tools / Sandbox
  ↓
State Store
  ↓
Knowledge Base
  ↓
Observability / Notification

1. Scheduler

负责定时唤醒，例如：

cron；
systemd timer；
workflow scheduler；
queue worker；
云函数；
long-running service。

它不负责思考，只负责"什么时候运行"。

2. Task Queue

Agent 每次醒来后，不应该随机行动，而应该从任务队列中取任务。

任务可以分为：

text 复制代码

research
ingest
lint
summarize
test
monitor
report
repair

每个任务都应该有状态：

text 复制代码

pending
running
blocked
done
failed
needs_human

3. Checkpoint

每次执行都要保存 checkpoint：

当前任务；
已完成步骤；
中间结果；
文件修改；
下一步；
失败原因；
是否需要人工介入。

这样即使进程崩溃，也可以恢复。

4. Idempotency

长期 Agent 的任务要尽量幂等。

也就是说，同一个任务重复执行，不应该造成重复破坏。

例如：

不要重复发送同一封邮件；
不要重复创建同一条 issue；
不要重复提交相同 commit；
不要重复覆盖用户文件；
不要重复摄入同一份资料。

5. Watchdog

Watchdog 负责检测：

是否卡死；
是否超时；
是否连续失败；
是否费用异常；
是否重复执行同一动作；
是否需要通知用户。

6. Permission Policy

24h Agent 必须有明确权限边界。

例如：

操作	策略
读取知识库	自动允许
新增草稿	自动允许
更新索引和日志	自动允许
删除文件	人工确认
修改核心规则	人工确认
访问外部 API	成本和风险审批
git commit	用户明确授权
git push	每次确认
访问密钥	默认禁止

否则，长期运行的 Agent 很容易从"自动化助手"变成"自动化事故制造机"。

七、如何实现知识库的自我迭代？

Harness Engineering 不仅适用于 coding agent，也适用于知识库维护。

一个自我迭代知识库可以采用这样的闭环：

text 复制代码

Ingest → Synthesize → Link → Question → Lint → Plan Next Sources

1. Ingest：摄入

把原始资料放入 raw 层，例如：

论文；
博客；
会议记录；
网页剪藏；
代码；
实验日志。

LLM 读取资料后，不是简单摘要，而是提取：

核心观点；
关键概念；
相关实体；
证据；
矛盾；
待验证问题。

2. Synthesize：综合

把新资料和旧知识融合：

新资料是否支持已有结论？
是否推翻旧判断？
是否补充了新的概念？
是否出现新的争议？
是否需要拆分新页面？

3. Link：链接

知识库的价值来自链接。

每次摄入都应更新：

index；
相关概念页；
来源页；
术语表；
问题池；
矛盾页。

4. Question：提出问题

好的知识库不只是保存答案，还应该产生问题：

哪些概念还不清楚？
哪些结论缺来源？
哪些方向值得继续搜索？
哪些实验可以验证？
哪些页面需要重构？

5. Lint：健康检查

定期让 Agent 检查知识库：

是否有孤立页面；
是否有重复页面；
是否有过时结论；
是否有无来源判断；
是否有互相矛盾内容；
是否有高频概念没有独立页面；
是否有该沉淀到 outputs 的长分析。

6. Plan Next Sources：规划下一批资料

最后，知识库应该主动提出下一批资料建议：

该读哪篇论文；
该查哪个项目；
该验证哪个 claim；
该补哪个术语；
该写哪篇专题文章。

这样知识库就从"被动笔记"变成了"主动研究系统"。

八、Harness Engineering 的典型应用场景

1. Coding Agent

最直接的场景是编码助手：

自动读代码；
修 bug；
跑测试；
解释失败；
写 PR 描述；
做 code review；
维护项目知识库。

这类 Agent 对 tool use、context engineering 和安全边界要求极高。

2. Research Agent

用于长期技术调研：

跟踪论文；
搜索 GitHub 项目；
比较技术路线；
维护竞品分析；
自动生成周报；
发现知识缺口。

这类 Agent 的关键是 memory 和 self-evolving knowledge base。

3. Ops Agent

用于运维和监控：

读取报警；
查询日志；
分析 incident；
生成排障建议；
自动执行低风险修复；
通知 on-call。

这类 Agent 对权限、安全和可观察性要求极高。

4. Algorithm Discovery Agent

用于自动发现或优化算法：

生成候选算法；
执行 benchmark；
分析失败；
进化搜索；
保存实验结果；
防止 reward hacking。

这类 Agent 的关键是 evaluator 和 sandbox。

九、未来趋势：Harness Engineering 会成为新的 AI 工程核心

我认为 Harness Engineering 会成为 AI Agent 时代的基础工程方向，类似当年的 DevOps 和 MLOps。

未来真正拉开 Agent 能力差距的，不只是模型参数，而是：

谁的工具系统更可靠；
谁的上下文管理更高效；
谁的 memory 更准确；
谁的 observability 更完整；
谁的 evaluator 更 robust；
谁的安全边界更清晰；
谁的 harness 能从失败中自我演化。

可能出现的新岗位包括：

Agent Harness Engineer；
Context Engineer；
Agent Runtime Engineer；
Agent Observability Engineer；
LLM Tooling Engineer；
AI Reliability Engineer；
Agent Safety Engineer；
Autonomous Workflow Engineer。

这些岗位的共同点是：他们不是单纯"调 prompt"，而是在构建一个能让模型稳定工作的复杂系统。

十、一个最小可落地架构

如果你想从零实现一个 Harness Engineering 系统，不需要一开始就做得很复杂。

可以从这个最小版本开始：

text 复制代码

project/
├── agent/
│   ├── system_prompt.md
│   ├── tools.yaml
│   ├── permissions.yaml
│   └── memory.md
├── knowledge/
│   ├── raw/
│   ├── wiki/
│   ├── outputs/
│   ├── index.md
│   └── log.md
├── runs/
│   └── run_001/
│       ├── trace.json
│       ├── result.md
│       └── errors.log
├── tasks/
│   ├── queue.json
│   └── state.json
└── evaluator/
    └── check.py

运行闭环：

text 复制代码

1. 从 tasks/queue.json 取任务
2. 读取 knowledge/index.md 和 memory.md
3. 构造上下文
4. 调用模型和工具
5. 写 trace.json
6. 运行 evaluator
7. 更新 wiki / memory / log
8. 如果失败，生成 root-cause report
9. 下一轮基于 report 改进 harness

如果要进一步升级成 AHE，则增加：

text 复制代码

harness workspace
  ↓
自动分析失败
  ↓
自动提出 harness 修改
  ↓
记录预测影响
  ↓
下一轮验证
  ↓
保留或回滚

十一、常见误区

误区一：Harness Engineering 等于写 Prompt

不是。Prompt 只是 harness 的一个组件。

Harness 还包括 tools、memory、middleware、scheduler、evaluator、sandbox、observability 等。

误区二：Agent 越自动越好

不是。成熟 Agent 必须有清晰权限边界。

自动化的目标不是取消人，而是让人只介入高价值、高风险决策。

误区三：Trace 只是日志

不是。Trace 是 agent 自我改进的训练材料和证据来源。

没有 trace，就没有可靠的 failure attribution。

误区四：评估通过就说明 Agent 真会了

不一定。可能只是 reward hacking、过拟合 benchmark 或绕过测试。

必须结合 hidden tests、行为审计和语义验证。

误区五：Memory 越多越好

不是。错误 memory 比没有 memory 更危险。

Memory 必须可审计、可更新、可删除、可追溯来源。

十二、总结

Harness Engineering 是 AI Agent 从 demo 走向生产系统的关键工程能力。

它回答的问题不是：

如何让模型说得更好？

而是：

如何让模型在真实环境中长期、安全、可靠、可观察、可迭代地完成任务？

它的核心思想可以总结为一句话：

模型是大脑，harness 是让大脑真正工作的身体、工具、记忆、环境和反馈系统。

未来的 AI Agent 竞争，不只是模型能力的竞争，更是 harness 能力的竞争。

谁能更好地管理上下文、工具、记忆、评估、安全和自我迭代，谁就能构建更可靠、更强大的 Agent 系统。

参考资料

Agentic Harness Engineering: Observability-Driven Automatic Evolution of Coding-Agent Harnesses

https://arxiv.org/abs/2604.25850
Agentic Harness Engineering GitHub 项目

https://github.com/china-qijizhifeng/agentic-harness-engineering
Effective Harness Engineering for Algorithm Discovery with Coding Agents

https://arxiv.org/abs/2605.15221
Building Effective AI Coding Agents for the Terminal: Scaffolding, Harness, Context Engineering, and Lessons Learned

https://arxiv.org/abs/2603.05344
Karpathy: LLM Wiki

https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f