QDKT全面拆解Harness工程

一、Harness 的核心概念与定义

1.1 基本定义

Harness（驾驭/约束工程）是围绕大模型（LLM）构建的一套工程策略与思维方式，其核心目标是让 Agent 在长时间、高复杂度的任务执行中保持稳定、清醒与可控。

• Deepseek 的定义：Model + Harness = Agent。模型之外的所有工程组件（循环、工具调用、规划、Skill、MCP、Memory、Subagent 等）均属于 Harness 的范畴。没有 Harness，仅靠模型本身无法构成可用的 Agent。

• Kimi 的定义：当 Agent 在真实世界中长时间调用工具、穿梭于多端环境并持续完成复杂任务时，真正决定其能走多远的往往不是模型本身，而是Harness 与 LLM 共同优化的结果。Harness 决定了 Agent 的状态管理、上下文交接方式、反馈闭环机制，以及其在长时间执行中能否保持稳定。

1.2 本质属性

Harness 并非单一技能，而是一种综合性的工程思维与工匠精神，类似于产品经理的底层基本功。它专为Agent而生：如果产品形态只是 Chatbot、传统工作流（Workflow）或简单的业务赋能工具，则不涉及 Harness；只有将大模型放入具备自主循环能力的 Agent 中，才存在约束、控制与优化的必要。

1.3 核心思路：扬长避短

所有 Harness 策略均围绕两个维度展开：

扬长（发挥模型优势）：

• 知识渊博：覆盖广泛领域知识。

• 记忆力强：现代模型已支持百万级 Token 上下文（如 100 万 Token，相当于两套《三体》的容量）。

• 推理与语言理解能力：具备强大的逻辑推导与自然语言处理能力。

• 接受弹性规则：能够处理非确定性、非遍历性的模糊规则，这是颠覆传统互联网产品形态的核心能力。

避短（规避模型缺陷）：

• 知识边界黑箱且有时效性：模型知识存在明确的训练截止时间，且具体知道什么、不知道什么是不可预测的。因此需要通过 RAG、搜索、Deep Research 等手段实时补全知识。

• 注意力分散：尽管基于注意力机制，但过长上下文或多任务并行会导致模型“收口”到单一输出时产生偏差，需进行上下文管理。

• 记忆容量有限：虽然支持超长上下文，但 100 万 Token 是硬上限。若在其中填充低质量信息（如垃圾搜索结果），则超长记忆的价值会被浪费，因此需要压缩与筛选。

• 无环境感知与永久记忆：模型没有时间概念、空间位置概念，也不记得之前的对话（所谓“记忆”只是每次 API 请求时人工塞入的历史上下文），因此需要环境感知设计与记忆管理。

• 听话但“没轻没重”：模型缺乏人类的疼痛/风险感知，会机械执行指令（如删除关键文件），因此必须通过约束、权限、沙箱等手段进行行为边界控制。

1.4 与相关概念的关系

• Prompt Engineering（提示词工程）：仅通过提示词约束模型，上下文来源单一。

• Context Engineering（上下文工程）：在提示词之外，通过 RAG、联网搜索、MCP 等方式为模型拼接更多外部知识，是 Prompt Engineering 的升级。

• Harness Engineering：不仅管理上下文内容，还管理上下文构建的全过程，包括对召回策略、模型选型、工具调用、状态管理等全链路组件的优化。它是 Context Engineering 的进一步扩展与系统化。

注意：Harness 与Hermes（爱马仕）不可混淆。Hermes 是一款具体的 Agent 产品（类似 OpenClaw），而 Harness 是让这类产品变得靠谱的工程精神。

二、产品经理类型与 Harness 的关联

2.1 业务本位 vs. 模型本位

• 业务本位：将 AI 视为与搜索、短视频类似的技术手段，用于提升现有业务效率或赋能原有产品（如剪映的 AI 功能、飞书的 AI 嵌入）。产品核心仍是原业务，AI 仅作锦上添花。此类场景通常只需 Prompt Engineering 或 Context Engineering，无需深入 Harness。

• 模型本位：以模型能力为核心出发点，围绕 AI 设计新产品（如扣子、即梦、IMA、Manus、Codex），或对原有业务进行彻底重构（如飞书将 API 文档改造为 CLI 供 Agent 调用）。此类产品必须掌握 Harness。

2.2 产品经理分类及能力要求

（1）赋能型产品经理（业务本位）

• 需深入理解业务卡点（即业务痛点及 AI 能消除的具体环节）。

• 必须熟悉大模型的能力边界与缺陷（知识时效、幻觉、随机性、提示词依赖）。

• 需扎实掌握四大工程策略：大模型 API、Function Call、Workflow、RAG。

• 需理解三种 AI 产品形态：

  • Copilot 型：辅助决策，不参与真实生产流程（如头脑风暴、翻译）。

  • 嵌入型：完成某一环节后由人类接手（如 AI 写初稿后人工修改、传统 Workflow）。

  • Agent 型：独立完成全流程工作（如 Web Coding、自动写 PRD）。

（2）AI 原生产品经理（模型本位 / Agent 产品经理）

• 必须具备赋能型产品经理的所有基础能力。

• 思维钢印：必须真正相信模型能力，愿意花费精力为模型提供高质量上下文。若始终认为“模型不行、不如人干”，则无法做出优秀的模型本位产品。

• 必须掌握 Harness：这是此类产品经理的核心竞争力，也是未来“金饭碗”所在。

三、Agent 的基本组件与工作原理

3.1 三大基本组件

1. 循环（Loop）：自动完成多轮对话拼接，实现“LLM 调用 LLM”的自我驱动机制。模型生成调用指令，执行后结果再次输入模型，形成自循环。

