Agent 任务粒度：什么时候该拆任务，什么时候该继续聊

发表于 分类于 本文字数： 3.5k 阅读时长 ≈ 13 分钟

用 Agent 做事时，最容易产生错觉的一句话是：继续。

继续查、继续改、继续修、继续总结。对话还没爆 token，模型也还在回应，好像就还能往下推进。可很多长任务不是死在上下文窗口不够长，而是死在上下文已经变脏了。

它读过太多中间材料，留下太多旧假设；它跑过几轮失败命令，记住了几条已经废弃的解释；它同时背着研究、规划、实现、验证和发布几个目标。表面上它还在执行，实际上当前判断已经被旧上下文拖住了。

所以我现在更愿意把 Agent 任务粒度看成一个工程判断：

一次 Agent 任务的合适大小，不取决于模型还能装多少 token，而取决于当前对话还能不能保持目标单一、边界清晰、证据新鲜、上下文干净。

这篇不讨论怎么“压榨” Agent 多干活，而讨论一个更实用的问题：什么时候该继续聊，什么时候该拆任务。

不是越长越能干

长上下文确实有用。

它让模型能读更大的文件、保留更多对话历史、处理更完整的资料包。对于很多任务，这直接提升了体验：不用频繁重复背景，不用把代码切得太碎，也不用每走一步就重新交代上下文。

但“放得下”不等于“用得稳”。

Lost in the Middle 这类研究已经说明，模型处理长输入时，相关信息的位置会影响使用效果；放在开头和结尾的信息，通常比放在中间的信息更容易被利用。[1] RULER 进一步提醒我们，标称上下文长度不等于真实任务里的有效上下文长度；当任务从简单检索变成多针、多跳、聚合时，性能下降会更早暴露。[2]

这些研究不是说长上下文没用，而是提醒我们：上下文窗口不是可靠记忆库。

真实 Agent 任务比论文里的长文本更乱。它不只是读一篇文章，而是在多轮里不断加入：

  • 用户补充的新约束
  • 模型自己写过的旧计划
  • 文件读取结果
  • 搜索结果
  • 测试日志
  • 报错堆栈
  • 已经被否定的假设
  • 尚未验证的总结

这些东西如果一直留在同一个对话里，问题就不只是 token 多。问题是旧材料会持续参与后续判断。

这就是我觉得 Context Rot 这个词好用的地方。它说的不是上下文超过硬上限，而是上下文还在窗口里，但质量已经下降：变长、变旧、变杂、互相干扰。Chroma 的技术报告把这个现象放在长输入性能退化里讨论；Anthropic 的上下文工程文章也把 context 当成有限资源，强调要把最小的高信号信息放进窗口。[3][4]

所以，长任务里最危险的往往不是模型忘了，而是它记住了太多不该继续起作用的东西。

任务太大时，Agent 会怎么漂

一个任务刚开始时，目标通常还算清楚。

“帮我查这个 bug。”
“把这个功能做完。”
“研究一下这个主题，然后写一篇文章。”

真正的问题发生在中后段。任务一大，Agent 会开始同时背几类工作：研究材料、比较方案、改文件、跑测试、处理失败、总结结论。每一类工作都需要不同的上下文，但它们常常混在同一个窗口里。

我见过最典型的漂移有几种。

第一种是沿用旧假设。

前面为了定位问题，Agent 提出过 A、B、C 三个可能原因。后来证据已经排除了 A，但 A 的解释还留在对话里。再往后写总结或做实现时，它可能又把 A 当成背景条件拿回来。

第二种是忘记新约束。

用户中途补了一句“不要动这个模块”“这次只写草稿，不发布”“不要改现有接口”。但窗口里还有更早的宽泛目标，后面的执行就可能被旧目标带跑。

第三种是把研究、计划和实现混成一团。

研究阶段本来应该宽一点，多读、多搜、多比较。实现阶段应该窄一点，只保留当前方案、相关文件和验收条件。如果研究材料不压缩，整个实现阶段就会背着一大堆候选路径前进。

第四种是工具输出堆积。

一次 rg、一段日志、一篇网页、一串测试失败，在当下都很有用。但定位完成后，完整原文常常不该继续留在 active context 里。Anthropic 的 cookbook 把 compaction、tool-result clearing 和 memory 分成三种不同手段：压缩会话、清理可重新获取的大型工具结果、把稳定事实写到外部记忆。[5]

这说明一个简单事实：长运行 Agent 需要上下文治理，而不是只靠“继续”。

好任务的四个条件

我现在判断一个任务能不能继续留在同一个 Agent 对话里，会看四个条件。

第一，目标单一。

这个任务能不能用一句话说清完成状态？不是“把这个系统优化一下”，而是“给支付回调入口补上事件级幂等，并用现有测试覆盖重复回调”。不是“研究 Agent 任务粒度并写一堆东西”，而是“基于已有来源写一篇面向 AI 编程用户的判断文章”。

目标越单一，Agent 越容易知道自己现在该服务什么。

第二，边界清晰。

哪些文件在范围内？哪些模块不能动？哪些材料只是背景？哪些结论必须有来源？如果边界说不清，Agent 会用自己的默认模式补齐，而默认模式通常是“尽量完成更多”。

第三，可验证。

代码任务要有测试、lint、build、截图或人工检查点。研究任务要有来源、claim-to-source 映射和事实边界。写作任务要有读者、论点、结构和证据清单。

没有验收方式的任务，很容易变成模型写了一段更顺的解释。

第四，上下文可控。

完成任务所需的实时材料，不能把大量无关历史长期留在主对话里。旧日志、旧搜索结果、旧方案、已废弃计划，如果只是“曾经出现过”，就不该自动继续拥有影响力。

这四个条件凑在一起，基本就是一次 Agent 任务的健康边界：

