上周四凌晨我在改自己那套半成品 harness 的日志模块，改到第三版还是对不齐——某个 agent 今天做的决定，和它三天前那个决定，到底是不是同一个“人”做出来的，我的记录里说不清楚。
就是在这种情绪下刷到的 arXiv:2611.01918。
AgenticMobility，八个人，11 月 1 号挂上去的，主分类 cs.MA，顺手挂了 cs.AI 和 physics.soc-ph。一句话：让 LLM 智能体在 MATSim 里当出行者和交通管理者，跑很多天，看它们怎么互相磨。
平台做得好不好我不评价，我又没跑过它的代码。我要说的是它公布的那组数字里，哪部分是实打实的检查结果，哪部分只是听起来很漂亮。
最值钱的是摘要里最不性感的那一段
持久化智能体跨轮次保留身份和状态；用明确接口规定它能看到什么信息、能执行什么动作、什么时候做决定；再用相互关联的记录，把决策、执行、反馈串起来。
翻译成人话：这不是在秀模型多聪明，这是先把 agent 的权限边界和审计链搭出来。
前两年我看 agent 仿真类的论文，最烦的就是这种：行为讲得天花乱坠，你往下翻，它连“agent 说的那个动作最后到底有没有被执行”都不检查。模型输出一句“我决定改走北环”，论文就当它走了。这不叫仿真，这叫让实习生写周报。
当前实现里，出行者选路线和出发时间，管理者在 MATSim 里定期调路段收费。联合运行时，1,179,300 个最终目标决策全部满足动作约束；执行检查确认被接受的选择确实落实了；个人记忆跨天保留。
这串数字不是“发现”，是验收报告。我喜欢验收报告。
摊下来，一个配置一天两千三百来个决策——粗粗反推，出行者规模在两千量级。画外音：这个量级的好处是，一旦某天某个环节漏掉了执行校验，总量上很容易看出来；坏处是，也很难靠人眼盯住。
如果让我给这套记录挑毛病，我会先看三个字段：这条决策引用了哪几条记忆、它在第几天被执行、执行结果和第几天预期的偏差是多少。差不多长这样：
{
"agent": "traveler_0417",
"day": 63,
"action": {"type": "departure_time", "value": "07:42"},
"constraint_ok": true,
"executed_at": "day_63",
"memory_refs": ["day_12_toll_shock", "day_58_late_arrival"],
"outcome_delta_min": -4
}
没有 memory_refs 这一栏，你永远说不清一个 agent 第 63 天的选择是“适应”还是“随机漂了一下”。它扛不扛得住这个字段，我不知道。
五种配置，各跑一次
五种配置，每种 100 天，每种各运行一次，共享同一个模拟随机种子。
我在这句上停了很久。
在一个记忆跨天保留、管理者按周期反馈的系统里，一次运行的轨迹是被前面每一步锁死的。第 7 天某个出行者被收费挤得早走了 12 分钟，这个偏移跟着它的记忆进第 8 天，再进第 60 天。你跑一次拿到的是“这一条轨迹”，不是“这个配置下的行为”。想从里面读出个体适应、集体结果、管理干预的差别——方差是个未知数。
而且“共享同一个随机种子”这句，在一个每轮都要过 LLM 的系统里，能保证的东西非常有限。模型那边的采样不归你的种子管。种子只锁住了仿真侧的随机性，锁不住语言模型这一层的不确定性，而这层不确定性恰恰会被记忆一路放大。
所以演示里那句“路线选择保持稳定，出发时间发生调整，受控出行结果与全体人口结果之间存在差异”，我信它是真的——它确实发生了。我不信的是它能代表这个配置。这两件事差得很远。
收一收，这是平台论文
人家自己在摘要里写的就是 preliminary demonstration，初步演示。演示的意思是“它能跑通，跑出来的东西有结构”，不是“我证明了这个结构”。这个分寸他们拿捏得比我上面那段吐槽公正，我上一段话说得冲了。
但另一件事我想说死：这套平台的卖点恰恰是记忆和反馈。记忆是路径依赖的燃料。你越让 agent 记得住，越没法拿一次运行代表一个配置。这不是这一篇的毛病，这是整条 persistent agent 仿真线的结构性问题——大家都在拼谁家 agent 记得久、适应得像，没人报方差。
我想要的那张表其实特别朴素：同一配置，从同一个种子起，重跑十遍，把 100 天里每天的出发时间分布画出来，看第 30 天到第 100 天这段的带宽。如果带宽比配置之间的差异还宽，那“出发时间发生调整”就只是这条轨迹的自言自语。
我知道这贵。LLM 调用按量计费，十遍就是十倍的账。但“贵”和“不做”是两回事，起码该在文里写一句“方差未测”。
真正让我坐直的是那个管理者
出行者今天的路线是昨天收费的函数，明天的收费是今天拥堵的函数。两个环套在一起，中间还夹着 LLM 一次几十秒的推理延迟。这是我半夜想起来会笑一声的那种架构，也是所有 bug 的温床。
但我看好它，恰恰因为它贴近真的东西。现实里的管理干预本来就是滞后的，不完整，被干预对象还会适应。你把管理者也做成一个会记住上次调价效果的 agent，这个闭环里长出来的东西，比一堆静态均衡图有意思。
至于这闭环稳不稳——五种配置各一次，真看不出来。
扯远了，回正题。我那套日志模块最后是怎么收的？我没重构，我在每条记录上硬加了一个 parent_event_id，把“这个决定是被哪次反馈触发的”串起来。粗暴但有效，丑得要命。后来证明我一开始想推倒重写那个判断是错的——问题根本不在结构，在我压根没记触发源。
所以规则就一条：带持久化记忆的 agent 实验，报结论之前先把同一配置重跑几遍，方差贴不出来，就老老实实写“演示”两个字。
有没有人真把这条线跑出过种子扫描？我很想看。