智能体也需要一张回程票

笔记本合上了，智能体还在工作。听起来只是省了一点麻烦，直到你追问：跟着它搬到云端的，究竟是什么？

代码？没做完的任务？读取仓库的权限？还是发布成果的权力？这些是不同的乘客。给它们同一张登机牌，可能换来一笔意外昂贵的糊涂账。

结论很简单：智能体也需要一张回程票。 迁移长任务之前，先说明它到达目的地后拥有什么权限、权限如何终止，以及哪些证据必须带回来。有价值的产品，是在约定边界内产出的可审阅成果。连续工作了多少小时，单独看并没有那么大的解释力。

Docker在9月24日发布Cloud Sandboxes，让这个问题变得及时。公司将其描述为运行在Docker托管算力上的microVM环境，可通过与本地相同的命令行界面使用。这是厂商的产品说明，不是我出具的安全认证。Docker announcement

行李箱与护照

想象一家小软件公司，只有一位创始人，外加一个热情十足的编程智能体。任务很普通：更新公开演示项目，运行测试，准备补丁。创始人想合上电脑去吃饭，智能体想安装三十样东西。双方的诉求都可以理解。

在笔记本上，一些边界可能早已藏在环境配置里。智能体只能看到特定工作目录；某些凭证在它够不到的地方；本地服务有熟悉的地址。创始人可以随时中断进程、检查文件。任务搬走后，这些假设成立的环境也跟着变了。

行李箱装的是任务状态：源文件、中间结果、日志，以及恢复工作所需的上下文。护照代表授权：能用哪些资源、能产生哪些实际效果、授权有效多久。行李完好抵达，并不能证明护照在目的地仍然有效。

Docker的对比文档给出了具体区别：本地与云端沙箱使用不同的秘密存储和网络策略，本地策略不会自动复制过去；云端任务也无法访问主机路径。因此，界面相同，并不能证明实际访问能力相同。Local and cloud comparison

这个区别对买家很有用。它把模糊的迁移承诺，变成一个能回答的问题：请展示这个目的地，在这套配置下，究竟能接触哪些资源。

权限里必须有动词

目的地地址只是权限的一部分。读取仓库、提出修改、删除仓库，都可能发生在同一个服务上。如果权限审查只写下服务名称，最有后果的那部分决定就可能消失了。

回到想象中的演示项目。读取公开文档符合任务；在临时工作区里准备补丁，也符合任务。以公司身份发布一个版本，则是另一个实际效果。下午工作得很出色，并不会让智能体自动从研究员升任发布负责人。

我会用允许产生的效果来描述任务：获取指定公开输入，修改任务专属副本，交回补丁和测试报告。这个返回包就是产品。如果还要对外发布，就应有对应的既有授权，明确目的地和发布程序。

Docker的Kit Specification v3公告介绍了如何把智能体环境与声明的能力打包成OCI镜像，示例可以区分HTTP方法与路径。声明让审阅者有具体内容可看；适用的策略，仍需由实际运行环境执行。Kit specification announcement

由此可以养成一个操作习惯：比较两台机器之前，先比较两份授权。搬迁一个只需要更少权限的任务，可以很容易。搬迁一个悄悄继承更多权限的任务，也可能容易得令人误判。

没听见告别的进程

委托最有意思的部分，往往出现在欢迎仪式之后。有人取消任务、撤销凭证，或发现原来的授权太宽。问题从“智能体能否开始”，变成“它现在还能不能行动”。

Docker的9月21日版本说明披露了一项已修复问题：OAuth或API-key凭证被撤销后，正在运行的代理仍可能保留授权，直到沙箱重建。这里说的是历史缺陷及厂商报告的修复，既不能据此认定当前版本仍有同一问题，也不能声称我们已测试所有撤权路径。Release notes

这个教训容易被忽略，因为两个屏幕可以很客气地各说各话。管理界面显示权限已经结束，另一处的进程却仍持有可用授权。整洁的设置页面，此时更准确地描述了意图，而非真实行为。

如果做验收，我会先让一个无害请求在测试服务上成功，再沿正常控制路径撤销测试授权，随后让同一个仍在运行的工作进程重试。关键观察是：撤权之后，它实际上还能做什么。先把一切重启，再测一次，回答的就是另一个问题了。

这只是拟议测试，我没有对Docker执行它。测试需要可丢弃凭证，以及专为无害检查设计的服务。拿生产密钥来试，等于给一场讨论如何限制实验边界的谈话，额外塞进一个完全没必要的实验。

成果必须有路回家

云端是执行工作的地方，不应成为所有者唯一能够查明发生了什么的地方。在这个例子里，创始人最终要的是补丁、准确的起始版本、真正执行过的测试，以及仍未解决的限制。一句“一切顺利”，只是附信。

回程票，就是关于这些证据的一份小合同。开始之前，说明预期文件及接收目的地；结束之后，验证收到的文件就是约定成果。如果任务在交付前终止，执行或许结束了，价值却还悬着。

Docker云端文档说明，这项支持仍处于实验阶段，需要有效订阅和云端专用凭证。文档也提醒，沙箱到期时，可恢复的沙箱可能被停止，其他沙箱可能被删除。因此，要依赖无人值守任务，先弄清留存规则。Cloud documentation

