Pylon Sync 发布 Agent-First 全栈实时框架：多智能体协作状态同步终于有了原生解法

7 月 8 日，一个名叫 Pylon Sync 的开源项目在 Hacker News 上以 Show HN 形式首发，短时间内冲上首页。项目定位很直接——Agent-First 的全栈实时框架，主打一件事：让多个 AI Agent 之间、Agent 和用户之间、Agent 和后端状态之间的实时同步，变成框架原生能力，而不是每个团队自己糊一遍 WebSocket + Redis + 状态机。

这个赛道其实已经挤了不少玩家，从早期的 Liveblocks、Yjs 到后来的 Convex、Jazz，再到面向 Agent 场景的 Mahilo、LangGraph。但 Pylon Sync 是第一个把 "Agent 是一等公民" 这件事写进设计文档第一页的框架。

一句话看懂它在解什么问题

先说个场景。你在做一个多 Agent 协作的写作应用：一个 Agent 负责查资料，一个 Agent 负责写初稿，一个 Agent 负责校对，用户随时可能插进来改一段。这里面每一个动作都是状态变更——检索结果要广播给写作 Agent，写作 Agent 的 token 要流式推给校对 Agent 和前端，用户的编辑要中断当前 Agent 的生成并让下游 Agent 感知到。

过去你怎么做？大概率是这套组合拳：

• 前端上 WebSocket 或 SSE
• 后端拿 Redis Pub/Sub 或者 NATS 做消息总线
• Agent 之间搞个 message queue，可能是 Kafka 也可能是内存队列
• 状态一致性自己写，冲突了自己 merge
• 前端拿到 delta 再自己 patch UI

代码量爆炸，而且每次加一个 Agent 或者一个新的状态字段，五个地方都得改。Pylon Sync 的核心主张就是：这些同步逻辑不该由业务开发者反复写，框架应该像 React 处理 UI 状态一样，处理 Agent 状态。

技术拆解：它到底怎么做的

CRDT 是底子，但不是全部

Pylon Sync 底层用的是 CRDT（无冲突复制数据类型），这不新鲜，Yjs、Automerge 早就在用。但 Pylon Sync 做了两件不一样的事。

第一，把 Agent 的中间状态也纳入了同步图。传统 CRDT 同步的是文档、是数据，Pylon Sync 同步的还包括 Agent 的思考过程、工具调用、token 流。这意味着一个 Agent 在"想"什么，另一个 Agent 可以立刻看到，而不用等它输出最终结果。

第二，分层同步策略。不是所有状态都需要强一致，Agent 的 scratchpad 可以是最终一致的，但工具调用的执行顺序必须是有序的。Pylon Sync 让你在字段级别声明同步语义，这个设计在框架里比较少见。

全栈的意思是真全栈

很多所谓"全栈框架"其实只是前后端在一个仓库里。Pylon Sync 的全栈是指同一份状态定义在浏览器、服务端、Agent 运行时里都能用，而且自动同步。

用它的开发者写代码大概是这样的感觉：

// 定义一个 Agent 会话状态
const session = defineState({
  messages: syncedList<Message>(),
  activeAgents: syncedSet<AgentId>(),
  scratchpad: syncedMap<AgentId, string>({ consistency: 'eventual' }),
  toolCalls: syncedLog<ToolCall>({ ordered: true }),
});

// Agent 端读写
session.scratchpad.set(agentId, 'analyzing user intent...');
session.toolCalls.append({ name: 'search', args: {...} });

// 前端读，自动响应式
const pad = useSyncedState(session.scratchpad);

前端订阅的这个 pad，任何一端更新它，其他端毫秒级看到。这个体验和 Convex、Jazz 是像的，差别在于Pylon Sync 内置了 Agent 生命周期原语：Agent 的启动、暂停、中断、切换上下文，都是框架 API，不用自己实现。

中断和分叉是原生能力

这是我觉得最值得说的一点。用户在 Agent 生成到一半时打断它，重新引导方向——这个操作在 LangGraph 里可以做，但状态怎么回滚、下游 Agent 怎么感知、UI 怎么表现，都得自己处理。

Pylon Sync 把中断做成了一等原语。任何一个同步状态节点都可以 fork，可以 rewind，可以 replay。这让 Agent 应用有了类似 Git 的时间线能力，多用户对同一个 Agent 会话做不同分支的实验也变得可行。

跟谁比？各自站在什么位置

把当前几个相关方案放一起看：

| 框架 | 定位 | Agent 支持 | 状态同步 | 全栈 | |------|------|-----------|---------|------| | LangGraph | Agent 编排 | 强 | 弱 | 否 | | Convex | 实时后端 | 弱 | 强 | 是 | | Jazz | 本地优先协作 | 弱 | 强 | 是 | | Mahilo | 多 Agent 通信 | 强 | 中 | 否 | | Pylon Sync | Agent-First 全栈 | 强 | 强 | 是 |

