这篇只谈一件事单上下文 Agent 为什么会在规模任务上失败。后两篇再写动态 workflow 把什么搬进代码以及六种组织形状怎么选。失败机制先看清后面的设计才不会落成功能清单。很多人调 Agent先加提示词「不要遗漏」「逐项处理」「做完再总结」。短任务里这些话通常够用。改个函数、查个报错、写段说明模型在同一段对话里边看边做往往比任何复杂编排都快。规模上去就麻烦了。审查几百个路由、迁移一批组件、核对长报告里每条技术声明、同时推进几个互斥的根因假设——这时候翻车多半不是模型突然变笨而是它被迫在同一个上下文窗口里同时背计划、背进度、背一堆中间材料。Anthropic 讲 Claude Code Dynamic Workflows 时说得很直白默认 harness 让模型在同一上下文里既规划又执行普通编码没问题一旦进入长时间、大规模并行、强结构或对抗性任务几类失败就会反复出现。LangChain 谈 Dynamic Subagents动机也差不多规模下做不完上下文也管不住。这篇只谈一件事单上下文 Agent 为什么会在规模任务上失败。后两篇再写动态 workflow 把什么搬进代码以及六种组织形状怎么选。失败机制先看清后面的设计才不会落成功能清单。单上下文会话里计划、状态、证据和日志挤在一起旁边标出漏项、自证偏差、目标漂移、上下文污染单上下文到底在硬扛什么单上下文不是「只能开一个 Agent」。更准确的说法是计划、状态、证据和局部推理都挤在同一条对话轨迹里。模型每轮都要重读越来越长的历史再决定下一步。像一个很能干的人被迫一边开会一边记账一边改文档还得保证账本不丢、议程不跑偏。短会还行开到第三小时漏项和跑题几乎是结构结果不是态度问题。规模任务通常会撞上这些情况。对象一多覆盖就不能靠感觉宣布得说清一共多少、做了多少、漏了多少。阶段一长发现、验证、修复、回归不再是一句话而要跨很多轮次守住同一套规则。中间产物也厚搜索片段、日志、候选方案、失败尝试、被淘汰的假设都会来抢主判断的注意力。单上下文擅长局部判断不擅长长期记账。很多人硬把记账也塞给模型规模一上来就开始按概率漏项、自证、跑偏。失败一看起来完成了其实只做了一部分Anthropic 管这叫 agentic laziness复杂多段任务做到一半模型就宣布结束。安全审查要看 50 项它认真处理了 35 项却交出一份读起来很完整的报告。不是模型不懂「请全部处理」。普通工具调用里覆盖范围靠它自己记。哪些文件看过、哪些跳过、哪些失败要重试全堆在上下文里。上下文越长「我处理了很多」就越容易滑成「我处理完了」。举个更具体的过程。你让 Agent 审查src/routes/下所有鉴权缺口。前二十个文件它很认真边读边记报告片段也漂亮。到第四十个文件时上下文里已经堆满早期发现、代码片段、临时结论。它开始更爱做摘要式推进挑「看起来重要」的继续看把「看起来像重复」的略过。最后产出一份结构整齐的总结读者却没法从报告本身核对——目录里到底有多少路由哪些被打开过哪些只扫了文件名哪些超时失败后再也没回来完整语气还会掩盖未完成。一份带分级、带建议、带「优先修复」的报告读起来像完工证明。可如果缺少覆盖账本那只是文风不是证据。这类失败通常不是智力不够是覆盖还停在口头承诺没落成结构。这也解释了为什么「再强调一遍不要遗漏」常常没用。提示词提高的是顺从意图不是记账能力。你可以说「全部」账本却必须回答「全部等于多少」。这是两件事。失败二自己发现的问题自己验证时容易放水第二类叫 self-preferential bias模型偏爱自己的发现。先让它提风险再让它在同一上下文里验证结果往往不稳。为了前后一致它可能倾向确认假设已经写在上下文里也更容易被带偏。单上下文里这几乎是默认形态。发现者和验证者共享同一段对话历史。验证者并不是在重新读证据更像在回看自己刚才说过的话。提示词写「请认真反驳」只是软约束上下文里已有的结论会继续拉扯后续判断。从信息路径看更清楚。发现阶段结束后上下文里已经有候选问题、支持性摘录还有一段把它们串起来的叙事。验证若还在同一条轨迹里模型看到的不是中性证据包而是带着结论的证据包。个别条目仍可能被驳回但整体很难维持真正的对抗姿态。发现写得越自信验证越容易变成润色而不是证伪。安全审计、事实核查、重要架构决策误报成本都不低。发现和验证不拆开你得到的往往不是更高置信度而是更会自圆其说的报告。很多人以为「让模型自己再检查一遍」等于加了一道质检在单上下文里它更像让作者给自己的文章写审稿意见。偶尔有用当不了制度。后面会讲到的 adversarial verification就是把这层失败做成结构发现者扩大召回验证者隔离上下文、重读证据、只返回确认或驳回。验证靠隔离不靠自觉。失败三目标在压缩和拉扯中慢慢走样第三类是 goal drift。任务跨很多轮尤其再经过摘要压缩原始目标会慢慢走样。每次总结都有损。边缘约束、「不要做 X」、最初的过滤标准都可能在压缩里丢掉。长任务几乎必然触发压缩。上下文满了就要摘要摘要留主线丢掉的常常是边界。规模任务里要命的也往往是边界不要改公共 API、不要把待确认当成已确认、只报告有证据的问题、某类告警可以忽略。主线还在边界没了执行看着仍在推进方向已经偏了。还有另一种漂移流程只活在自然语言描述里。你说「先找风险再独立验证只保留确认项」。句子很短执行却很长中间夹着发现、去重、派发、等待、判定、过滤、汇总。模型每一轮都要重读上下文、重新决定下一步。轮次一多它可能少做一次验证把「待确认」当成「已确认」或在总结阶段忘掉最初的筛选标准。不是模型完全不懂流程是流程没有变成稳定的执行结构只存在于可被改写、可被遗忘的上下文叙述里。ReAct 式「看一步做一步」在短链路很强链路一长每一步的局部最优会累积成全局漂移。早期一个「差不多就行」的决定后面会被当成既成事实继续放大。goal drift 大概有两张脸。一张是压缩丢约束一张是临场重规划改流程。单上下文两头都吃。失败四中间材料把主判断淹没规模任务还会制造大量中间信息搜索片段、日志、候选方案、失败尝试、局部推理、被淘汰的假设。这些若都回到主上下文主模型就要一边维持目标一边消化噪音。上下文窗口的问题不只是装不装得下更是装进去以后还能不能保持判断质量。信息越多目标越容易变形早期假设越容易污染后续判断局部细节也越容易压过整体约束。一个文件里的奇特实现可能被概括成「全项目都这样」一次偶然复现可能让它过早锁定根因。很多人以为更大窗口能解决问题。更大窗口能推迟问题不等于消除问题。单上下文仍然要同时承担工作记忆和执行账本。任务一长账本越厚判断越钝。窗口变大只是让「钝」来得更晚并不改变计划、状态、证据挤在一起的结构。还有个隐蔽后果中间材料会改变模型的说话方式。它开始花更多 token 解释自己做过什么而不是推进还没做的事。对用户来说输出更长了像是更努力了对任务来说覆盖进度未必前进。热闹和进展不是一回事。这几类失败为什么会缠在一起失败互相加固漏项到完整语气报告再到自验证偏袒、摘要丢边界最后难以证明做完漏项到完整语气报告再到自验证偏袒、摘要丢边界最后难以证明做完真实事故很少只命中一种。更常见的是连锁。先漏项。模型在中后段开始跳过「看起来相似」的文件再用一份完整语气的报告把缺口盖住。如果后面还有自验证它会优先验证自己已经写进叙事的发现而不是去找被跳过的空白。压缩发生后原始要求里的「每个路由都要看」可能被收成「完成了鉴权审查」。中间材料越多主模型越难回头检查覆盖账本——因为账本本来就不存在只存在于它对自己进度的印象里。所以单上下文的问题往往不是某一个 bug而是缺少外置结构时错误会互相加固。漏项制造虚假完成感虚假完成感降低继续搜索的动机自证偏差保护已有结论压缩再把边界磨掉。最后你得到一份很像答案的文本却很难说清它凭什么算做完为什么加提示词常常救不回来「不要遗漏」「严格验证」「按步骤执行」当然有用。短任务里它们能提高顺从度边界情况下也能把模型往回拉一把。但在规模任务上它们答不了更硬的问题总共有多少对象哪些已经处理哪些失败验证者和发现者是否隔离停止条件是什么完成证据是什么这些问题如果只能靠模型在对话里口头回答可靠性就仍然建立在自觉上。自觉会波动结构不会。Anthropic 和 LangChain 后来走向动态 workflow本质上不是让模型更努力而是承认规模下先垮的是记忆与流程保真不是单次推理能力。换个说法也行。提示词是软约束适合表达偏好和原则规模任务需要硬约束适合表达集合、阶段、协议和停止条件。软约束放进上下文会和其他文本一起抢注意力硬约束放进代码和运行时不靠模型每轮「想起来」。可以对照着看软约束常见写法是「不要遗漏」「认真验证」「按步骤做」。它表达意图不产生可核对账本。硬约束常见形态是「工作集 这 120 个文件」「每个 finding 必须过独立验证」「连续两轮无新发现才停」「最终报告必须带确认数 / 驳回数」。它表达结构完成后能复查。当然不是所有任务都该上硬约束。边界清楚、步骤少、结果可人工一眼核对时硬约束就是成本。单上下文在那里仍然是正确默认。把失败讲清楚不是为了否定单 Agent而是标出它能力曲线开始弯折的地方。一个小复盘同一句话两种结果同一句需求「审查src/routes/找出缺鉴权的路由别漏。」单上下文常见轨迹是打开若干文件 → 写下若干问题 → 中后段开始挑「重要的」看 → 产出一份分级清晰的报告。报告可能很有用但你很难追问「120 个文件里哪 35 个没打开」。完整语气已经把缺口盖住了。如果你改成硬约束思路同一句话会先被拆成可执行账先列出全部路由文件并打印数量再逐个审查并记录状态每个可疑项单独验证最后只输出确认项并附上总数、成功数、失败列表。这时「别漏」不再靠自觉而靠列表和状态字段。我写这个对照不是说后者一定更「先进」。它更贵也更慢。但它回答了一个单上下文经常答不清的问题你凭什么说做完了什么时候单上下文仍然够用边界其实挺清楚。改一个明确文件、回答一个局部问题、在已知小范围内做一次探索单上下文通常最好。对象集小阶段短中间材料有限人工也能快速验结果。强行上多 Agent 和脚本编排只会更慢更贵。另一种也够用你要的是思路不是覆盖证明。比如「帮我看看这个模块可能有哪些风险方向」。你要启发不是审计报告。这时漏几项可以接受完整语气的危害也较小因为你本来就不把它当完工证明。一旦任务变成大量对象、多阶段、还需要证明做完单上下文就开始系统性吃力。下一篇会接着讲动态 workflow 并不是多开几个 Agent而是把控制流、状态和覆盖从对话里搬进代码。模型少背账系统多记账。