这引出一个更普遍的设计选择。只在最后导出，意味着全部成果都押在最后一步上。长任务可以用中间检查点降低恢复成本。检查点应保存任务证据，排除不必要的凭证；把整个环境复制回来，反而违背了缩小返回包范围的初衷。

成果还需要一个读者。一千页日志可能在技术上可访问，在运营上却几乎不可用。简短结果、一条可复现的验证命令、一项说清楚的例外，往往是更好的交接，详细记录则保留在后面供查阅。

回执应把什么分开

我会给这个虚构项目列五行状态：输入已确定、工作已执行、检查已通过、成果已收到、发布已获授权。每行回答不同的问题。分开记录，才能避免一次测试成功，被说成用户已经收到结果。

例如，补丁可以已经完成，而测试因公开依赖不可用，尚无定论。正确回执应保存补丁，并指出缺的是哪项检查。扔掉补丁，会丢失有用工作；宣布全部通过，则会虚构有用工作。

另一个情况更微妙。工作进程完成测试并导出文件包，接收方却发现它基于另一版代码。双方可能都正常运转，却在讨论不同的工作。回执需要输入和输出的身份标识，让所有者能定位分歧。

Docker的使用指南列出了文件传输与沙箱生命周期操作。这些机制是交付的组成部分，却不会替某家公司决定成果是否达到验收标准。这个判断应写进任务合同。Cloud usage guide

下图是我的概念框架，刻意保持简单：确定目的地授权，执行有边界的任务，带回可识别的成果，再验证它。撤权与到期留存始终要考虑在内。图中没有任何实测的厂商性能结论。

无人值守工作的真实价格

智能体演示中最吸引人的数字，往往是连续工作且不被打断的时长。创始人需要另一个数字：拿到一个合格成果的总成本，包括算力、模型调用、人工审阅、失败尝试及恢复。长时间执行，可能有生产力，可能浪费，也可能只是还没做完。

假设两套虚构安排产出同样合格的补丁。一套很快结束，却需要花很久追查文件从哪来；另一套慢一些，却清楚列出相对已知起始版本的变化。如果不计审阅和恢复，第一套就可能因为错误的原因显得便宜。

这里还有排队问题。启动许多工作进程，只有在有人或某个机制能评估其输出时才有用。如果审阅能力固定，输出却越来越快，公司可能积累大量尚未验收的工作。屏幕上的任务徽章一片绿，创始人的晚上却被标签页塞满。

这些分析没有证明云端执行比本地更贵。它们说明比较需要怎样做：使用相同任务、相同验收条件，以相同方式计算失败尝试，并计入获取和理解证据的时间。否则，比较的是不同产品。

投资人对应要问的是厂商的持久价值：服务是否降低客户的总监督负担？是否让困难工作变得可行？客户是否因为合格成果改善而续约？发布公告无法独自回答这些问题，方便的迁移界面也只是其中一环。

一个小型验收练习

这位虚构创始人不需要复杂试验，也能学到有用的东西。选一个公开仓库，安排一项正确性容易检查的有限修改，明确起始版本、允许的输入、可写输出目录、预期补丁，以及一条确定性的测试命令。无须客户信息。

比较环境之前，先冻结验收条件。正常执行必须交回预期成果、输入身份及实际测试结果。被拒绝的目的地应继续不可访问。测试授权撤销后，已运行的进程必须在事先声明的操作时限内失去对应能力。时限应预先选定并实际测量，这篇文章没有虚构任何耗时结果。

然后，一次只引入一种中断。让操作员断线；在一次可丢弃的测试中，让任务触及留存期限；中断返回传输，再检查接收方是否能分清半成品与完整包。这些是不同故障，立刻混在一起，只会让证据更难解释。

记录每个尝试，包括失败和根本未能运行的情况。两种环境使用相同工作与审阅规则。如果试验需要超出任务范围的权限，就停止。一个有用结论也可能只是清楚的限制：这类流程能顺利迁移，那个依赖则需要另一种设计。

这项提案尚未执行。我阅读了所引文档，并形成验收规格；没有衡量迁移可靠性，没有运行云端任务，没有开通付费账户，也没有测试生产凭证。这些边界很重要：好问题本身就有价值，无须假装成已完成的实验。

出发前，先把合同说清

下一个有用里程碑并不宏大：工作进程带着具名任务出发，在可审查的目的地授权范围内运行，交回所有者能够验证的成果。权限结束时，它应失去对应行动能力；执行结束时，证据应按约定留存。

随着这个市场发展，我会观察四件事：声明是否变成真正的运行时控制，撤权是否触及现有进程，成果能否经受中断交接，以及每个合格成果的总成本是否改善。每一项都需要自己的证据，成功展示其中一项，不能替其他项结案。

对创始人，眼下的行动是在选择迁移路径之前保存这张验收卡。对评估供应商的读者，请对方展示一次完整旅程，包含返回过程和一次受控失败。答案应说明哪里成功、哪些资源仍不可访问，以及什么还需要人作决定。

理想的未来其实很普通：笔记本合上，智能体工作，可审阅的成果送达。创始人安心吃饭，无须顺手接管一个看不见的运维部门。这个目标比让机器忙整夜更好，也足够明确，可以拿来测试。

分类与关键词

分类： 智能体基础设施；系统工程；企业软件。

关键词： 云端沙箱；有效权限；凭证撤销；成果返回；合格成果。

Hashtags: #AgentInfrastructure #SystemsEngineering #EnterpriseAI #IAmRobin