那篇被转来转去的《AI agent 别用 while(true) 当骨架》，讲得对，但讲对了也没用。因为现在生产里跑着的 agent，十个有八个还在 while(true) 里打转——不是因为写的人蠢，是账期没到。你让一个 PMF 都没跑通的团队现在就上事件溯源、Postgres、replay、快照，那才叫账算不清。事件溯源是债，不是错。while(true) 也一样。区别就一条：你知不知道自己在赊账，以及哪天该还。
半年前我见过一个 agent 项目，核心跑分挺好看，扒开看就是一个 while(true) 加一个大 JSON state 来回读写。当时我说这玩意儿上生产要出事，朋友回我一句：先跑到能出事再说。后来呢？真没出事。不是设计对，是同时在线就仨人，什么中断、并发、要回看历史的情况，全碰不上，while(true) 单线程跑得飞起。这时候你要逼他重构成事件流，他第一反应大概率是“你在教我花钱买风险”。他这笔账没毛病。说句扫兴的，这种“先跑到能出事再说”的活法，三个人在线的时候是对的，等人稍微多起来就是另一张账单。
但那个作者有一笔账算到我心坎里了：单一大 JSON state 这东西不诚实。它假装自己是个能代表一切的状态快照，实际上扛不住任何一个真实的、乱序、要回头改历史的生产场景。你可能运气好一直不碰这些场景，可运气不是设计。这是两笔账，得分开。前一笔是你现在能用，后一笔是你迟早要还。
真正让我看进去的是他那句“事件日志当唯一真相，state 只是投影”。这也不是新东西——做交易系统、做风控账本的早这么干，redo log 加回放这套老掉牙了。可放到 agent 这拨新玩具身上，它突然变锐利了。为什么？因为 agent 的每一步都是副作用：发一个工具调用、改一个文件、回一句话。你在 while(true) 里往 state 对象上加个字段表示“这一步做了”，跟你往表里 insert 一行 event 说“这一步做了”，看着是一回事，账本上完全不同。前者是状态，后者是记录。状态会被覆盖、会混进脏东西，最后被拍平到看不出谁干的，记录不会。你想想，一个能覆盖的状态和一个不能覆盖的记录，哪个更像账本？这问题不用答。
它那个 caused_by 指针把会话变成一棵 git 一样的树，这个比喻我认。你想想，用 git 的时候你是靠一个“当前工作区状态对象”撑着的吗？不是吧，是靠提交链。那为什么 agent 会话就要回到单状态对象的老路？因为大家都在赶路。赶路的人都这么写，先写进一个 state，反正 demo 要的是能跑。等真需要分支、需要从三天前那条消息重新 fork 一个 thread，你才发现整个 state 已经没法拆了。到那天你才明白，while(true) 不是架构，是账期。这时候再去补事件日志，就不是设计选择，是抢救。
插一句不相干的，回正题。这文章里我最喜欢的地方，是一个它没展开讲的东西：给模型只留一个 CLI 工具，内部命令自己消化，其他直接下到用户的 shell。这笔账比事件溯源那段还重。你想想，市面上一堆 agent 框架天天搞什么 tool schema、function call 定义、一百个工具的权限矩阵，累得半死。他直接收窄到“一个入口，其他的交给 shell