别给智能体一台电脑:Electric 的“智能体即数据”新架构

James · 2026-08-27
听中文精华AI 合成朗读00:00
我们认为多智能体系统是一个分布式数据问题。
— James

关联

这一集是 Scanning Dev Souls 在 Heavybit Dev Guild 现场对 James 的短访。Electric 最早做 Postgres 同步引擎(让数据在服务器和客户端之间实时同步的技术),后来把同步技术泛化成面向智能体的数据原语,最近发布了 Electric Agents——一个跑协作式多智能体系统的运行时。

他们最核心、也最反直觉的主张是:智能体不是计算,而是数据。

反模式:把智能体塞进沙箱

今天大多数人想把智能体部署到线上时的思路是:拿一个智能体“线束”(harness,即驱动 LLM 循环干活的外壳,比如 Claude Code 这类工具),把它整个塞进 Docker 容器、沙箱或虚拟机里——因为你默认智能体需要一台电脑:要文件系统、要跑 bash 和 grep 这些工具调用。

James 认为这是反模式,问题有两个。

第一是可观测性的倒退:如果你在本地用 Claude 让它做研究、派生子智能体,那些子智能体的会话日志在哪?答案是藏在你电脑一个隐藏文件夹里的 JSON Lines 文件里。

企业视角看这不可接受——“为什么生成了这个产物?决策痕迹在哪?

”全被埋了。移植到线上沙箱里同样被埋:难道要 SSH 进沙箱去翻日志?过去 20 年大家拼命把组织搬上云、接上 Prometheus、Datadog 这类监控体系,结果智能体却被当成黑盒容器部署,完全没接进这套标准基础设施。

第二更根本:这个做法把智能体建模成了计算。而关键洞见是——智能体的本质是会话日志,是数据层的记录。

一旦把智能体当计算,你杀掉计算进程,智能体就“没了”;但正确的心智模型是:智能体作为逻辑实体,即使不在运行也存在,它活在数据层的持久化记录里。你需要的是“我聊完了就把它休眠/缩容到零,之后还能回来找同一个智能体会话、或者分叉它”——这只有在会话日志和状态放在数据层、计算随时可重跑的前提下才成立。

还有一个规模问题:未来会有海量智能体——每个工作流程的每一步、每次客户互动、每个接触点都可能有一个智能体。如果每个都当虚拟机跑、各占 2GB 内存,效率低到不可理喻。所以这套模型天然指向“无服务器智能体”:像函数一样,可以缩放到零、也可以缩放到万亿。

正确架构:智能体逻辑与工具执行分离

那不隔离也不行——总不能让智能体在通用服务器上横冲直撞。答案不是沙箱,而是把智能体逻辑和工具调用执行拆开

James 给了一个很妙的类比:让智能体给数据分析师生成报告,你是让它“幻觉”出一个 CSV 文件,还是让它发一条 SQL 查询给一个真正受你控制的数据库、由数据库执行查询计划导出数据?后者显然对——而智能体的工具调用也该这么干。现在出现了很多仿真层项目,它们在智能体看来像是在用电脑,但底层实际由正规的在线系统来兑现文件操作和工具调用。

于是架构变成两半:一边是一个轻量函数(比如 Cloudflare Worker 或边缘函数那种 isolate)来跑富有表现力的智能体逻辑,包括代码模式、代码执行;另一边,凡是要创建产物、查数据系统的动作,走传统数据平台——因为那是确定性的、可监控、可保证质量的软件。Anthropic 的 Managed Agents 和 Cloudflare 的 Project Think 这两篇论文,最终都趋同到了这个架构上。

Electric 的位置:原语,不带锁定

Electric 从数据层出身,做的就是给平台和产品构建者提供同样的基础设施原语——持久化流协议,适合存智能体会话数据、在其上搭协作式多智能体系统——但不带平台锁定。Anthropic 的东西很好,但它想让你用 Claude;Cloudflare 的 Durable Objects 和 Agents SDK 也很棒,但它是云厂商,你得在它的云上跑。如果你想拥有自己的基础设施,这就是 Electric 的空间。

落地门槛很低:全是开源的,网站首页就有 MPX 快速入门,跑起来就是一个运行时;你像定义请求处理函数一样定义智能体实体,可以继续用 Vercel AI SDK、TanStack AI、Mastra 这些熟悉的框架,只包一层运行时垫片就接入平台。还有内置智能体直接可用,自带派生模式、类似 OpenClaw 的管理器模式。域名刚从 Electric SQL 换成了 electric.ax——ax 指 agent experience。

【背景】MPX 大概率指软件包直接执行工具 npx 的转写误写;OpenClaw 可能是开源智能体框架 OpenClaw(转写稿原样如此)。

本集带走

  • 心智模型换掉:智能体不是计算,是数据层的会话日志;作为逻辑实体,它不在运行时也存在。把它建模成计算进程,一杀就没了、无法休眠后找回或分叉。
  • 别把线束塞进沙箱当默认架构:那会把决策痕迹埋进黑盒,SSH 翻日志不是可观测性。
  • 架构拆法:智能体逻辑放轻量函数(isolate/边缘函数)里跑;工具调用执行走正规在线系统——像“发 SQL 查数据库”而不是“让模型幻觉出 CSV”。
  • 规模推演:每个流程步骤、每次客户互动一个智能体的未来下,按虚拟机跑(各占内存)不成立,要的是能缩放到零的函数式智能体。
  • 看两篇参考:Anthropic Managed Agents 与 Cloudflare Project Think 的论文,行业已趋同于“逻辑与执行分离 + 会话持久化”架构。
  • 不想被锁定:可以用开源原语(如 Electric 的持久化流协议)自建同款基础设施,并沿用现有 AI 框架。
全部金句 3 条

我们认为多智能体系统是一个分布式数据问题。
We think of multi-agent systems as a distributed data problem.
—— James · [01:15]

所以我们要看到的关键点是:智能体不是计算,它们是数据。
And so the key thing about agents that we see is that agents are not compute, they are data.
—— James · [05:52]

当你把智能体看作逻辑实体时,你会意识到即使它们不在运行也存在,这就是为什么把它们建模为计算是完全错的,因为它们并不活在计算里。
And so when you think of agents as like logical entities, you realize that they exist even when they’re not running, which is why if you model them as compute, it’s just wrong because they don’t live in the compute.
—— James · [07:03]

接着看

顺着「智能体」挖下去

换个口味