2. 任务规划（Planning / Reasoning）：Agent 需知道任务何时开始、如何拆解、何时结束，避免无意义空转。

3. 工具（Tools）：延伸模型能力并赋予其“手脚”以改造环境。主流 Agent 至少包含四大工具：

   • Bash：调用终端，是 Agent 改造自身生存环境、具备“生命力”的核心。

   • File Read / File Write / File Open：文件的读取、创建与编辑。互联网虚拟世界本质上由文件构成，掌握文件操作即掌握对数字世界的改造能力。

3.2 基础工作流程

用户需求 → 提示词组装 → 任务规划（可选写入本地文档）→ 进入 Agent 循环：

1. 拼接消息（提示词 + 历史上下文）。

2. 提交 LLM 推理分析。

3. 模型判断是否需要调用工具：

   • 需要：进行权限检查 → 执行工具 → 改造环境 → 获取结果 → 将结果拼回消息 → 继续循环。

   • 不需要：直接生成答案 → 跳出循环 → 输出给用户。

4. 过程中可进行记忆管理（本地存储）。

四、Harness 工程策略详解（以写作 Agent 为例）

当 Agent 具备基础生命循环后，必须通过 Harness 策略解决一系列稳定性与可靠性问题。以下是以“写作 Agent”为场景的逐层优化迭代：

4.1 任务规划与状态管理（1.0 迭代）

问题：Agent 可能跑偏、忘记做到哪一步、无法判断任务是否完成、无限循环。

策略：

• 强制 Todo 清单：要求 Agent 维护一个 Markdown 格式的任务清单（Todo 文档），明确列出步骤。

• 状态追踪：每轮循环强制调用工具更新任务状态（如进行中/已完成）。

• 强制回顾（Hooks）：通过自动脚本（Hook），在每轮循环结束时将当前任务清单重新拼接到上下文尾部，利用模型的“近因效应”（越靠后的信息权重越高），确保其每轮都能看到当前进度。

• 熔断机制：设置硬性的轮次上限（如 50 轮、90 轮），超过则强制终止，防止无限循环。

4.2 上下文管理（Context Engineering）

问题：多轮工具调用后，上下文窗口（如 64K/128K）被撑爆，导致循环中断或成本激增。

策略：

• 信息筛选与压缩：评估每轮该带入/剔除的信息，对历史消息进行压缩与回滚（如搜索返回的万字结果可压缩为摘要）。

• Subagent（子代理）：将子任务委派给其他 Agent 处理，仅接收其最终结论，不占用主上下文窗口（如同让实习生调研后只汇报结论）。

• 按需加载工具：避免一次性加载所有工具描述，根据当前任务阶段动态加载所需工具，减少 Token 消耗。

4.3 沙箱与权限管理

问题：Agent 可能“逃逸”出指定工作空间（如将文件写到桌面、误删系统文件）。

策略：

• 沙箱隔离：为 Agent 划定明确的工作目录与操作边界，限制其对系统关键区域的访问。

• 权限分级：对敏感操作（如删除、系统级修改）设置硬性脚本审核或人工确认机制，而非完全依赖模型自我判断。

• 产业价值：沙箱与权限管理未来可能成为 Agent 产业链中的独立环节（类似微信生态中的第三方服务商）。

4.4 Hooks（自动化脚本）

问题：所有环节都依赖模型推理，Token 消耗大且不必要。

策略：

• 在 Agent 循环中嵌入非模型触发的自动化脚本（Hooks）。例如权限审核、格式校验、固定代码生成等，直接通过程序自动化完成，无需调用 LLM，从而降低成本并提升确定性。

4.5 记忆管理

问题：模型没有永久记忆，新开对话即遗忘；不同场景对记忆的需求不同。

策略：

• 永久记忆：将用户偏好、关键事实固化，在每次 API 请求时自动拼入上下文。

• 按需检索：将非关键记忆存入外部存储，仅在需要时检索调用。

• 场景化策略：

  • 如 OpenClaw 会带入近期日记内容；

  • 如 Hermes 仅提取关键小节写入 Memory 文档；

  • 情感陪伴类 Agent 需尽可能多带入历史记忆；

  • 工程类 Agent 则无需过多情感记忆。

4.6 错误恢复与兜底策略

问题：工具报错、模型 API 异常、循环崩溃、记忆读取失败等导致 Agent 宕机。

策略：

• 分级兜底：预设不同故障场景（工具失败、模型失败、循环中断、记忆失效）的恢复机制。

• 状态重置与续跑：失败后不直接终止，而是尝试重置状态、跳过当前步骤或向用户反馈具体阻塞点，确保任务可恢复而非直接废弃。

4.7 迭代路径总结

一个完整的写作 Agent Harness 优化可分为7 层迭代（6 轮升级）：

1. 出场配置：基础 Loop + 工具 + 简单提示词。

2. 任务规划与状态管理：增加 Todo 清单、状态追踪、强制回顾、熔断机制。

3. 上下文管理：历史压缩、信息筛选、Subagent、按需加载。

4. 沙箱与权限：工作目录隔离、敏感操作限制。

5. Hooks 自动化：脚本替代模型执行确定性任务。

6. 记忆管理：永久记忆写入、按需检索、场景化策略。

7. 错误恢复：全链路兜底、状态重置、故障反馈。

实践参考：同样的写作场景，不同 Agent 产品的优化逻辑与顺序存在差异（如 Codex 迭代 8 个版本，Hermes 迭代 7 个版本），但核心原则一致——持续优化每个环节，让 Agent 更靠谱、更稳定、更可控。