背景知识

在深入解读 OneDayAgent 之前，先厘清几个核心概念。

什么是长时程（Long-Horizon）任务？ 长时程任务指需要多步推理和行动、跨越较长时间（从几分钟到数小时）的开放式请求，例如“调研一个主题并生成一份带图表的报告”。这类任务要求智能体在大量步骤中保持目标和约束的一致性，同时处理跨环境（网页、本地文件、代码执行等）和多模态（文本、图像、表格等）输入。

什么是智能体（Agent）的“目标漂移”和“状态丢失”？ 目标漂移指智能体在执行过程中逐步遗忘原始指令中的约束（如“不要修改第三页”），最终输出偏离用户意图。状态丢失指中间结果（如搜索到的证据）在跨环境切换或上下文积累时未能正确传递，导致后续步骤无法复用已有成果。

什么是 Harness（框架/套件）？ Harness 指支撑智能体执行的管理层，负责任务分解、内存管理、工具调用编排和结果验证，而不是智能体本身。它提供结构化的执行流程，使后端大模型能够在可控的上下文中发挥能力。

什么是 AgentIF-OneDay 基准？ 一个专门评估长时程日常任务指令跟随的基准，包含 104 个真实场景任务，涵盖工作、学习和生活，要求智能体生成具体的交付物（如报告、幻灯片、表格）。评估指标为任务级综合得分（0~1），基于二元准则（加分/扣分）计算。

---

一、背景：为什么需要 OneDayAgent？

1.1 长时程日常任务的执行困境

随着大模型智能体从单轮问答扩展到软件工程、计算机操作、深度研究等复杂场景，用户需求逐渐转向跨工作、学习和生活的开放式日常任务。一个典型指令可能需要：收集网页证据、编辑本地文件、生成报告或幻灯片。与短任务不同，这些请求具有三个显著特征：

• 长时程（Long-Horizon）：智能体必须在大量推理和行动步骤中保持目标和约束。

• 跨环境（Cross-Environment）：任务往往需在网页、本地文件、代码执行、生成图片等环境间切换。

• 多模态（Multimodal）：输入可能包含文本、文档、图像、表格等多种附件。

这些特征共同导致三个执行失败模式：

1. 目标漂移：早期约束（如格式要求）在长轨迹中被遗忘。

2. 状态丢失：中间证据（如搜索结果）在切换环境时未能传递。

3. 上下文溢出：累积的交互历史超过模型上下文窗口，导致后续步骤无法进行。

1.2 现有方法的局限性

现有工作分别针对上述失败模式提出了解决方案，例如：

• 推理脚手架（如 ReAct、Tree of Thoughts）：增强推理深度，但无法防止目标漂移。

• 反馈式修正（如 Reflexion、Self-Refine）：通过事后反馈改进输出，但修复粒度粗、成本高。

• 记忆管理（如 RAG、摘要压缩）：缓解上下文压力，但缺乏对跨环境状态的显式传递。

然而，这些失败模式相互交织、叠加放大，单独修复某一项往往不够。例如，即使使用了摘要压缩，如果目标约束在分解时丢失，最终交付物仍不完整。因此需要一个统一的管理框架，将分解、记忆、验证协同起来。

OneDayAgent 的核心洞见是：长时程智能体不应依赖单次不间断的 ReAct 轨迹，而应通过显式的任务分解、可恢复的执行记忆和全局验证/修复，将开放式请求转化为可管理的执行流程。

---

二、核心创新：分解、验证与记忆三位一体的管理框架

OneDayAgent 的技术精髓可概括为：将开放式请求分解为有界子任务，通过执行记忆保持状态，最后用全局验证和针对性修复确保交付物对齐原始意图，整个过程对后端大模型无特殊要求。

2.1 任务分解（Task Decomposition）

设计动机：日常请求往往隐含多个子目标，单次执行容易过载。分解给大模型提供每次聚焦的局部目标，同时由框架保管全局意图。

实现方式：OneDayAgent 首先将原始请求解析为有序子任务列表（最多 6 个），每个子任务具有独立的描述和依赖关系。子任务之间串行执行，前一个子任务的输出（答案+生成的文件）作为后一个子任务的输入上下文。子任务边界同时也是“上下文保存接口”——后续子任务继承任务级状态，但不继承低层 ReAct 轨迹，从而避免上下文膨胀。

2.2 全局验证与针对性修复（Global Verification and Repair）

设计动机：完成所有子任务并不保证最终交付物满足原始需求。长时程执行仍可能遗漏隐性要求或产生局部合理但全局不完整的产物。

实现方式：合成阶段将所有子任务结果汇总为候选交付物。随后进入全局验证步骤：验证器（同样基于大模型）检查候选交付物是否满足原始请求的所有要求，同时考虑附件和中间产出。验证输出为完成/未完成 + 缺陷描述。

若验证失败，则进入针对性修复：框架根据验证器的缺陷描述，仅修正交付物中缺失或不一致的部分，而不是重启所有子任务。修复后可再次验证，形成闭环。实验显示 95/104 任务首次验证通过，修复可挽回约 6/9 的失败案例。