LangGraph 更像 Agent 界的 Airflow，擅长把 Agent 编排成 DAG，但它不管前端也不管实时同步。你用 LangGraph 做的应用，前端还是得自己接 SSE 一路 patch 状态。

Convex 是通用实时后端，Agent 是它众多用例之一。它的优势是数据库和函数一体化，劣势是没有针对 Agent 的抽象，Agent 的中断、并发、上下文切换都得业务层自己做。

Jazz 走的是本地优先路线，CRDT 玩得很溜，但对 Agent 场景的支持基本没有，更像一个协作应用的基础设施。

Mahilo 定位近似，主打人机协同的多 Agent 通信，但它偏后端，前端和状态持久化都不是重点。

Pylon Sync 想吃的是这几家中间的那块地——既要 LangGraph 的 Agent 抽象能力，又要 Convex 的全栈实时体验，还要 Jazz 的 CRDT 严谨性。野心不小。

开发者反馈：热度高，但质疑也不少

HN 讨论区目前 400+ 评论，观点相当分裂。

正面声音主要集中在几点：

• API 设计干净，比 LangGraph + 自建 WebSocket 那一套心智负担低太多
• CRDT + Agent 中间状态的组合确实是没人这么做过
• 文档和示例质量高，Show HN 少见的诚意

质疑的声音也很直接：

• 抽象太重。有开发者指出，对于只有 2-3 个 Agent 的简单应用，用 Pylon Sync 是杀鸡用牛刀，直接一个 WebSocket 就够了。
• CRDT 的心智成本。字段级别声明一致性语义听起来很美，实际用起来需要开发者理解最终一致、因果一致、强一致的区别，这个门槛不低。
• 锁定风险。全栈框架的通病，一旦选了就很难出来。Convex 已经吃过这个亏。
• Agent 运行时兼容性。目前 Pylon Sync 对 LangChain、LlamaIndex 生态的适配还比较浅，重度依赖这些框架的团队迁移成本高。

有个评论我觉得说得挺到位："这不是让 Agent 开发变简单的框架，而是让复杂 Agent 应用变得可维护的框架。" 边界在哪里，是每个团队自己要判断的。

值不值得现在上？

我的判断是看你在做什么规模的东西。

如果你在做一个简单的 ChatGPT 套壳，或者单 Agent 的 RAG 应用，别碰 Pylon Sync，用 Vercel AI SDK + 一个后端框架就够了，Pylon Sync 的抽象成本你根本不需要付。

如果你在做的是多 Agent 协作、多用户实时参与、需要中断和分叉的复杂应用——比如 AI 编程 IDE、AI 会议助手、AI 协作写作平台——那 Pylon Sync 值得认真评估。它把一些原本要自己啃三个月的硬骨头（分布式状态一致性、Agent 生命周期、实时前端同步）打包成了 API。

对模型层的选择，Pylon Sync 本身不绑定任何模型，它只管状态同步。所以你想在同一个应用里让 GPT-5 写代码、Claude 4 做审查、DeepSeek V4 处理长文本，走 OpenAI Hub 这样的聚合网关就能用一个 Key 全搞定，国内直连也方便，兼容 OpenAI 格式意味着 Pylon Sync 里怎么定义 Agent，接谁都一样。

更大的信号：Agent 基础设施在分层

退一步看，Pylon Sync 的出现说明 Agent 基础设施正在快速分层，这个信号比框架本身更值得关注。

2024 年之前，Agent 生态几乎是 LangChain 一家独大，什么都往里塞。2025 年开始分化——Agent 编排（LangGraph、Temporal Agent）、Agent 通信（Mahilo、A2A 协议）、Agent 记忆（Mem0、Zep）、Agent 观测（LangSmith、Langfuse）、Agent 沙箱（E2B、Modal）各自成为独立的品类。

Pylon Sync 抢的是Agent 实时状态层这个位置，之前是空的。这一层填上之后，Agent 应用的技术栈会越来越像现代 Web 应用——每一层都有专业选手，业务开发者只需要选型和组合。

对开发者来说是好事。三年前你要做一个像样的 Agent 应用，得自己造大半个基础设施；今天你可以像搭 React + Next.js + Vercel + Supabase 那样搭 Agent 栈。

不好的地方是选型开始变复杂了。每一层都有 3-5 个候选，怎么组合怎么迁移都是新问题。Pylon Sync 能不能在这一层站稳，看接下来半年它对现有 Agent 编排框架的集成深度，以及有没有真实的生产用户站出来背书。

Show HN 只是开始，真正的考验才刚刚开始。

参考来源

• Pylon Sync Show HN 讨论帖 - Hacker News 上 Pylon Sync 首发讨论（社区讨论）