一篇Harness研究后的思考！

公众号名称：Datawhale

作者名称：陈希伟

发布时间：2026-05-30 22:07

Datawhale干货

作者：陈希伟，Datawhale贡献者

一、Agent 圈终于不再只谈模型

最近，CMU/Yale 等机构发布了一篇关于 Agent Harness Engineering 的综述。这篇文章的出现有着极强的行业标志意义：它正式宣告了一个共识的转移——大模型 Agent 的可靠性，绝不能再只盯着模型本身。

论文主页地址：https://picrew.github.io/LLM-Harness/

在过去很长一段时间里，业界对 Agent 的期待建立在几个朴素的线性外推上：模型参数越大，Agent 就越聪明；上下文窗口越长，Agent 就能处理越复杂的任务；外接的 API 工具越多，Agent 的能力边界就越广。

这些判断没有错，但极其单薄。

二、为什么模型更强了，Agent 还是会翻车

任何一个真正动手跑过长程任务的开发者都很容易发现：Agent 走向崩溃，往往不是因为它突然丧失了逻辑推理能力，而是因为整个系统缺少一个稳定的运行时结构。

• 它会不知不觉地遗忘当前的任务主线；

• 它会把一次带有幻觉的推理当作确凿的事实写入记忆；

• 它在调用完破坏性的工具后，完全没有同步更新世界状态；

• 它甚至在经历了一次致命的误判后，依然能用极度自信的语气沿着错误的因果链一路狂奔。

这些系统级的雪崩，绝不是靠换一个千亿参数的大模型，或者塞进 1M Context Window 就能解决的。

Agent 从来不是一个模型 + 一段 System Prompt，更不是一个模型 + 几个 Function Call。真正的工业级 Agent，是一个由模型、状态机、记忆流、执行沙箱、验证器、监控追踪和恢复策略共同构成的复杂操作系统。

三、Harness 火了，但它还不是终点

CMU/Yale 的综述证明了 Harness Engineering 已经成为行业显学。但在我的研究脉络里，我认为 Harness 仅仅是跨出的第一步。

Harness 解决的是静态问题：“Agent 的外围系统由哪些组件构成？”

而我正在探索的，是更为致命的动态问题：“这些组件，如何共同维护一个长期稳定、可审计、可回滚、可恢复的运行状态？”

我将这个方向定义为：State-Aware Runtime（状态感知运行时）。

四、Harness 之后，真正的问题开始进入 Runtime

这里的 State-Aware Runtime，不是单纯给 Agent 加一个 memory，也不是把历史对话塞进长上下文，而是把 Agent 的每一步执行都建模为可验证的状态转移：系统必须知道当前状态是什么，哪些动作只是候选，哪些动作已经提交，哪些状态可以回滚，哪些失败需要隔离或交给人类处理。

Anthropic 和 OpenAI 过去一年的平台演进，其实都在做同一件事：把大模型剥离出聊天框，塞进可控的工程脚手架里。Anthropic 强调可组合的 Agent 模式（Context Engineering / Long-running Harness），OpenAI 则在推平台原生（State / Guardrails / Monitoring）。

Harness Engineering 的兴起，为我们提供了一张精密的组件地图。但这还远远不够。地图标明了河流与山脉，但地图本身无法运转机器。

1. 在 Runtime 里，最先要解决的是状态如何被维护

在一个长程 Agent 中，真正的核心是高频的状态转移。每一次的运转，绝不仅仅是生成下一个 Token，而是：

在这个执行流中，最可怕的不是模型输出了错误答案，而是系统根本不知道当前处于什么状态。

哪些事实是不可篡改的常识？哪些只是临时的会话上下文？哪些动作已经被永久写入了数据库？错误发生后，系统应该把状态指针回退到哪一个安全的存档点？

如果缺乏显式的状态管理，Agent 充其量只是一个看起来极其聪明，但内部状态早已相互冲突的文本生成器。

2. 在 Runtime 里，长上下文并不等于长期状态管理

目前各家大厂都在疯狂卷上下文窗口，这极易掩盖一个核心的工程痛点：长上下文绝对不等于长期状态管理。

如果只是简单粗暴地将几万字的历史对话塞给模型，非但不能获得稳定的记忆，反而会引发灾难：早期严格的设定可能被中间的闲聊覆盖；临时的推测可能被模型当作真理固化；摘要压缩过程可能悄悄篡改了任务的初衷。

Context Engineering 的核心设问是：“怎么把正确的信息送进 Prompt？”

而 State-Aware Runtime 的质问要严厉得多：“什么是当前状态？谁有权修改状态？已经被污染的状态如何隔离与恢复？”这才是真正的系统工程。

3. 在 Runtime 里，真正危险的是错误状态被提交

传统评测大模型（如 MMLU），我们只看最终答案：答对即成功，答错即失败。

但评估 Agent 时这种思路完全失效。Agent 的失败是在过程中发酵的，具有极强的级联传播特性。

如果模型错误判断了用户意图，只要这个判断仅仅停留在候选文本阶段，重试即可解决。但如果这个误判被系统写入了长期记忆，那么后续几十个步骤的规划都将在这片地基上坍塌。

