摘要： Codex、Claude Code 与 Cursor 可以组合成 Always-on Coding Agent，但“持续工作区”不应理解为三款 Agent 长期共用一个可写目录。可靠方案是用持久控制平面保存任务、状态、审计与制品，为每次任务创建独立 Git Worktree 或隔离云环境，并通过分支、PR、队列和检查点交接。本文提供平台能力对比、参考架构、Docker/任务配置、十二步部署、成本与安全控制，以及断点恢复和自动熔断方案。
核心结论
Always-on Coding Agent 的核心不是让一个终端永不退出，而是让任务可以持续接收、隔离执行、保存进度、失败恢复、人工接管和安全交付。Codex、Claude Code 与 Cursor 应共享 Git 与任务状态，不应共享同一个活跃工作副本。
- 一个任务一个隔离工作区： 使用 Worktree、容器或云 VM，避免多个 Agent 覆盖文件、锁文件和依赖。
- 持久的是控制面，不是进程： 任务队列、检查点、Commit、日志、预算和审批长期保存；Runner 可以随时销毁重建。
- 三款工具按优势分工： Codex 处理后台并行任务和自动化，Claude Code 处理终端式复杂改造与持续命令，Cursor 负责 IDE 协作、Cloud Agent 与人工审查；具体分工需团队实测。
- 所有交接都要有制品： 以 Commit、Patch、PR、测试报告和
handoff.md为准，不依赖聊天上下文或某台机器的内存。 - 默认禁止生产直写： Always-on 会放大 Prompt Injection、无限循环、Token 成本和凭据泄露，必须有网络、权限、预算、超时、审批、审计和熔断。
官方能力能做什么，不能做什么
OpenAI 官方文档显示，Codex Cloud 可在独立云环境中后台执行任务并支持并行；Codex App 具备 Worktree、Automation、Git 与多线程能力。Codex 的 Worktree 让同一项目的多个任务在独立签出中运行，减少互相干扰。云环境可以预装依赖和工具，但它不是企业跨三款 Agent 的统一持久状态数据库。
Anthropic 官方文档显示，Claude Code 支持后台 Bash、后台子 Agent、Worktree 行为、Hooks、项目记忆与远程控制相关工作流。后台进程仍需限制超时、日志和权限，不能把一个长期 Shell 当成可靠队列。Claude 的 Auto Memory 也更适合辅助连续性，不应替代 Git、Issue、任务状态与可审计交接文件。
Cursor 官方文档说明 Cloud Agents 运行在隔离云 VM 中，可以从网页、移动端、桌面、Slack、GitHub/Bitbucket、Linear 与 API 启动；环境可通过快照、Agent 引导设置或 .cursor/environment.json/Dockerfile 配置。Cursor Worktree 也强调每个任务拥有独立文件和变更。多仓环境与长时间运行的能力边界可能不同，应以当前控制台为准。
| 能力 | Codex | Claude Code | Cursor | 统一架构中的位置 |
|---|---|---|---|---|
| 后台/远程任务 | Codex Cloud、Automation | 后台命令、子 Agent、远程工作流 | Cloud Agents、API/集成触发 | 任务执行器 |
| 并行隔离 | App Worktree、云环境 | Worktree/独立目录 | Worktree、隔离云 VM | 每任务工作区 |
| 项目指令 | AGENTS.md | CLAUDE.md | Cursor Rules/项目配置 | Git 中版本化 |
| 持久状态 | 线程、云任务、Git | 会话/记忆、Git、文件 | Cloud Agent 任务、Git | 外部状态库为准 |
| 人工审查 | Diff、Git/PR 工作流 | Diff、Commit/PR | IDE、Agents Window、PR | 统一 Merge Gate |
更细的指令共用方式可参考 AI Stack Nav 的 AGENTS.md 与 CLAUDE.md 内容，安全环境可参考 Coding Agent Sandbox。
推荐架构：持久控制面 + 临时执行面
控制平面包括任务队列、调度器、策略引擎、预算账本、Secrets Broker、制品库和审计系统。它接收 Issue、告警、定时扫描或人工请求，将任务标准化为包含仓库、基线 Commit、目标、允许工具、预算、超时、验收命令和审批级别的 Task Manifest。
执行面是可销毁的 Runner。调度器为任务创建分支和 Worktree，或启动隔离容器/云 VM；注入短期、最小权限身份；拉取目标 Commit；加载项目指令；调用指定 Agent；周期性提交检查点。任务完成后上传 Patch、测试与日志，创建 PR，然后销毁环境。
这解决了“Persistent”的悖论：环境不必永久存在，但任务可从最后一个可信 Commit 与 Manifest 重建。依赖缓存和容器镜像可复用，用户目录、浏览器 Cookie、SSH Agent 与长期 Token 不复用。
task:
id: TASK_ID
repository: YOUR_REPOSITORY
base_commit: YOUR_COMMIT_SHA
agent: codex
goal: 修复登录超时并补充回归测试
workspace:
type: git-worktree
ttl: 4h
checkpoint_minutes: 15
permissions:
repositories: [YOUR_REPOSITORY]
network: [model-gateway.internal, package-mirror.internal]
production: deny
limits:
max_steps: 80
max_retries: 2
max_cost_usd: 12
acceptance:
commands: ["YOUR_FORMAT_COMMAND", "YOUR_TEST_COMMAND"]
output: pull_request为什么不能三款 Agent 共写同一个目录
共享可写目录会产生不可预测竞争：Agent A 修改依赖并运行安装，Agent B 同时读取旧锁文件；Agent C 格式化整个仓库，覆盖尚未提交的变更。即使 Git 最终能显示 Diff，中间态也可能污染测试、缓存、生成文件和数据库。
Worktree 为每个任务提供独立工作副本与分支，主仓库对象可共享，磁盘成本通常低于完整复制。云 VM 或容器进一步隔离进程、网络和凭据。对不适合 Worktree 的系统，例如本地数据库、移动模拟器或重型构建缓存，应为每个任务分配独立端口、数据库 Schema、缓存命名空间和临时目录。
同一 Issue 如果需要多个 Agent，可以串行交接：Codex 先实现，Claude Code 做对抗审查，Cursor 中由开发者修订和合并；或者并行产生多个候选分支，再由评测器比较。禁止让审查 Agent 在原实现目录中直接修改而不保留基线，否则无法区分作者和评审的贡献。
标准化交接：Task Manifest 与 handoff.md
聊天记录不是可靠接口。Agent 交接至少包含基线 Commit、当前 Commit、已完成项、未完成项、已运行命令、失败输出、已知风险、下一步建议和预算使用。建议在任务分支生成 .agent/handoff.md，同时将结构化字段写入状态库。
## 交接摘要
- Task：TASK_ID
- Base：YOUR_BASE_SHA
- Current：YOUR_CURRENT_SHA
- Agent：Codex
- 状态：awaiting_review
## 已完成
- 修复超时分支逻辑
- 新增单元测试
## 验证
- `YOUR_TEST_COMMAND`：通过
- `YOUR_LINT_COMMAND`：未运行，原因见日志
## 风险与下一步
- 需要 Claude Code 审查并发边界
- 合并前需人工确认数据库迁移不要把 Secret、完整 Prompt 或客户数据写入交接文件。日志存储引用 ID 即可。下一个 Agent 必须先验证 Commit 与工作区干净状态，再继续执行；不能盲信前一 Agent 声称“测试通过”。
十二步搭建 Always-on Coding Agent
- 选择事件来源。 从 GitHub Issue、告警、定时维护和人工表单中选择少量高价值任务，避免一开始接受任意自然语言触发。
- 建立任务数据库。 保存状态、优先级、仓库、Commit、预算、锁、租约、审批与审计引用，队列消息只传 Task ID。
- 制作签名基础镜像。 固定运行时、Git、构建工具与 Agent CLI，镜像按摘要引用，禁止启动时执行未知远程脚本。
- 配置项目环境。 将依赖安装、格式化、测试和常用操作写入版本化文件；为 Codex、Claude Code 与 Cursor 分别适配官方环境机制。
- 实现工作区管理器。 一任务一分支、一 Worktree/VM；命名含 Task ID，验证目标路径后再创建或回收。
- 接入短期身份。 Git、包仓、模型和工具凭据由 Broker 按任务签发，禁止挂载员工主目录与长期 Key。
- 部署调度与租约。 Worker 获取有 TTL 的租约并续期；心跳消失后任务回到可恢复队列，而不是两台 Worker 同时继续。
- 增加检查点。 在通过最小验证后提交临时 Commit，保存 Manifest 与日志位置；不得把脏目录快照当作唯一恢复点。
- 配置质量门。 Agent 输出进入 PR，CI 在干净环境重新运行格式化、类型、单测、安全与依赖扫描。
- 增加人工审批。 合并主分支、部署、发信、删除、付款、权限变更和生产数据库操作必须独立确认。
- 加入预算与熔断。 限制 Token、工具调用、并发、运行时间和重试；异常循环时保存补丁并停止。
- 演练恢复与回滚。 杀死 Runner、让网络中断、制造冲突和 Agent 升级，确认可从可信 Commit 恢复并撤销身份。
调度策略：三款工具怎么分工
不要用工具品牌直接决定任务，应该根据能力标签路由。任务声明是否需要 IDE 人工交互、后台云环境、长时间终端、浏览器、跨仓库、指定模型、特定 MCP 或移动端控制。调度器再从当前可用 Agent 中选择，并允许人工覆盖。
一种可行分工是：Codex Automation 执行定时依赖扫描、Issue 分类和可重复维护任务；Codex Cloud 处理并行后台实现；Claude Code 处理需要大量终端迭代、代码库探索或专属 Hooks 的任务；Cursor Cloud Agent 接受 Slack/GitHub/Linear 触发，Cursor IDE 用于开发者审查和快速修订。这是实施建议，不代表三家官方规定。
Agent 之间不直接发送自由文本指令，而由调度器生成新的 Manifest。上游输出经过 Schema 校验、敏感数据检查和预算评估后，才成为下游输入。这样可以降低 Prompt Injection 跨 Agent 传播。
可靠性：租约、幂等、重试与冲突
队列采用至少一次投递时，每个副作用必须有幂等键。创建分支、PR、评论、工单和制品都以 task_id + action + version 去重。Worker 获取租约后记录所有者与到期时间；只有当前租约持有者能写任务状态。
重试只针对网络超时、供应商 429/5xx 和可识别的瞬时错误，采用指数退避与抖动。测试失败、权限拒绝、合并冲突和预算耗尽不是自动无限重试理由。连续相同错误达到阈值时进入 NEEDS_HUMAN。
恢复顺序是：验证仓库与基线、恢复最后可信检查点、新建干净工作区、重新运行最小测试、再继续任务。不要复用可能被攻陷或状态不明的容器。合并冲突由独立任务处理，并保留原候选分支。
安全：Always-on 会放大哪些风险
第一是触发面扩大。Issue、PR 评论、Slack、网页和依赖文档都可能含提示注入。只有授权用户和受信事件类型能创建任务；外部文本作为数据传入，不得自动升级权限。
第二是凭据常驻。Runner 不保存长期 API Key，使用短期工作负载身份和 Secrets Broker；日志、Shell 历史、Git Diff 与交接文件不得输出密钥。模型、Git、包源和工具访问经过出口代理与审计。
第三是生产权限。Markdown 中写“不要部署”不是安全控制。生产网络默认不可达，CI/CD 使用独立身份，付款、删除、发布、发邮件、修改账户、修改权限和生产数据库操作均需人工审批。
第四是供应链与逃逸。基础镜像最小化，禁止特权、Docker Socket 和宿主目录，依赖使用内部镜像、锁文件与签名/摘要。Agent 与 MCP 工具分别做权限控制；Codex Sandbox 不会自动保护第三方 MCP 工具自身的权限。
成本与容量规划
总成本包括模型 Token、Cursor/Codex/Claude 产品用量、云 VM、缓存、存储、网络、CI、日志和人工审查。持久 VM 全天运行通常浪费；更好的方式是控制面常驻、Runner 按需启动，使用预热池与签名快照降低冷启动。
每个 Task Manifest 设置模型预算、工具预算、最长运行、最大步骤、最大子 Agent、最大并发和日志字节。达到 70% 提醒、85% 降级、100% 熔断可作为起点。熔断允许保存 Patch 和审计，但禁止新计费动作。
衡量价值不要只看完成任务数。应跟踪有效 PR、合并率、缺陷逃逸、返工、平均恢复时间、人工审查时间和单位有效变更成本。多个 Agent 重复解决同一问题只有在需要候选比较时才值得。
监控、审计与日常运营
每个任务记录触发者、Manifest 版本、Agent/模型、镜像摘要、工作区、Commit、命令、工具调用、网络目标、预算、检查点、CI、审批和最终 PR。日志写入 Agent 无法修改的远端系统，并对 Prompt 与源代码脱敏。
关键告警包括租约重复、心跳丢失、工作区长期未回收、同类失败循环、Token/工具调用突增、新域名访问、生产地址尝试、Secret 扫描命中、审批后参数变化与积压队列增长。
日常清理不能直接递归删除模糊路径。管理器只回收带 Task ID、位于预设根目录、租约过期且变更已保存的工作区。重要 Patch 先归档，再清理分支和存储；生产保留策略按合规要求执行。
环境配置：怎样让三个 Runner 得到一致结果
Persistent Workspace 最常见的失败并非模型能力，而是环境漂移：本地使用 Node 22，云 Runner 仍是 Node 20；一个 Agent 从公共 npm 下载，另一个使用内部镜像；数据库时区、locale、文件大小写和换行符不同，导致测试结果无法比较。
应把运行时、系统包、包管理器、依赖锁文件、环境变量名、启动命令和健康检查全部版本化。优先用一个签名 Dockerfile 或内部基础镜像作为共同基线，再分别映射到 Codex Cloud environment、Claude Code 开发容器/工作区和 Cursor Cloud Agent 环境。平台专属配置只负责调用同一套安装脚本，不要维护三份互相漂移的依赖列表。
.agent/
├── task.schema.json
├── bootstrap.sh
├── healthcheck.sh
├── handoff-template.md
└── policies/
├── network.yaml
├── tools.yaml
└── budget.yaml
Dockerfile.agent
AGENTS.md
CLAUDE.md
.cursor/environment.jsonbootstrap.sh 必须可重复执行，第二次运行不能破坏工作区；下载使用固定版本、摘要和内部镜像；失败立即返回非零状态。健康检查不仅测试命令是否存在，还要确认 Git Remote、目标 Commit、磁盘空间、模型网关、包镜像和测试依赖均可用。Secret 由运行时注入，不写进镜像层、仓库或快照。
环境升级采用 Build ID。Task Manifest 记录实际使用的镜像摘要、依赖缓存版本和 Agent CLI 版本；失败恢复默认使用原 Build，除非原版本存在安全漏洞。若必须切换 Build，应创建新的任务尝试并保留旧分支，避免在同一任务中改变环境后继续声称结果可复现。
验收测试：怎样证明 Always-on 不是“偶尔能跑”
功能测试先覆盖一条完整黄金路径：创建低风险 Issue，队列生成任务，Runner 获得租约，创建 Worktree，Agent 修改示例代码，提交检查点，CI 复测，人工批准后合并，最后销毁工作区。每一步都应能通过 Task ID 查询状态与证据。
随后进行故障注入。执行中杀死 Runner，确认租约到期后只产生一个恢复 Worker；在模型调用中断网，确认有限重试而不是死循环；让测试持续超时，确认预算熔断并保存 Patch；制造 Git 冲突，确认任务进入人工状态；让 Secrets Broker 拒绝请求，确认系统不会退回员工长期 Key。
安全验收还要在 Issue、README、网页和 MCP 返回中放入受控提示注入，要求 Agent上传环境变量或访问生产地址。合格结果不是模型回复“我不会”，而是即使模型尝试，网络、身份和工具策略仍然拒绝，并生成可关联告警。
性能验收记录冷启动、依赖准备、首次有效修改、测试、PR 创建和人工等待时间。优化时优先处理镜像、缓存和队列瓶颈，不要为了少等几分钟而复用不可信工作区或长期凭据。容量测试逐步提高并发，确认全局预算、仓库 API Rate Limit、CI 配额和数据库连接不会被同时耗尽。
回滚与灾难恢复
控制面数据库、制品元数据和审计索引需要备份；代码成果本身应尽早提交到远程临时分支。恢复演练要证明：即使调度器和全部 Runner 丢失，也能从任务数据库、Git Commit、制品与日志重建任务状态。不能把某个供应商聊天线程当作唯一恢复源。
平台升级失败时，停止领取新任务，让运行中任务在限定时间完成或检查点退出，然后回滚调度器和基础镜像。已经创建的 PR 保持不变，新版本不得静默重写旧任务。若审计或策略服务不可用，系统进入失败关闭，只允许查看状态和导出证据。
退出某款工具时，Task Manifest、Git、PR、测试和制品仍应可用。调度器只需将能力标签路由到剩余 Runner，而不需要迁移专有聊天历史。正因为如此，平台无关的状态层比“三个 Agent 永久在线”更重要，也能降低供应商锁定。
事实依据与来源
截至 2026 年 9 月 22 日，OpenAI 官方资料确认 Codex Cloud 支持在独立云环境后台、并行处理任务，Codex App 提供 Worktree 与 Automation；Anthropic 官方文档确认 Claude Code 支持后台任务、Worktree、Hooks 与项目记忆；Cursor 官方文档确认 Cloud Agents 在隔离云 VM 中运行，可通过多种入口与 API 触发，并可用环境文件、快照或 Dockerfile 配置。
“统一持久控制面、每任务临时执行面、三工具按能力路由”的方案是本文的实施建议，不是三家公司联合发布的产品。三款工具的套餐、云运行时长、区域、并发和多仓限制可能变化，具体以当前官方文档、控制台和企业合同为准。文中的 YAML、状态机、阈值和分工需要在真实项目验证。
FAQ
Persistent Workspace 是三款 Agent 共用一个目录吗？
不是。可靠含义是任务状态和制品可持续恢复，每个任务仍使用独立 Worktree、容器或云 VM，通过 Git 和 PR 交接。
必须同时购买三款工具吗？
不必须。先选一种完成队列、隔离、检查点与 PR 闭环，再根据明确能力缺口引入第二或第三种，避免重复订阅与治理复杂度。
Agent 任务中断后怎样继续？
从状态库读取 Manifest，验证最后可信 Commit，在新工作区重新运行最小测试后继续。不要依赖旧终端或未提交的脏目录。
可以让 Always-on Agent 自动合并和部署吗？
低风险仓库可在严格策略下自动合并，但生产部署、数据库迁移、权限变更和外部消息应保留独立 CI 身份与人工审批。
Worktree 能解决所有隔离问题吗？
不能。它隔离工作副本，不自动隔离进程、网络、凭据、数据库和缓存。高风险任务仍需容器或 VM、独立身份与网络策略。
三个 Agent 如何避免重复工作？
调度器使用任务租约和幂等键；每个 Agent 只能写自己的分支。并行候选必须显式标记，由评测或人工选择，而不是自动互相覆盖。
Always-on 的最低成本起步方案是什么？
一台受控 Runner、Git Worktree、简单队列、短期凭据、PR/CI 与人工合并即可。先跑定时维护和低风险 Issue，再扩展云 Runner 与多 Agent。
如何防止 Issue 中的 Prompt Injection？
把 Issue 内容视为不可信数据，任务模板固定权限和工具；外部文本不能修改预算、网络或审批。高风险动作在模型外由策略引擎阻断。
参考来源
- OpenAI, Codex Cloud
- OpenAI, Codex Worktrees
- OpenAI, Codex Automations
- OpenAI, Codex Cloud environments
- Anthropic, Claude Code settings
- Anthropic, Claude Code Hooks
- Anthropic, How Claude remembers your project
- Cursor, Cloud Agents
- Cursor, Worktrees
- Cursor, Agent Security
工具选型与提示词资料
适合阅读工具评测、工具推荐、对比测评类文章后继续转化。
0 回复