JavaGuide - Harness Engineering
HarnessEngineering
Harness Engineering：六层检查框架、上下文管理与工程实践
Harness
一个很有名的公式将 Agent 概括为：Agent = Model + Harness。
其中 Model、LLM 虽然是 Agent 的决策中枢，却完全没有任何活动能力，堪称“缸中之脑”，它既没有记忆能力，无法选择上下文，也无法使用工具，甚至无法感知到外界，只能处理输入的文本。
而 Harness 就是为了补足裸露 LLM 的缺陷而被创造出来的产物。LLM 没有记忆？不能用工具？不能感知外界？没关系，由我们人类为 LLM 创造一个沙箱环境，只要能完成工作，它需要什么，我们就给它什么，一切以 LLM 的判断为准，我们只做后勤工作，换言之，我们要做一个全盘支持 LLM 运作的环境。
然而，我认为 Harness 还应当再次分层，将其分为 Runtime 和 Capacity 。前者为 Agent Loop 的运行时环境，包括工具系统、记忆系统、上下文管理系统、Agent Loop 感知反馈循环等，将之组成为一套独立的软件系统，缺少任何一个组件就无法使 Runtime 可靠运行的基础设施；而后者则是用于增强 Agent 的组件，例如 skill、知识库等研究如何让 LLM 更有效更精确完成任务的研究，虽然缺少也不会导致 Agent 停摆，但加上就有可能使 Agent 效果更好。
我的判断是，Capacity 中的一部分，例如 Skill，或类似于基于 Skill 构建 规划-执行-审查-纠错 Workflow 的做法，会随着 LLM 基础能力提升而触碰到边际效应，它们都有一个特点：以人类的视角去指导 LLM，以人类的智慧补足 LLM 缺失的智能。
这个判断其实已经被侧面映证过了一次，就是前面提到构建 Workflow 的做法，这种实践盛行于 2026年4月，基于 Claude Code 等 Agent 应用，使用 gstack、superpowers 等 skill 库编排各种工作流，特别是 规划-执行-审查-纠错，我们当时的想法是：为 LLM 构造一个无法出错、完全按照我们的编排执行的环境，就是 Harness Engineering。然而，这套做法在仅仅一段时间后就被摒弃了，有人认为是因为太 heavy 了，然而根本原因则是 LLM 在几个月内的成长速度完全超出想象，以至于我们引以为豪的工作流，基础模型自己就能构建了，甚至能够随着任务的不同而构建更加适合任务的工作流，我们不断地加砝码反而拖累了 Agent 的性能，或者说我们设想中的通用工作流本身就是一厢情愿。
综上，我认为当前 Harness 的重心要放在 Runtime 上，全世界工程能力最强的 deepseek，更是直接将他们的 Agent 命名为 Deepseek Harness，Harness 实际上更向 Agent Loop Runtime 的概念靠拢。