07.1 · Workspace：报告生成了，为什么还不能交付？

Workspace把任务输入、执行中的工作文件和正式产物分开管理，让一次执行结束后，系统仍能找到并核对交付结果。

本课的位置：Workspace位于右侧文件与执行环境层，保存当前任务的输入、工作文件和正式产物。

下面用一个教学设例说明：用户交来“背景、方案、待办”三份资料，要求Agent整理成一份导航和一份摘要。模型已经生成正文，但导航还在写，用户此时点了下载。系统应该返回哪一版，服务重启以后又该从哪里找到它？

问题落在工作空间层。Harness安排当前Run，执行器在工作空间内处理资料，产物服务只向用户开放已经提交的结果。聊天里出现“已完成”这句话，不能代替文件交付事实。

同一个任务中的文件，为什么不能放在一起随便改？

三份原始资料是输入，清洗后的文本、处理脚本和临时表是工作文件，最终导航与摘要才是候选产物。它们承担不同职责，修改规则也不同。

输入按快照固定并只读提供。处理过程中发现标题不统一，就在本次Run的工作区生成规范化副本，保留原件及其来源。用户中途更新资料时，系统要明确继续使用旧快照，还是推进要求版本重新处理；不能前半段读旧资料、后半段读新资料，却仍声称整份报告基于同一版本。

不同Run拥有独立写入位置。两次任务都生成“资料摘要”，名称相同也不会覆盖。一次Run恢复后还可以使用新的尝试目录，避免旧执行者的半成品混入新结果。

目录结构表达归属，真正的限制由访问接口、只读挂载和执行身份落实。文件工具要拒绝越界路径与符号链接逃逸，执行器也不能凭同等系统权限任意访问其他任务。工作空间负责文件组织，沙箱负责进程、文件与网络等隔离，两者需要配合。

普通后端导出任务也需要这些安排。Agent的步骤和处理代码可能动态产生，因此还要关联实际使用的处理方案，而不是只记录一个模糊的“生成报告”动作。

哪一步才算真正交付？

如果最终下载地址直接指向正在写入的摘要，用户可能拿到半篇内容；若摘要已经更新、导航还是旧版，也会得到一套内部不一致的文件。

解决办法是先准备一个完整候选版本，再统一切换正式引用。候选在暂存区写完并关闭，产物服务核对内容和文件集合，通过以后才让正式入口指向它。

这里用到manifest，即产物清单。它说明这个版本属于哪个Run、基于哪份输入快照、包含哪些文件，以及每个文件的长度和内容摘要。摘要根据字节计算，可以发现文件传输或存储后的变化；它不能证明摘要中的业务结论正确，那是下一篇输出校验的职责。

清单核对要排除缺文件、多余文件、越界路径和不允许的文件类型。否则一份临时日志也可能随着报告一起暴露。正式产物保持不可变，修改内容就生成新版本。

原子发布的目标是让读者看到旧的完整版本，或新的完整版本。比如系统用一个current引用记录当前版本：先让v2的导航、摘要和清单全部就位，再切换current。切换就是对读者的可见提交点，不必把多个文件逐个覆盖到旧版本上。

读者开始一次下载后，还要固定这次读到的版本引用。不能每取一个文件都重新读current，否则下载导航和下载摘要之间恰好切版，仍可能混用两个版本。

生成服务在切换前退出，会留下什么？

假设v1已经正式交付。生成服务准备好了完整v2，却在切换current之前异常退出。恢复服务重新读取正式引用，仍然得到v1；v2虽然存在，但没有被提交为当前版本。

这时不能按修改时间挑最新目录，也不能把所有暂存文件直接开放。v2可能只差最后一步，也可能因业务校验不通过而被留下；“文件存在”没有说明它是否获准交付。

恢复流程先核对正式引用及其清单，再恢复服务；未引用版本等待后续判断或回收。清理前要确认没有活跃任务仍引用这些文件，并遵守保留期限。缓存可以重新下载，尚未提交的工作结果可以重新计算，已经交付的产物和操作账本则承担不同的保留责任。

如果清单和文件不一致，系统应阻止这份交付，并定位到具体版本与文件，而不是用旧缓存悄悄补齐。清单本身也要来自可信的产物服务；攻击者若能同时改文件与清单，摘要一致仍不能证明内容可信。

文件指针、数据库指针和对象存储怎么选？

单机、文件不大、单个发布者时，“完整版本目录＋小型引用”容易理解和恢复。在支持相应语义的同一文件系统内，重命名可以实现名称替换的原子可见性。

但原子可见与断电持久是两件事。文件同步将内容推进到存储，目录同步涉及名称与引用是否持久；实际保障取决于操作系统、文件系统和设备。不能把一次重命名成功解释成任意硬件故障下绝不丢数据。跨文件系统移动、多个对象上传，也不能直接套用一次目录重命名的语义。

多个执行者可能同时发布时，还要防止旧任务后写覆盖新任务。数据库适合保存小型引用与版本条件：只有当前要求、持有者和引用版本仍匹配，才允许切换。条件不成立就放弃发布，不因为文件已生成而强行覆盖。

数据库事务只控制元数据。大文件可以先写入独立存储，再提交引用；引用回滚不会让已上传文件自动消失，孤立文件仍需回收。

对象存储适合多机器共享与大文件交付，但需要分别处理上传完成、内容校验、引用提交。采用不可变对象身份，验证完整性后通过支持条件写入的入口切换清单引用，避免同一个对象名在校验后被覆盖。代价是状态更多，也更依赖清楚的元数据账本。

保存工作快照以后，能恢复到哪一步？

快照应对应一个明确步骤边界，关联输入版本、已保存代码、中间结果、依赖与环境、下一步骤，以及已经确认的外部操作。边写文件边随意复制，得到的未必是可接续状态。

固定运行时、依赖锁文件和镜像摘要，可以提高环境可重建程度；模型版本、远端数据和随机性仍可能变化。要复核已经交付的结果，保留原输入、实际处理过程和原输出，通常比要求模型再次生成更可靠。凭据只保留需求或引用，不装进通用快照。

文件恢复也不会撤销外部动作。假如v1已经发送，工作目录后来回到“发送之前”，原来的发送事实仍然有效；如果回执未知，先按原操作ID对账，不能从目录状态推断“尚未发送”。

工作空间让文件交付有了归属、版本和提交点。下一篇把执行交给云端：客户端断线、两个运行器争抢、旧运行器迟到时，系统怎样守住同一个任务的执行资格？