← 返回 2026-08-06

OneDayAgent:面向自主智能体的长时程执行框架 OneDayAgent: Towards a Long-Horizon Harness for Autonomous Agents

Jingsheng Zheng, Xinyuan Fang, Jintian Zhang, Zhengke Gui, Huajun Chen, Ningyu Zhang 📅 2026-08-04 👍 34 2026-08-11 18:30
AgentIF-OneDay LLM Agent 任务分解 执行记忆 跨后端迁移 长时程任务 验证与修复

通过任务分解、执行记忆与验证修复,构建可跨后端迁移的长时程智能体框架

前置知识

ReAct(推理-行动交织范式)

ReAct 让大模型在执行时把『思考(Thought)』和『行动(Action)』交错进行:模型先推理下一步该做什么,再调用工具,工具返回观察(Observation)后又进入下一轮思考。它把纯文本生成变成了接地到环境的决策循环。

OneDayAgent 的每个子任务都在 ReAct 循环里执行,理解 ReAct 才能明白为什么单条 ReAct 轨迹在数小时的长时程任务里会因上下文累积和目标漂移而崩溃,也才能理解作者为何要在循环外面包一层 harness。

AgentIF-OneDay 基准

一个任务级指令遵循基准,含 104 个日常任务、767 个实例级打分点,覆盖 Work/Life/Study 三类场景,要求 agent 处理附件、多模态证据并产出具体交付物。任务分三类交互模式:OWE(显式多步流程)、LII(隐式规则推断)、IR(迭代精修已有产物),用二元 rubric 加奖惩再归一到 [0,1]。

论文的全部主结果、消融、行为分析和后端分析都建立在这个基准上,不懂它的任务类型划分和打分方式就无法读懂所有表格里的数字。

上下文窗口与上下文溢出

上下文窗口(context window)是模型一次能处理的最大 token 数,OneDayAgent 设为 128K。长时程 agent 的多步交互轨迹会不断膨胀,超过窗口就会出现上下文累积/溢出(context accumulation/overflow),导致早期信息被挤出、模型无法继续推理。

执行记忆(Execution Memory)这一核心能力整层都是为应对上下文压力设计的,包括 0.9× 阈值的自动压缩和 0.95× 的紧急裁剪,是理解方法动机的关键。

LLM-as-judge 评估

用一个强 LLM 充当裁判,按预设 rubric 给 agent 的产出打分,而非依赖人工或固定脚本。本文用 Gemini 系列做判官,并发现新旧判官版本对同一 run 打分能差 3.12 个百分点。

所有得分都来自 LLM-as-judge,判官选择和严格程度直接影响结论;作者专门讨论判官替换带来的保守偏差,这是评估可信度的核心环节。

研究动机

随着大语言模型越来越多地承担工作、学习、生活三类开放式日常任务,单条指令往往需要同时跨越网页检索、本地文件编辑、代码执行和多媒体处理等多个环境,并最终产出一个具体交付物(如一份 PPT 或报告)。这类任务具有三个本质特征:长时程(horizon 从分钟延伸到数小时甚至超过 24 小时)、跨环境(在网页、本地文件、代码、外部服务之间切换)、多模态(输入和证据可能是文本、文档、图像、表格)。三者叠加带来三类执行失败:目标漂移(goal drift,agent 执行到后期忘记了早期约束,比如先在网页查资料、后改本地交付物时丢掉了最初的格式要求)、上下文累积(context accumulation,多步交互轨迹不断膨胀直到超出可用上下文预算)、状态丢失(state loss,切换环境时先前子任务搜到的证据没能传递过来)。现有方法通常只针对单一失效模式——推理支架、基于反馈的修正、记忆管理——但这些失效会相互耦合、叠加放大,孤立修复其中一类并不足够。

