Pydantic创始人：图库无法兼顾类型、并行与快照，代码才是智能体架构

在AI智能体开发中，关于使用显式图（Graph）还是循环/提示词作为核心架构的争论日益激烈。Pydantic创始人Samuel Colvin在其文章《The code is the graph》中提出一个反直觉的观点：传统的图库是一个错误，真正的图就是代码本身。他认为，虽然人类编写具体业务代码的工作正在减少，但开发者需要转向更高级的任务——定义问题、设定指标和约束，并让智能体易于迭代。

Colvin指出，大多数流行的图库（如LangGraph或早期的pydantic-graph）试图通过节点和边来抽象控制流，但这导致了根本性的技术冲突。他将其称为“图的CAP定理”：任何构建图智能体的开发者都想要三个特性——类型安全（确保节点间数据传递正确）、并行执行（支持扇出和汇聚）以及状态快照（允许崩溃后从断点恢复）。然而，现有的图API无法同时提供这三者。

其机制在于，当引入并行执行时，“当前运行位置”不再是一个简单的节点指针，而是一组正在执行的节点和半填充的汇聚点。如果多个节点同时修改共享状态，快照写入的时刻变得模糊不清：部分更新可能已发生，部分未发生。为了在并行下实现可序列化的快照，节点必须停止直接修改状态，转而返回变更描述，由运行时在提交点应用合并规则。这一过程破坏了类型安全，因为合并规则（如reducer）通常声明在节点代码之外，类型检查器无法验证其语义正确性或跨字段不变量。

相比之下，原生代码天然解决了这一问题。在Python中，if是分支，for是循环，await asyncio.gather(...)是扇出和汇聚。调用栈记录了执行状态，调试器和类型检查器可以直接工作。例如，两个异步函数并行执行后，开发者可以显式地写一行代码来合并结果，这行代码既是类型安全的，又是确定顺序的。持久化则可以通过外部引擎（如Temporal）重放代码来实现，或者在沙箱环境中通过保存整个解释器状态来实现。

为了解决智能体生成代码的安全执行问题，Pydantic开发了Monty，一个专为智能体设计的沙箱Python解释器。Monty不持有操作系统资源（如套接字或文件描述符），所有外部交互必须通过宿主注册的函数进行。这使得解释器的堆和调用栈成为一个连贯的值，可以在任何等待外部调用的时刻进行快照和恢复。这种设计使得智能体可以编写纯Python代码来编排子任务，既保留了语言的表达力和安全性，又实现了图库难以企及的持久化和并行能力。