智能体会持续干活后，企业该怎么管理它的工作现场？

一个智能体完成一轮问答，留下的往往只是一段对话；但它如果要连续数小时分析数据、改多份文件、等人工确认，再交给另一个智能体复核，真正的交付就不再只是“答案”。任务进行到哪里、用了哪些文件、谁能继续打开、暂停后如何恢复、结束后什么该保留，都会决定这段工作能否被接住。

9月，云厂商开始把这件原本藏在工程细节里的事做成产品：OpenAI发布Agents API时，将长任务所需的上下文、工具协调、运行环境和中间产物并列；Google随后为智能体沙箱推出专用持久工作区。信号很明确：智能体要进入生产，不只是多了一个会调用工具的“同事”，而是多了一种需要被管理的工作现场。

任务一旦跨时段，文件现场就成了业务上下文

OpenAI在9月10日的发布中，把“可持续数日运行”“处理上下文、工具与子智能体”和“保存中间结果的环境”放在同一套能力里。其客户Nash称，物流场景的长任务可能跨越数小时或数天，需要持续处理上下文、恢复和多步骤执行；这是客户案例，不代表所有企业都会获得同等效果，但它提示了任务形态的变化：智能体做的已不是一次性生成，而是一段可暂停、可续跑、可交接的工作。

当任务跨越人、智能体和时间，文件、草稿、运行记录与待确认项不再是附件；它们共同构成了“这件事做到哪里”的业务事实。

过去，团队习惯按应用给权限：谁能用CRM、谁能进知识库。现在还需要按任务给现场：这个任务能读写哪一份目录，能安装或调用什么，产物是否允许共享给复核智能体，等待审批时是否应冻结，超时后由谁接管。没有这些定义，前一个智能体留下的文件可能找不到、被错误复用，或在不该共享时被带入下一轮工作。

平台在补的，不只是存储，而是隔离、恢复与协作

Google 9月16日发布的智能体工作区存储，明确瞄准大规模沙箱：每个任务启动时自动附加一个隔离、持久的文件工作区；闲置沙箱可以暂停，收到新输入后再恢复；多个智能体也可在同一工作区内协作，并用文件锁避免写入冲突。它目前面向非生产工作负载开放、生产支持仍采用准入名单，因此不是一项可直接套用的成熟通用结论，却把企业未来要解决的三个问题说得很具体。

第一是隔离：不同客户、不同任务和不同权限等级不能因“临时文件”混在一起。第二是恢复：任务暂停并不等于任务结束，恢复时应找回同一版本的资料、状态和待处理事项。第三是协作：研究、执行、质检三个智能体共享一份项目材料时，谁能改、谁只读、谁能签收，必须像团队协作一样被写清楚。

别只配置工具，给每项任务一张“工作现场卡”

我建议企业从最常见的长任务开始，先做一张轻量的“工作现场卡”，而不是急着重建整套基础设施。卡上至少写五件事：任务目标和最长运行时间；允许读取、写入与共享的资料范围；可调用的系统和临时凭证；暂停、恢复、超时与人工接管的规则；以及任务结束时应归档、删除或回写知识库的产物清单。

这张卡的价值不在于多一份表，而在于把“工作环境”从默认配置变成可审阅的业务决定。比如市场智能体整理竞品时，可以保存公开素材与分析草稿，却不能把客户名单带进共享目录；财务分析任务可以等待业务确认，但超过约定时间必须冻结，不应自行沿用过期数据；复核智能体可以读取初稿和证据，却不应覆盖原始结论。这样，工作区才不是一个不透明的临时盘，而是责任清楚的任务容器。

STARBOX视角：把工作现场沉淀为可复用的交接能力

在STARBOX的组织—BOX—智能体三层里，组织层不只决定谁能使用智能体，也应定义哪些任务可持续运行、哪些资料可共享、何时必须接管；BOX不只放知识，还应保留任务卡、已确认版本、交接记录和可复用产物；智能体才在这套边界内执行、暂停、协作与回写。DDABC闭环里的Analyze可以找出频繁中断或反复返工的现场，Benchmark比较恢复时效与交接成本，Calibrate再把有效的目录、权限和交接规则固化下来。

我的判断是，未来企业管理智能体的最小单位，既不是一个模型，也不只是一个Agent名称，而是一段有边界、有状态、可交接的工作现场。谁能先把这种现场标准化，谁才更可能让长任务从“跑得出来”变成“接得住、复用得了”。