Agent Harness Engineering：从"提示词工程"到闭环系统设计
摘要：很多团队还在研究”怎么给 AI 写更好的提示词”，但更值得思考的问题早已变成：如何让 AI Agent 在系统里持续运行、自我验证、记忆上下文、在合适的时机停止或升级给人。本文以 agent-harnass 仓库为线索，梳理这套工程化思路。
一、开环的痛点：人在循环里
传统的 AI 使用模式是这样的：
- 人提出任务
- AI 生成结果
- 人检查结果，发现问题
- 人重新提示，回到第 2 步
这是典型的 开环（Open Loop） 系统。它的瓶颈很明显：人成了循环里不可省略的一环。只要人不在，系统就停转。
OpenAI、Anthropic、Google 近年发布的 Agent 资料都在试图回答同一个问题：能不能把这个闭环交给系统？
二、闭环三要素：Context、Harness、Skill
agent-harnass 仓库把这个问题拆成了三层：
| 层级 | 解决什么问题 | 典型实践 |
|---|---|---|
| Prompt Engineering | 怎么问 AI 一次？ | 写好 prompt，调 temperature |
| Context Engineering | 给 AI 看什么？ | 目标、约束、代码、文档、工具 schema、历史决策 |
| Harness Engineering | 把 AI 嵌入什么系统？ | 执行循环、工具注册、验证、日志、沙箱、停止条件 |
| Skill Engineering | 可重复能力怎么封装？ | SKILL.md、脚本、模板、验收清单 |
这四层的演化方向是明确的：
1 | Prompt Engineering |
Prompt Engineering 解决”怎么问”，而 Harness Engineering 解决的是：“以后这类事怎么不用人反复盯”。
三、最小闭环的六个部件
一个可靠的 agent harness 至少要显式定义这六件事：
- Goal（目标）：要达成什么结果、何时完成、约束是什么、验收标准是什么
- Actor（执行者）：主 Agent、子 Agent、脚本，还是人类 reviewer
- Environment（环境）：代码库、浏览器、API、数据源、凭据、沙箱边界
- Feedback（反馈）：测试、日志、截图、trace、CI、eval、review、人工确认
- Memory（记忆）：持久文档、任务板、progress log、source map、决策记录
- Stop Condition（停止条件）：完成、阻塞、风险、低置信度、预算耗尽、需要交接
💡 开发者提示：少了其中任何一项，系统仍然可能回答问题，但那不是 harness，只是一次性的提示。
四、三大 provider 的工程启示
OpenAI：Agent 是系统，不是 prompt
OpenAI 的 Agents SDK 把 agents、tools、handoffs、guardrails、sessions、tracing 作为一等公民暴露出来。Ryan Lopopolo 在 Harness Engineering 一文中强调：代码仓库本身应该是系统记录，AGENTS.md 是目录，测试、CI、日志、截图、skills 都是 agent 的工作环境。
工程化结论：把 agent 的指令、工具、权限、追踪、升级路径都显式化，不要让它们藏在 prompt 里。
Google/DeepMind：模型 + 工具 + 编排
Google 的 ADK 和 A2A 协议把生产级 agent 需要的 sessions、artifacts、evals、callbacks、multi-agent 通信 都纳入了框架。
工程化结论：模型推理和编排控制要分离；工具和产物要显式；多 Agent 通信要在单 Agent 循环已经可观测、可测试之后再引入。
Anthropic：从简单开始，渐进加自主性
Anthropic 的 Building effective agents 提出了一个重要的区分：workflow 是预定义路径，agent 是动态决策路径。他们的建议是：
- 路径已知 → 用 workflow
- 路径未知 → 用 agent
- 质量敏感 → 加 evaluator-optimizer 循环
- 重复行为 → 封装成 SKILL.md，不要塞进长 prompt
- 上下文是有限资源 → 用 just-in-time retrieval、compaction、subagents
五、值得复用研究模式
| 模式 | 核心思想 | 适用场景 |
|---|---|---|
| ReAct | 推理和行动交替，观察改变下一步 | 工具调用、搜索、导航 |
| Reflexion | 失败后写反思，作为下次重试的反馈 | 多轮重试、调试、优化 |
| Voyager | 成功轨迹升级为 skill library | 长期任务、持续学习 |
| Generative Agents | 记忆 + 反思 + 规划，行为跨时间连贯 | 助手、模拟、长期 workspace |
| SWE-agent | Agent-Computer Interface 决定编码性能 | 代码编辑、测试、shell 交互 |
这些模式共同说明：Agent 成功的关键不仅在于模型能力，更在于模型- harness - 环境的系统设计。
六、工程清单：启动 agent 项目前问自己
启动前：
- 目标是否具体、可验证？
- 验收标准是否写清楚了？
- 当前 workspace 是否已检查？
- 风险权限是否已识别？
执行中：
- 多步任务是否有可见计划？
- 是否优先使用一手资料？
- 重复流程是否已沉淀为 skill？
- 是否尽快运行验证？
交付前：
- 每个产物是否已检查？
- 引用来源是否已标注？
- 文档是否覆盖 context、harness、skills、loop、memory、feedback、stop conditions？
- 未来 agent 能否从 AGENTS.md 开始工作？
七、总结
从 agent-harnass 仓库，我们看到的不只是一些文档，而是一种工程化迁移：
- 从单次 prompt → 到系统设计
- 从人在循环 → 到系统闭环
- 从一次性输出 → 到可复用能力包
如果你正在构建 coding agent、research agent、multi-agent workflow，或者只是想把自己团队的 AI 工作流”系统化”起来，这套框架值得作为起点。
下一步：把仓库内容克隆下来，按仓库结构整理你自己的 harness 文档。不需要全盘照搬，但六个部件（Goal、Actor、Environment、Feedback、Memory、Stop）值得作为你所有 agent 项目的检查清单。
🤔 你怎么看？ 你团队现在是用 “提示词工程” 还是 “Harness Engineering” 的思路在做 AI 项目？欢迎在评论区分享你的经验。
本文基于 ra1nzzz/agent-harnass 仓库内容整理，辅以 OpenAI、Anthropic、Google/DeepMind 官方资料。
