后台 Agent 已到来，而你的编排系统尚未准备就绪

每半年，构建 AI Agent 的“正确”方式就会改变一次。

我们曾经历过 RAG 成为共识、人人都在搭建向量数据库的阶段，接着是 ReAct。我们需要虚拟内存来解决那个 4k 上下文的问题！等等，现在上下文窗口已经巨大了。最近 Anthropic 发了一篇博客——我们要搞 Prompt 链式调用、路由、创建编排器-工作者（orchestrator-workers）了！上下文工程才是真正的重头戏。我们需要一个浏览器来管理这个，不，MCP 才是未来。我们正在构建大量拥有滑稽人类角色感的垂直子 Agent。不对，模型变强了，拥有优秀提示词的通用 Agent 才是王道。哇，OpenAI 也入局 MCP 了，这绝对是未来。现在流行 CLI，MCP 出局了。接下来需要沙箱，但启动速度有多快？我们要造软件工厂了。怎么在不同 Agent 间同步上下文？……

如果你把基础设施与其中任何一种模式硬耦合，那你至少已经重构过两次了。而且你还会继续重构。

本文的核心论点：存在一个不会变化的层——持久化编排（Durable Orchestration）：步骤、事件、状态、重试、可观测性。上述每一种模式都运行在这组相同的底层原语之上。如果夯实了这一层，切换 Agent 模式会变得更容易。如果搞砸了，每次模式迭代就是一场重写或迁移。

框架陷阱

Agent 框架不是普通的类库。它们是对某种获胜模式的押注。当模式发生转移时，你无法通过重构解决，只能推倒重来。

LangGraph 将基于图的控制流封装为核心范式。CrewAI 聚焦于基于角色的 Agent。AutoGen 则针对对话式多 Agent 设计。每种框架都为一种特定的 Agent 工作视图进行了极致优化，而当这种视图转变时，它就成了包袱。（LangChain 本身已转向“深度 Agent”，随着微软转向 Microsoft Agent Framework，AutoGen 已进入维护模式。这就是前车之鉴。）

当 Anthropic 发布其 Agent 模式指南时，直接否定了生态中半数框架内置的假设。他们的明确建议是：从原始 LLM API 开始，避免使用会遮蔽 Prompt 和响应的框架。他们原话写道：“对底层机制的错误假设是客户出错的常见来源。”当然，Anthropic 有其自身利益考量，但这番话依然成立。

问题不在于抽象。抽象本身没问题。问题在于耦合。应该抽象的是底层原语：步骤、重试、状态。不要抽象拓扑结构。从一种框架方案切换到以规划优先的循环（planning-first loop），意味着要重写整个 Agent，而不是简单替换某个组件。

我之前写过相关文章：为什么 Agent 需要一个执行 Harness，而不是一套沉重的 Framework。核心理念是：Agent 逻辑应当被包裹在稳定的执行层中，而不是嵌入到框架的控制流里。Harness 保持不变，变化的是 Agent 逻辑。

真正不变的是什么

支撑每一种模式的底层都有五个原语：

• 持久化步骤（Durable Steps） - 工作断点检查，防止循环中途出错导致丢失 40 分钟的计算进度。
• 持久化的外部状态 - 能够承受进程崩溃和重新部署。
• 并行工作协调 - 扇出/扇入（fan-out/fan-in）、并行工具调用、子 Agent 委托。
• 事件驱动的控制流 - 暂停并等待信号（如人工审核 Human-in-the-loop、取消指令），无需保持连接长开。
• 结构化的执行可观测性（Traces） - 记录每一步和每一个决策，支持排查特定及全局问题。

这些原语并不编码具体的 Agent 模式，而是提供执行保障。你可以将它们组合成今天需要的任何模式，并在明天模式变更时重新编排。我在《Agentic Systems 必需的三种模式》一文中深入探讨了具体的组合策略。无论是委托、扇出还是编排器-工作者架构，底层都依赖这组相同的原语。

ReAct 循环、规划型 Agent 以及多 Agent 委托模式，最终都会简化为相同的 step.run() 和 step.invoke() 调用。Agent 循环、HITL 和委托完全可以直接基于这些原语构建。

后台 Agent 的能力缺口

下一波重大的模式转移已经在发生：从同步聊天型 Agent 转向异步后台 Agent。这正是大多数基础设施崩塌的地方，也是持久化编排变得不可或缺的关键所在。

以往的范式大多是基于同步的、类聊天交互的体验。API 请求发出后，LLM 周边的一切处理都比较有限和简单。毕竟，用户体验要求响应必须尽可能快。

随着模型和方法的不断演进，Agent 可以承接耗时数分钟甚至数小时的长程任务。一个 Agent 循环可能跨越数百个步骤（LLM 调用与工具调用）。所有成功的应用都需要异步后台处理——因为任务耗时太长，根本无法适应同步的用户体验。基础问题集是一样的，但衍生出了一批新挑战。