目标单一，边界清晰，可验证，上下文可控。

如果这四项都满足，继续聊通常没问题。反过来，如果其中两项开始失控，就应该考虑拆。

什么情况下可以继续聊

不是所有任务都要拆。过度拆分也会制造流程负担。

我会在这些情况下继续让同一个 Agent 往下做。

任务范围很小，只涉及一两个文件，或者一篇文章的一个明确章节。

上下文还短，里面没有很多失败路径、旧假设和互相竞争的方案。

验收方式明确。比如“跑这个测试”“生成这篇草稿”“检查这几个链接”“把这段内容改得更清楚”。

下一步需要的不是新判断，而是接着当前状态执行。比如刚刚形成了清晰大纲，下一步就是按大纲写正文；刚刚定位了失败测试，下一步就是做最小修复。

这类任务继续聊是自然的。拆出去反而会损失刚刚形成的局部上下文。

一个简单判断是：下一步需要的是更多历史，还是更干净的判断？

如果下一步需要更多历史，可以继续。如果下一步需要更干净的判断，就该拆。

什么情况下应该拆

真正该拆的时候，通常会出现一些很明确的信号。

第一，同时包含多个阶段。

如果一个请求里同时有 research、plan、implement、verify、document、publish，而且每个阶段都会产生大量中间材料，就不要期待一个对话从头干到尾还保持清爽。

更好的方式是分阶段：

1
Research -> Plan -> Implement -> Verify -> Document

每一阶段把输出压缩成下一阶段真正需要的内容。Research 阶段的输出不是“所有资料全文”，而是来源、关键结论、争议点、待验证问题。Plan 阶段的输出不是“所有思考过程”，而是目标、范围、步骤、风险和验收。Implement 阶段只需要当前方案和相关文件。

第二，工具结果太多。

如果对话里已经堆了大量日志、网页、搜索结果、测试输出、文件全文，继续往下通常会让模型越来越难抓重点。此时要么清理，要么摘要，要么开新上下文，只保留可追溯指针。

第三，方向多次变化。

用户中途改过几次目标，Agent 也尝试过几种方案。这种任务继续聊很容易“旧方向诈尸”。更稳的做法是停一下，明确当前方案和废弃方案，再进入下一阶段。

第四，出现多个互相竞争的假设。

调试任务尤其常见。A 解释看起来合理，B 解释也合理，C 解释后来被测试推翻。如果这些假设没有被整理成“事实、假设、已排除、待验证”，Agent 后面很容易把它们混用。

第五，任务跨模块或跨责任边界。

比如一次修改同时涉及前端、后端、数据库迁移、部署脚本、监控告警和文档。它们不是不能一起做，而是每一块最好有独立验收和独立上下文。

第六，已经形成稳定结论。

一旦某个结论变成长期可复用的知识，就不要只留在聊天记录里。项目规则进 AGENTS.md 或文档；领域结论进 wiki；验证方式进脚本或 CI；一次性交接进 handoff。下一阶段读取稳定产物，而不是继承整段杂乱历史。

拆任务不是制造流程负担

很多人不愿意拆任务，是因为拆听起来像项目管理开销。

但对 Agent 来说，拆任务的意义不是官僚化，而是给它换一个更干净的工作现场。

研究阶段需要发散，允许多读、多搜、多比较。

计划阶段需要收敛，把发现压缩成目标、边界、步骤和验收。

实现阶段需要局部、稳定、少噪声，只看当前要改的文件和决策。

验证阶段需要新鲜证据，不需要旧的“应该没问题”。

沉淀阶段需要把可复用结论写到长期位置，不需要保存所有聊天细节。

这其实和人工作很像。你不会把会议白板、草稿纸、错误日志、最终设计稿、上线 checklist 全部摊在同一张桌子上，然后指望自己越干越清醒。你会在不同阶段清桌面、换材料、归档结论。

Agent 也需要这样的工作现场。

一句实用判断

我最后会把任务粒度压成一句话：

如果下一步需要的是更多历史，就继续；如果下一步需要的是更干净的判断，就拆。

继续，适合当前目标还单一、上下文还干净、验收还明确的时候。

拆，适合任务已经跨阶段、工具输出太多、旧假设太多、方向变化太多，或者下一步需要独立判断的时候。

这不是为了少用 Agent。恰恰相反，是为了让 Agent 更稳定地做完真正有价值的事。

好的 Agent 协作，不是把一个巨大任务塞进一个巨大对话里。

而是让每一次对话都像一个边界清楚的工作单元：知道要做什么，知道不做什么，知道用什么证据判断完成，也知道什么时候该把稳定结论交给下一阶段。

Agent 任务粒度，本质上不是 token 管理。

它是上下文卫生。

参考与延伸阅读

  1. Nelson F. Liu et al., Lost in the Middle: How Language Models Use Long Contexts。这篇研究说明，相关信息在长上下文中的位置会显著影响模型表现，开头和结尾通常比中间更容易被利用。 ↩︎

  2. Cheng-Ping Hsieh et al., RULER: What’s the Real Context Size of Your Long-Context Language Models?。这里引用它来支撑“标称上下文窗口不等于复杂任务中的真实可用上下文长度”。 ↩︎

  3. Chroma, Context Rot: How Increasing Input Tokens Impacts LLM Performance。这里引用它对输入变长、干扰项和任务结构导致性能退化的分析。 ↩︎

  4. Anthropic, Effective context engineering for AI agents。文中把 context 视为有限资源，并强调上下文工程是管理推理时可用 token 的策略集合。 ↩︎

  5. Anthropic Cookbook, Context engineering: memory, compaction, and tool clearing。这里引用它区分 compaction、tool-result clearing 和 memory 的工程边界。 ↩︎