如果模型生成了一个危险的 API 调用，只要被外部 Validator 拦截了，系统依然安全。但如果这个调用已经切实改变了外部数据库或游戏世界的状态，错误就已经从语言幻觉变成了外部状态污染的物理影响。

因此，长程 Agent 的核心设计，根本不是强求模型永远不犯错，而是建立一套极其森严的边界防御：严格区分候选输出与已提交状态。

4. 在 Runtime 里，判断可靠性不能只看成功 Demo

现在的 AI 圈充斥着各种花哨的成功 Demo：模型自主规划了十几步，调了各种 API，完美搞定任务。

作为研究者，我对这种幸存者偏差的信息量深表怀疑。对于构建高可靠系统而言，真实的失败轨迹远比完美的 Demo 有价值得多。

只有深入解剖 Trace，你才会知道：

• 崩溃究竟发生在哪里？是状态投影缺失，还是工具执行链断裂？

• 是模型无视了输出规范，还是 Validator 的规则太松懈？

• 是错误记忆被意外写入，还是系统在重试时陷入了死循环导致错误扩大？

这也是我越来越推崇 Trace-Native **Evaluation（轨迹原生评估）**的原因。不要只问最后做成了没有，必须要问这个结果是如何一步步生成的？中间状态有无被污染？系统能否精准定位错误并执行恢复？

对独立研究者来说，系统失控问题值得深挖

回看我过去一段时间的独立研究，我并不是一开始就带着 “State-Aware Runtime” 这个概念出发的。

最早的问题只是：为什么模型明明答对了，过程却不稳定？为什么一个长篇叙事 Agent 可以对话流畅，却在角色知识和关系状态上不断漂移？为什么结构化生成任务里，语言表达看起来自然，底层数学结构却被悄悄改写？

这些问题分布在不同任务里，但它们逐渐暴露出同一类矛盾：

LLM 的生成能力越来越强，但生成过程缺少稳定的状态边界、过程约束和失败恢复机制。

在规范推理中，我关注的是答案正确和过程忠实之间的断裂，也就是 procedural fidelity 问题。

在长篇叙事 Agent 中，我关注的是角色知道什么、不知道什么、何时应该记得或遗忘，也就是 epistemic memory 问题。

在多 Agent 社会交互中，我关注的是行为分布如何被社会信息通道和规范绑定方式改变，也就是运行环境对 Agent 行为的塑形作用。

在结构化生成任务中，我关注的是语言流畅和结构忠实之间的断裂：一个问题讲得自然，不代表它真的保留了原始数学结构。

在游戏 Agent Runtime 中，我关注的是自由对话和世界状态提交之间的边界：一个角色可以生成有趣回复，不代表它可以随意改写剧情、关系或世界状态。

这些方向不是被硬塞进同一个框架，而是从不同侧面说明了同一个趋势：长程 Agent 的可靠性问题，越来越难用单点模型能力解释，必须转向运行时层面的状态管理、过程审计、门控拦截和失败恢复。

所以，我现在的研究定位如下：

关注长程 LLM Agent 中的状态保持、程序遵循、过程审计、门控与回滚机制，
并将其理解为 State-Aware Runtime 问题，
而不是单纯的 Prompt Engineering 或 Memory Augmentation 问题。

在算力即正义的大模型时代，作为资源有限的独立研究者，去硬拼模型训练或冲榜 Benchmark 显然是不明智的。

但 State-Aware Runtime 却是一个极其适合独立研究者深耕、且具备长期壁垒的方向。

在这里，拼的不是千卡 GPU 阵列，而是对系统失败极度的敏感与耐心。一个人完全可以独立完成高密度的 Failure Trace 拆解、长程叙事的状态漂移分析、本地模型的 Validator 与 Rollback 实验，甚至是建立一套详尽的 Agent 崩溃分类学（Failure Taxonomy）。

大厂的视角往往聚焦在如何让模型做对更多事，而独立研究者完全可以站在暗处研究当系统注定会做错时，如何保证它不会毁掉一切。

结语：Agent 的下半场，是系统的较量

大模型会继续疯狂变强，上下文窗口会被彻底打爆，具身智能和多模态 API 将如潮水般涌来。

但当潮水褪去，真正的工业级瓶颈绝不仅是模型够不够聪明。决定胜负的标尺将变为：
系统能否在极度混乱的外部环境中长期维持内部状态？能否依靠机制截杀错误操作的提交？能否留下可解释的审计轨迹，并在雪崩发生后优雅地回滚恢复？

模型负责无限生成可能性，Harness 负责提供物理的约束环境，而 State-Aware Runtime 负责维护状态的一致性、审计过程的忠实、阻止灾难的提交。

Agent 竞逐的下半场，谁能率先把这些高能力但不稳定的模型，安全地装配进一套可审计、可恢复的状态机系统中，谁才能拥有下一代智能操作系统的真正的护城河。

**一起“**点****赞”三连↓

---

Original 陈希伟 Datawhale

---

内容效果不满意？点此反馈