一篇Harness研究后的思考！

状态 Agent 模型 State AwareRuntime

发布于 2026-06-14

版权声明

我们非常重视原创文章，为尊重知识产权并避免潜在的版权问题，我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容，访问作者的公众号页面获取完整文章。

查看原文：一篇Harness研究后的思考！

文章来源：

Datawhale

扫码关注公众号

扫码阅读

手机扫码阅读

文章主旨：大语言模型Agent的可靠性不能仅依赖模型能力提升，必须转向以状态感知运行时（State-Aware Runtime）为核心的系统工程，通过状态管理、过程审计、门控拦截与失败恢复机制来构建可稳定运行的工业级Agent。

关键要点：

Agent崩溃的根源在于缺乏稳定的运行时结构，模型更强、上下文更长并不能解决系统级状态污染、任务主线遗忘、错误级联传播等问题。
Harness Engineering（如CMU/Yale综述）提供了组件地图，但仅解决静态组件构成，动态状态维护、审计、回滚是更关键的“运行时”问题。
State-Aware Runtime的核心在于：将每一步执行建模为可验证的状态转移，严格区分候选输出与已提交状态，实现状态回滚、失败隔离与轨迹原生评估。
长上下文不等于长期状态管理，上下文窗口扩大可能加剧设定被覆盖、推测固化等风险；真实的失败轨迹比成功Demo更有价值。
独立研究者可聚焦系统失败分析、状态漂移、Validator/Rollback实验及Agent崩溃分类学，不依赖大规模计算资源。

内容结构：

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

CMU/Yale发表的Agent Harness Engineering综述标志着共识转移：大模型Agent的可靠性不能仅盯着模型本身。过去业界依赖线性外推（参数更大、上下文更长、工具更多），但这些判断单薄。

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

实际运行中Agent崩溃往往不是模型推理能力丧失，而是系统缺少稳定运行时结构，表现为：遗忘任务主线、将幻觉写入记忆、调用工具后未更新世界状态、沿错误因果链自信狂奔。这种系统级雪崩无法通过换大模型或加上下文窗口解决。工业级Agent应是模型、状态机、记忆流、执行沙箱、验证器、监控追踪和恢复策略构成的复杂操作系统。

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

Harness Engineering解决静态问题（外围系统组件构成），但作者探索的动态问题更致命：组件如何共同维护长期稳定、可审计、可回滚、可恢复的运行状态？作者将方向定义为State-Aware Runtime（状态感知运行时）。

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

State-Aware Runtime不是简单加memory或长上下文，而是把每一步执行建模为可验证的状态转移。Anthropic和OpenAI的演进也在做类似事：将模型塞进可控工程脚手架。具体子要点：

1. 状态维护：核心是高频状态转移，系统必须知道当前状态、哪些动作已提交、哪些状态可回滚。最可怕的是模型输出错误答案，而是系统不知道当前状态。
2. 长上下文不等于长期状态管理：简单塞入历史对话会引发设定被覆盖、推测固化、摘要篡改初衷。Context Engineering在问“怎么送信息进Prompt”，State-Aware Runtime问“当前状态是什么、谁有权改、如何隔离恢复”。
3. 真正危险的是错误状态被提交：Agent失败具有级联传播特性。误判如停留在候选文本可重试，若写入长期记忆则后续规划崩溃；危险API调用若被拦截安全，若已改变外部状态则造成物理影响。核心设计是建立候选输出与已提交状态的严格边界防御。
4. 判断可靠性不能只看成功Demo：真实失败轨迹比成功Demo更有价值。需深入解剖Trace，定位崩溃位置（状态投影缺失、工具链断裂、模型无视规范等）。作者推崇Trace-Native Evaluation（轨迹原生评估），不仅问结果如何，还要问中间状态有无污染、能否精准定位并恢复。

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

作者从多个侧面（规范推理中的procedural fidelity、长篇叙事Agent中的epistemic memory、多Agent社会交互、结构化生成、游戏Agent Runtime）观察到同一矛盾：LLM生成能力强但缺少稳定状态边界、过程约束和失败恢复机制。独立研究者可深耕State-Aware Runtime，拼的不是GPU阵列，而是对系统失败的敏感与耐心，研究失败轨迹、状态漂移、Validator/Rollback实验、Agent崩溃分类学。大厂聚焦让模型做对事，独立研究者可研究当系统注定做错时如何保证不毁掉一切。