本文是「每周 Signal｜AI × SE」第 27 期，欢迎关注和交流～
Agent Session 可以保存，但随着任务变长、多次执行和多 Agent 接力，一项工作的长期状态正在逐渐从单次 Session 中拆出来。任务、决策、产物和验证结果可能需要由更长期的 Workspace 持有，而 Agent Session 更像其中一次具体的执行。
Coding Agent 已经可以连续工作几个小时，Session 也可以保存。
但任务一旦跨过一次 Session，问题还是会出现：下一次继续工作的 Agent，到底应该从哪里知道，这件事现在做到哪了？
最直接的答案当然是读取之前的 Session。里面有用户说过什么，Agent 做过什么，调用过哪些工具，修改过哪些文件。如果 Context 太长，还可以做压缩和摘要。
这些能力都很重要，但它们主要解决的是“之前发生过什么”。而一项持续几天甚至几周的工作，还需要回答另一个问题：现在是什么状态？
这两件事看起来很类似，但其实是两个不同的问题。
假设一个 Agent 正在完成一次比较大的代码改造。
第一天，它分析了代码结构，确定了迁移方案，修改了两个模块，跑过一轮测试，还有三个问题没有解决。第二天再继续时，真正重要的信息并不是完整复现昨天几十轮对话，而是哪些方案已经确认、哪些代码已经修改、哪些测试已经通过、哪些问题还没有解决，以及下一步应该继续什么。
这些信息当然可以存在 Session History 里。但如果每次继续工作，都需要 Agent 重新阅读一大段历史，再从里面推断“当前状态”，系统其实是在反复重建一份本来可以明确保存的状态。
任务越长，这个问题越明显。Context 会越来越大，旧的 Tool Result 会被压缩，一部分探索过程会被摘要，下一次继续工作的甚至可能已经换了模型或者 Harness。
保存了 Session，仍然不等于保存了工作。
最近几个月出现的一些变化很有意思。它们解决的问题并不完全相同，但都在尝试把“Agent 的一次执行”和“长期工作状态”分开。
第一层变化，是交互入口与 Session 开始分离。
VS Code 最近推出独立的 Agent Host。过去 Agent Runtime 跟着一个编辑器窗口运行，新的架构里 Agent Host 独立存在，Editor、Agents Window 和远程客户端都可以连接到同一个 Host。VS Code 明确让 Host 持有与具体 Agent 无关的权威 Session 状态，因此关闭原来的项目窗口或者切换客户端，并不意味着这次 Agent 工作必须结束。
第二层变化，是计算环境与工作状态开始分离。
Vercel 的 Sandbox 可以按任务创建和销毁，但 Drives for Vercel Sandbox 拥有独立的生命周期。仓库、依赖和构建结果可以留在 Drive 中，再挂载给后续 Sandbox 继续使用。Vercel 甚至直接把让 Agent Workspace 跨越一次性 Sandbox 持续存在列为典型场景。
Microsoft Foundry 也在显式区分 Conversation 和 Hosted Sessions：前者保存消息、工具调用和响应，后者对应一个带持久化文件系统的隔离运行环境。即使计算资源被释放，文件状态仍然可以保存，之后重新恢复。
第三层变化，是Agent Session 开始被放回更长期的项目容器里组织。
GitHub 已经把 Agent Sessions 放进 Repository 的 Agents Tab，让 Session 与代码、Issue 和 PR 出现在同一个项目环境中。
这些设计离统一架构还很远，但它们都在处理一个越来越明显的问题：
Agent 的一次执行可以结束，而工作状态需要继续存在。
长期 Agent 一出现，我们很容易把问题归结为：Agent 需要更好的 Memory。
但这可能把很多不同的问题混在了一起。
“这个用户更喜欢简洁一点的回答”，很适合成为 Memory。
但“这个项目使用 React 19”“这次迁移还剩三个模块”“方案 B 因为无法兼容旧接口已经被否决”“当前还有两条测试失败”“刚才已经生成了一个待 Review 的 PR”，这些并不是需要模型模糊“记住”的东西。
它们本来就是这项工作的明确状态。
如果这些确定的信息仍然只能藏在聊天记录里，等 Agent 下次通过检索、摘要或者长 Context 重新“想起来”，那我们其实是在用 Memory 补一个缺失的工作状态层。
Memory 可以帮助 Agent 回忆，但任务状态、决策、产物和验证结果，更适合被系统直接保存。
这也是为什么 Context Window 越来越长，并不能单独解决长任务问题。Agent 需要的不只是看到更多历史，它还需要明确知道：这项工作现在到底处于什么状态。
长期 Agent 需要的未必是越来越大的 Memory，而是先把那些本来就属于工作的确定状态，交给更明确的状态层管理。
早期 Coding Agent 的任务通常比较短：修一个 Bug、修改代码、运行测试、提交 PR，一次 Session 往往可以覆盖从开始到结束的全过程。
现在 Agent 承担的任务越来越长。一个任务可能跨几个小时甚至几天，需要等待 CI 或外部系统返回结果；可能先在本地启动，再转到云端继续；也可能先由一个 Agent 分析，再由另一个 Agent 实现，甚至多个 Agent 同时处理不同部分，最后由人 Review。
当这些情况出现以后，Session 和工作的边界自然开始分开。
Session 更像某个 Agent 在某段时间里完成的一次具体执行，而工作本身还包含任务、代码、决策、产物、验证证据，以及不同执行之间的交接状态。
一项工作可以经历很多次 Session，但仍然是同一项工作。
这时候，一个比单次 Session 持续更久的状态容器开始变得重要。
可以把这里说的 Workspace 理解为：围绕一项持续工作建立的、独立于单次 Agent Session 的状态容器。
它不是一个特定产品，也不只是 IDE 里的代码目录或者持久化文件系统。不同系统里的具体实现可以完全不同，但它至少需要能够回答几类问题：
这项工作的目标是什么，现在推进到哪里；当前代码和文件是什么状态；哪些方案和约束已经确认；已经产生了哪些产物；哪些验证已经完成、还有哪些问题没有解决；过去又有哪些 Agent Session 参与过这项工作。
因此，一个比较完整的 Workspace 可能包含：
项目资产 + 当前任务状态 + 决策与约束 + 产物 + 验证证据 + 执行记录 + Agent Sessions
其中任何一部分都可能由已有系统承载。
在 GitHub 里，它可能由 Repository、Issue、PR 和 Agent Sessions 共同组成；在云端 Agent Runtime 里，可能是持久化文件系统、任务状态和 Session Store 的组合；在 IDE 或 Agent Host 中，也可能表现为由 Host 管理的一组项目与 Session 状态。
所以 Workspace 并不一定对应一个新的数据库或者一个新的产品页面。它更重要的意义是划出一条工作的长期状态边界。
Session 负责记录某一次 Agent 执行了什么，Workspace 则负责回答：这项工作现在是什么状态。
过去的关系更像：用户 → Agent Session → Context → 工作结果
Session 是主要容器。
另一种正在出现的结构则更像：Workspace → 提供当前任务需要的 Context → Agent 执行 → 产生代码、产物和证据 → 写回 Workspace
Agent Session 仍然重要，但它开始更像 Workspace 中的一次执行记录，而不是整项工作的唯一载体。
目前还不能说行业已经进入所谓的 “Workspace-first Agent” 阶段。VS Code 主要解决的是 Agent Host，Vercel Drive 首先还是持久化存储能力，GitHub 不同 Agent 之间也还不能无损接管彼此的工作状态。
因此目前更稳妥的判断是：
工作状态正在逐渐从单次 Agent Session 中被拆出来。
至于 Workspace 最终会不会成为新的工作中心，还需要继续观察。
今天的 AI 产品已经不只是 Chat。ChatGPT 已经明确提供 Chat 和 Work 两种体验，其中 Work 面向更长、多步骤、最终交付导向的任务。类似的产品形态也在越来越多地出现：AI 开始持续执行任务、操作文件和工具，并交付文档、表格、代码等完整产物。
当任务从一次问答变成持续几小时甚至几天的工作，产品面对的问题也随之变化。一项工作可能经历多次 Agent 执行、多个 Session，甚至不同 Agent 之间的接力。
这时，Project 或 Workspace 的意义也可能进一步变化。它不再只是把几段 Chat 和几份文件归到一起，而可能成为长期保存任务状态、产物、决策和执行证据的工作载体。
如果这种变化继续发展，真正值得关注的可能是：
从用 Session 组织一次次执行，走向用 Workspace 组织一项持续的工作。
这个变化还有一个更深的影响。
未来 Agent 很可能越来越容易替换。同一个任务可以交给不同模型和 Harness，执行环境也越来越临时：Sandbox 可以随时创建和销毁，本地任务可以转到云端，多个 Agent 也可以进入同一个项目工作。
如果真正重要的状态仍然绑定在某一个 Agent Session 里，每次切换都会带来交接成本。新的 Agent 需要重新阅读历史，重新理解为什么做过某个决策，重新判断哪些任务已经完成，甚至重新跑一遍之前已经做过的验证。
但如果这些信息已经属于 Workspace，事情会变得不一样。
Agent 进入时，只需要获得当前任务真正需要的那部分 Context；执行完成后，再把新的状态、产物和证据写回去。下一次进入的可以是同一个 Agent，也可以不是。
真正持续存在的是工作，而不是某一次 Agent 对话。
这一步现在还没有成为事实。但如果 Agent、模型、Harness 和执行环境都越来越容易替换，那么长期工作继续绑定其中某一个 Session，会变得越来越不自然。
Agent 仍然会拥有 Session，Session 也依然会被保存。
只是一次 Session，可能不再等于一项工作。
Agent 的工作，不该只存在 Session 里。
《企业研发 AI 自动化》是我持续记录 AI 进入真实研发流程后的实践系列。
它关注的不只是 AI Coding 工具本身，而是从需求输入、任务表示、Agent 执行到自动化验证的完整链路：AI 如何在真实工程系统里稳定运行，并逐渐形成可复用的研发自动化能力。
欢迎关注和交流～
