这次实验里，文件真的写成功了。
我们通过 CodeFlowMu 的真实受控文件执行器完成写入，再启动另一个进程读取文件。读回内容的 SHA-256 摘要，也就是用来核对字节是否一致的内容指纹，与执行回执里的事后摘要完全相同。
接着，我们做了一件很普通的事：把这份文件在实验目录里改名，保留全部内容。
原来的路径现在找不到文件了，历史回执却仍然是 succeeded，即执行成功。
这里没有丢失事故，也没有矛盾。回执正确记录了当时的写入；路径检查正确回答了现在能不能从原位置取回文件。
改名只是一个最小干预。我们要检查的不是“改名后路径会变”这条文件系统常识，而是：当成果的当前可用性发生变化时，历史执行回执究竟还能支持什么判断？
容易出错的不是这两条记录，而是把它们压成同一个“任务成功”。 当 Agent 要跨进程、跨工作区甚至跨远程环境长期工作时，这个差别会影响下一轮拿到什么，也会影响人最终收到了什么。
1. 我们批准的，是一份内容，还是一次具体操作？
先把镜头从“写完以后”移到“写入之前”。
CodeFlowMu 是我们在开发的本地多 Agent 协作系统，通过任务文件、执行会话和证据组织工作。它的受控文件操作不只是收到一段文本就写入，而是构造请求、取得批准，执行前再核对请求。
这条链里有两个容易混淆的摘要。
一个是内容摘要，回答这些字节是不是同一份内容。另一个是操作摘要，回答这是不是先前批准的那次具体操作。相同文本写入不同工作区，或者用于不同任务，内容可以相同，操作身份却不应被想当然地视为相同。
为了确认现有系统究竟绑定了什么，我们在固定基线 c008d9db91a21136fc61a4f60314e22db395d5d2 上，使用真实请求构建器做了四组对照。每组在新建的独立实验目录中跑两轮。
| 对照 | 实际观察，两轮一致 | 它排除了什么误解 |
|---|---|---|
| 相同工作区、任务与请求，重新构造 | 操作摘要相同 | 相同输入不会无故变成另一份批准对象 |
| 批准后，目标从不存在变成已有其他内容，再重新构造并执行 | 返回 APPROVAL_STALE；本次执行器未产生文件效果 | 原批准不能直接覆盖已经变化的目标 |
| 拟写字节相同，换一个工作区 | 内容摘要相同，操作摘要不同 | 内容相同不代表执行位置相同 |
| 工作区和内容相同，换一个任务 | 操作摘要不同 | 同一位置、同一内容也不能代替任务身份 |
第二行尤其重要。我们不是只看到“摘要变了”，就认定保护有效，而是继续尝试执行。结果是旧批准被判定为不再适用，介入实验的那份新内容没有被覆盖。
这四组的验证深度并不相同：更换工作区、任务的两组只验证了操作摘要不同；目标变化那组才进一步走到旧批准在执行时被拒绝。请求身份被区分，不等于所有跨工作区、跨任务的执行路径都已完成验收。
源码也解释了这一结果：请求包含工作目录、任务主体与目标快照等信息；执行入口重新构造请求，再由审批服务比较操作摘要。
这组对照因此明确了可复用的起点：请求已经纳入工作区与任务身份，受测目标变化也能使旧批准不再适用。
2. 写入证据很扎实，为什么还不能回答现在的交付？
第五组实验专门看写完以后的事情。
受测执行器先写临时文件，再通过重命名形成目标文件，随后返回目标的事后快照。我们使用独立进程读回，核对内容摘要；再在实验目录内把成果改名保留，分别检查原路径和历史回执。
| 观察时点 | 当前文件事实 | 执行证据 |
|---|---|---|
| 真实执行器写入完成 | 目标文件存在 | 回执为成功，包含事后摘要 |
| 新进程重新读取 | 读回摘要等于回执摘要 | 成功不是只存在于原进程的内存里 |
| 在实验目录内改名保留后 | 原路径不存在，保留副本存在 | 原执行回执仍为成功 |
两轮结果相同。新进程读取证明了这次文件写入可以被另一个进程看到，但不是断电恢复实验，不能据此承诺断电后的所有持久化行为。
图 1：对应 B4：这是同一份文件的三个观察时点，不是三份独立成果；改名后完整字节仍在保留位置，没有删除文件。 来源：本文受控实验，AI 绘制的解释图。
这个对照看似简单，却能纠正两种相反的做法。
第一种是过度相信历史成功：既然当时写入成功，交付时就不再检查成果位置。
第二种是为了保持一个状态“看起来一致”，把原来的成功改成失败：现在原路径没有文件，所以当时一定没有写成。
两种做法都丢掉了时间。前者用过去替代现在，后者用现在篡改过去。
更准确的表达应当同时容纳：当时写入了哪些字节；这些字节属于哪个任务、哪个工作区；现在从哪里取回；谁在何时确认它满足交付要求。
本轮没有调用业务验收流程，因此不能写成“验收把缺失成果判成了通过”。我们验证的是执行证据的职责边界，不是在给整个验收系统定罪。
3. 远程沙箱把这个差别变成了更昂贵的问题
如果所有文件都在一台长期存在的电脑里，这个差别有时只是一次路径核对。换成会被替换的远程执行环境，它就可能决定上一轮劳动能否保留下来。
Paperclip 是组织 Agent 工作和执行状态的开源系统；Daytona 提供远程沙箱，也就是用来运行代码的隔离环境。Paperclip 的 #12901 变更描述了这样的问题：成功一轮的修改可能只留在远程沙箱，复用环境时看似正常，替换环境后却可能从旧的宿主数据重新开始。该变更在成功收尾前导出并合并成果；只恢复工作区时不再提交一轮模型执行；无法取回未导出字节时明确阻断。核验截至 2026 年 9 月 6 日，该 PR 已合并，但作者注明没有在本地运行付费 Daytona 套件，我们也未独立复跑远程测试。
这份外部材料与本地改名实验不是同一种故障。它们相遇的地方，是同一个问题：“执行端已经做成”与“后续工作能从约定位置接着用”，中间还有没有一段需要确认的交接？
本地改名对照回答不了远程导出和合并是否正确。远程项目的变更，也不能反过来证明我们的产品有同样的部署链或同样的数据风险。
我们检索了 CodeFlowMu 本轮研究范围内的运行时与界面层源码，未找到与该 Daytona 导出、同步恢复链对等的产品实现。这是限定范围内的未发现，不是对所有依赖或用户部署的全局断言。
因此，当前结论不是“赶快造一套远程工作区系统”，而是先确认真实使用场景是否需要这次交接。外部问题提供了方向，不能替产品需求提供事实。
4. 长期任务需要的，是有位置、有归属、有时点的成果
对长期工作的 Agent，恢复任务描述还不够。如果下一轮读到的是旧文件、另一个工作区的文件，或者无法核对归属的产物，即使对话还接得上，工作基础也可能已经不同。
这不意味着每个团队都必须引入一个新的制品平台。对于实际存在成果交接的系统，可以先用五个问题检查既有流程：
- 交付位置在哪里？ 哪个目录、仓库提交或存储对象是认可的成果来源，而不是执行时的临时副本？
- 这是谁的成果？ 能否关联到任务、执行记录和工作区，避免只凭文件名认领？
- 内容是否一致？ 核对的是实际字节，还是“文件存在”和模型的一句说明？
- 什么时候检查过？ 上一次写入时的证据，不能直接当作当前交接检查。
- 谁做业务验收？ 执行器证明写入，不意味着它有权宣布内容正确、任务完成。
这些是由本轮证据推导的检查建议，不是 CodeFlowMu 已经新增的一套接口或冻结开发任务。
如果真实部署有远程环境，还应追加“环境替换”对照：保留成果后换一个执行环境，核对下一轮得到的身份和字节；交接失败时，区分补交成果与重新执行原动作。前者是在搬回已有劳动，后者可能再次产生外部效果，不能仅用一个“重试”按钮混在一起。
反过来，如果只是本地工作区操作，现有精确请求绑定、事后快照与明确的交付检查可能已经足够。研究的价值，也包括证明某个方向现在不必开发。
5. 不要让一个“成功”承担所有责任
本轮研究留下的是两条同时成立的判断。
一条是肯定：受测请求的操作摘要能够区分工作区、任务和目标变化，目标变化场景进一步验证了旧批准被拒绝；真实写入结果也能够通过新进程读回确认。
另一条是边界：历史回执证明过去发生过什么，不天然承诺成果永远留在同一路径。当前可用性和业务交付需要各自的判断，不能从一次成功写入直接推出来。
工程上的下一步，是在真实交付入口核对位置、归属、字节和检查时点，再判断既有流程是否足够，而不是先假定需要一个新的存储项目。
对长期 Agent 来说，“做成过”是一条值得保留的历史；“现在交得出来”，是另一条需要核对的事实。
证据与范围
本篇使用五个工作区场景，每个两轮，共十条受控观测。原始记录是 boundaries-1788695589568.json 中的 B0–B4；双语证据包提供源码映射、逐轮脱敏数据、研究探针和完整性校验。公开包去除本机路径和进程编号，保留全部观测；记录校验不等于产品复跑，后者仍需有权访问固定源码及其依赖。
本研究没有生产丢失率样本，没有运行断电、远程沙箱删除、真实远程同步或并发分支合并，也没有执行 PM/QA 业务验收。写作阶段复核了既有记录，没有把复核说成新一轮产品实验。成果改名后保留完整副本，从未删除用户文件。
你们的系统在交付或接管时，会重新核对成果位置和内容吗？
