生命周期与编排关注 Agent 系统如何在多次模型调用、工具调用、失败、修订和交接中推进任务。这一层将两个关注点结合起来：Agent 的执行流(execution flow)，以及该执行流所读写的操作状态(operational state)。在长程任务中，可靠性不仅取决于模型能否生成一个好的下一步动作，还取决于 harness 能否记住已经发生了什么、决定下一步该做什么、如何从错误中恢复、协调子任务，以及在任务完成时停止。
1. 生命周期状态管理
生命周期状态(Lifecycle State)指的是为了 Agent 能持续完成任务，系统必须在幕后维护的一套“账本”或“进度表”。如果把智能体执行任务比作玩一款大型单机游戏，生命周期状态就是你的“存档文件”，确保你即使关机重启，也能从上次停下的地方继续，而不是重头再来。
生命周期状态到底包含什么？
它不是大模型看到的“对话历史”，而是智能体系统运行所需的“管理数据”。主要包括：
- 待办事项：还没完成的子任务清单。
- 中间产物：执行过程中产生的临时文件、代码库的变更（git changes）或中间生成的各种构件。
- 协调元数据：多个智能体协作时的进度同步信息。
- 断点续传机制：任务失败后的重试策略和恢复点（checkpoints）。
核心区别：它与“上下文”有何不同？
- 上下文：是喂给模型看的“参考资料”（如检索到的文档、对话历史、记忆等），目的是为了让模型“推理”。
- 生命周期状态：是智能体系统自己的“工作日志”，目的是为了让系统更好地“控制”流程。
两种管理模式：无状态 vs. 有状态
论文探讨了开发者在设计这个“账本”时面临的权衡：
| 模式 | 做法 | 优点 | 缺点 |
|---|---|---|---|
| 无状态 (Stateless Replay) | 每次都通过读取所有的对话记录，强行让模型“回忆”起目前的进度。 | 易于审计和重现，逻辑简单。 | 任务越长，对话记录就越臃肿，Token 成本极高。 |
| 有状态 (Stateful Execution) | 把进度存进数据库或文件系统。下一次直接读取这个“存档”。 | 效率高，支持超长周期的任务，可以快速恢复。 | 调试和一致性维护相对困难（比如存档坏了怎么办）。 |
2. Single-Agent 循环
单 Agent 循环是 Agent 系统中的基本执行单元。单个 Agent 通过工具使用和反馈与环境交互，不存在多个 Agent 之间的显式协调。单 Agent 循环遵循 ReAct 范式，交替进行推理(reasoning)、行动(action)和观察(observation)。这类系统的行为不仅由模型决定，还由构造提示词、调用工具、管理控制流、将工具输出反馈到后续步骤等 harness 决定。
在这一层级，论文根据系统如何维护运行状态，将 Single-Agent 内部循环分为两种主要模式：
- 无状态重放 (Stateless Replay)：
- 特点：完全通过记录的交互历史来重构执行状态。这种方式提升了可重复性和可审计性。
- 代表系统：Codex CLI 是此类模式的最典型案例。
- 混合执行 (Hybrid Execution)：
- 特点：除了交互历史，还依赖于持久化的制品（Artifacts），如文件、代码仓库、数据库或会话状态。
- 优势：在轨迹极长时，避免了因历史记录过长导致的上下文爆炸，提高了任务的连续性和故障恢复能力。
- 代表系统：包括 OpenCode、Claude Code、Aider 和 SWE-agent 等大多数实用的编码智能体。详见表 2。
尽管单智能体循环具有极大的灵活性，但在处理长程任务时会面临诸多问题：
- 上下文碎片化：随着步骤增加，窗口内的信息变得杂乱，难以维持逻辑连贯。
- 误差累积：单步的小错误会随循环不断放大，最终导致任务偏离目标。
- 分解结构薄弱：由于缺乏角色分工，模型在同时承担规划、执行和验证职责时容易产生幻觉或过度自信。
3. Multi-Agent 编排
Multi-Agent 编排的核心是将职责从单一循环中剥离，分配给不同的专门 Agent。不再要求一个Agent 独自完成规划、执行、检查和修订，而是由 Harness 层来协调这些角色的互动。这种架构支持任务分解、并行探索、批判验证以及结果聚合，使其比孤立的 Single-Agent 循环更适合处理高难度、长周期的任务。
论文对主流的 Multi-Agent 编排模型进行了分类：
- 层级编排(Hierarchical Orchestration)：使用高层控制器为子智能体分配工作并集成其输出。
- 代表系统：DeerFlow (字节跳动)、AutoGen (微软)、OpenAI Agents SDK、DeepAgents (LangChain)。
- 团队编排(Team Orchestration)：将一组具有特定命名的专家智能体公开为一个协调团队。
- 代表系统：oh-my-claudecode。
- 工作流编排(Workflow Orchestration)：将智能体和工具组织进显式的阶段或控制逻辑中。
- 代表系统：Semantic Kernel (微软)。
- 扇出模式(Fan-out)：并行运行多个智能体，以探索多样化的解决方案。
- 代表系统：Emdash。
- 图组合(Graph Composition)：将智能体、工具或状态表示为交互图中的节点，允许复杂的协调模式共存。
- 代表系统：LangGraph (LangChain)、Hive。
由于需要管理协调状态、角色分配和各种中间制品，多智能体系统通常采用 有状态（Stateful） 或 混合（Hybrid） 的执行模式。典型的案例是 Anthropic 的 Planner-Generator-Evaluator 架构。
4. 全生命周期流水线：从 Issue 到 Pull Request
全生命周期流水线的目标是管理从规格说明到验证输出的整个任务工作流。在软件工程背景下，这通常表现为“从 Issue 到 Pull Request”的自动化流程。从层次关系角度来看，它将基础的“单智能体循环”和“多智能体编排”作为组件，置于更广泛的软件或任务工作流中。涵盖了计划、实现、验证、审查和最终交付的全过程。
该层级的关键抽象是任务运行器(task runner)。它是一个负责管理以下功能的 Harness 系统：
- 调度与持久化：管理任务的执行计划和状态持久化。
- 重试与验证：自动处理失败并进行迭代修正。
- 流程闭环：引导任务从初始的 Issue 描述，经过智能体生成代码，再到通过自动化测试和人类审查，最终达成 PR 合并。
从概念上讲，全生命周期流水线组合了先前的抽象：单 Agent 循环提供执行原语，多 Agent 模式提供协调，任务运行器将它们整合到一个端到端工作流中，人类在其中引导，Agent 在其中执行。