Wired 2026 年 8 月 27 日报道称，OpenAI 正在测试一种面向 Codex 的 Persistent mode，让 agent 能持续工作，直到用户把它“put to sleep”。同一周，The Guardian 也报道了 OpenAI 高管对 persistent AI cyber-attacks 的担忧；Wired 另一篇报道还复盘了 OpenAI agents 在安全评测中攻击 Hugging Face 的争议事件。参考来源：Wired Persistent Agent、The Guardian、Wired Hugging Face Hack。
这些报道真假细节以后还会变化，但趋势已经很清楚：AI 产品正在从“你问我答”走向“我会一直替你盯着”。这不是交互形态的小升级，而是系统边界的大变化。常驻 agent 会跨会话保留任务状态，可能主动创建后续任务，可能在用户离开后继续读文件、跑测试、查网页、排队调用模型。它更像一个云端 worker，而不是一个聊天窗口。
一旦 agent 常驻，核心问题就从“模型会不会回答”变成“谁在控制它”。答案不能只是一个停止按钮。停止按钮只能处理用户已经注意到的问题，而常驻 agent 的风险恰恰在于用户没有持续盯着。
从会话到任务
聊天产品天然以会话为边界。用户输入一句话，模型回复一句话，历史记录就是上下文。agent 产品则以任务为边界：目标、计划、工具、检查点、结果和验收都属于任务。常驻 agent 又进一步把任务变成可挂起、可恢复、可衍生的工作流。
这意味着系统必须有任务注册表。每个任务至少记录：
task_id
owner
goal
allowed_tools
permission_lease
budget
created_at
last_active_at
state
parent_task_id
acceptance_criteria
audit_log_uri没有任务注册表，常驻 agent 就会退化成“一个长期存在的聊天上下文”。这很危险，因为权限、预算和责任都无法归属。用户也无法回答：它现在为什么在跑，它准备做什么，它是否已经越过原目标。
权限要变成租约
普通应用常用长期 token。常驻 agent 不适合这样做。它可能在后台运行数小时甚至数天，如果拿着长期邮箱、GitHub、Slack 或云账户权限，任何目标漂移都会被放大。
更合理的设计是权限租约。用户批准的不是“这个 agent 永远可以访问 GitHub”，而是“在接下来 2 小时内，为 task_id 某某，可以读取这个 repo、创建分支、提交 PR，但不能合并、不能读 secrets、不能访问其他组织”。租约到期后，agent 必须重新申请或降级。
权限租约还要和工具调用绑定。比如读取 issue、修改代码、运行测试、提交 PR 是不同能力，不应该因为都属于 GitHub 就一次全开。常驻系统的默认策略应该是最小权限加短时有效。
主动性需要刹车
Persistent mode 最吸引人的部分是 proactive：agent 能提出后续任务，甚至在用户未请求时继续推进。这也是最容易出问题的部分。
主动性必须经过三层刹车。
第一层是目标边界。agent 可以在目标内生成子任务，但不能随意改变目标。例如“修复 CI 失败”可以派生“重跑测试”“定位 flaky test”“更新依赖锁文件”，但不应该派生“重构整个构建系统”。
第二层是成本边界。每个任务有 token、工具、时间和外部 API 成本上限。超过上限时进入等待状态，而不是继续尝试。
第三层是风险边界。删除数据、发送外部消息、发布版本、修改生产配置、合并代码，都应该进入人工确认队列。常驻 agent 可以准备动作，但不应默认执行高风险动作。
审计不是日志堆积
很多团队以为有日志就是可审计。实际上，审计需要能回答因果问题：agent 为什么做了这个动作，它看到了什么证据，它使用了什么权限，它的结果由谁验收。
常驻 agent 的审计记录应该按任务组织，而不是按模型请求散落。一次任务的审计链包括初始目标、计划版本、工具调用、观察结果摘要、关键决策、权限变更、失败恢复、最终产物和验收结果。模型完整上下文可以脱敏保存，但不应该是唯一证据，因为上下文太长也太难读。
对 coding agent 来说，最好的审计对象不是“模型说它改好了”，而是分支 diff、测试日志、lint 结果、review 评论和回滚路径。对运营 agent 来说，审计对象是草稿、收件人、审批记录和发送凭证。越常驻，越要把结果证据从模型叙述中剥离出来。
调度器要能暂停和收尸
常驻 agent 必须由调度器管理，不能只靠一个后台进程。调度器至少要支持队列、优先级、超时、心跳、暂停、恢复和取消。
暂停不是杀进程。暂停意味着 agent 停在可恢复检查点：当前目标、计划、已完成步骤、未完成工具调用、临时文件、权限状态和下一步候选都被保存。恢复时，系统先重新验证权限和上下文，再继续执行。
取消也不能只停模型调用。取消后需要清理临时资源、关闭外部会话、标记未完成产物、撤销短期凭证，并向用户说明当前状态。如果 agent 已经创建 PR 或发起工单，取消不等于外部世界自动回滚。
产品边界
常驻 agent 的第一批好场景应该是低风险、可回滚、验收明确的任务。比如清理 TypeScript error、补文档、更新测试快照、整理会议纪要、汇总监控异常、定期生成研究摘要。这些任务有明确产物，失败成本有限，用户能审核。
不适合一开始交给常驻 agent 的任务包括：自动处理客户退款、自动修改生产权限、自动外发法律文件、自动交易、自动删除数据。这里不是模型能力问题，而是责任与恢复问题。一个系统越主动，就越需要清楚地告诉用户“我不会做什么”。
结论
常驻型 AI agent 的真正挑战不是让模型多跑几个小时，而是把持续工作变成可治理的系统。开发者需要从聊天 UI 思维切换到任务控制面思维：任务显式化、权限租约化、预算硬约束、风险动作排队、审计证据独立、调度可暂停。
未来一年，agent 产品的差距不会只体现在模型聪明程度上，而会体现在谁能把“长期自主性”变成用户可理解、可停止、可追责的工程系统。没有控制面的 persistent agent，只是一个运行时间更长的风险放大器。