北京大学：2026年Harness Engneering-驯服Agent从理论到落地（69页）.pdf

核心结论速览： 从Prompt到Harness的演进本质是控制权从“人写指令”迁移到“系统机制”：优秀的Agent系统不是靠更长的Prompt解决问题，而是靠设计约束、循环和验证的工程体系。真实系统演进路径表明：规则被记录但约束力下降→Skill沉淀方法但不能决策→Orchestrator统一调度→Hook实现程序化执行。 “完成”不能自证——必须用外部证据和验证结果证明任务完成：Obligation（任务契约）将完成标准统一管理——明确“需要完成什么”和“满足哪些条件才算完成”。五步完成链路：列出契约→派发执行→收集证据→按契约验证→确认归档。 Constraint层只处理机器能判断的事，把探索和推理留给Agent：约束层职责是状态记录、任务契约追踪、证据验证和生命周期规则。涉及方案探索、复杂推理、创造性决策的部分交给Execution Loop中的Agent完成。Constraint层保持小而稳定，不随任务复杂度膨胀。 Hook将规则从“模型需要主动遵守”转变为“系统自动执行”：规则只有具备可验证、可拦截、可执行的能力，才能成为系统的一部分。Hook在工具调用前/后、会话初始化等生命周期节点自动触发检查逻辑。 Memory + State + Event System让Agent可以暂停→恢复→继续执行：企业任务可能持续数小时甚至数天。系统需要主动保存任务状态、已完成步骤、历史决策、错误记录、验证结果，让Agent像操作系统保存进程状态一样支持长周期任务。 Skill提供方法与证据，但不该拥有裁决权：当Skill开始承担任务分配和流程控制时，容易演变成实际上的“决策中心”。决策权（调度者决定流程）与执行权（执行者完成任务）必须严格分离。Harness工程的本质：控制权的系统化迁移。从“写好Prompt”到“设计好系统”。Harness Engineering的兴起标志着AI工程范式从“如何让模型输出更好”转向“如何让Agent系统持续、稳定、可控地完成任务”。核心变化不是技术栈的升级，而是控制权的迁移——从人的经验和模型自觉，迁移到明确的系统机制。核心洞察：很多AI系统的问题并非能力不足，而是缺少将“应该完成”转化为“必须经过验证才能完成”的机制。一个真实Agent系统的演进实录清晰展示了这一过程。演进四阶段：控制权如何逐步迁移。阶段一：从口头叮嘱到CLAUDE.md。零散要求变成显式约束。规则示例：修改代码前先理解现有结构、优先采用简单可维护方案、始终围绕目标执行。问题：规则文件从几十行增长到数百行后，Agent的遵循能力下降。重要规则不会自动获得更高优先级。Prompt适合表达原则和偏好，但不适合作为生命周期级别的强制控制机制。阶段二：用Skill沉淀方法论，警惕“夺权”风险。CLAUDE.md负责“应该遵守什么规则”，Skill负责“如何完成某类任务”。但Skill开始承担任务分配和流程控制时，容易演变成实际上的“决策中心”——抢任务、争夺调用权、缺乏统一裁决标准。设计原则：不能让同一个模块既当运动员又当裁判。阶段三：引入Orchestrator统一调度。系统拆分为三层：策略层（规则）、决策层（调度）、执行层（执行）。Orchestrator负责选择执行者、管理执行流程、管理验收状态（放行/可恢复阻断/硬阻断）。Orchestrator是系统中的调度中心，负责连接任务、能力和验证机制，本身不参与具体执行。阶段四：通过Hook实现规则程序化执行。如果“这一步是否通过”仍由AI自己判断，评审者和执行者依然是同一角色。Hook在工具调用前/后、会话初始化等生命周期节点自动触发检查逻辑。规则由“模型需要主动遵守”转变为“系统自动执行”。规则只有具备可验证、可拦截、可执行的能力，才能真正成为系统的一部分。数据来源：北大青鸟人工智能研究院《Harness Engineering——驯服Agent 从理论到落地》。任务契约（Obligation）：让“完成”可验证。核心问题：AI说“我做完了”不等于真的做完了。传统Agent系统中，任务完成的判断依赖模型的主观陈述。当状态记录能回答“发生了什么”却回答不了“这件事算不算做完”时，系统缺少客观的验收标准。Obligation（任务契约） ：统一管理完成标准。完成一个任务不再依赖Agent的主观判断，而必须满足预先定义的验收条件。这类似把一份施工合同和一份验收清单合并成一份文件——既明确“需要完成什么”，也规定“满足哪些条件才算完成”。四种可独立校验的身份。Harness通过以下四个身份来验证任务完成的真实性：1. 请求归属：谁提出这次任务。2. 任务契约：任务必须满足哪些验收项。3. 执行载体：具体是哪一次执行在处理任务。4. 事实记录：关联Memory、State、Event System中的状态变化和事件记录。五步完成链路。1. 列出任务契约。2. 派发执行。3. 收集执行产出的证据。4. 按契约逐项验证。5. 确认完成并归档。目标：形成一条可验证、可追溯的完成链路，而不是靠模型一句“我做完了”来结束任务。三类容易被忽略的断裂点。1. 路由完成，但无人接手：任务已分配，却没有实际执行者认领。2. 任务派发，但长期无响应：执行过程陷入沉默，无超时检测和异常恢复。3. 结果返回，但没有验收：执行产出已生成，却没有经过契约验证。数据来源：北大青鸟人工智能研究院《Harness Engineering——驯服Agent 从理论到落地》。Harness核心架构的构建指南。第一层：Constraint（约束层）——Agent可以做什么？约束层是前馈控制，在错误发生前避免错误。架构约束：定义项目基本规则——系统架构、Coding Convention、API设计、仓库结构。典型文件：AGENTS.md、CLAUDE.md、ARCHITECTURE.md。工具边界：限制Agent能够调用的工具——Read/Edit File、Terminal、Browser、MCP Tool。遵循最小权限原则：是否允许联网/执行Shell/删除文件。权限控制：强制执行的机器规则——Human Approval、Sandbox、Runtime Policy、Hook/Tool Permission。核心目标：让Agent不容易犯错，而不是犯错以后再纠正。第二层：Context（上下文管理）——AI应该知道什么？Context是Harness的输入管理系统，正从“一次性输入内容”转变为“需要持续治理的运行时资产”。Knowledge：项目知识库、文档管理、RAG（检索增强生成）。Memory：短期/长期记忆、工作记忆、用户偏好、历史任务。Compression：Summary（摘要）、Compression（压缩）、Sliding Window（滑动窗口）。第三层：Orchestration & State（编排与状态）——任务如何推进？Workflow（编排机制） ：Planner/DAG、Task Graph、Scheduler。Runtime（运行时管理） ：Long-running Agent、Checkpoint、Resume、Retry、Session。Multi-Agent（多角色协作） ：Planner→Researcher→Coder→Reviewer→Evaluator分工。State Management（状态管理） ：Event Store、Current State、Memory Persistence。第四层：Feedback & Verification（反馈与验证）——如何证明任务真正完成？自动反馈：Evaluator/Reviewer Agent、Reflection（自我反思）、Retry（重试机制）。自动验证：Unit/Integration Test、Benchmark、Linter、Build验证。数据来源：北大青鸟人工智能研究院《Harness Engineering——驯服Agent 从理论到落地》。Harness实践的行动指南。第一步：先分类，再动手。每当出现新问题，先想清楚性质：是约束类问题、状态类问题、契约类问题、验证类问题，还是成本类问题？问题的性质决定了它该被放进系统的哪一层。第二步：明确各层定位。 Prompt定位是表达意图，而非实施管控——适合承载原则和偏好，不适合作为强制控制手段。 Skill提供方法与证据，但不该拥有裁决权——任务分配权和最终“合格”判定不该交给Skill自己。 约束层保持“小而稳”——只处理不依赖模型主观理解、能被系统稳定验证的事务。 真正的扩展性和智能判断交给Execution Loop——不要不断往Constraint层堆功能。第三步：建立任务契约机制。一切“必须完成”的事项都应归到统一的任务契约机制中追踪，不能让它们零散地存在于prompt措辞、临时性报告或散落的脚本里。第四步：实现Hook程序化执行。Hook可在工具调用前、调用后、会话初始化等关键生命周期节点自动触发检查逻辑。规则位置发生变化不等于最终决策权真正交给系统。可靠的Agent约束体系不仅需要清晰的规则定义，还需要由机器执行的自动化检查机制。第五步：构建Memory + State + Event System。执行过程中的状态和决策记录需要由系统主动保存。这些信息必须独立存在，并成为系统判断当前进展的依据。让Agent可以暂停→恢复→继续执行。第六步：将执行链路收归系统。将Request→Decision→Action→Evidence→Validation→Audit Log转化为可验证、可追溯的完整链路。强能力不等于可直接信任——即便是能力很强的Agent，其输出也需要先经过转化，变成可验证、可审查的形式，才能进入系统的下一环节。数据来源：北大青鸟人工智能研究院《Harness Engineering——驯服Agent 从理论到落地》。延伸阅读：以上为报告核心内容分析，如需获取完整报告详细数据及全部案例分析，请访问下载页下载完整PDF报告。FAQ。Q1：Harness工程与Prompt工程的根本区别是什么？A：Prompt工程关注“如何说对话”，Harness工程关注“整个系统如何可靠运行”。Harness通过约束、循环、验证三大机制，让Agent从“聪明但不可预测”变成“能力强且可管理”。Q2：任务契约（Obligation）的作用是什么？A：统一管理完成标准，明确“需要完成什么”和“满足哪些条件才算完成”。任务完成不再依赖Agent主观判断，而必须满足预先定义的验收条件。五步链路：列出契约→派发执行→收集证据→按契约验证→确认归档。Q3：为什么Skill会“夺权”？如何避免？A：当Skill开始承担任务分配和流程控制时，容易演变成决策中心。应严格分离决策权（调度者决定流程）和执行权（执行者完成任务），不要让同一个模块既当运动员又当裁判。Q4：Hook在Harness中扮演什么角色？A：Hook在工具调用前/后、会话初始化等生命周期节点自动触发检查逻辑，将规则从“模型需要主动遵守”转变为“系统自动执行”。规则只有具备可验证、可拦截、可执行的能力，才能真正成为系统的一部分。Q5：Memory + State + Event System的核心价值是什么？A：主动保存任务状态、已完成步骤、历史决策、错误记录、验证结果，让Agent可以像操作系统保存进程状态一样支持长周期任务——暂停→恢复→继续执行。数据来源说明：本页面所有内容均来源于北大青鸟人工智能研究院《Harness Engineering——驯服Agent 从理论到落地》（2026年7月14日）。