摘要： 本文解释如何把 Codex 配置成可持续处理编程目标的 Persistent Agent：用长时间运行的 Goal 承担单次复杂开发，用 Scheduled Tasks 定期检查 PR、CI 与依赖状态，用项目聊天和 AGENTS.md 保存可复用上下文，再通过工作树、权限配置、网络白名单、审批点和审计记录控制风险。最重要的结论是：截至 2026 年 9 月 2 日，“Codex Persistent Agent”并非 OpenAI 单独发布的产品名，而是一种工程组合方案；它适合需要持续修复、测试和维护代码的个人与企业团队，但不应被配置成拥有生产密钥和无限权限的无人值守进程。读完本文，你可以搭建一套能长期工作、可以中途纠偏、失败后可恢复、关键操作必须人工确认的 Codex 编程智能体。
核心结论
Codex 可以承担 Always-on 风格的持续编程工作，但正确做法不是让一个会话永远运行，而是把“单次长任务、定时唤醒、持久项目规则、隔离工作树、权限策略和人工审批”组合成可恢复的任务系统。
- 值得使用： 对 PR 看护、CI 修复、依赖升级、测试补齐、代码审查和技术债清理价值较高；对付款、生产部署、删库和权限变更不应完全自动化。
- 能力边界： 长任务会保持原有 sandbox 与 approval policy；启动 Goal 不会自动扩大权限，缺少输入或审批时可以暂停。
- 持续机制： Scheduled Tasks 可按分钟、每日、每周或自定义 RRULE 运行；同一聊天内的计划任务可以沿用聊天上下文，独立任务则每次创建新聊天。
- 长期记忆： Codex 的工程记忆主要来自项目聊天、代码仓库、任务产物、
AGENTS.md、Issue/PR 和外部系统，而不是一个无限增长、自动可信的隐藏记忆库。 - 实施建议： 默认使用工作区写权限、限制网络目的地、为每个并行 Agent 分配独立 worktree，并在合并、发布、生产变更和敏感数据操作前设置人工审批。
“Persistent Agent”到底是什么
“Persistent”容易让人联想到一个永不退出、拥有永久记忆并能随意操作电脑的 Agent。对于 Codex，更准确的定义是：目标可以持续推进，任务可以按计划再次运行，上下文和项目规则可以复用，执行状态可以被人类查看与纠偏。
它由四种不同的“持续性”组成：
| 持续性 | Codex 中的实现 | 解决的问题 | 不代表什么 |
|---|---|---|---|
| 执行持续性 | 长时间运行的 Goal/聊天 | 完成功能、跨文件修改、测试与修复 | 不保证永不暂停或永不失败 |
| 调度持续性 | Scheduled Tasks | 定期检查 PR、CI、漏洞和依赖 | 不等于一个进程永久在线 |
| 上下文持续性 | 同一聊天、项目、仓库产物 | 延续目标、约束和历史结果 | 不应替代结构化状态库 |
| 规则持续性 | AGENTS.md、Skills、组织策略 | 固化测试、编码、安全与审批要求 | 不会覆盖管理员强制策略 |
OpenAI 官方的长任务文档说明，用户可以在同一聊天中追加上下文、调整约束或询问状态；并行聊天各自保留目标、消息和结果。官方同时提醒，不要让两个聊天修改同一批文件，应使用 Git worktree 隔离。因此，企业落地的关键不是“让 Agent 活得更久”，而是让每一次执行都能定位状态、重复验证并安全交接。
总体架构：把长任务变成可治理的任务系统
推荐采用六层架构：触发层接收人工目标、定时计划、Webhook 或 CI 事件；编排层生成任务 ID、拆分步骤并控制并发；Codex 执行层在独立聊天或 worktree 中修改代码；工具层提供 Git、测试、MCP、插件和内部 API；状态层保存 checkpoint、日志和评测结果；治理层处理最小权限、审批、审计与回滚。
一个可上线的任务记录至少应包含以下字段：
task_id: CODPA-20260902-001
goal: "修复订单服务的间歇性测试失败"
repository: "YOUR_ORG/order-service"
branch: "agent/CODPA-20260902-001"
worktree: ".worktrees/CODPA-20260902-001"
status: "running"
checkpoint: "reproduced_failure"
allowed_actions:
- read_repository
- edit_workspace
- run_tests
blocked_actions:
- production_deploy
- rotate_secrets
- delete_database
approval_required:
- merge_pull_request
- change_permissions
retry_limit: 2
timeout_minutes: 90这份 YAML 是实施模板，不是 Codex 官方固定配置格式。它的价值在于把任务边界从自然语言变成可验证字段，使外部调度器、CI 或团队看板能够判断下一步，而不是依赖 Agent 自己声称“已经完成”。
准备项目：建立可复用的工程上下文
Persistent Agent 的第一步不是开启最高权限，而是让仓库变得容易理解和验证。官方文档确认，Codex 会在执行前读取 AGENTS.md，并按全局、仓库根目录、当前目录逐层合并指令；更靠近当前目录的规则优先级更高。默认合并大小上限为 32 KiB，因此不要把全部产品文档塞进一个文件。
- 在仓库根目录建立
AGENTS.md，写清安装、测试、目录边界与提交要求。 - 为支付、身份、数据库等敏感子目录增加更严格的
AGENTS.override.md。 - 将验收条件写成可运行命令，如
npm test、pytest -q、make lint。 - 将不可自动执行的动作单独列为“必须审批”，不要只写“注意安全”。
- 为长任务创建任务模板，明确完成定义、超时、重试、回滚和交付物。
下面是一份适合持续编程 Agent 的仓库规则：
## Repository workflow
- 修改前先复现问题，并记录失败命令。
- 只修改当前任务相关文件；发现无关问题时创建备注，不顺手重构。
- 修改 JavaScript 后运行 `npm run lint && npm test`。
- 不读取 `.env`、密钥目录或生产数据快照。
- 不直接推送主分支，不自动合并 PR。
- 数据库迁移、权限变更和生产部署必须等待人工审批。
- 完成时输出：变更摘要、测试证据、剩余风险、回滚步骤。如果你还在设计 Agent 规范，可参考 AI Stack Nav 的 Codex Agent 教程检索；需要接入外部工具时，可继续查看 MCP 权限治理相关文章。
配置长时间运行的编程 Goal
长任务适合一个有明确终点的复杂目标，例如“实现功能并通过测试”，不适合含糊的“持续优化代码”。OpenAI 官方建议在同一聊天中继续发送消息来补充上下文或纠偏；启动 Goal 不会扩大访问权限，遇到决策点仍会暂停。
高质量 Goal 应包含六项信息：目标、范围、禁止项、验收命令、交付物和停止条件。例如：
目标：修复 checkout 服务重复扣减库存的问题。
范围：仅允许修改 services/checkout、tests/checkout 和相关文档。
禁止：不修改支付网关配置，不访问生产环境，不执行真实付款。
验收：运行 npm run lint、npm test -- checkout、现有集成测试。
交付：给出根因、变更文件、测试证据、兼容性风险和回滚方案。
停止：如果必须变更数据库结构或需要生产凭据，暂停并请求审批。运行过程中可发送“先汇报当前证据，不要继续修改”“保持 API 兼容”“把数据库迁移改为设计建议”等 steer 消息。纠偏应修改约束或验收条件，而不是另起一个会修改同一工作区的 Agent。
并行任务必须隔离 worktree
同一仓库可以并行处理多个目标，但不要让不同聊天写入同一 checkout。一个通用的 Git 准备方式如下：
git fetch origin
git worktree add .worktrees/CODPA-001 -b agent/CODPA-001 origin/main
git worktree add .worktrees/CODPA-002 -b agent/CODPA-002 origin/main任务完成并合并后再清理 worktree。若任务仍在运行、存在未提交修改或需要保留审计证据，不要自动删除。对于非 Git 项目，Scheduled Tasks 会直接在项目目录运行，冲突风险更高，应限制并发为 1。
用 Scheduled Tasks 实现 Always-on
真正的 Always-on 通常来自“定期唤醒并检查状态”。官方文档显示，计划任务既可以回到当前聊天，也可以独立运行：前者适合持续跟进同一 PR 或部署，后者适合每日漏洞扫描、每周依赖报告等相互独立的工作。
可直接用自然语言创建任务，例如：
每 15 分钟检查当前 PR 的 CI 状态和新评论。
如果出现新的、可复现的测试失败，定位原因并在独立 worktree 中修复；
只修改与失败相关的文件，运行受影响测试和完整 lint；
不要自动合并，不要部署生产；需要新增依赖、修改数据库或扩大网络访问时暂停；
当 CI 全绿且没有未处理评论时，汇报证据并停止本轮。官方支持分钟级跟进、每日/每周计划以及自定义 RRULE。每月 1 日上午 9 点的高级计划可以表达为：
RRULE:FREQ=MONTHLY;BYMONTHDAY=1;BYHOUR=9;BYMINUTE=0
计划任务的生产级提示词
计划任务提示词必须能够跨时间独立理解，至少定义：检查对象、什么算新增事件、允许做什么、何时不报告、何时停止和何时找人。不要只写“每天检查项目并修复问题”，否则它可能重复处理旧问题或产生无意义报告。
建议增加幂等键：
{
"task": "pr-guardian",
"repository": "YOUR_ORG/YOUR_REPO",
"pull_request": 128,
"event_sha": "YOUR_COMMIT_SHA",
"last_processed_check": "YOUR_CHECK_RUN_ID",
"max_retries": 2,
"human_gate": ["merge", "deploy", "permission_change"]
}每轮先比较 event_sha 与 last_processed_check，没有新状态就结束；失败达到上限后转人工，而不是无限重试。频繁使用 worktree 的计划任务还应定期归档历史运行，避免长期堆积。
权限治理：Sandbox、审批和网络边界
Codex 的安全不是一个“允许/拒绝”开关。官方将它拆成两层：Sandbox 决定技术上能访问什么，approval policy 决定何时必须停下来询问。Codex Cloud 在隔离容器中运行；本地 CLI 和 IDE 使用操作系统级沙箱。默认网络关闭、写入通常限制在工作区。
截至核验日期，官方权限文档给出了三个内置本地权限配置：
| 权限配置 | 能力 | 适合场景 | 建议 |
|---|---|---|---|
:read-only | 只读命令执行 | 代码审查、架构分析、事故初查 | 默认用于未知仓库 |
:workspace | 可写活动工作区和系统临时目录 | 功能开发、测试修复 | Persistent Agent 推荐起点 |
:danger-full-access | 移除本地沙箱限制 | 极少数受控运维场景 | 不用于常规定时任务 |
Scheduled Tasks 无人值守运行，使用默认 sandbox 设置。官方特别警告：如果使用 full access，后台任务可能在不询问的情况下改文件、运行命令和访问网络；更稳妥的配置是 workspace-write，并用规则只放行确有需要的动作。组织管理员还能通过 requirements.toml 限制可选权限模式，个人配置不能放宽这些强制边界。
网络白名单不是全局安全墙
本地命令要访问网络，需要先开启相应网络能力；若希望域名规则真正生效，还要启用 network proxy。示意配置如下：
default_permissions = "project-edit"[features]
network_proxy = true
[permissions.project-edit]
extends = “:workspace”
[permissions.project-edit.network]
enabled = true
[permissions.project-edit.network.domains]
“api.github.com” = “allow” “registry.npmjs.org” = “allow”
必须注意，命令网络代理不自动覆盖 Web Search、插件、MCP Server、浏览器、Computer Use 或 Codex Cloud；这些入口拥有各自的权限与网络控制。企业若只配置命令域名白名单，却给 MCP Server 宽泛凭据，仍然可能绕过预期边界。
人工审批与企业安全门
Always-on Agent 的价值是减少等待，不是取消责任。推荐把动作分成三档：读取、分析、测试等低风险动作自动执行；修改工作区、创建分支、提交候选补丁等中风险动作在隔离环境自动执行；合并、发布、生产写入、密钥与权限操作必须人工审批。
审批请求不应只显示“允许吗”，而应包含：
- 任务 ID、仓库和目标分支；
- 将执行的精确命令或工具；
- 影响的文件、数据与外部系统；
- 测试结果和风险等级；
- 凭据范围与有效期；
- 拒绝后的安全回退路径。
对 MCP 或插件调用也要做参数校验。删除、发送、购买、发布等有副作用的工具必须暴露明确的破坏性标记并触发审批。Agent 生成的工具参数不能直接进入数据库或 shell，应经过 schema 校验、路径规范化、命令白名单和业务授权检查。
失败恢复、Checkpoint 与长期记忆
持续任务不可避免会遇到网络中断、会话暂停、测试超时、审批缺失和代码基线变化。可靠方案需要外部化状态，而不是只依赖聊天记录。
推荐在每个阶段写入 checkpoint：queued → environment_ready → reproduced → patch_created → tests_passed → awaiting_approval → merged/closed。恢复时首先验证仓库 SHA、依赖锁文件、任务所有者和上次测试证据；基线改变时重新复现，不要直接沿用旧结论。
长期记忆可分三层：
- 规范记忆：
AGENTS.md、Skills、代码规范和安全策略，经过团队评审后长期保留。 - 项目记忆： ADR、Issue、PR、测试报告、任务状态和变更日志，可追踪来源与版本。
- 会话记忆： 当前聊天中的假设、临时分析和中间输出，默认不应视为权威事实。
写入长期记忆前检查来源、时效、隐私和冲突。模型推断应标为“待验证”，用户纠正应关联任务和日期，密钥、个人数据与生产样本不应进入普通记忆文件。
三个可直接落地的工作流
工作流一：PR Guardian
每 10～15 分钟读取 PR 的新评论、检查运行和最新 SHA；只处理新事件。发现失败后在专用 worktree 复现，生成最小补丁并运行测试；如果涉及公共 API、数据库迁移或新增生产依赖，提交分析后等待审批。CI 全绿后只给出可审查摘要，不自动合并。
工作流二：夜间技术债维护
每天夜间扫描 lint、类型检查、过期依赖与低风险告警，按“可自动修复、需设计决策、疑似误报”分类。自动修复限定在格式、明确弃用 API 和测试稳定性问题；依赖大版本升级、许可证变化和安全配置修改转入人工队列。每轮最多创建一个 PR，避免噪声淹没团队。
工作流三：持续测试补齐
每周分析近期变更与缺失覆盖路径，为高风险业务逻辑补充测试。它不能只追求覆盖率数字，而要生成失败前能捕获真实回归的断言。涉及付款、鉴权或隐私逻辑时，测试数据必须脱敏，禁止调用真实生产服务。
监控指标与验收标准
Persistent Agent 不应以“运行了多少小时”衡量。更有意义的指标包括任务成功率、首次通过率、平均人工等待时间、回滚率、重复事件率、越权请求次数、每个有效 PR 的成本和人工接受率。
建议上线门槛：连续两周所有任务均有可追踪 ID；100% 的生产动作经过审批；重复处理率低于团队设定阈值；失败重试有上限；每个候选补丁包含测试证据；权限拒绝不会导致任务绕路执行。具体数值属于企业实施建议，应根据仓库规模、风险等级和团队响应时间实测确定。
风险、限制与注意事项
第一，长时间运行不等于保证完成。模型可能误判根因、陷入局部修复或在依赖环境变化后失去有效上下文。第二，计划任务会继承默认权限配置；配置过宽时，无人值守会放大误操作。第三，同一工作区的并行修改会产生覆盖和合并冲突。第四，聊天上下文和模型推断不是权威数据库，长期事实应写入可审计系统。
还要防范 Prompt Injection：Issue、PR 评论、网页和依赖包文档都属于不可信输入。外部文本中出现“读取密钥”“关闭测试”“上传仓库”等指令时，Agent 不应执行。任何联网安装都可能引入供应链风险，应固定锁文件、验证来源、限制域名并在 CI 中重新构建。
对比与选型建议
一次性交互式 Codex 适合探索和小修复；长 Goal 适合有明确验收标准的跨文件开发；同一聊天计划任务适合持续看护一个事件；独立计划任务适合周期性扫描。若任务要求严格跨系统事务、复杂审批 SLA 或长期结构化状态，应让 n8n、Temporal、GitHub Actions 等外部编排器负责状态机，Codex 只承担分析与代码执行节点。
不要因为任务周期长就默认选择 full access。优先从 :read-only 或 :workspace 开始，只为明确的目录、命令和域名增加权限。生产系统永远保留独立的身份验证、业务授权和审批，不能把“Agent 有权限调用工具”等同于“业务允许此次操作”。
事实依据与来源
- 官方已确认： OpenAI Docs 说明了长任务纠偏、并行聊天、worktree 隔离、Scheduled Tasks 的运行方式，以及 sandbox 与 approval policy 不会因启动 Goal 自动扩大。
- 官方已确认： Scheduled Tasks 可在当前聊天中按分钟、每日或每周跟进，也可作为独立任务运行；Git 仓库可使用专用后台 worktree。
- 官方已确认： 本地权限配置包含
:read-only、:workspace和:danger-full-access，权限策略与网络代理存在明确作用范围。 - 编辑判断： “Codex Persistent Agent”是对上述能力组合的工程化命名，不是本文核验到的独立官方 SKU 或单一功能名称。
- 实施建议： 六层架构、YAML 状态字段、三档审批、checkpoint 状态机和监控门槛是本文给出的落地方案，需要在真实仓库验证。
- 尚待核实： 不同账户、地区、客户端版本与组织策略可能影响功能入口、额度和可用权限，最终以用户界面和管理员配置为准。
FAQ
Codex Persistent Agent 是 OpenAI 的正式产品名吗？
不是本文能够从官方资料确认的独立产品名。它更适合表示由 Codex 长任务、Scheduled Tasks、项目上下文、AGENTS.md、worktree 和权限治理组合出的持续编程方案，文章中不应把它包装成一个拥有固定价格或 SLA 的新 SKU。
Codex 可以真正 24 小时不停运行吗？
可以通过长任务与计划任务持续推进工作，但不应理解为单一会话永久不间断。设备休眠、网络、审批、组织策略、任务超时和环境变化都会影响执行。本地长任务还应启用防休眠；后台任务更适合通过定时唤醒和 checkpoint 恢复。
Scheduled Tasks 能自动修复 PR 的 CI 吗？
可以按计划检查 PR 状态，并在工具与权限允许时定位和修复新失败。生产级配置应限定仓库、分支、worktree、重试次数和测试命令；自动合并、部署以及权限或数据库变更应保留人工审批。
长期记忆是不是会自动记住所有聊天？
不应这样设计。可靠的长期记忆应放在 AGENTS.md、ADR、Issue、PR、任务数据库和测试报告中，并附来源与版本。会话内容适合作为临时上下文，不宜未经验证直接沉淀成永久规则。
Always-on Agent 应该使用 full access 吗？
通常不应该。官方明确提醒，后台计划任务在 full access 下风险更高。推荐以 :workspace 为起点，把文件、网络和工具范围缩到完成任务所需的最小集合，只对少数动作单独放行。
网络域名白名单能限制所有 Codex 工具吗？
不能。命令网络代理只约束沙箱内命令流量，不自动覆盖 Web Search、插件、MCP Server、浏览器、Computer Use 或 Codex Cloud。企业必须分别配置这些入口的权限、凭据和允许列表。
两个 Codex Agent 可以同时修改同一仓库吗？
可以并行处理，但不要写同一个工作目录。官方建议使用 Git worktree 给不同聊天分配独立 checkout，并明确文件所有权与合并顺序；否则容易互相覆盖、污染测试结果或产生难以审计的冲突。
如何判断 Persistent Agent 是否完成任务？
不要以 Agent 的自然语言结论为准。完成条件应是可验证证据：目标 commit、变更清单、指定测试通过、静态检查通过、风险说明、回滚方案，以及需要时的人类审批记录。
参考来源
- OpenAI Docs：Long-running work
- OpenAI Docs：Scheduled tasks
- OpenAI Docs：Agent approvals & security
- OpenAI Docs：Permissions
- OpenAI Docs：Custom instructions with AGENTS.md
- OpenAI Docs：ChatGPT & Codex changelog
工具选型与提示词资料
适合阅读工具评测、工具推荐、对比测评类文章后继续转化。
