文章目录
-
- [核心概念：Harness 是什么](#核心概念：Harness 是什么)
- [三大支柱：Harness Engineering 关注什么](#三大支柱：Harness Engineering 关注什么)
- 如何落地：一个可执行的实践路径
-
- [第 1 步：先设计环境，再谈 Agent](#第 1 步：先设计环境，再谈 Agent)
- [第 2 步：把"需求"改写成 Agent 可执行计划](#第 2 步：把“需求”改写成 Agent 可执行计划)
- [第 3 步：把规范变成"硬约束"](#第 3 步：把规范变成“硬约束”)
- [第 4 步：构建闭环，而不是"更好的 Prompt"](#第 4 步：构建闭环，而不是“更好的 Prompt”)
- [第 5 步：把每次事故都转化为 Harness 进化](#第 5 步：把每次事故都转化为 Harness 进化)
- 团队层面的角色变化
Harness Engineering（驾驭工程）本质上是：在人类几乎不写代码的前提下，围绕 AI Agent 搭建一整套"环境 + 约束 + 工具 + 反馈闭环"，让 Agent 能长期、可靠地完成软件开发工作。它把工程师的重心从"写代码"转移到"设计和优化 Agent 所处的环境"。 cloud.tencent
核心概念：Harness 是什么
- Harness = 约束 + 工具 + 文档 + 反馈循环，是围绕 AI 编程 Agent 搭建的完整运行环境，而不是某个单一框架或库。 juejin
- 在 OpenAI 的实践中，人类工程师不再直接写代码，而是通过系统设计、仓库结构、CI 规则、文档和工作流设计来"驾驭" Codex 这类 Agent 完成整个项目。 openai
- LangChain 等社区把公式写得很直白：Agent = Model + Harness，模型只是大脑，Harness 提供状态、工具执行、反馈循环和可执行约束，模型才真正变成能干活的 Agent。 developer.aliyun
一个简单类比：在传统工程里你雇的是"程序员"，在 Harness Engineering 里你雇的是"学徒 + 车间"，你主要在设计车间（环境和规章），而不是亲自拧每一颗螺丝。
三大支柱：Harness Engineering 关注什么
主流文章会把 Harness Engineering 拆成几块，但实质上围绕三件事：上下文、约束、反馈。 cnblogs
-
上下文工程（Context Engineering）
- 不再是"给 Agent 一份 1000 页文档"，而是设计持续更新的知识库、动态上下文（代码仓、运行日志、导航状态等），并精细控制能塞进模型的那点上下文预算。 cloud.tencent
- 代码库结构、文档目录、计划/决策日志、技术债清单，都被当作 Agent 的"操作说明书"，并受版本控制，Agent 通过读取这些文件理解当前项目状态。 openai
-
架构约束与"围栏"（Guardrails）
- 把架构/规范写进可执行规则，例如在 Linter、CI 脚本、依赖检查工具里强制"service 不能依赖 controller""禁止直接访问某些模块"。 aicoding.csdn
- 一旦 Agent 提交的代码违规则，CI 会直接失败，错误信息本身又回流给 Agent 作为新上下文，引导其修正代码，形成自我矫正。 aicoding.csdn
-
垃圾回收与反馈回路
- 每当 Agent 犯错，就改进 Harness，让同样错误"以后再也犯不了"，这就是 Hashimoto 对 Harness 的朴素定义：持续把经验固化进环境。 yage
- 通过测试、Linter、本地可观测性（日志/指标查询）、自动回归和 Agent 自己运行代码+看报错+修复，形成"写 → 跑 →看 → 改"的闭环，并尽量不打断到人类。 developer.aliyun
如何落地：一个可执行的实践路径
下面给你一个可以在团队里逐步落地的实践路线，从"有个会写代码的 LLM"走向"有 Harness 的 Agent 团队"。 juejin
第 1 步：先设计环境，再谈 Agent
- 统一代码仓结构：明确模块边界、依赖方向，把架构约束写成 README 和机器可读规则（如 eslint/tslint、import-lint、自定义 check 脚本）。 cnblogs
- 建立基础工具链：
- 必须有：单元/集成测试、Linter、格式化工具、基础 CI 流水线。
- 尽量有：可在本地或 CI 中由 Agent 调用的"运行/测试/打包/部署"命令，既能自动执行，又能产生日志和报错文本。 developer.aliyun
第 2 步：把"需求"改写成 Agent 可执行计划
- 用"深度优先工作法"：把大目标拆成模块，再拆成"设计 → 编码 → 测试 → 评审"等小步骤，每一步都有清晰输入、输出和验收标准。 openai
- 这些计划作为文本文件（例如
plans/feature-x.md）放进仓库并版本化，Agent 通过读取计划文件知道当前任务和上下文，而不是靠零散对话记忆。 cnblogs
第 3 步：把规范变成"硬约束"
- 对所有"口头约定/架构原则"，问一句：能不能变成 Linter 规则、依赖图检查或者 CI 阶段脚本，让违规代码根本合不了并自动给出修复提示？ aicoding.csdn
- 对常见错误模式，给 Agent 提供专门的"纠错工具"：如运行特定测试、调用日志查询、执行静态分析，结果作为新上下文返回，让 Agent 学会"自己查错"。 developer.aliyun
第 4 步：构建闭环，而不是"更好的 Prompt"
- 默认流程应是：Agent 写代码 → 自动跑测试/Linter → 根据报错自己修 → 再次提交；只有它多次失败或涉及业务判断时，才升级到人工兜底。 openai
- 部署可观测性栈（哪怕是简化版）：让 Agent 能调用接口查看服务日志和指标，实现"自己排查问题"，而不是每次出错都问人类。 cnblogs
第 5 步：把每次事故都转化为 Harness 进化
- 每当 Agent 出非预期行为，优先问："这能不能通过补充文档、规则或工具，让它以后再也犯不了？"而不是"让它这次写仔细一点"。 yage
- 具体手段包括：
- 增补架构文档、最佳实践示例，放入仓库固定位置。
- 增加新的 Linter/测试用例，专门卡掉这类错误。
- 为该类问题写专门"调试脚本"供 Agent 调用。 juejin
团队层面的角色变化
- 工程师角色：从写业务代码，转向设计仓库结构、规则体系、计划与工作流、工具和观测能力，是更偏"系统设计 + 工程管理"的角色。 yage
- 人类介入方式：从"审每一行 PR"，变成"只兜底 Agent 搞不定的少数复杂判断"，大部分流水线工作都在 Harness 里自动发生。 openai
- 能力要求：反而更需要深厚的系统直觉，才能知道哪些约束要硬编码进环境，哪些自由度留给 Agent，这也是文章里说的"学徒缺口"问题。 hub.baai.ac