摘要：WIRED 根据代码内容报道，OpenAI 正在测试 Codex 的 Persistent mode，使代理能够持续工作直到被休眠，并主动创建跨会话后续任务。OpenAI 确认相关功能处于测试阶段，但尚未给出近期上线计划。常驻能力并非简单延长一次运行时间，它要求任务队列、长期记忆、事件触发、权限租约、成本预算和审计机制共同重构。软件工程团队可能因此从“向 AI 提交一次任务”转向“管理一组持续工作的数字工程角色”。
摘要
WIRED 根据代码内容报道，OpenAI 正在测试 Codex 的 Persistent mode，使代理能够持续工作直到被休眠，并主动创建跨会话后续任务。OpenAI 确认相关功能处于测试阶段，但尚未给出近期上线计划。常驻能力并非简单延长一次运行时间，它要求任务队列、长期记忆、事件触发、权限租约、成本预算和审计机制共同重构。软件工程团队可能因此从“向 AI 提交一次任务”转向“管理一组持续工作的数字工程角色”。
从一次会话到持续进程
现有编程代理通常以用户请求为边界。它接收任务，读取仓库，修改文件，运行测试，在几分钟或几小时后结束。即使任务没有完全完成，会话也会因时间、上下文或运行限制停止。使用者需要重新发起任务，并解释上次进度。
据 WIRED 报道，测试中的 Persistent mode 会“持续工作直到被休眠”，其中的 proactivity 机制还允许代理在完成当前请求后创建后续任务，跨会话继续执行，并根据历史交互判断哪些工作值得推进。报道同时指出，这种模式不会自动扩大权限，修改用户系统以外的对象仍需事先批准。由于功能尚未正式发布，具体界面、能力边界和上线时间都可能变化。
常驻代理与长会话的区别类似守护进程与一次性脚本。长会话只是把同一任务运行得更久；常驻代理需要在没有即时提示的情况下维护任务队列，响应代码提交、测试失败、依赖更新和用户反馈。它还要决定何时工作、何时等待、何时通知用户。这些决策会把智能体从工具提升为一种持续的软件运行单元。
软件工程为什么适合常驻代理
软件开发天然包含大量异步和周期性工作。测试需要等待构建，代码评审会产生新意见，依赖库持续发布更新，线上指标可能在部署后数小时才暴露问题。人类工程师通过 issue、消息、日历和记忆把这些事件串起来，一次性代理很难维持完整闭环。
常驻代理可以在几个场景发挥作用。它可以接收需求后分解任务，先实现最小版本，等待 CI 返回，再处理失败；可以跟踪代码评审意见，逐条修改并更新说明；可以定期检查依赖与安全公告，在沙箱分支上生成升级方案；也可以在部署后观察日志和指标，发现异常时回滚或请求人工处理。关键在于，代理不再把一次回复视为工作的终点。
这种能力对中小团队尤其有吸引力。许多维护任务重要却不紧急，长期占用工程师注意力。常驻代理能够承担跟踪、复核和准备工作，人类保留架构判断、风险决策和业务沟通。但它也可能制造新的管理负担：如果代理不断创建“有用”的后续任务，团队会被大量低价值变更和通知淹没。
主动性必须有明确的经济函数
代理主动工作意味着持续消耗计算资源，也会占用测试环境、代码审查和人工注意力。没有约束的主动性很容易演变为“看起来很勤奋”的自动化：整理文档、重构无关代码、反复运行大型测试，却没有提高交付价值。
工程上需要为常驻代理设置任务价值函数。任务至少要有来源、目标、验收标准、预算、截止时间和停止条件。代理可以主动发现候选任务，但进入执行队列前应依据风险分层。低风险的文档补充和测试复现可以自动进行；涉及生产配置、对外发布、数据迁移和付费资源的操作需要审批。
预算不能只按 token 计算，还要包含 CI 时间、云资源、第三方 API 和人工复核。一个看似低成本的代理如果每天产生十个需要人类审查的 PR，会把成本转移给团队。更合适的指标是被接受的变更比例、缺陷修复周期、人工节省时间和引入问题数量。
长期记忆比大上下文更关键
持续运行数周或数月的代理不可能把全部历史一直放在上下文中。它需要分层记忆：当前任务上下文保存正在处理的文件和计划；项目记忆保存架构约束、测试方法和重要决策；用户记忆保存沟通偏好和审批边界；审计日志则完整保留过去动作，供追责和复盘。
记忆写入本身需要治理。代理总结错误后，错误可能在未来持续影响决策。项目事实应尽量从代码、配置和正式文档重新读取，推断与偏好则要标注来源和置信度。关键决策由人类确认后写入长期记忆，临时猜测应随任务结束清理。
跨会话任务还需要可恢复状态。代理休眠或运行失败后，应知道最后一个已验证步骤、尚未完成的动作和环境是否发生变化。任务状态最好保存为结构化记录，而不是依赖聊天摘要。代码提交、测试报告和工件哈希可以作为恢复锚点，防止代理基于过期状态继续修改。
权限应该像租约一样到期
一次性代理获得权限后很快结束，暴露窗口相对有限。常驻代理若长期持有仓库写权限、云凭据或生产访问权，风险会显著增加。权限系统应采用最小权限和短期租约：代理在执行具体任务时申请所需权限，任务结束或超时后自动回收。高风险凭据不进入模型上下文，由受控工具代为执行。
持续代理的威胁还包括目标漂移。长期运行中，任务描述、代码状态和业务优先级都会变化。代理可能继续推进一个已经取消的目标，或者为了完成不可能任务采用意外手段。WIRED 引述的相关安全讨论也指出，高持久性会放大对齐风险。停止条件、异常检测和外部监督因此比单次代理更重要。
一套稳健架构可以划分为四层。规划层生成候选任务，但不能直接获得高权限；执行层在隔离环境完成代码和测试；验证层独立检查变更、权限与结果；审批层由人类决定是否合并、部署或对外行动。规划和验证最好使用不同上下文，避免同一个代理同时充当运动员和裁判。
团队管理对象将从提示词变成数字岗位
当代理能够持续工作，企业不会只配置一个“万能 Codex”。更可能出现多个职责明确的数字角色：维护代理处理依赖与技术债，测试代理复现缺陷和补充用例，文档代理跟踪接口变化，安全代理扫描风险，交付代理准备发布说明。每个角色拥有不同权限、预算、事件源和考核指标。
这与数字工匠平台的设计高度一致。平台的管理对象应当包括岗位能力、技能包、工作队列、审批流和交付物，而非聊天窗口数量。Skill 用于沉淀稳定方法，MCP 或其他工具协议连接系统，记忆保留项目知识，审计层记录全过程。常驻模式让这些组件从按需调用转为持续运转。
组织流程也会随之改变。代码仓库需要更清楚的规则文件和自动验收，任务系统要为机器执行提供结构化字段，测试环境要支持大量隔离分支，评审流程要能识别代理生成的变更。缺少这些基础时，常驻代理只会把原有混乱放大。
现在应该怎样准备
在功能正式发布前，企业不必围绕具体产品做重投入，可以先改造工作方式。第一，选择低风险、可自动验收的持续任务，例如依赖检查、测试失败归因和文档同步。第二，为每类任务定义明确停止条件与人工接管点。第三，建立短期凭据和沙箱分支。第四，记录代理完整轨迹，定期统计有效产出与误操作。第五，把成功流程沉淀成可版本化 Skill，避免每次从提示词重新开始。
常驻智能体可能成为编程代理发展的重要转折，也可能因成本、噪声和安全问题停留在少数场景。判断它是否成熟，应观察它能否长期保持目标、尊重权限、控制成本，并在适当的时候停下来，连续运行时长只是次要指标。软件工程需要一套能够被安排、被审计、被叫停并对交付结果负责的持续执行系统。