你以为的 AI Agent 新框架，其实是 40 年前的老配方

一个让人扫兴的判断

先抛结论：2026 年这一批号称"生产级"的 AI Agent 框架，它们最硬核的地基，不是什么全新发明——而是软件工程 40 年前就备好的三道老配方。

这话听起来像泼冷水，但对做产品的人反而是好消息。因为它意味着：让 Agent 变得可靠，你不必等模型更聪明，也不必自己从头造轮子——成熟的答案早就躺在计算机科学的经典教材里。

这篇文章想讲清楚三件事：生产级 Agent 到底难在哪、那些"新框架"到底在偷师谁、以及你该怎么用。

先说说：为什么惊艳的 Agent 一上生产就崩

你一定见过那种 demo 惊艳的 Agent——几分钟内订好机票、写完报告、跑通一个复杂流程。但真把它放进生产环境，它几乎总是出问题。

Palantir 在 2026 年 DevCon 大会上，用一个"病人出院 Agent"把这件事讲透了：这个 Agent 负责在病人离院前拟好出院方案——查病历、看化验单、起草处方，等医生签字后，再真的把处方发给药房、把账单发给保险公司。看起来简单，但它藏着六个几乎必然翻车的坑：

1. 崩溃是必然的。进程会死、节点会升级、内存会爆、模型服务会宕机——一个长时间运行的 Agent，迟早会崩在某一步。
2. 一重启就失忆。状态只存在本地内存里，进程一重启，之前干到哪全忘了。
3. 时间会错乱。假设 Agent 里有个变量叫"当前日期"。它周二晚上 23:58 第一次跑，崩了；周三凌晨 00:02 重跑——同一句"查今天的化验单"，两次拿到的是不同结果。这种非确定性极难排查。
4. 副作用会重复。一重启，处方可能发去药房两次、保险可能被重复扣费。而现实世界的动作是撤不回来的。
5. 它需要等，但等不起。医生签字可能要等几小时甚至几天。让进程一直挂在那儿干等，既撞上前面说的崩溃风险，成千上万个 Agent 常驻还烧掉大把算力成本。
6. 出了 bug 没法复盘。传统调试是"拿导致 bug 的输入再跑一遍"。但 Agent 做不到——世界已经往前走了，副作用已经发生了，你重现不了当时的场景。

这六个坑指向同一句扎心的判断，也是这场发布会最值得记住的一句话：

"Agent 有用性的瓶颈，往往不是智能（intelligence），而是信任（trust）。"

全行业都在砸钱把模型变聪明，而且确实见效了。但从"能演示"到"敢干真活"之间隔着的，不是智商，而是你敢不敢信任它安全地完成一件有真实、不可逆后果的事。

老配方登场：三道 40 年前就有的菜

那怎么解决"信任"？有意思的地方来了——这些坑，分布式系统领域早在几十年前就系统性地解过。三道老配方，我用大白话 + 类比讲给你听。

第一道：Event Sourcing（事件溯源）——记账本，而不是只记余额。

普通做法只保存"当前状态"（比如账户余额 100 块）。事件溯源多存一样东西：一本按顺序记下每一笔变动的账本（存了 50、取了 30、又存了 80……）。它的铁律是——任何状态改变都必须先记一笔账。这样一来，当前余额其实是"把整本账从头加一遍"的结果。好处是：账本还在，你就能随时从头重建状态、回放到任意历史时刻、甚至纠正一笔记错的账再重算。你每天用的版本控制系统（Git、SVN）就是活生生的例子——提交历史是账本，工作区是当前状态。

第二道：CQRS（读写职责分离）——后厨和前台菜单，分开设计。

一家餐厅，"怎么做菜"（写）和"怎么给客人展示菜单"（读）是两套完全不同的逻辑。硬用一套模型同时伺候两头，往往两头都做不好。CQRS 就是把这两套拆开：写用写的模型，读用读的模型。但要注意——它的提出者 Martin Fowler 特意警告过：大多数系统并不需要 CQRS，硬上只会徒增复杂度。这是一条难得的"边界智慧"：好模式用错地方就是坏模式。

第三道：Actor 模型——一群只靠发消息沟通、各管各状态的小人。

想象一个系统由许多"小人"（Actor）组成：每个小人守着自己的私有状态，谁也不碰谁的内存，彼此只能靠发消息沟通；每个小人有个自己的收件箱，一条一条串行处理。这样天然就没有"抢同一块内存"的锁竞争问题，特别适合高并发。这套模型由 Carl Hewitt 在 1970 年代提出——是的，比你我很多人的年纪都大。

对上号：所谓"新原语"，就是老配方换了层皮

现在把两边摆到一起看。

Palantir 这套框架的核心，是三个它称之为"原语"的东西：context item（上下文项，一份带强类型状态的数据）、event（事件，用来改变状态）、effect（副作用，异步地去碰真实世界）。官方把它包装成一个很时髦的说法——"Agent loop 本质是一台分布式状态机"。

但你把它和上面三道老配方对一下，会心一笑：

• context item 通过 event 改变自己的状态、还能回放——这就是事件溯源。
• context item 的状态是强类型的，因此前台界面能直接漂亮地渲染给护士看，不用去解析一堆模型吐出的文本——这就是 CQRS 的读写分离（而且 Agent 场景还多了一个刁钻需求：同一份状态要同时喂给人看的界面和喂给模型的上下文，一份数据两个"读端"）。
• context item 各管各的状态、靠 event 这个"消息"驱动、effect 异步向外发消息——这就是 Actor 模型。

