72%的工程团队说，传统敏捷工具每个迭代要白扔14小时做行政杂活。Linear 1.20和Asana 7.0都号称能把这摊事砍掉89%，但拆开看，两家走的完全是两条路。
Linear的赌法：Rust+无锁，把GC连根拔了
Linear 2025年Q3公开说过，他们把工作流引擎从Node.js整个重写成Rust。核心就一招：无锁状态机。
每个工作流实例是按工作区分片的不可变实体，状态转移靠FoundationDB底层的原子比较-交换操作硬怼。没有互斥锁争抢，1万并发转移也扛得住。实测14,000次状态转移/秒，p99延迟压到2毫秒以内。
选FoundationDB不是拍脑袋——多键原子事务+跨数据中心复制，刚好对上Linear要的数据一致性。工作区ID分片，不同团队的状态转移互不踩脚。
部署形态很极端：单二进制容器，没有JVM、没有Node运行时。客户端→边缘网关（Rust/Axum）→工作流引擎→事件存储→Redis只读副本→客户端，链路短到离谱。
Asana的解法：TypeScript全栈+CRDT混打
Asana 7.0没换语言，但架构换血。工作流运行时还是TypeScript，底层改成CRDT（无冲突复制数据类型）叠加事件溯源。
相比6.0版本，冲突解决开销降了67%。关键设计是运行时和前端共用同一套TypeScript代码库，类型安全全栈贯通。
链路比Linear长一截：客户端→NGINX负载均衡→API网关（NestJS）→工作流运行时→PostgreSQL事件存储+Redis CRDT注册表→GraphQL读取层→客户端。但"长"有长的道理，前端后端同语言省掉大量序列化摩擦。
省钱的账怎么算
从Jira迁到Linear 1.20的团队，每10个工程师年省2.1万美元行政工具开销。Asana这边没给具体数字，但CRDT减掉的67%冲突处理成本，换算成工程师时间也是实打实的。
Gartner预测到2026年Q3，B轮后创业公司里60%会把敏捷工作流标准化到这两款工具之一。不是Jira用不起，是14小时杂活堆到第N个迭代，团队真的忍不了。
两条路的本质分歧
Linear押的是极致性能：Rust无锁、单二进制、毫秒延迟，适合状态转移爆炸的大型工程团队。Asana押的是开发体验：TypeScript全栈、类型共享、CRDT保最终一致，适合产品工程混编、迭代节奏快的组织。
一个把运行时砍到骨头，一个把运行时和前端焊成一体。没有银弹，只有场景错配。
热门跟贴