http://www.youtube.com/watch?v=WFyFCFC15dE
这篇演讲的题目是 《Beyond Sandboxes: Architecting Durable Runtimes for AI Agents》（超越沙箱：为 AI Agent 构建持久化运行时），演讲者是 Orkes 的联合创始人兼 CTO Virein Baraiya。
演讲的核心观点是：在生产环境中运行 AI Agent，仅仅依靠“沙箱（Sandbox）”来实现隔离和保护是不够的，更需要一个“持久化运行时（Durable Runtime）”来保证 Agent 的状态可持久化、崩溃后可恢复、过程可审计。
以下是演讲的核心内容总结：
一、 核心痛点：为什么传统的“沙箱”和“内存循环”不够用？
传统的 Agent 开发通常把 Agent 当作一个在内存循环（LLM in the loop）中运行的实体：LLM 观察状态 $\rightarrow$ 决定调用工具 $\rightarrow$ 更新状态 $\rightarrow$ 继续循环 08:45。但这种模式在生产环境中存在巨大缺陷：
- 无法应对长周期任务： 如果一个 Agent 需要运行几天、几周，甚至包含“人工介入（Human-in-the-loop）”环节（例如等待审批或用户提交文档），把整个进程挂在微型虚拟机或沙箱里会极大浪费 CPU 和内存资源 05:54。
- 缺乏崩溃恢复能力（Crash Recovery）： 传统的内存循环在进程奔溃（如网络超时、系统断电）后，内存中的状态和上下文就会全部丢失，无法精准从断点恢复 07:38, 09:10。
- 多 Agent 协同复杂： 在沙箱中运行的 Agent 彼此之间通信时，需要处理复杂的 IP 寻址、重试逻辑等胶水代码 06:26。
二、 核心架构思想：将“推理”与“执行”分离
演讲者提出，应当把 Agent 的关注点进行分离 04:32：
- 沙箱用于保护“执行（Actions）”： 专门用来运行由 Agent 生成的、可能存在安全风险或 Bug 的工具代码。
- 持久化框架用于编排“推理（Reasoning）”： LLM 只负责提出计划（例如：“我建议调用天气工具，参数是波士顿”），而不直接执行它。真正的工具调用由底层的运行时（Runtime）系统接管 05:03。
- Agent 本质上是动态构建的“Sagas（长事务工作流）”： 传统工作流图是静态预定义的，而 Agent 是由 LLM 随着运行动态构建图（Late-bound Sagas），但它们同样需要底层的持久化基座来记录每一步 11:04。
三、 解决方案：Conductor 与 Agent Span
为了落地这一架构，演讲者介绍了两个开源项目：
- Netflix Conductor（微服务工作流引擎）： 这是演讲者团队在 Netflix 期间开发的（现由 Orkes 维护）。它作为一个持久化基座，通过数据库（如 Postgres、Redis）将 Agent 运行的每一步（LLM 调用、工具调用、状态流转、人工输入）都写入账本（Ledger） 12:28, 15:03。
按需挂起： 遇到人工介入或长周期等待时，工作流会暂停，释放全部 CPU 和内存，直到下一个事件触发唤醒，即使隔了 6 个月也能继续 18:03, 19:11。
Agent Span（Agent 运行时）： 构建在 Conductor 之上的 Agent 专用运行时。它像一个编译器，可以把目前市面上主流的 11 种 Agent SDK（如 LangGraph、OpenAI Agents、Vercel AI SDK 等）定义的 Agent，在不修改业务代码的前提下，直接转换为 Conductor 的持久化工作流运行 14:09, 23:34。
四、 带来的核心价值
- 确定性的护栏（Guardrails）： 护栏由框架层硬性控制，而不是让 LLM 决定是否调用，防止 LLM 因幻觉绕过安全检查（例如误删数据库） 10:05。
- 全量审计与回放（Audit & Replay）： 即使在几个月后，合规部门想要审计某个 Agent 为什么做出了某项决策，开发者都可以查看完整的执行记录，甚至可以通过 Mock 掉 LLM 的方式来“回放”整个执行过程 19:34, 24:17。
- 更高效的测试与 Eval： 可以改变某一步 LLM 的输出，来观察后续工具链和业务逻辑的走向，让 Agent 测试更具确定性 20:13。
五、 落地建议与技术护城河
演讲者在最后给出了几点实践建议 21:56：
- 工具的幂等性： 由于系统采用至少一次交付（At-least-once）的队列，必须注意处理非幂等工具（如转账）的重试逻辑。
- 上下文腐化（Context Rot）： 随着 Agent 循环次数增多，账本和上下文会极速膨胀。建议将复杂的 Agent 拆分为多个子 Agent（Sub-agents），让每个子 Agent 只维护各自相关的局部上下文 22:58。
- 企业的真正护城河（The Moat）： 基础模型（如 OpenAI、Anthropic）会不断迭代甚至把一些外部过程内化，但它们永远拿不到企业自身的业务上下文（Context）。通过持久化运行时捕获到的、企业独有的业务执行流程和决策上下文，才是企业在 AI 时代真正的壁垒 24:45。
通俗易懂的解释下Conductor 与 Agent Span
我们可以用一个通俗的类比来理解 Conductor 和 Agent Span 的关系。
把大模型（Agent）想象成一个“极其聪明但记性极差、随时可能失忆的侦探”。他办案时需要频繁打电话问专家（调用 LLM）、翻查档案（调用工具），甚至需要等领导审批（人工介入）。
这时候，演讲里提到的这两个开源项目就扮演了不同的角色：
1. Netflix Conductor：不知疲倦的“书记官”兼“时间暂停器”
传统的做法是让侦探自己一边查案一边在脑子里记进度。如果中间侦探突然“晕倒”（程序崩溃、网络断开），案子就得从头查起。
- 它的核心功能（账本机制）： Conductor 就像是给侦探配了一个形影不离的“书记官”。侦探每说一句话、每打一个电话、每翻一页档案，书记官都会死死地记在小本本（数据库）上。就算侦探突然晕倒，换个新侦探来，翻开小本本就能立刻接着上一步往下查，绝不浪费时间。
- 按需挂起（时间暂停）： 办案过程中，侦探需要等领导审批一个文件，而领导去度假了。如果让侦探一直在办公室干等着，公司得天天给他发高额薪水（白白占用服务器 CPU 和内存）。 有了 Conductor，书记官会直接让侦探“原地消失”（释放所有计算资源），把案子封存起来。等 6 个月后领导度假回来一签字（触发唤醒事件），书记官啪的一下把案子重新打开，侦探瞬间“复活”，不偏不差地从等签字的那一秒继续往下干。这期间没花公司一分钱的资源费。
2. Agent Span：高级的“同声传译员”（翻译官）
侦探（Agent）有很多流派，有的说英语（LangGraph 框架写出来的），有的说法语（OpenAI SDK 写出来的），他们办案的套路各不相同。而书记官 Conductor 是个老古板，它只听得懂极其严谨的、工厂流水线式的“标准公文”（Deterministic Workflow）。
- 它的核心功能（编译器/运行时）： Agent Span 就是一个“超级同声传译”。 你不需要逼着侦探去学怎么跟老古板书记官沟通（不用修改你现有的 Agent 业务代码）。你用市面上任何主流框架（比如 LangGraph 或是 OpenAI 官方 SDK）写好你的 Agent，Agent Span 会在底层自动把侦探嘴里那些天马行空的推理和想法，翻译成老古板书记官能听懂的“标准公文”并交给它去记录和执行。
总结一下
- Conductor 解决了 Agent 在生产环境中的“生存问题”——通过记笔记和高阶省电模式，保证 Agent 任务死不掉、开销低、随时可查。
- Agent Span 解决了 Agent 的“适配问题”——让你用市面上最流行的姿势去写 Agent，然后无缝享受 Conductor 带来的超强稳定性，中间不需要掉一层皮去重构代码。