让Agent每次读10个文件分批处理，前5批完美，第6批开始随机跳过、第7批试图一口气读完剩下几十个——长任务中Agent为什么会在缺少约束时“自作主张”？

目录

一、导语：一个可复现的失效现场

设想一个并不复杂的批处理任务：目录下有约120个文本文件，要求Agent每批读取10个，逐批总结并记录已处理清单，直到全部完成。前5批（共50个文件）执行得近乎完美：读取、摘要、登记、进入下一批，节奏稳定。第6批开始，输出里出现了“跳过”的痕迹——某些文件既没有被读取，也没有被记录，却直接进入了下一批。到第7批，Agent突然改变策略，试图一次性把剩余几十个文件全部读入上下文，结果要么触发上下文长度限制，要么在超长输入中丢失细节，最终产出一份覆盖面残缺的总结。

这个现场之所以值得严肃对待，是因为它具备三个特征：可复现、有明确的分界点（第5批到第6批之间）、且失效模式具有“策略突变”性质，而非简单的随机错误。它提示我们，问题可能不在单个步骤的能力，而在跨步骤的状态维持机制。换言之，Agent在第6批之后“忘记了自己正在做什么、做到哪里、还剩多少”，于是用局部看起来合理、全局却有害的方式“自作主张”。

笔者认为，把这一现象归因为“模型不听话”是廉价的，也是不科学的。更可取的做法是把它当作一个系统失效来拆解：任务状态在何处丢失？丢失后模型依据什么做决策？为什么失效恰好在第6批附近集中出现？本文的主线正是围绕“任务状态外部化”展开——凡是模型无法可靠内隐维持的东西，都必须外显为可读、可校验、可回滚的结构化状态。

二、背景与问题定义：长任务Agent的“状态失锚”

2.1 什么是长任务与任务状态

在本文语境中，“长任务”指需要多轮工具调用、跨越较长上下文、且完成条件依赖对历史步骤的持续追踪的任务。与之相对，单轮问答或单次工具调用不构成长任务。任务状态（task state）则指描述“目标是什么、已完成什么、剩余什么、下一步做什么、有哪些约束”的结构化信息集合。它至少包含四个维度：目标状态、进度状态、约束状态与环境状态。

关键区分在于：任务状态可以内隐地存在于模型的上下文与注意力之中，也可以外显地存在于文件、变量、清单或数据库里。前者依赖模型自身的记忆与推理，后者依赖外部系统的持久化。长任务失效的根源，往往就是过度依赖前者而忽视了后者。

2.2 现象的可复现性边界

需要强调，本文描述的现象并非某个特定模型的专属缺陷，而是一类在多种主流大模型Agent框架中都能观察到的模式。其可复现性受若干边界条件影响：批次大小、单文件长度、上下文窗口占用率、是否显式要求“先登记再继续”、是否存在外部进度文件、以及是否在每批结束时做一致性校验。这些条件恰恰构成了后文工程协议的设计变量。

本文评述：把“第6批”当作一个固定阈值是危险的。它更像是一个由上下文占用、指令衰减与策略切换共同决定的“相变点”，会随任务规模与提示结构漂移。工程上不应追求精确预测该点，而应设计让该点不再致命的机制。

2.3 问题定义：自主性越界

本文将“自主性越界”定义为：Agent在未被授权的情况下，自行改变任务执行策略（如合并批次、跳过步骤、提前终止），且该改变未被显式记录或校验。它与“合理的自主决策”的区别在于是否可追溯、是否在约束范围内、是否可回滚。第7批“一口气读完”正是典型的自主性越界：它用一次高风险的大动作替代了多次低风险的规范动作。

三、机制剖析：目标漂移、记忆衰减与自主性越界

3.1 目标漂移：从“逐批处理”到“尽快收尾”

长任务中，初始指令“每批10个”在上下文中会随着轮次增加而被稀释。模型在每一轮都要重新“回忆”这条约束，而回忆的可靠性随距离衰减。当剩余文件数量显得庞大时，模型容易把局部目标从“规范地逐批处理”替换为“尽快完成任务”，这是一种目标漂移。漂移不是随机噪声，而是优化压力下的系统性偏移：模型倾向于选择看起来能更快达成终态的路径。

笔者认为，目标漂移的本质是“终态奖励”与“过程约束”之间的张力。若提示中只强调“完成全部文件”，而不同时强调“必须逐批且每批登记”，模型就有动机用更少的步骤逼近终态。约束必须与目标同等显式，才可能被同等对待。

3.2 工作记忆衰减：上下文不是硬盘

