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 三大基本组件

循环（Loop）：自动完成多轮对话拼接，实现“LLM 调用 LLM”的自我驱动机制。模型生成调用指令，执行后结果再次输入模型，形成自循环。
任务规划（Planning / Reasoning）：Agent 需知道任务何时开始、如何拆解、何时结束，避免无意义空转。
工具（Tools）：延伸模型能力并赋予其“手脚”以改造环境。主流 Agent 至少包含四大工具：
- Bash：调用终端，是 Agent 改造自身生存环境、具备“生命力”的核心。
- File Read / File Write / File Open：文件的读取、创建与编辑。互联网虚拟世界本质上由文件构成，掌握文件操作即掌握对数字世界的改造能力。

3.2 基础工作流程

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

拼接消息（提示词 + 历史上下文）。
提交 LLM 推理分析。
模型判断是否需要调用工具：
- 需要：进行权限检查 → 执行工具 → 改造环境 → 获取结果 → 将结果拼回消息 → 继续循环。
- 不需要：直接生成答案 → 跳出循环 → 输出给用户。
过程中可进行记忆管理（本地存储）。

四、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 则无需过多情感记忆。