跳转至

四十九：Harness Engineering

来源:http://mp.weixin.qq.com/s?__biz=MzYyNTk3Njg1NA==&mid=2247484651&idx=1&sn=8d824d3e3db1e2ed664e22ed34d6ad22&chksm=f01eb792c7693e847623c81d0296dafe474ed16e5835e46ffb36b4e425d49aa7b591abb9f5e3#rd

1. 学习范围

本日主题是 Harness Engineering，重点是理解 Agent Harness 的定义、组成、设计原则和工程实验方法。 img

本日覆盖： - Harness Engineering 的背景和定义。

  • Agent Harness 与 prompt、tool、workflow、framework 的区别。

  • Harness 的核心组成：上下文、状态、工具、权限、人审、评估、记忆、执行环境和可观测性。

  • 深度 Agent 中 Harness 如何提升任务成功率。

  • 编码 Agent 的 harness 设计。

  • 企业落地中的安全、评估和迭代。

2. Harness 的基本定义

img

Harness 原意是“承载和约束系统运行的外部装置”。在 Agent 工程中，Harness 指围绕模型构建的一整套执行环境和控制系统，让模型能够可靠地感知任务、调用工具、管理状态、接受反馈、完成验证并安全地产生外部影响。 可以抽象为：

Model
  + prompts
  + tools
  + state
  + memory
  + permissions
  + runtime
  + evals
  + observability
  = Agent Harness
Harness Engineering 的核心观点是：Agent 能力不只来自模型本身，也来自模型周围的工程脚手架。

3. Harness 与 Prompt Engineering

Prompt Engineering 主要优化模型输入文本。Harness Engineering 优化模型所处的任务环境。 对比：

Prompt Engineering: 如何说清楚任务。
Harness Engineering: 如何让模型在正确环境中行动、验证和恢复。
复杂 Agent 失败时，继续改 prompt 往往不足够。还需要改工具接口、状态表示、上下文注入、权限边界、测试环境、回滚机制和人审流程。

4. Harness 与 Agent Framework

Agent Framework 提供构建 Agent 的库或框架，例如图执行、工具调用、状态机和 checkpoint。Harness 更偏具体应用的运行环境和产品化约束。 Framework 是可复用技术底座，Harness 是某个任务域的完整工作台。 例如编码 Agent 的 Harness 可能包括： - 仓库 checkout。

  • 文件编辑工具。

  • 测试运行器。

  • Linter。

  • Git diff。

  • PR 评论读取。

  • 人工审批。

  • 回滚机制。

5. Harness 的核心目标

Harness 的目标不是让模型“更聪明”，而是让模型更可靠地完成任务。 核心目标： - 给模型正确上下文。

  • 给模型可控工具。

  • 保存任务状态。

  • 限制危险动作。

  • 让错误可观测。

  • 让结果可验证。

  • 让人类能在关键点介入。

  • 让系统可以迭代改进。

6. Context Harness

Context Harness 负责把任务相关信息组织给模型。它不是简单地把所有历史塞进上下文，而是选择、压缩、排序和标注信息。 上下文来源包括： - 用户请求。

  • 系统规则。

  • 文件和代码。

  • 工具结果。

  • 记忆。

  • 任务计划。

  • 失败反馈。

  • 环境状态。

Context Harness 的难点是信息过多、来源可信度不一、上下文窗口有限以及 prompt injection 风险。

7. State Harness

State Harness 管理任务执行状态。复杂任务不能只依赖模型在对话中“记得”当前进度。 状态应包括： - 任务目标。

  • 当前计划。

  • 子任务状态。

  • 工具调用结果。

  • 文件变更。

  • 错误和重试次数。

  • 是否通过验证。

  • 是否等待用户确认。

状态显式化可以让 Agent 可恢复、可调试、可中断。

8. Tool Harness

Tool Harness 定义模型可以调用哪些工具、如何调用、如何处理结果和错误。 关键设计： - 工具描述清晰。

  • 参数 schema 严格。

  • 返回结构化。

  • 错误可机器读取。

  • 高风险操作确认。

  • 工具调用可审计。

  • 工具权限最小化。

工具接口不好时，模型即使推理正确，也可能因为参数错误或结果误读失败。

9. Environment Harness

Environment Harness 提供模型行动的执行环境。例如代码 Agent 需要真实仓库、依赖、测试环境、命令执行沙箱和文件系统。 环境设计要点： - 可重复。

  • 可隔离。

  • 可恢复。

  • 有资源限制。

  • 有权限边界。

  • 有执行日志。

没有可靠环境，Agent 只能生成建议，无法可信执行任务。

10. Permission Harness

Permission Harness 控制 Agent 能做什么。它包含身份、授权、工具权限、资源范围和用户确认。 常见策略： - 只读默认。

  • 最小权限。

  • 高风险操作前确认。

  • 删除、支付、部署等操作强制人审。

  • 按用户、租户、项目隔离。

  • 记录权限决策。

Harness 不应把权限交给模型自觉遵守。

11. Human-in-the-loop Harness

