跨设备 agent 这门生意，护城河不在"多"

搞跨设备 agent 的，多半死在"状态管理"这笔账上。

上周 arXiv 上一篇预印本（编号 2608.05729），讲的是个叫 Unified Agent 的东西——核心就一句话：你的 agent 跨设备和跨时间跑，得把状态带着走。听起来朴素得不像话？说句扫兴的，现在市面上那些吹得天花乱坠的"跨设备智能体"，真去扒底层，状态一断就归零，跟裸奔没区别。你手机上跟它交代了什么，切到电脑上它两眼一抹黑——这就叫没账本。

现在市面上两条路线，各有各的死穴。把设备当工具的单代理系统，跑哪儿算哪儿，跨时间的全设备状态管理基本是零；多代理系统呢，代理之间倒是能协调了，但跨设备、跨时间请求需要的紧凑状态携带，做不了。两头都不靠，这就是现状。

这篇论文真正把账翻出来的地方在这儿：作者主张 agent 得维护一种"有效设计的状态"——把参与证据、陈述事实、待处理请求组织成紧凑且可直接用于决策的形式。翻译成人话就是：别什么都记，记那些对下一步决策有用的，按账本思路精算，别按垃圾桶思路囤。

插一句不相干的，我半年前算过一笔 agent 平台的账，当时判断"状态管理是护城河"，被几个朋友怼说太保守——现在看这篇论文的基准测试结果，那个判断到现在还立得住。他们测出来 Unified Agent 显著优于四种已发表设计的适配版本，更狠的是换了多模态大语言模型系列、调了能力和推理预算，优势还在。这说明什么？说明这笔红利不挂在某个特定模型的烟花上，状态设计本身带来的优势是稳健的——换什么底盘都跑得动。这才是能规模化的东西。

那怎么办？真想在这条赛道上活下来，别去卷"我能接多少设备"——接得越多，状态越碎，账越算不清，这条死路。该卷的是"我能不能把跨设备、跨时间的状态压成一个紧凑的决策单元"。这笔账算得过来，护城河就在你这儿；算不过来，你就是在帮平台方免费趟坑，趟完了被一句更新抹掉。

论文末尾提了句代码和数据会发在 GitHub 上——真发了的话，建议别急着 fork，先拿它的基准测一测你自己 agent 的状态设计。测完大概率会发现自己一直在交认知税。

本期认知税：以为"多设备支持"就是差异化卖点——多设备谁都能接，状态谁也带不利索，这才是账本上的真窟窿。

这笔账，你自己算。咱下篇见。