要让后台 Agent 成功落地，必须具备以下几个条件：

支持崩溃恢复的长时间运行。 运行时间越长，失败的成本就越高。一个耗时 45 分钟的 Agent 运行绝不应该跑在只有 5 分钟超时的 Lambda 函数中，也不应该只存在于单个进程的内存里。它需要能够在重启、部署和基础设施故障中存活下来的执行环境（即持久化执行）。

多步骤可观测性。 当后台 Agent 在运行 30 分钟后产生错误结果时，你需要追踪它的每一个步骤。包括每一次 LLM 调用、工具触发、决策节点和子 Agent 委托。仅仅拼凑日志和状态数据是远远不够的。

事件驱动的控制流。 后台 Agent 需要能够暂停并等待外部输入或触发器（人工审批、Webhook 数据、其他 Agent 的结果、反馈信息），同时不阻塞线程或占用长连接。Agent 应该能进入休眠状态并被唤醒。

生命周期管控。 团队经常不得不自行拼凑数据库查询、日志检索工具、用于取消进行中的任务的钩子，以及定制调度系统来控制异步工作。你要么采用提供完整生命周期控制（状态、取消、调度、检查）的成熟方案，要么就得自己搭建一套脆弱的系统，并在规模扩大后持续投入维护成本。

关于沙箱呢？

有人可能会说：沙箱提供商不是已经解决这个问题了吗？他们解决的其实是另一个问题。沙箱工作在计算层——它回答的是“Agent 在哪里运行？”部分沙箱支持暂停和恢复完整的虚拟机状态，这固然强大，但这只是运行时快照，而非工作流快照。它们无法告诉你哪些步骤已完成、返回了什么值，或是该从哪里继续执行，除非让已经成功的任务重新跑一遍。

有些人直接在沙箱内部运行执行 Harness（例如 Claude Code、OpenCode）。这通常会将 Harness 的状态嵌入沙箱的文件系统中，从而使沙箱的 VM 快照充当持久化层。这意外地把沙箱提供商变成了“编排”提供商。实际上，现在的 Agent 编排被分散到了多个层级中，可观测性和持久化程度参差不齐。

这两个层是互补的，但在走向生产环境的路上将二者混为一谈是一个代价高昂的错误。编排层应该位于沙箱之上，负责管理沙箱的生命周期并保留状态。

可组合性的论点

持久化编排不仅关乎可靠性，更关乎可组合性。这些原语可以组合成尚未命名的新模式。

今天的模式（ReAct、规划、多 Agent）并不是终点。模型的新能力必将催生我们无法预见的架构。如果你的底层原语具备可组合性，那么新模式仅仅是新的组合方式，而非全新的基础设施。

当你拥有了 step.run()、step.invoke()、step.waitForEvent() 和 step.sleep() 时，你就能构建出无法被现有分类法清晰归类的系统：

• 委托给 5 个子 Agent，等待前 3 个完成后取消另外 2 个，在合成中间结果后再继续执行。
• 构建类似自动化研究（autoresearch）的管道，每晚在 Agent 轨迹上进行评估，并根据实际有效的结果自动更新系统提示词或工具选择。
• 并行运行同一任务但采用两种不同的提示策略，等待两者完成、对结果打分并记录胜出者——随时间推移积累数据集。

模式的演变比以往任何时候都快。本质上它们都是组合产物。由于框架编码了固定的拓扑结构，很难适应这些动态变化。而可组合的原语没有这个问题。

这里还有一个容易被忽视的角度：拥有强大编排能力和可观测性的团队迭代速度更快。当你能够看清每次 Agent 运行的每一个步骤（结构化数据，而不仅仅是日志）时，你就能识别出有效的部分并替换无效的部分。可组合性的差距，本质上是可观测性的问题。 看不见的东西，自然无法重组。

实践中的形态

这并非纸上谈兵。以下是它在真实基础设施决策中的映射。

编排层（稳定）：持久化执行、步骤原语、事件系统、状态管理、可观测性、调度。这是你们的多年期架构决策。无论 Agent 模式如何变迁，它都不会改变。

Agent 层（灵活）：如何组织 LLM 调用、工具使用、推理和委托。这部分每 3 到 6 个月就会更新一次。它应该可以轻松调整，因为它本质上只是在持久化原语之上运行的应用代码。

模型层（易变）：调用哪个 LLM、哪种 API、哪家供应商。这部分每月都可能变动。它应该只需修改一行配置，而无需动架构。

为“重写”而设计

Agent 拓扑结构是有保质期的。你现在搭建的那个架构，六个月后就跑不动了。新模型、新研究、新模式——这是常态，而非缺陷。

围绕这一点去设计。拥有合适原语的编排层能让团队快速适应变化。让它之上的所有层按需自由演变。

后台 Agent 不是即将到来，而是已经落地。唯一的问题是：你的基础设施是否已准备好让它们运行，还是说你即将面临又一次推倒重来。