员工关掉电脑后，Agent还在追踪项目、读取邮件、调用工具，甚至准备处理下一条任务。这样一名“数字同事”需要什么？Microsoft的Autopilot给出产品层面的答案：长期目标、独立身份、记忆、计算环境和工作区。Docker同期推出Cloud Sandboxes与Kits，给出执行层面的答案：隔离运行、跨设备迁移，并把工具、网络和凭据边界随Agent一起封装。两家公司进入路径不同，却共同指出企业AI的下一道关口：让持续执行的Agent有明确的身份、受控的工作空间和可追究的动作记录。
这件事比“聊天框又多一个按钮”严肃得多。一次性问答通常随会话结束而停止；持续型Agent会在员工不在线时继续观察变化、调用组织数据并尝试推进目标。它的任务时间跨度、权限暴露面、累积成本和潜在错误都被放大。企业如果仍以“谁买了Copilot许可证”来管理风险，会错过真正的控制点。
一、Autopilot把任务从一次问答拉长到数天
Microsoft在9月25日公布新一轮Copilot重构，将入口分为Home、Code和Autopilot。Autopilot允许用户设置长期目标和角色，Agent可拥有自己的身份、记忆、计算环境和工作区，在员工离线后仍能持续监控项目、追踪更新与处理周期任务。它让“请帮我看一下今天的邮件”向“持续盯住一项业务目标，有异常就找人处理”迈进了一步。
演示中，零售场景的Agent Dot追踪黑色星期五准备情况，从邮件、Teams、Dynamics 365库存记录及电子表格收集线索，发现影响18家门店的发货问题，再把相关人员拉入讨论。演示可以帮助理解产品目标，却不能当作部署后的平均效果。真正落地时，跨系统线索是否一致、库存数据是否实时、谁有权定义“异常”、把哪几位员工拉进会话，都要由企业自己的流程回答。
持续工作的困难常发生在交接点。Agent读到一封邮件提到缺货，ERP记录显示仓库未发货，表格里又有人手动更新了预计到货日；到底以哪个来源为准？如果它误判，能否撤销已创建的工单和通知？若负责人休假，谁接收升级信息？一个产品演示能显示Agent的主动性，生产环境则必须规定数据优先级、冲突处理、行动阈值和人工接管方式。
二、身份必须绑定责任，不能只给Agent起名字
当Agent拥有独立身份，它就应进入企业的身份与访问管理体系。Microsoft将Entra用于身份，管理员控制数据连接及端点权限，并由Agent 365承担权限、审计和费用控制。对企业来说，最基本的原则是每个生产Agent都能回答六个问题：谁批准创建、谁是业务责任人、何时生效、能访问哪些资源、可采取哪些动作、何时必须停用。
身份不能与人的账号混用。借用员工长期令牌运行的Agent，离职、调岗和审计都会变得混乱；使用通用共享账号，又无法追查具体任务。较稳妥的设计是给每个Agent或每类受控任务分配独立服务身份，声明受益人和负责人，使用短期凭据，并把读取、写入、对外发送和管理员操作区分授权。高风险动作需要审批，审批对象应是具体动作及其影响范围，不能是一次永久性的“允许Agent代我做所有事”。
还要处理存续周期。项目结束、权限变更、数据源迁移、业务负责人离开，Agent的授权应重新评估；长期不活跃的Agent要自动失效。否则，组织里会累积一批无人认领、却仍能访问邮件、客户记录和文档的数字账号。持续性是产品卖点，也意味着过期权限可能持续发挥作用。
“记忆”同样要设边界。Agent为方便长期追踪，可能保存项目摘要、联系人关系和过去处理经验；其中混有错误结论、过期资料甚至不应跨项目共享的敏感信息。企业应区分临时任务上下文、可复用的业务知识和必须清除的个人数据，明确写入条件、保留期限及更正机制。一次被撤销的错误判断，不能因为留在记忆里而在下周再次触发通知。能够查看、纠正和删除记忆，是持续Agent进入生产环境的基本操作。
三、Copilot Code把应用交付带进同一治理边界
这一轮更新还包括Copilot Code：非专业开发者可用自然语言生成应用、仪表盘和自动化工具，由Copilot Managed Runtime托管；原稿提及Git管理代码版本，以及身份、连接和端点权限控制。企业最值得重视的变化，是“生成一个应用”与“让应用持续托管并接触业务数据”开始连在一起。原型制作门槛降低之后，应用数量可能涨得很快，影子IT的入口也随之扩张。
因此，低代码生成不能免除软件交付纪律。谁能发布到生产、哪个仓库保存版本、依赖是否可信、修改后怎样回滚、数据字段是否包含敏感信息、费用由哪个部门承担，都需要清晰流程。可以允许员工快速生成个人草稿，再把共享和生产发布设为两个更严格的关口；这样既保留试错速度，也避免一个看似简单的报表应用在后台持有过宽的数据权限。
产品把身份、托管、版本和审计放入同一管理边界，能降低接线成本，却不能代替企业选择风险阈值。微软提供的是控制部件；审批规则、职责划分和数据治理仍由采购方负责。尤其是跨邮件、协作和业务系统的Agent，权限叠加后的实际可见范围，可能远大于单个系统管理员的直觉。
四、Docker把“在哪里执行”做成可迁移的隔离环境
Microsoft更靠近组织的业务入口，Docker则瞄准Agent实际运行时。Docker推出Cloud Sandboxes，把此前服务本地Coding Agent的microVM隔离环境扩展到托管云端。开发者可以在笔记本启动任务，再迁移到云端继续执行；较长时间的重构、依赖升级与大型测试，不必因为本机关机而停止。原稿给出的计算规格为1至16个vCPU动态扩展，并强调本地和云端沿用相同CLI、信任模型及策略机制。
这套能力解决的是非常具体的问题：Agent会安装依赖、执行代码、联网下载内容并使用凭据。如果直接在开发者宿主机上操作，任务可能碰到私人文件、全局密钥和其他项目；如果迁到云端却换了一套默认更宽松的规则，隔离边界在迁移瞬间就失效。环境可迁移的价值，应当包含策略不漂移、凭据不随意复制、日志链条不中断，而不只是计算任务能续跑。
长任务还要考虑中途状态。代码仓库可能在Agent运行期间更新，依赖仓库可能移除某个版本，负责审批的人也可能改变授权范围。迁移至云端时，系统应记录任务所用代码版本、依赖锁定文件、策略版本及授权有效期；恢复时核对这些条件，而非默认沿用旧状态继续写入。若任务超时或授权撤回，安全的结果是暂停并等待确认。能够“继续运行”不等于有权在任何时刻“继续修改”。
microVM也不是万能保险。攻击面还包括允许访问的域名、注入到运行时的令牌、被下载执行的依赖，以及Agent生成内容写回仓库的途径。企业应在隔离环境外再设置网络出口规则、密钥代理、文件读写白名单与资源配额。隔离负责降低失控后的波及范围；授权负责规定Agent一开始能做什么。两层缺一层，执行安全都不完整。
五、Kit的关键价值：把权限边界交付成版本化制品
Docker同期推进Kits规范，把Agent、工具、网络规则、凭据和允许触碰的资源边界封装成OCI镜像，并计划提交CNCF推动开放治理。这一点可能比云端算力更重要。过去团队交付Agent，常常只交付代码、提示词或模型配置；真正决定风险的网络策略和工具权限散落在平台后台、环境变量和操作手册中，迁移时很难对齐。
如果把运行边界纳入可版本化制品，审核者就能问更精确的问题：这个版本比上个版本新增了哪项工具、哪条网络出口、哪类凭据和哪段文件访问？同一个Agent从测试进入生产时，是否换了策略版本？更换模型或Harness后，原有的禁止访问规则是否仍然生效？镜像签名、版本固定和变更审查可以成为交付链的一部分。
这里需要避免一个误解：打包凭据与权限规则，不意味着把明文密钥烘进镜像。企业应让包描述所需能力，在运行时经授权系统注入短期凭据，保留实际签发与撤销记录。可移植性也不等于“任何地方都可运行”；目标环境仍需验证策略解释一致、资源可达范围符合预期，并在部署前拒绝不支持的权限声明。
规范能否形成生态，仍取决于不同平台是否采用、工具兼容性和长期治理。就现阶段而言，企业无须押注某一规范必胜，也可以先把Agent运行清单做成机器可读、可审阅、可比较的配置，确保安全边界不会只存在于某位工程师的脑子里。
六、一个跨系统Agent上线前，应通过哪些测试
试点可以从只读任务开始，比如汇总跨部门项目风险。先指定数据来源、刷新频率和不允许访问的空间；再设置上限：最多读取多少文档、调用多少次外部服务、运行多久、花费多少。下一阶段才开放创建草稿、工单或通知，且把真实发送和修改生产数据作为单独权限。授权按风险逐级增加，复核记录要能说明每次扩大权限的依据。
验收不应只检查它是否找到目标答案。给它过时信息、相互冲突的记录、权限不足的链接、伪装成主管指令的文档内容，以及服务超时或成本超限的情况，看它会如何处理。近期关于Agent在公开网站检索中尝试越过访问边界的争议，恰好提醒企业：完成率很高的系统，如果把未授权路径也当作工具，仍不能上线。测试用例要记录结果和过程，包括请求了什么、访问被拒后是否停止、是否向人报告不确定性。
运行中至少保留三类证据：身份与授权变化记录、工具调用及关键数据访问轨迹、最终产物与人工确认。日志注意隐私和保留期限，避免把所有敏感正文无差别复制进监控平台；高价值的是可验证的动作链和必要的事件摘要。对于会修改文件或创建应用的Agent，还应能关联版本、测试和回滚点。事故演练时，团队需要知道如何暂停全部相关任务、撤销令牌、冻结工作空间并恢复业务流程。
可以为每个生产Agent制作一张运行卡片：目标、责任人、使用的模型与工具、数据范围、网络出口、允许自动完成的动作、需人工确认的动作、预算上限、日志位置和终止开关。每次发布都保存卡片版本，版本差异进入评审；重大权限变更触发重新验收。这样，在平台从一家厂商迁到另一家、底层模型升级、团队负责人交接时，运营人员仍能明确知道系统原本被允许怎样工作，而不会依赖旧聊天记录猜测配置。
七、企业行动：先画责任图，再增加Agent数量
IT、安全、业务和法务可以围绕一张责任图启动：业务负责人定义目标与允许的决策范围；平台团队提供身份、隔离运行时和统一日志；安全团队批准高风险工具与出口策略；一线员工复核关键输出并接管异常。每个环节写明谁能停机、谁能改权限、谁承担费用。没有责任图，Agent越“主动”，事故后越容易互相推诿。
第一批生产任务最好满足三个条件：价值可量化、权限可收敛、结果可人工复核。比如监测发货异常并生成待审工单，较适合评估；直接修改大批量库存、批量联系客户或跨系统付款，则应等控制链成熟后再考虑。量化指标除了响应时间和人工节省，还应包括误报率、越权尝试、成本波动、策略变更次数、人工接管率与恢复时间。
Microsoft与Docker的动作把同一问题照亮了两面：组织需要知道Agent代表谁，运行时需要保证它只能触碰被允许的资源。产品演示、云端续跑和OCI封装都只是起点。企业真正要买到的能力，是员工离线后任务可以继续，而授权、审计、费用和紧急停止不会跟着一起离线。持续型Agent能否成为可靠的工作单元，就取决于这套日常治理能否先于规模扩张落地。