Human-in-the-loop 让人在关键点介入。介入点可以是计划确认、权限批准、结果审核、异常处理和最终发布。 人审并不意味着系统不自动化，而是把不可逆、高风险或高不确定步骤交给人类裁决。 高质量人审界面应展示： - Agent 想做什么。

  • 输入参数。

  • 影响范围。

  • 风险等级。

  • 可选操作。

  • 回滚方式。

12. Evaluation Harness

Evaluation Harness 用于持续衡量 Agent 是否真的变好。它包括离线测试集、在线指标、回归测试和任务级评分。 评估层次： - 单步工具选择。

  • 参数正确性。

  • 子任务完成率。

  • 最终任务成功率。

  • 人工修改量。

  • 成本和延迟。

  • 安全违规。

  • 错误复发率。

没有 Evaluation Harness，Agent 调优容易变成凭感觉改 prompt。

13. Observability Harness

Observability Harness 记录 Agent 执行轨迹，帮助定位问题。 Trace 应包含： - 输入和上下文。

  • 模型调用。

  • 工具调用。

  • 状态变化。

  • 权限决策。

  • 人工确认。

  • 错误和重试。

  • 最终输出。

  • 评估结果。

复杂 Agent 的失败往往不是最终答案本身，而是中间某一步偏离目标。

14. Memory Harness

Memory Harness 决定 Agent 如何保存和使用历史经验。它不是无限保存聊天记录，而是管理记忆生命周期。 包括： - 写入策略。

  • 检索策略。

  • 记忆类型。

  • 冲突处理。

  • 删除和遗忘。

  • 隐私隔离。

  • 记忆有效性评估。

Memory Harness 与 Evaluation Harness 结合，才能避免错误记忆长期污染系统。

15. Coding Agent Harness

编码 Agent 的 Harness 是典型场景。它通常包含： - 仓库读取。

  • 代码搜索。

  • 文件编辑。

  • 测试运行。

  • Linter。

  • 类型检查。

  • Git diff。

  • PR/Issue 上下文。

  • 代码 review。

  • 人工确认。

编码 Agent 的成功不只取决于模型会不会写代码，还取决于它能否验证修改、理解仓库结构、避免误改和处理测试失败。

16. Deep Agent Harness

Deep Agent 需要长时间、多步骤、多工具执行。Harness 对它尤其重要。 关键能力： - 长任务状态持久化。

  • 子任务分解。

  • 失败恢复。

  • 中间结果管理。

  • 预算控制。

  • 检查点。

  • 过程验证。

  • 人审插入。

没有 Harness，深度 Agent 容易迷失、循环、过早终止或错误传播。

17. Harness Engineering 的实验方法

Harness Engineering 应通过实验迭代。 常见实验： - 改上下文组织方式。

  • 改工具 schema。

  • 增加测试工具。

  • 增加人审步骤。

  • 增加 checkpoint。

  • 改错误返回格式。

  • 增加 verifier。

  • 调整权限边界。

每次实验应比较端到端成功率、成本、延迟和失败模式变化。

18. Harness 失败模式

常见失败包括： - 上下文缺失。

  • 状态丢失。

  • 工具描述不清。

  • 工具返回不可解析。

  • 权限过宽。

  • 人审信息不足。

  • 没有真实验证。

  • trace 缺失。

  • 环境不可复现。

  • 错误恢复路径缺失。

  • 评估集不覆盖真实任务。

19. Harness 与安全

Harness 是 Agent 安全的主要承载层。模型不应直接获得无限制行动能力。 安全设计包括： - 沙箱。

  • 权限最小化。

  • 租户隔离。

  • 机密信息过滤。

  • 高风险操作确认。

  • 输出审查。

  • 工具调用审计。

  • 回滚机制。

Agent 越能行动，Harness 越重要。

20. Harness 的生产化原则

生产环境中的 Harness 应满足： - 任务状态可持久化。

  • 工具调用可审计。

  • 结果可验证。

  • 人类可介入。

  • 错误可回放。

  • 权限可治理。

  • 指标可监控。

  • 变更可回滚。

  • 实验可对比。

21. 核心总结

Harness Engineering 是围绕模型构建可靠 Agent 执行环境的工程方法。它强调上下文、状态、工具、权限、环境、人审、评估和可观测性共同决定 Agent 的实际能力。 面试表达时应突出： - Harness 不是 prompt，而是模型周围的完整工程系统。

  • 对深度 Agent 和编码 Agent，Harness 往往比单次提示更关键。

  • 可靠 Agent 的关键是状态显式、工具可控、结果可验证、过程可观测、人类可介入。

22. 参考资料

  • LangChain: The Anatomy of an Agent Harness: https://blog.langchain.com/the-anatomy-of-an-agent-harness/

  • LangChain: Improving Deep Agents with Harness Engineering: https://blog.langchain.com/improving-deep-agents-with-harness-engineering/

  • HumanLayer: Harness engineering for coding agents: https://www.humanlayer.dev/blog/skill-issue-harness-engineering-for-coding-agents

  • Mitchell Hashimoto: My AI Adoption Journey: https://mitchellh.com/writing/my-ai-adoption-journey

            预览时标签不可点

    <div class="