把上下文窗口当作工作记忆是常见误解。上下文是有限的、会被后续内容挤压的、且模型对其中远距离信息的利用效率并不均匀。随着批次推进，早期的“已处理清单”被推到上下文远端，模型对其的读取可靠性下降。于是出现“跳过”——并非模型故意遗漏，而是它已无法可靠地判断哪些文件处理过、哪些没有。

这一机制可以用信息论视角粗略刻画：设第t批时，模型对初始约束的有效信息量为I(t)，则I(t)随t单调不增。当I(t)低于维持规范执行所需的阈值时，失效概率上升。该模型是定性的，但足以指导工程：与其祈祷I(t)衰减得慢，不如把关键状态搬到上下文之外，使I(t)不再承担记忆职责。

3.3 局部最优诱惑：合并批次的“看起来很美”

第7批“一口气读完”在模型看来可能是局部最优：一次调用覆盖剩余全部文件，步骤数最少。但它忽略了上下文长度限制与长输入下的细节丢失，属于用全局风险换取局部步骤节省。这类决策在缺少显式成本约束时尤其容易出现。

本文评述：要抑制这种诱惑，不能只靠“请不要合并批次”这类否定式指令，而应给出正向的、可执行的替代路径与明确的成本信号，例如“每批最多10个，超过则必须拆分为多次调用，并在账本中登记批次号”。否定式指令在长上下文中衰减更快，正向协议更耐久。

3.4 三者的耦合：为什么恰好在第6批附近爆发

目标漂移提供动机，记忆衰减削弱约束，局部最优提供看似合理的出口，三者叠加才导致策略突变。单独看，任何一项都不足以解释“前5批完美、之后崩坏”的陡峭曲线；合起来看，它就是一个典型的相变：当约束信息量跌破阈值，系统从规范执行态跃迁到自主越界态。

四、工程路径：任务状态外部化的协议设计

4.1 核心原则：状态外显、步骤原子、校验前置

任务状态外部化的核心原则有三条：其一，状态外显——把目标、进度、约束写入外部文件或变量，每轮读取而非依赖回忆；其二，步骤原子——每批处理是一个不可再分的原子步骤，禁止在单步内合并多批；其三，校验前置——在进入下一批之前校验本批完整性，不通过则回滚重做。

这三条原则并非本文首创，分布式系统中的幂等、事务与检查点思想早已有之。本文评述：把分布式系统的成熟范式迁移到Agent长任务，是当前最务实的方向；但迁移时必须注意差异——Agent的“事务”边界由自然语言与工具调用共同界定，比数据库事务更模糊，因此校验必须显式化、可机器判定。

4.2 进度账本：一个最小可用的数据结构

进度账本（progress ledger）是外部化的核心载体。它至少应记录：批次号、本批文件列表、每文件处理状态、校验结果、时间戳。下面给出一个最小示例（JSON）：

{
  "task_id": "batch-summarize-120",
  "batch_size": 10,
  "total_files": 120,
  "batches": [
    {"batch": 6, "files": ["f051.txt", "..."], "status": "pending",
     "checksum": null, "verified": false}
  ],
  "cursor": 50,
  "constraints": ["每批最多10个", "先登记后继续", "校验不通过则回滚"]
}

关键在于：每轮开始时，Agent必须先读取账本、确认cursor与约束，再执行本批。这样，约束与进度不再依赖上下文记忆，而依赖一次确定性的文件读取。

4.3 分批协议：把“每批10个”写成可执行状态机

仅用自然语言说“每批10个”是不够的，应把它写成状态机：读取账本→取cursor开始的10个→逐个处理并写回状态→校验本批数量与状态→更新cursor→若未完成则循环。状态机的每个转移都有明确的前置条件与后置条件，模型只需按转移执行，无需自行规划。

可参考的工程教程与视频资源包括：LangGraph官方文档中关于持久化与检查点的章节（https://langchain-ai.github.io/langgraph/）、OpenAI Cookbook中关于工具调用与多步任务的示例（https://cookbook.openai.com/），以及Anthropic关于构建有效Agent的工程博客（https://www.anthropic.com/engineering）。这些资源提供了检查点、重试与工具编排的实操范式。

4.4 校验闸门与失败回滚

校验闸门是防止“跳过”扩散的关键。每批结束后，用确定性代码（而非模型自评）校验：本批文件数是否等于预期、每个文件是否都有状态、是否有重复或遗漏。校验不通过则回滚到上一检查点，重做本批。回滚的成本远低于带着遗漏继续推进的成本。

笔者认为，校验必须由外部程序完成，不能交给模型“自查”。模型自查存在确认偏差，容易把“我以为处理了”当作“已处理”。外部校验把主观判断变成客观事实，这是状态外部化的最后一道防线。

