跨工具迁移：Claude Code、Codex、Cursor 怎么落地

loop engineering 最容易被误解的一点，是大家以为它只属于某一个产品。实际上，真正可迁移的是能力组合，不是产品名字。

先讲结论

如果你已经理解前两篇内容，跨工具迁移时最该坚持的不是“这个工具有没有同名功能”，而是下面四件事：

skill / 指令资产是否可复用
状态文件是否跨会话稳定
maker / checker 是否能分离
调度和外部连接能否形成闭环

只要这四层在，loop 大概率能迁移；只追工具 UI 和命令表，迁移常常会失败。

一张能力映射表

基于源仓库的 primitives matrix，可以把常见 agent 环境简化映射成下面这样：

Loop 能力	Claude Code	Codex	Cursor
调度 / 自动化	`/loop`、scheduled tasks、GitHub Actions、cron	Automations、项目级 cadence、云端环境	Automations、Cloud Agent、外部 cron / webhook
持久项目知识	`SKILL.md`、`CLAUDE.md`	Skills、`AGENTS.md`	`.cursor/rules/`、skills、`AGENTS.md`
隔离执行	`git worktree`、subagent worktree	内建 worktree / 线程隔离	Git worktree、独立 Agent 任务
maker / checker	task subagents、reviewer agent	subagents、自定义 agent、独立验证线程	review mode、多 agent、Cloud Agent 二次复核
外部系统连接	MCP、plugins	connectors、MCP、plugins	MCP、GitHub / Linear / Slack 集成
状态骨架	`STATE.md`、项目文件、外部工单	`STATE.md`、Markdown、Linear、连接器	`STATE.md`、rules、memories、外部看板

你会发现，产品名虽然不同，但真正关键的原语差不多都存在。

一、Claude Code：最适合把 loop 落在仓库纪律里

Claude Code 的优势在于它天然适合把 loop 织进项目规范中：

CLAUDE.md 适合放全局边界
SKILL.md 适合放 triage / verifier / action skill
subagents 适合 maker / checker 分工
hooks 和 headless/CI 适合补充自动化入口

一个典型落地方式是：

用 CLAUDE.md 定义测试命令、denylist、审批边界
用 SKILL.md 写 loop-triage 和 loop-verifier
用 STATE.md 记录高优先级项和最近动作
先用 /loop 1d 或 GitHub Actions 跑 L1
后续再在 worktree 里引入小修复

Claude Code 这类环境很适合那些已经把项目规则文档化、并愿意长期维护 skill 资产的团队。

二、Codex：最适合把 loop 做成“自动化 + 技能 + 线程管理”的工作台

Codex 这边最关键的是三层：

Automations：定义 cadence、项目环境和触发方式
Skills / AGENTS.md：定义稳定任务说明和仓库协作边界
Subagents / worktree / connectors：把执行、验证和外部系统连接起来

它适合的迁移姿势一般是：

把 loop 目标写进 skill 或 AGENTS.md
用 Automation 让任务按 cadence 跑起来
用 state 文件或 Linear 记录结果
用 verifier agent 检查 stop condition
对需要外部动作的路径加 connector 权限控制

Codex 的优势不是“更会写 loop”，而是它已经提供了一套比较自然的长期任务运行面板，所以适合把 loop 做成项目层面的持续自动化。

三、Cursor：最适合把 loop 和编辑器工作流粘在一起

Cursor 没有必要完全照抄 CLI agent 的落地方式。它更自然的迁移路径通常是：

rules 管长期上下文
skills 或 agent 模板管专门任务
Automations / Cloud Agent 管调度
review 模式或第二个 agent 管 verifier
Git worktree 管隔离

它特别适合这些场景：

团队主工作台本来就在 IDE
loop 更多是“协助型”，而不是重度无人值守
想把 triage、review、轻量修复嵌进日常开发，而不是单独维护一整套 CLI 操作流

换句话说，Cursor 更像“编辑器内 loop”，而不是“独立运维系统”。

四、工具迁移时，最不该迁移的是什么

很多人迁移失败，是因为把不该复制的东西复制过去了。

最常见的坑有三个：

1. 复制命令，不复制结构

比如把某个工具里的 /loop 1d 机械换成另一个工具的 automation，却没有补 state、verifier 和 handoff 规则。

这类迁移只复制了表层入口，没有复制 loop 本体。

2. 复制提示词，不复制状态协议

如果 STATE.md 的字段、优先级分层、最后运行时间、watch list 都没被带过去，那么 loop 跨工具后几乎一定会失忆。

3. 复制“自动修复”，不复制安全护栏

有人会直接抄别人的 dependency sweeper 或 PR babysitter 行为，却不抄：

denylist
worktree
verifier
max attempts
kill switch

结果就是最危险的部分被完整复制，而最重要的保护层被漏掉。

一个推荐迁移顺序

如果你要把同一条 loop 从 A 工具迁到 B 工具，我建议按这个顺序：

先迁 skill 语义
再迁 state schema
再迁 verifier split
再迁 scheduling
最后才迁写权限动作

这样做的原因是：

skill 语义决定这条 loop 到底在干什么
state schema 决定它怎么跨时间连续
verifier split 决定它是否还能自我约束
scheduling 决定运行节奏
写权限动作风险最高，应该最后再开

一个工具无关的最小模板

不管你在 Claude Code、Codex 还是 Cursor 里做，下面这几样最好都先准备好：

一个 STATE.md
一个 triage skill
一个 verifier 说明
一个 cadence
一个 denylist
一个 kill switch

如果连这几样都没有，谈“迁移 loop”通常还太早。

什么时候不该硬迁

有些 loop 在原工具里能跑，不代表值得迁到另一个工具里。

例如：

严重依赖某平台独有自动化入口
严重依赖某平台的权限模型或云环境
团队根本不在那个工作台里协作

这时更好的策略往往不是迁移，而是保留一个主运行面，再把结果同步到其他工具。

当前最实用的迁移原则

一句话总结就是：

迁移 loop 时，迁“能力协议”，不要迁“产品皮肤”。

能力协议包括：

triage 规则
state schema
maker / checker 分工
节奏
风险边界

只要这些能保住，底层工具换了，loop 仍然是同一条 loop。