最有说服力的证据来自 Palantir 的另一场发布——它的底层"持久化层"叫 Orchestrator。讲者亲口描述它的工作机制：把每一步操作记进一个持久化的账本（ledger），崩溃后从账本回放（replay）、把状态重新注水（rehydrate）回来。"账本 / 回放 / 重新注水"——这不就是事件溯源的教科书定义逐字念了一遍吗？

它还顺手解决了前面那六个坑：靠账本回放做到崩溃可恢复；靠一个"幂等键（idempotency key）"保证处方只发一次（exactly-once）；靠"信号（signal）"机制让 Agent 在等医生签字时彻底挂起——进程完全销毁、不占任何内存和算力，等签字信号来了再拉起一个新的隔离环境恢复现场。等待，于是变得几乎免费。

不止 Palantir：这已经是一门显学

你可能觉得这是 Palantir 一家的花招。恰恰相反——把"让程序崩了也能从断点续跑"做成一个专门的执行引擎，这件事有个正式名字叫 durable execution（持久化执行），而且 2026 年它已经是显学。

• Temporal：这个领域最成熟的通用引擎，一句广告词很传神——"就像给你的程序装了终极自动存档"。
• LangGraph：开源 Agent 框架，用 checkpointer（检查点）给 Agent 存状态快照，崩了从最近的检查点恢复。
• Restate：轻量级的开源新秀，直接把"AI Agent"列为头号用例。

四家（算上 Palantir Orchestrator）做的是同一件事，共享同一套骨架：持久化日志 + 崩溃回放 + 只执行一次 + 挂起/恢复。说穿了，durable execution 就是把"事件溯源"这道老配方，从一种"数据怎么存"的模式，做成了一台"程序怎么跑"的引擎。

为什么偏偏是 AI Agent 把这门几十年的老手艺重新捧红？因为 Agent 恰好把对它的需求全部放大到了极致：Agent loop 跑得久、必然崩，需要断点恢复；Agent 会真扣款真发货，需要只执行一次；Agent 要等人审批、等外部结果，需要低成本挂起；Agent 每调一次大模型都很贵，崩溃后能回放已完成的步骤、而不是重算，能省下真金白银的 token。

那么，从业者到底该怎么用？

讲了半天原理，落到行动上其实很简单。

第一，别自己搓一根 while 循环硬扛。 如果你的 Agent 要处理"等家长审批""等批改结果返回"这类长时间、异步、多方参与的状态，不要用一个死循环 + 一堆 try-catch 硬扛。直接站在成熟的 durable execution 框架肩膀上。

第二，按你的约束选框架，别纠结"谁最强"。 四个代表各有各的甜区：

它们不是谁取代谁，而是同一道老配方在"隔离强度、生态锁定、成熟度、上手门槛"这几个约束下的不同取舍。

第三，记住 Palantir 那两条真正的增量。 老配方是地基，但这批框架也不是纯粹的复制粘贴，它们贡献了两点新东西：一是用强类型 + 极简接口（Orchestrator 甚至只暴露两个方法）把这些"重模式"的使用门槛降到了"没几行代码"；二是照顾到了 Agent 独有的 human-in-the-loop（人在环中）需求——同一份状态要同时对人和对模型友好呈现。

收尾：一个比框架更值钱的启示

如果这篇文章你只带走一句话，我希望是这句：

AI 时代冒出来的很多"新问题"，其实是老问题换了个场景。

生产级 Agent 面临的崩溃、并发、状态一致、精确一次——这些，分布式系统、数据库、工作流引擎领域已经和它们缠斗了几十年。谁先看穿"哦这不就是事件溯源 / Actor 模型换了层皮"，谁就能少走弯路，直接调用几十年沉淀下来的成熟答案。

这也带来一个反直觉的能力判断：在一个模型能力日新月异、框架层出不穷的时代，吃透计算机科学的经典，可能比追每一个新框架更保值。因为框架会过时，但"事件即真相""读写分离""隔离状态靠消息通信"这些底层模式，几十年都没变过——它们只是换了个名字、又火了一次。

最后补一句我自己的判断。我持续维护个人知识库的这半年，有个越来越强的体感：AI 时代，事实型知识正在快速贬值——框架的 API、参数、用法，AI 随时帮你查到、讲给你听；真正稀缺的，是"穿透现象看本质"的那一下判断。就像这篇文章：四个框架的文档，AI 都读得比我快，但"它们是同一道老配方"这个识别，才是人还值钱的部分。所以与其焦虑追不完的新框架，不如把力气花在两处：吃透那些几十年不变的底层模式，和刻意练习"这次的新东西，对应旧世界里的什么"的翻译能力。

最后交代一下这篇文章的"来路"：它不是临时检索拼出来的。所有事实与判断，都来自我持续维护的个人 AI 知识库——从 Palantir 两场发布会的逐字消化，到经典分布式模式的系统补课，再到四个框架的横向对比，每个结论都有出处、可回溯。这也是「飞说 AGI」想做的事：不做热点的转述，只做有来路的判断。 💬 你还见过哪些「新概念其实是老配方换皮」？评论区聊聊——点赞最高的，下一篇就拆它。