2.3 执行记忆（Execution Memory）

执行记忆由三层机制构成，以应对状态丢失和上下文压力：

• 摘要式截断（Summarized Truncation）：对高容量工具输出（如搜索返回、网页内容、文件读取）进行摘要压缩，只保留可复用的证据，避免对话历史被噪声淹没。

• 子任务状态传递（Subtask State Passing）：每个子任务的提交答案和生成的文件句柄作为紧凑检查点，使得后续子任务可以复用之前的文件、图像、搜索证据，而无需重放历史。

• 自动上下文压缩（Automatic Context Compression）：当累积轨迹超过上下文预算的 90% 时，触发大模型生成的历史摘要（保留系统提示、原始任务和最近 3 轮），接近硬限制时则启用确定性应急裁剪。这使得长时间执行始终保持在上下文窗口内。

2.4 统一工具与环境接口

OneDayAgent 将网页访问、学术搜索、计算、文件操作和多模态处理封装为统一的 ReAct 行动空间，智能体在同一共享的“观察-推理-行动”循环中调用这些工具。工具调用可产生或修改工作区中的文件、图像、代码输出等，这些工件在整个工作流中持久可用，供后续子任务、合成、验证和修复引用。

---

三、实验验证：在 AgentIF-OneDay 上刷新最佳成绩，跨五个后端模型稳定迁移

3.1 主实验结果

OneDayAgent 在 AgentIF-OneDay 的 104 个任务上，以 GLM-5.2（744B）为后端，取得整体得分 0.821，显著超越官方基线（包括 Gemini-3-Pro-Preview 等）和额外运行的 Codex（GPT-5.5 medium）。该领先优势覆盖所有任务类型、领域、评分维度和输入附件设置（见表 2）。

任务类型	OneDayAgent (GLM-5.2)	最佳基线 (Gemini-3-Pro)
开放式工作流执行 (OWE)	0.821	0.733
隐性指令推理 (LII)	0.799	0.682
迭代细化 (IR)	0.831	0.712
整体	0.821	0.722

3.2 消融实验：分解与验证的贡献

控制变量实验（表 3）显示：

• 仅启用分解，得分从 0.771（直接执行）提升至 0.804；仅启用验证，得分提升至 0.804。

• 两者同时启用，得分达到最高的 0.821。

• 成本差异显著：分解增加约 10.6 分钟延迟和 60% 工具调用，验证仅增加 2.2 分钟。因此，若追求最高分用全模块，若追求性价比可只用验证。

3.3 执行行为分析

• 分解深度：大部分任务被分解为 2~4 个子任务，只有 16/104 任务为单子任务。更深的分解对应更高的执行成本（工具调用和耗时），表明分解与任务复杂度正相关。

• 验证与修复：95/104 任务首次验证通过，9 个进入修复，其中 6 个被恢复，3 个仍失败。修复集中在更难的任务类型（IR）、领域（study）和长时间预算任务，表明验证/修复作为“交付风险机制”而非通用分数助推器。

• 上下文管理：35/104 任务触发了压缩，最高压力任务累计约 35 万 token。压缩次数与最终得分几乎无相关性（近零相关），说明上下文管理在保持任务质量方面有效。

3.4 后端模型迁移性

核心结论：OneDayAgent 作为一个不依赖特定后端的框架，在五个不同模型（GLM-5.2、Gemini-3.1-Pro、Qwen3.5-397B、Qwen3.6-27B、Qwen3.5-9B）上均能完整运行并取得非平凡分数（0.613~0.821）。模型规模呈大致趋势但不严格：Qwen3.6-27B 并未超过 Qwen3.5-9B，Gemini（疑似>1T）仅排第二。这表明智能体性能不仅取决于参数规模，还受执行风格影响（如工具调用次数、修复率、延迟等）。

3.5 典型案例：PPT 编辑任务

一个“花语”PPT 编辑任务展示了框架的价值：用户要求修订幻灯片内容、对比东西方解读、插入图片、删除一页、更新结论。OneDayAgent 分解为“研究”和“PPT修改”两个子任务。修改子任务因文件描述符错误失败，但合成阶段识别出失败，验证器发现缺失的 PPT 文件，修复阶段成功生成缺失的演示文稿，二次验证通过。

---

四、学术洞见：OneDayAgent 揭示了哪些深层规律？

洞见一：分解与验证是互补而非替代

分解和验证各自都能显著提升得分，但两者结合增益小于各自增益之和，说明它们覆盖了部分重叠的失败模式。分解通过结构化执行减少错误，验证则捕获遗漏并修复。对于成本敏感场景，验证单独使用已足够接近全模块效果，且成本极低。

洞见二：长时程智能体的“状态传递”比“记忆增强”更关键

许多现有工作强调“记忆机制”（如 RAG、摘要），但 OneDayAgent 的实验表明，子任务边界的状态显式传递（提交答案 + 文件句柄） 是防止状态丢失的关键。低层 ReAct 轨迹可以丢弃，但任务级成果必须保留。这启示我们：长时程系统的设计应聚焦于“可恢复的执行状态”，而非简单的信息缓存。

