Josh Rosen - Local Workspace, Remote Work
Josh Rosen（@JoshARosen）2026-08-27 的长文推文，29 赞。论点：我们想让 agent 自主运行、并行协作、睡后持续工作，却把全部状态放在”碰巧在哪台机器跑”的本地文件系统上——等于用”worker 与工作同址”的存储模型构建分布式系统，这是一个巨大的架构矛盾。核心主张浓缩为口号：workspace 留本地，work 搬远程（详见 Agent 状态分层）。
要点
- 本地文件系统是 coding agent 成功的基石，也是天花板：稳定路径、跨模型调用持久化、增量编辑、数十年 Unix 工具链——没有它很难想象 agent 达到今天的能力。问题出在它成为权威记录（authoritative record）之后。
- 多 agent / 多机后立刻撞上分布式经典问题：哪份 plan 是最新的？两个 agent 能否同时更新同一任务？远程 agent 需要 developer 笔记本上的状态怎么办？隔夜完成的成果如何被发现？事件触发的 agent 如何保证读到与创建者相同的状态？
- Git 解不了这个题：源码本就有强 merge/versioning 模型，Git 顺手；但执行态是活的——plan 几分钟一变、任务在 unclaimed→claimed→blocked→complete 间流转、中间结果需要立刻对其他 worker 可见。把它当文件意味着在文件系统上重建同步、锁、新鲜度与生命周期语义。
- MCP 正在反映 workspace / work 的划分：2026 年 7 月 spec 去除 session affinity，请求可由水平扩展的实例独立处理（agent 的交互不再绑定单一本地有状态进程）；Tasks 原语让操作返回可回查/更新的 handle，roadmap 讨论部分结果、steering、长时操作（durable work 活在协议后面而非发起进程里面）；Resources 方向未定但维护者讨论过让它更像远程文件系统（层级访问、put/upload 语义）。
- 落地路径——先给 work 建模：识别 agent 工作中存在的概念（goals / plans / tasks / findings / decisions / evidence / approvals / deliverables），赋予类型、稳定身份、相互关系，形成”活的工作模型”（goal→plan→task，finding 支撑 decision，decision 改变后续）。agent 推进时增改这个模型而非留下一堆孤立文件。经 MCP 暴露（发现、跟随关系、增改对象、生命周期流转）；底层 Postgres / 现有应用库即可。从一个 workflow 的几个核心概念起步，不必一次建全。
- 趋势判断：agent 正走出交互式 CLI session——异步运行、事件唤醒、跨机执行、互相交接、job 持续数小时到数月。做功的进程越来越临时，work 的模型不能临时。agent 要从 CLI 助手 scale 成持续运行的系统，算力会进云，durable work 必须跟着走。
值得留的原话
- “We are trying to build a new generation of distributed systems around a storage model that assumes the worker and its work live in the same place.”（开篇）
- “Local files are a great working surface, but they are a poor canonical state layer for distributed agents.”（Local State 一节收束句）
- “The process doing the work will become increasingly temporary. The model of the work cannot be.”（结尾）
- “If agents are going to scale from CLI assistants into continuously running systems, their compute will move into the cloud. Their durable work has to move with it.”（结尾）
评论区
- @DanielNguyenHQ：文件系统是很好的 scratchpad，但一旦 worker 会消失就是糟糕的 source of truth；两个 agent 需要同一份 plan 时，所有权与状态流转比路径更重要。
- @semanticbeeng（KSE）：状态管理确实要解决，但这些问题过去 20 年分布式有状态系统已有答案，应在此基础上建，而不是从文件系统出发。
与已有页面的关联
- Agent 状态分层：本源新建的概念页，承载核心主张（workspace ephemeral / work authoritative）。
- Agentic Memory 的姊妹问题：memory 论”agent 记什么”，本源论”agent 的工作状态存哪、谁权威”——一个偏内容（知识），一个偏基础设施（分布式状态层）。评论区”20 年分布式已有答案”的提醒与 Agentic Memory 里”先借鉴已有系统”的立场同调。
- Agent Fleet 管理 的基础设施前提：fleet 委派、隔夜工作、跨机移动之所以可行，前提正是有共享权威的 work 状态层；Grok Bot 的”共享云电脑”其实已经是一种朴素实现。
- LLM Wiki / 本库的自指视角：brain wiki 本身就是”work 住在远程权威层（git 仓库）而非 agent 本地会话”的小型实践——agent 每次会话都从 wiki 重建上下文，durable state 全在库里。
- MCP 首次在库内出现（2026-07 spec 去 session affinity、Tasks 原语、Resources 远程文件系统化），暂记于本页，待第二个来源出现再建页。