本文的目标是本文的目标是设计一个通用的长时程执行框架(harness),把开放式请求转化为受管的执行过程:在统一动作空间下同时管理任务分解、执行记忆和最终交付物验证三类能力,使 agent 能在数小时级时程内保持目标与约束、在异构环境间传递状态、并在上下文压力下不崩溃。进一步地,作者希望这个框架不绑定特定后端模型——同一套 harness 无需针对后端做专门调优,即可稳定地跑在来自不同家族、不同厂商、不同规模的 LLM 上,并能与通用 agent(如 Manus、ChatGPT-Agent、Codex、AutoClaw)在任务级指令遵循基准 AgentIF-OneDay 上正面比较,争取新的 SOTA。

与已有工作不同的是,已有长时程 agent 研究切入角度较为分散:规划方向用搜索式推理支架或层次化分解,记忆方向用上下文折叠、agent 记忆刻画、记忆增强结构,验证方向关注失败诊断与修复建议。然而很少有人在同一框架内联合处理分解、记忆与验证,更少有工作把 harness 当成一个可跨后端迁移的独立层来系统研究。最接近的 InfiAgent 通过文件中心化的状态外置来严格限制推理上下文,但既不做任务分解也不验证最终交付物。OneDayAgent 的独特切入正是把 harness 视为可迁移的执行层,同时回答『单个框架能否联合管理这三类失效』和『跨后端迁移是否是无声的』这两个尚未被系统研究的问题。

核心方法

OneDayAgent 的整体直觉是:与其让一条不间断的 ReAct 轨迹硬扛整个长时程任务,不如在执行循环里显式插入分解、记忆和验证阶段。具体技术路线是一条简单执行路径:用户请求连同附件进入 Planner,被分解为最多 6 个有顺序的子任务,原始请求被保留为全局意图;每个子任务在共享的 ReAct 循环里执行,后端 LLM 对当前子任务推理、调用统一工具、观察环境反馈并更新工作状态,中间发现和产物写入执行记忆与工作区;全部子任务完成后,Synthesizer 把累积的状态和产物合成候选最终交付物;接着 Verifier 对照原始请求、执行轨迹和实际产物做一次全局校验,若发现缺失或不一致就进入靶向修复循环,修复后重新评估,验证因此成为任务级的最终守卫而非被动打分。整个流程始终在统一动作空间(网页、学术搜索、计算、文件、多模态)上运作。

核心创新在于把三类失效当成『同一个执行过程的不同切面』联合管理,而不是三个独立模块。第一,把任务分解的子任务边界同时用作上下文节省接口——后续子任务只继承任务级压缩状态而非完整 ReAct 轨迹。第二,把检查与修复当成紧密耦合的两个 artifact 级、任务全局阶段:Verifier 不是只看最终文本回复,而是对照原始请求、子任务答案和实际生成的文件来判断,发现缺陷后由靶向修复只改缺失或不一致的部分而非重启所有子任务。第三,把执行记忆当作执行控制机制而非信息仓库:通过 summarized truncation、subtask state passing 和 automatic context compression 三层,让记忆在上下文压力下既能继续推进又不会成为瓶颈。这与单条 ReAct 轨迹、或仅做记忆外置的方案有本质区别。

方法步骤详情

完整步骤为:(1) Planner 接收任务+附件,输出 1 到 6 个有序子任务的 JSON,子任务串行执行。(2) Executor 对每个子任务进入 ReAct 循环(最多 200 次迭代,温度 $1.0$、top-$p=0.95$),子任务之间用『答案+结果文件句柄』作紧凑 checkpoint,失败重试 3 次。(3) 工具层把网页 search/visit、学术搜索、python_interpreter/execute_command、文件读写编辑、analyze_image/generate_image 统一成同一动作空间,长输出/长消息超阈值时做有界摘要。(4) Synthesizer 把子任务结果合成候选交付物。(5) Verifier 重点看实际生成文件而非 agent 自述,输出 completed/reason/missing_items 的 JSON。(6) 未通过则进入靶向修复(最多 3 次),修复后重新验证。上下文累积到 $0.9\times$ 预算触发 LLM 摘要压缩,到 $0.95\times$ 触发紧急裁剪。

技术新颖性