4.5 提示结构：把约束放在“每轮必读”的位置

即便有了账本，提示结构仍需配合。建议把约束与协议放在系统提示的固定段落，并在每轮用户消息开头重复一次“先读账本、再执行、后校验”。这不是啰嗦，而是对抗上下文远端信息衰减的低成本手段。重复的位置比重复的次数更重要：放在每轮开头，等于把约束重新拉回注意力近端。

五、关键数据与案例：从现象到可验证指标

5.1 可观测指标的定义

要把“自作主张”变成可度量的问题，需定义指标：批次完整率（本批实际处理文件数/预期数）、跳过率（未处理却被标记为完成的比例）、策略突变率（批次大小偏离协议的比例）、回滚率（校验失败触发回滚的比例）。这些指标均可由账本与校验日志自动计算。

5.2 一个模拟数据的对照说明

为说明协议效果，本文构造一组模拟数据（非真实实验，仅用于演示指标关系）：在无外部账本的条件下，批次完整率随批次号上升而下降，第6批后下降加速；在引入账本与校验闸门后，完整率维持在接近1的水平，代价是每批多一次文件读写与校验调用。该模拟数据仅用于说明机制方向，不构成实证结论，真实效果需以具体框架与模型上的实测为准。

本文评述：模拟数据的价值在于把定性机制转成可讨论的量化关系，但绝不能被当作证据。工程团队应在自己的任务分布上采集真实指标，再决定协议参数（批次大小、校验频率、回滚粒度）。

5.3 案例拆解：第7批“一口气读完”的成本

以剩余60个文件为例，一次性读入意味着上下文需要容纳约6倍于单批的输入。在长输入下，模型对首尾信息的利用通常优于中段，导致中段文件被“读过但没记住”。表面上完成了，实际上覆盖面残缺。相比之下，6次规范批次虽然调用次数多，但每次输入短、校验清晰，总体可靠性更高。这是典型的“步骤数换可靠性”的权衡。

六、对比与局限：约束的代价与边界条件

6.1 约束不是免费的

外部账本与校验闸门会增加调用次数、文件读写与延迟。对于短任务，这些开销可能超过收益。因此约束设计应遵循“按任务长度分级”：短任务用轻量提示，长任务才启用完整协议。约束的粒度也应可调，批次大小、校验频率、回滚粒度都是参数。

6.2 边界条件：何时该允许“合并批次”

并非所有合并都是越界。当剩余文件总长度远小于上下文预算、且任务对细节精度要求不高时，合并批次可能是合理的效率优化。关键在于：合并必须是显式授权的、有记录的、可回滚的，而不是模型在无约束下的即兴决定。授权式合并与越界式合并的区别，正是制度与自觉的区别。

6.3 与现有研究的对照

围绕长任务Agent的可靠性，近年研究集中在几个方向：一是长上下文中的信息利用与“迷失在中间”现象；二是工具调用与多步规划的可验证性；三是记忆机制与外部存储的引入；四是Agent评测基准的构建。本文不逐篇复述，而是指出一个共同缺口：多数工作关注“单步能力”或“端到端成功率”，对“跨步骤状态维持”的显式建模仍不充分。本文评述：状态外部化应成为长任务Agent设计的一等公民，而非事后补丁。

可延伸阅读的公开资源包括：ReAct与Reflexion等经典工作的原始论文页面、AgentBench与WebArena等评测基准的官方仓库，以及各大模型厂商关于工具调用与结构化输出的文档。这些资源有助于读者把本文协议落到具体框架。

七、结论与展望：把“自觉”变成“制度”

回到开头的现场：前5批完美、第6批跳过、第7批试图一口气读完。本文给出的解释是任务状态失锚下的系统性失效，给出的路径是任务状态外部化——账本、状态机、校验闸门与回滚。其核心思想可以概括为一句话：不要要求Agent“自觉”记住约束，而要用制度让它“不得不”遵守约束。

展望未来，长任务Agent的可靠性提升大概率沿着三条线推进：更结构化的外部状态与检查点原语、更可验证的中间步骤校验、以及把约束编译进工具与运行时而非仅写在提示里。笔者认为，谁先把“状态外部化”做成框架级能力，谁就更可能让Agent在长任务中既保持自主性又不越界。

对工程团队的可操作建议是：先用账本与校验闸门把失效“看见”，再用指标把改进“量出来”，最后按任务长度分级启用协议。这套路径不依赖特定模型，也不要求重写业务逻辑，是当前性价比较高的起点。

八、主要参考文献