洞见三：验证/修复应当基于交付物内容，而非仅基于文本报告

OneDayAgent 的验证器直接检查生成的文件内容（如 Excel 表、幻灯片），而非仅依赖智能体的描述性总结。这使得验证更可靠，并能发现“报告声称完成但实际文件缺失”的典型失败。这种“检查实物”的设计可迁移到任何需要生成具体产出的场景。

洞见四：跨后端迁移可行，但执行风格差异显著

同一套框架在五个不同模型上都能运行并取得可用结果，说明框架本身并不与特定模型深度耦合。然而，不同模型在延迟、工具调用次数、修复率上差异巨大（例如 GLM-5.2 平均 53.6 分钟，而 Gemini 仅 21.4 分钟），这意味着后端选择不仅要看精度，还要考虑执行成本分布。框架设计应允许这些差异，而不试图强行标准化。

洞见五：长时程智能体的评估需要任务级指标，而非步骤级准确率

AgentIF-OneDay 使用任务完成度（交付物是否满足所有要求）作为评分，这与传统 QA 或步骤成功率的评估截然不同。OneDayAgent 的成功表明，面向最终交付物的优化（验证/修复）比提高每步正确率更有价值。这也解释了为何分解和验证对整体得分贡献大。

---

五、局限性与未来方向

论文坦诚讨论了以下局限：

1. 工作区隔离缺失：当前实现直接在宿主机上执行 shell 命令、读写文件，存在安全风险（如恶意网页注入指令）。未来应采用容器化隔离、命令白名单和输入过滤。

2. 基准覆盖面有限：仅在 AgentIF-OneDay 上评估，未在其他长时程基准（如 WebArena、OSWorld）上验证，泛化性需进一步测试。

3. 后端支持：虽然测试了五个模型，但均为闭源或大规模 API，未涉及开源小模型（如 7B 级）的适用性。

4. 多模态能力：虽然支持图像分析和生成，但未系统评估跨模态任务（如“根据图表生成报告”）的性能。

5. 成本与延迟：GLM-5.2 后端平均每任务耗时近 54 分钟，对实时交互不友好；优化策略（如缓存、并行）未探索。

6. 修复成功率：修复仅能挽回约 2/3 的首次失败任务，复杂错误仍需人工介入。

未来方向包括：

• 安全沙箱集成：与容器或虚拟机结合，实现安全的命令执行和文件访问。

• 自适应分解：根据任务复杂度和后端能力动态调整子任务数量和粒度。

• 多模态联合推理：在分解和验证阶段引入视觉语言模型，更好地处理图像/表格。

• 成本感知规划：在分解时预估各子任务的资源消耗，选择最低成本路径。

• 人机协同修复：对修复失败的任务，提供交互式界面让用户补充修正。

---

六、核心思想总结与可借鉴点

OneDayAgent 的核心思想可以用一句话概括：通过任务分解将长时程请求转化为有界子任务，使用执行记忆保持状态，并以全局验证和针对性修复确保最终交付物对齐原始意图，无需针对特定后端调整。这个原则背后，是四层可迁移的方法论：

• 结构化执行优于自由轨迹：显式的分解和状态管理比单次 ReAct 更适合长时程任务。

• 验证应基于实物而非汇报：检查生成的文件内容，而非智能体的文本总结，能更可靠地判断完成度。

• 修复是验证的自然延伸：验证失败后，应提供有针对性的修正机会，而不是全盘重来。

• 跨后端迁移是可行的：只要框架不绑定特定模型的内部机制，同一套管理流程可在多种模型上工作。

对研究者的借鉴：

1. 当设计长时程智能体时，优先考虑“交付物导向”的评估和优化，而非仅关注中间步骤准确率。

2. 记忆机制应区分“任务级状态”和“交互历史”，前者必须传递，后者可压缩。

3. 验证器可以复用与执行器同级别的大模型，但需要明确指示其检查文件内容而非文本描述。

对工程师的借鉴：

1. 如果你的系统需要处理跨环境、多步骤的用户请求，务必引入任务分解和验证修复闭环，即使只采用验证模块也能显著提升可靠性。

2. 为每个子任务设置明确的输入输出边界，这既有助于控制上下文，也有助于故障隔离。

3. 在实际部署中，安全隔离是不可妥协的，建议从一开始就规划沙箱环境。

4. 后端选择应综合考虑精度、延迟和调用成本，OneDayAgent 的跨后端数据表明，大模型并非唯一决定因素，框架设计同样关键。

---

OneDayAgent 通过将任务分解、执行记忆和验证修复有机结合，在 AgentIF-OneDay 基准上刷新了最佳成绩，并首次系统证明了长时程智能体框架可以在不同大模型后端之间稳定迁移。该方法为构建安全、可靠、可扩展的长时程自主智能体提供了从设计原则到工程实现的完整路径。