技术新颖性有三点。其一,验证-修复闭环是 artifact 级且任务全局的:不同于 Reflexion/Self-Refine 主要修订文本回复,OneDayAgent 的 Verifier 把实际生成的文件、截图、附件作为首要证据,把验证当成交付风险的『可观测+可恢复』机制——104 任务里 95 个首次通过、9 个进入修复、6 个被救回。其二,记忆三层结构(summarized truncation / subtask state passing / automatic context compression,$0.9\times$ 阈值与 $0.95\times$ 紧急裁剪)是执行控制而非被动存储,且在 35/104 任务触发压缩、最高约 350K token 时,压缩次数与得分相关性 $r=-0.034\approx 0$,未明显伤质量。其三,首次把 harness 当成可迁移层系统量化:同一套 harness 跑 5 后端、3 家族,揭示了『跨后端迁移并非无声』,区分了 harness 的可迁移性与后端诱导的执行风格差异。

Overview of OneDayAgent
Figure 2: Overview of OneDayAgent
Case study of a PPT-editing task
Figure 5: Case study of a PPT-editing task

实验结果

核心发现分四块。(1) 主结果:GLM-5.2 在 104 任务上取得 0.821 总体分刷新 SOTA,超过 AutoClaw 0.799、Codex 0.664、Manus 0.645、Genspark 0.635、ChatGPT-Agent 0.626 等,且在 OWE/LII/IR、Work/Life/Study、指令/事实/逻辑、有无附件各维度全面领先,提升是广谱的。(2) 消融:以 DIRECT(0.771) 为基线,单开分解得 0.804、单开验证得 0.804,同开得 0.821;单独增益(各+3.3pp)之和大于联合增益(+5.0pp),说明部分覆盖相同失效;执行记忆恒开,因关掉会上下文溢出。(3) 行为:多数任务被分为 2-4 子任务,5 子任务任务平均 117.2 分钟/156 次工具调用,1 子任务任务仅 20.6 分钟/17 次;验证-修复集中在 IR、study 域、长时程任务。(4) 后端:5 后端得分 0.613-0.821,呈弱参数规模趋势而非严格 scaling law(Qwen3.6-27B 0.613 未超 Qwen3.5-9B 0.624)。

Tool and environment interface in OneDayAgent
Table 1: Tool and environment interface in OneDayAgent
Main Results on AgentIF-OneDay
Table 2: Main Results on AgentIF-OneDay
Ablation results for decomposition and verification modules
Table 3: Ablation results for decomposition and verification modules
Backend coverage and performance under the same OneDayAgent harness
Table 4: Backend coverage and performance under the same OneDayAgent harness
OneDayAgent harness configuration
Table 6: OneDayAgent harness configuration
Execution behavior of OneDayAgent
Figure 3: Execution behavior of OneDayAgent
Backend scaling and execution-style interaction
Figure 4: Backend scaling and execution-style interaction
查看结构化数据
任务指标本文基线提升
AgentIF-OneDay 总体任务级指令遵循 Overall Score [0,1] 0.821 (GLM-5.2 后端) AutoClaw 0.799(最强基线);Manus 0.645、Codex(GPT-5.5 medium) 0.664 较最强基线 AutoClaw +2.2 个百分点,刷新 SOTA,且全面领先各维度
Open Workflow Execution (OWE) 显式多步流程 OWE Score [0,1] 0.818 Codex 0.682 / Manus 0.661 较 Codex +13.6 个百分点,长流程约束保持能力最强
Latent Instruction Inference (LII) 隐式规则推断 LII Score [0,1] 0.821 Genspark 0.719 +10.2 个百分点,隐式规则迁移能力显著领先
Iterative Refinement (IR) 迭代精修 IR Score [0,1] 0.829 ChatGPT-Agent 0.689 +14.0 个百分点,也是修复触发最集中的任务类型
Factuality 事实性 rubric Factuality Score [0,1] 0.835 Manus 0.731 +10.4 个百分点,体现接地检索与交付物核验的价值
跨后端迁移稳健性 5 后端 Overall 得分范围 0.613 (Qwen3.6-27B) ~ 0.821 (GLM-5.2) 同一未改动 harness 跨 GLM/Gemini/Qwen 三家族、5 后端,全部 104/104 任务成功完成

