Agent 任务拆解:2026 主流怎么把「一件大事」拆成「一串小事」,以及给企业 IT 总监的三条硬翻译
2026-09-04 · 美辰研究 · 阅读约 12 分钟
调研日期:2026-09-04
信源:Anthropic "Effective harnesses for long-running agents"(2025-11)、Zylos 2026-01/05、arXiv 2506.12508 AgentOrchestra
一、直接答你的问题
不是。 "先全部找素材 → 再全部整理 → 再全部写" 这种批处理模式是 2026 agent 落地的最大反模式,正确做法是单任务流水线 / 增量推进。
二、为什么批处理会死
失败率数学
- 任务时长翻倍 → 失败率 4 倍(2026 实证)
- 35 分钟墙:任何连续任务超过 35min 性能开始衰减
- Context window 漂移:每多塞一个并行分支,主上下文就被多占一份记忆
批处理的三个死法
- Context 爆炸——100 条素材如果一次性塞给 LLM,中间 80% 进 attention decay 区,真正有用的开头结尾被稀释
- 错误级联——前 5 条素材找错了,后面 95 条整理和写都跟着错,没有任何 checkpoint 隔离
- 崩溃归零——第 50 条崩了,要么从头来,要么从 50 条开始但前面 49 条的"理解"已经丢了
三、主流做法:增量流水线(incremental pipeline)
模式 A:单任务流水线 —— "找 1 个 → 整理 1 个 → 写 1 个 → 落盘 → 下一个"
素材 1 ──→ 整理 1 ──→ 写 1 ──→ 落盘
↓
素材 2 ──→ 整理 2 ──→ 写 2 ──→ 落盘
↓
...循环
每个环节完成后立刻落盘(artifact),下个环节只读上一个 artifact,不读全部。
Anthropic 长任务 harness 原文:"coding agent is tasked with making incremental progress in every session, while leaving clear artifacts for the next session."——逐次推进 + 留痕。
模式 B:分层流水线 —— "并行找 → 串行整理 → 并行写"
┌─ 找素材 A ─┐
Planner ──┬───┼─ 找素材 B ─┤──┐
│ └─ 找素材 C ─┘ │
│ ▼
│ 整理(串行,1 个 worker)
│ │
│ ┌─ 写 A ────────┤
└───┼─ 写 B ────────┤
└─ 写 C ────────┘
找素材阶段可并行(独立 IO),整理阶段串行(依赖全部素材 + 主控上下文),写阶段又可并行(每个独立成稿)。
模式 C:Worker Pool —— 同类任务并发池
适合"100 个相似任务":
- 主 agent 出"任务模板" + "完成标准"
- 100 个 worker(便宜模型)各自执行一个,每个跑在独立 context
- 主 agent 只收"成品 + 失败原因",不收过程
关键:每个 worker 不跟其他 worker 通信,互相不污染。
四、Anthropic 的两段式拆解(可直接套)
Anthropic 官方推荐的 long-running agent 模式:
- Initializer Agent(只跑一次):初始化环境,建目录、写 schema、扫依赖、出初始 plan
- Coding Agent(每 session 跑一次):读上一个 session 留的 artifact → 做增量推进 → 留 artifact 给下个 session
对应你的"批量找素材 + 写稿"场景:
| 你说的 | 拆解后 |
|---|---|
| 找 100 篇素材 | Initializer 一次扫,建素材清单 + 分类目录 |
| 全部整理 | 不批处理——每篇单独整理,落盘到 material_clean/<id>.md,进度可断点续做 |
| 全部写 | 每篇单独成稿,基于 material_clean/<id>.md 单文件上下文,不读全部素材 |
| 写作间依赖 | 只在 Initializer 阶段定"统一风格/引用规范",写作阶段不再传 |
五、对话粒度的关键判断
问题本质:每篇素材该不该一个独立对话?
| 场景 | 对话粒度 | 原因 |
|---|---|---|
| 100 篇独立成稿 | 每篇一个对话 | 不互相污染 context,失败可重做单篇 |
| 1 篇长稿多章节 | 多轮同一对话 | 章节间强依赖,上下文连贯 |
| 找素材 + 写稿混合 | 拆两个对话 | IO 阶段 vs 创作阶段需求不同 |
| 跨任务的状态记忆 | 用外部文件 / DB | 对话内 context 必丢,外部持久化才能跨 session |
反模式警示:100 个对话同时开 → context 互相看不见 → 主控 agent 必须在最外层用 artifact 同步,不是堆 100 个对话。
六、生产架构落地模板
[Planner: 1 次,强模型]
↓ 出 plan.json
[Initializer: 1 次,中模型]
↓ 建目录 + schema + 初始空 artifact
[Worker Pool: N 个对话,便宜模型]
├─ worker-1: 找素材 → material_raw/001.md
├─ worker-2: 找素材 → material_raw/002.md
├─ ...
└─ worker-N
↓ 全部落盘后
[Integrator: 1 次,中模型]
├─ 读 material_raw/*.md 索引
├─ 读 material_clean/*.md(如果之前有)
├─ 决定哪些已可用,哪些要重做
└─ 出 final/<id>.md
关键原则:
1. 每个 worker 跑完立刻落盘——不缓存
2. artifact 是契约——下个 agent 只读上一步产物,不读上一步 agent 的对话
3. 失败可重做单条——<id> 是 ID,重做只针对 ID,不影响其他
4. 主控有全局视图——但通过文件,不是 context
七、给你的直接建议
如果你要批量做"找素材 + 整理 + 写稿":
- 别用"先全部找完再统一处理"的批处理脑回路——错
- 用流水线脑回路——找一篇 → 立刻整理 → 立刻落盘 → 下一篇
- 跨任务的状态用文件 / DB,不用对话记忆——对话必死
- 同质任务用 worker pool(便宜模型并发),异质任务用串行流水线(主控调度)
- 失败可重做单条是关键,不是性能优化
八、给企业 IT 总监的三条硬建议
第一,问供应商「你这套 Agent 怎么拆任务」,而不是「你这套 Agent 用了哪个模型」。能稳定跑超过 1 小时的 Agent 一定有显式的任务拆解架构,不是大 prompt 干到底;不能回答这一条的,大概率跑不到 1 小时就会崩。
第二,合同附件里加一条「增量推进 + 留痕」条款。Anthropic 推荐的 long-running harness 模式是「每个 session 做增量推进 + 留 artifact 给下个 session」,落到合同就是:每个子任务可断点续做、失败可重做单条、有外部 artifact 可审查、不要 all-in-one 大对话。
第三,把「失败恢复」当一等公民谈。每子任务必须有 checkpoint / backtrack / retry-with-variation / reflection loop 四件套;不要等上线后第一次出事才补救。Sentrial 那个 78% 静默失败的客户就是栽在这——APM 看不出、模型没崩、但业务结果不对,只能事后复盘。
九、写在最后
2026 下半年,Agent 落地的真分水岭不在模型、不在协议、不在算力,而在「这件事怎么拆、怎么续、怎么回」。把任务拆得对、用 artifact 把状态续得住、让失败可重做,这三件事齐了,客户场景里的 Agent 才能从「演示台」走到「生产线上」。做不到这三件事,再强的模型也只是 35 分钟后的「失忆天才」。
