在当前的 AI 发展阶段，我们面临着一个核心的工程问题：当大模型不再仅仅是输出一段文本回复，而是要在真实的系统中持续完成复杂任务时，模型的周围还需要什么？
Harness Engineering 正是为了解决这一问题而诞生的系统性工程实践。
一、 系统责任的演进：为什么我们需要 Harness？
从早期的单次对话到如今的智能体（Agent），模型应用的形式经历了显著的演变，系统所承担的责任也在逐层扩大：
- 单次请求阶段： 系统的主要责任是处理输入、输出格式、超时以及基本的审计。
- Function Calling 阶段： 模型的输出开始代表外部行动请求，系统增加了工具选择、参数校验、执行以及错误回传的责任。
- Agent Loop / ReAct 阶段： 系统需要处理行动决策的循环、观察、重试机制、停止条件以及预算控制。
- Agent 任务阶段： Agent 需要对真实目标进行持续推进。这要求系统负责工作空间、跨会话状态、记忆、权限控制、独立验证、错误恢复以及服务化。
关键结论： 强模型、工具调用、循环（Loop）和上下文压缩机制，并不能自动解决长任务中的目标分解、状态管理和验证交接等问题。任务的最终结果越来越依赖于外部系统（如文件、数据库、浏览器），而非模型最后生成的几句话。
二、 什么是 Agent Harness？（定义与边界）
“Harness”一词借用自传统软件工程中的“测试控制台（Test Harness）”概念。它指的不是被测对象本身，而是为对象提供输入、运行环境、观测和断言的一套外部装置。
行业内对 Harness 的定义存在不同的视角（例如广义非模型层、严格运行时、运行时基底、外层使用者机制等），但这主要因为分析的单位不同，而非互相排斥。为了清晰界定一个系统是否构成了完整的 Agent Harness，业界提出了一套实用的“四问法”边界测试：
- T1：是否存在运行时闭环？ 上一步的环境观察能够真实改变下一步的行动，而非固定流水线。
- T2：能否感知并改变外部环境？ 工具不仅能返回知识，还能实际操作外部环境（如写文件、运行命令），产生副作用。
- T3：是否具有任务感知的上下文和状态管理？ 系统能主动根据任务内容和观察结果来管理上下文，而非简单地堆叠或截断历史聊天记录。
- T4：是否存在独立的控制或验证机制？ 拥有不依赖于“模型自觉服从”的硬性约束（如权限、预算断言、独立验证），来阻断或确认执行。
注：单独的 Prompt 模板、沙盒（Sandbox）、MCP Server 或固定工作流，通常只满足上述的部分条件，因此它们是 Harness 的重要组件，但不能等同于完整的 Harness。
三、 从任务生命周期反推 Harness 核心模块
Agent 在执行任务时，输出变成了行动，一次调用变成了持续循环，外部环境也成为了状态的一部分。为了应对这些挑战，一个完整的 Agent 运行与控制系统通常包含以下六大责任模块：
- 模型交互与输出控制： 负责结构化输出、函数调用、模型路由，将开放生成转化为系统可用的决策数据。
- 编排与行动 Loop： 管理状态机、路由、计划、重试和停止机制，让任务能按观察结果持续推进并保持预算边界。
- 工具、Skills 与 Workspace： 提供 MCP/API、Shell、文件系统等，赋予模型行动力，同时将副作用限制在安全环境内。
- 会话、状态与记忆： 管理 Session、进度（Progress）、检查点（Checkpoint）和交接，在多轮和长任务中维持连续性。
- 服务化与消息边界： 处理 API/Worker、流式输出、并发与外部消息收发，将 Agent 封装为长期运行的服务。
- 可观测、验证与 Eval： 涵盖事件日志、Trace、测试（Tests）与回归，用于还原过程、独立验收和持续改进。
四、 Harness 的六层架构体系
Harness 的覆盖范围可以划分为从内到外的六个层次，并不是每一层都需要从零自建，但需确保责任闭环：
- L0 模型层： 能力的基础，但不属于 Harness 范畴。
- L1 指导与上下文： 包括 Prompt、文档、RAG 和进度记录。是核心组件但不足以独立控制任务。
- L2 行动与环境： 工具、MCP、Workspace 和沙盒。让模型能改变现实状态。
- L3 任务运行与服务： Loop 循环、状态编排、记忆、流式处理和恢复机制。负责任务的持续执行。
- L4 质量与交付： 日志、Trace、测试、Eval 和 CI/CD。确保结果可见、可验、可回归。
- L5 治理与组织： 身份权限、成本管控、审计与组织交付模式。通常属于外层的 Agent-first Operating Model，其部分策略会被编码进运行系统中。
五、 Harness 工程的核心实践结论
通过行业前沿的实验（如 SWE-agent 的接口实验、Anthropic 的长任务实验、OpenAI 的 Agent-first 仓库实践），我们可以得出四条核心的工程结论：
- 任务必须从可验证的契约开始，而非单纯的 Prompt： 目标、验收证据、预算和权限必须成为可验证的外部系统对象。
- 上下文窗口（Context Window）绝不等于任务状态： 计划、进度、决策记录和工作基线必须被独立持久化，不能仅依赖压缩的聊天历史。
- 确定性的约束必须代码化，不能依赖自然语言： 权限边界、Schema 校验、Lint 阻断等必须在模型外部执行强制验证，不能指望模型“听话”。
- 失败必须进入可重复的回归闭环： 保留 Trace 与环境快照，精准定位失败根因（属于模型、工具、状态还是验证环节），并将其纳入 Eval 回归集中以防复发。
结语
Harness Engineering 的核心理念在于：Agent 的任务表现，绝不仅仅是模型自身能力的体现，而是模型、接口、上下文状态、控制机制与外部环境共同作用的系统属性。模型负责提供基础的智能，而 Harness 工程则负责将这种智能转化为能够受控、可持续、可观察、可验证的任务交付能力。