局限与改进

作者明确承认的局限有三。第一,所有结论只在 AgentIF-OneDay 单一基准上验证,向其他长时程/跨环境基准(如 LifeSim、AgencyBench、OdysseyArena)的泛化需要后续验证。第二,当前实现没有工作区隔离,直接在宿主机上跑,存在三类安全风险:不可信网页/文档的提示注入、execute_command 工具无白名单可执行任意 shell、压缩后注入指令可能跨子任务传播到验证与修复阶段。第三,评估用的 Gemini-3-Pro-Preview 判官已不可用,改用更严格的 Gemini-3.1-Pro-Preview(同一 run 偏低 3.12 个百分点),虽使结果偏保守,但判官替换本身引入不确定性。我额外观察到:FULL 虽得分最高但 score-per-latency 最低(1.53),且在 17 个任务上反而不如纯 VERIFY,说明 always-on 配置并非全局最优;上下文压缩与得分的因果关系也未做因果隔离,仅给出相关性 $r=-0.034$。

独立分析的弱点

独立分析的弱点及改进方向:(1) 成本-收益不对称——FULL 比纯 VERIFY 仅高约 1.7 个百分点,但延迟从 29.7 分钟涨到 53.6 分钟、工具调用从 29.3 涨到 51.6,改进方向是引入自适应策略:先用低成本 VERIFY,仅在风险信号(长时程/IR 任务)出现时再启用分解。(2) 安全性零隔离——建议加容器化工作区(文件系统与网络限制)、命令白名单、压缩感知的注入过滤。(3) 压缩机制只验证了相关性未验证因果——建议做对照实验直接禁用压缩看质量是否真下降,厘清压缩到底损耗多少信息。(4) 后端差异未被显式利用——既然 GLM 高成本高产出、Gemini 精简(21.4 分钟/18.7 工具调用)、Qwen3.6-27B 修复率 56.7% 最高,可做后端感知的 harness 配置或多后端协作。(5) 修复召回不完美(9 个进入修复只救回 6 个),可增强修复阶段的工具与失败诊断能力。

未来方向

作者提出的方向:在更多长时程/跨环境基准上验证泛化,加入工作区隔离等安全机制,对上下文压缩做因果隔离实验。基于成果可延伸的方向:(1) 把 harness 从串行子任务扩展为支持依赖并行/条件分支的 DAG 执行,进一步压缩长任务墙钟时间;(2) 把后端执行风格(延迟、工具量、修复率)做成可观测信号,实现后端感知的自适应配置,甚至用精简后端做规划、用强力后端做难子任务的多后端协作;(3) 把验证-修复闭环从最终交付物推广到每个子任务边界,做分层验证以更早捕获失败;(4) 研究 scaling law 失效的原因,区分是后端工具调用习惯、训练数据还是推理稳定性导致;(5) 探索记忆压缩的损伤量化与可证明的保真度界。

复现评估

复现评估较好。作者已开源 harness 代码(github.com/zjunlp/OneDayAgent)和完整轨迹数据集(HuggingFace zjunlp/onedayagent_traj),附录给出完整配置(200 次 ReAct、7200 秒超时、128K 上下文、最多 6 子任务、$0.9\times$ 压缩阈值、$0.95\times$ 紧急裁剪、温度 $1.0$、top-$p=0.95$、摘要上限 8000 字符)和系统提示词,工具接口、压缩阈值都公开。但复现成本高:仅 GLM-5.2 主 run 就调用后端 LLM 约 9000 次、输入 292.4M token、输出 10.7M token,还依赖 DeepSeek-V4-Pro(摘要)、Qwen3-VL-235B(视觉)、Qwen-Image-2512(生图) 等多个付费服务,单任务平均 86.5 次 LLM 调用。主要障碍是后端模型多需商业 API 且部分未公开权重,判官模型在评测期还可能下线。整体属可复现但需可观算力与 API 预算。