Agent

Agent_Harness工程

什么是 Harness Engineering，以及普通用户在 webcoding 中的可执行流程

English

Harness Engineering 到底是什么

我对这几篇文章交叉看完后的结论是：

Harness Engineering 不是“写更好的 prompt”这么简单，而是把 模型之外的所有工程化能力 设计成一个可迭代系统，让 Agent 在长任务里稳定地产生可验证结果。

一句话总结：

Agent = Model + Harness
Harness = 状态管理 + 工具系统 + 约束规则 + 反馈回路 + 执行编排

也就是说，模型负责“智能”，Harness 负责“让智能可用、可控、可复用”。

共同观点（跨文章对齐）

主题共识
Harness 定义不是模型本身，而是围绕模型的代码、配置、流程、工具和验证机制
目标降低监督成本，提高首轮正确率，支持长时间连续执行
关键方法把失败模式工程化沉淀：规则、工具、测试、回路
长任务核心矛盾上下文有限、会话中断、状态漂移、过早“宣告完成”
解决方向增量任务拆分、状态交接、自动验证、可观测反馈、持续纠偏

我理解的 5 个核心组成

  1. 任务脚手架
  • 明确任务拆分策略（一次只做一个 feature）
  • 明确完成定义（DoD），避免“看起来做完了”
  1. 状态与记忆
  • 可恢复状态：进度文件、提交记录、变更说明
  • 会话切换时有 handoff，不靠模型“猜”历史
  1. 工具与环境
  • 给 Agent 快速、确定性的工具（测试、lint、截图、日志查询）
  • 让 Agent 能自助获取上下文，而不是人工复制粘贴
  1. 反馈与传感器
  • 计算型传感器：lint/typecheck/unit/e2e（快、确定）
  • 推理型传感器：LLM review/语义 QA（慢、贵、但能看语义质量）
  1. 调度与治理
  • 失败后不是“再试一次”，而是补能力
  • 沉淀规则模板（AGENTS.md/docs/checklist），把经验组织化

普通用户做 WebCoding 的 Harness 流程

对于普通用户的学习，尤其是在找工作和刚刚进入职场的朋友一上来就用最规范的框架肯定是无法适应的。开发者也需要一个逐渐熟练使用harness的阶段。

第 0 步：先定义“完成”

先写一页 SPEC.md（需求规格说明文档，Specification），每个功能包含：

  • 用户场景
  • 输入输出
  • 验收标准
  • 失败场景

没有这一步，后面 Agent 很容易“自我感觉良好”。

第 1 步：建立最小 Harness 文件

建议至少有这 4 个文件：

  • AGENTS.md：仓库工作规则（命令、目录约定、禁改区域、提交规范）
  • TASKS.md：功能清单，状态用 todo/doing/done
  • PROGRESS.md：每轮 Agent 执行后写入“做了什么/没做完什么/下一步”
  • CHECKLIST.md：统一验收项（构建、测试、UI、性能、安全）

第 2 步：一轮只做一个 Feature

执行策略：

  • 从 TASKS.md 取一项
  • 给 Agent 一个明确边界任务
  • 禁止“一次性做完整站点”

这样能显著降低上下文混乱和回归风险。

第 3 步：让 Agent 先改，再自证

每轮要求 Agent 固定输出：

  • 改了哪些文件
  • 为什么这样改
  • 跑了哪些命令
  • 哪些检查通过/失败
  • 风险点和回滚点

这一步等价于把“隐性思考”转成“显性审计线索”。

第 4 步：双层验证（计算型优先）

每轮至少跑：

npm run lint
npm run test
npm run build

如果是前端页面改动，再加：

  • 关键路径截图对比
  • 关键交互手测清单
  • 主要断点的响应式检查

规则是：先过计算型传感器，再上推理型审查。

第 5 步：失败即沉淀为 Harness 资产

当 Agent 出错，不要只修当前 bug，要顺手做一件事：

  • 能写规则就写进 AGENTS.md
  • 能写脚本就加工具脚本
  • 能写检查就加到 CHECKLIST.md

目标是“同类错误不再发生”，这一步尤其重要是逐渐优化项目匹配harness的过程。

第 6 步：长任务做会话交接

当任务超过 1 个上下文窗口时，强制生成 handoff：

  • 当前目标
  • 已完成
  • 未完成
  • 阻塞点
  • 下轮第一步

并且落到 PROGRESS.md 或执行计划文件，而不是只留在对话里。

第 7 步：合并前做一次“发布级回路”

合并前统一跑一轮：

  • 回归测试
  • 页面主路径冒烟
  • 性能与错误日志快速巡检
  • Agent 自评 + 人工抽查

这一步是防止“单点通过，整体失稳”。

第 8 步：周维度做 Harness 垃圾回收

每周处理：

  • 删除过期规则
  • 修复失效脚本
  • 合并重复约束
  • 更新 docs 索引

Harness 也是代码，不维护会腐化。

从零开始尝试

可以现在就在你的项目中，用ai工具协助你创建以下文件：

  1. AGENTS.md 写 20-50 行硬规则，不要过于冗杂
  2. 每次只让 Agent 做 1 个功能点
  3. 每轮固定跑 lint/test/build
  4. 每轮写 PROGRESS.md
  5. 发现重复错误就补规则或脚本

仅这 5 条，通常就能把“靠感觉用 Agent”升级为“可持续提效的工程流”。

实践理解

Harness Engineering 本质上是在回答一个问题：

当 Agent 出错时，你是重复监督它，还是把错误转化成系统能力？

前者只会消耗人；后者会复利。

所以对普通 webcoding 用户来说，最重要的不是多高级的模型，而是：

  • 你有没有可执行规则
  • 你有没有自动化反馈
  • 你有没有把失败沉淀成下一次的确定性优势

我认为，当前AI模型的结果输出说到底还是概率模型，而当前市面上的大部分模型已经具备了不俗的能力足以解决我们的开发问题，而怎样让不够好的概率模型也能生成比肩行业顶尖的模型结果就是Harness工程的实际作用。

参考文章