Prime Agent，只给模型一个工具的长跑 agent
内容提要
prime-agent 将大型开发任务拆分为七个阶段，每阶段有独立合同、提交和PR检查点，并引入对抗审查。核心是187行markdown合同，定义阶段边界和验收标准，流水线编排器驱动Cursor云端agent执行，支持断流重连和进程恢复。设计强调小diff、契约先行，通过试写验证契约，确保代码质量与可审性。
延伸解读
合同先行：把验收标准写进流程
prime-agent 的核心不是代码，而是七份 markdown 合同，共 187 行。每份合同定义了阶段边界和验收标准，agent 的任务提示词只有一句“start phase N”，所有规则都长在合同里。这种设计让流程可复制，但合同高度依赖具体项目，换项目需重写，通用性有限。
试写审计：用一次完整实现验证契约
phase 5 要求 agent 完整实现一遍功能，验证前几个阶段的契约是否够用，然后整体回滚。看似浪费，实则划算：agent 算力便宜，契约返工成本高。在注定丢弃的试写中发现缺口，比在正式实现中返工代价小得多。
对抗审查：独立 agent 保证客观性
审查由全新 agent 执行，与实现者零共享上下文，避免自我审查走过场。审查 agent 从 PR checkout，依据合同检查代码质量和违约情况。phase 6 的断言也由独立 agent 编写，确保不变量不由实现者自定。这种设计提高了审查的独立性，但审查只有单轮，修复后不再复审。
容错与局限：断点续跑，但无预算
流水线支持断流重连和进程恢复，--resume 可续跑。但整体是串行执行，无超时和重试上限，一个阶段卡住会阻塞整条流水线。上下文全文内联，大文件会烧 token，且模型硬编码在源码中，换模型需改代码。
Q&A
prime-agent 是什么？它主要解决什么问题？
prime-agent 是一个运行在 Bun 上的终端小工具，用于驱动 Cursor 云端 agent 执行大型开发任务。它通过将任务拆分为七个阶段，每阶段有独立的合同、提交和 PR 检查点，并引入对抗审查，来解决直接让 agent 开发大功能时产生的 PR 过大、难以审查、错误难以定位的问题。
prime-agent 的七个阶段分别是什么？每个阶段的主要任务是什么？
七个阶段依次为：1. 侦查：读旧代码、挑或建 Linear 工单、写一页实现草稿，不写代码；2. 结构：只改 objects/ 下的类型定义，禁止 build；3. 契约：只动函数签名、常量和模块级数据，新函数体用 unreachable() 占位；4. 接线点：在运行路径上打 TODO 注释，不写代码；5. 试写审计：完整实现一遍 feature，验证契约，然后回滚；6. 断言：补缺口，加负空间断言；7. 实现：填掉全部 TODO，端到端跑通，验收脚本必须过。
prime-agent 的 phase 5 试写审计是什么？为什么说它是核心设计？
phase 5 试写审计是完整实现一遍 feature，验证阶段 2-4 的契约是否够用，发现缺口后按阶段归类上报，然后将试写代码整体回滚。它是核心设计，因为通过低成本试写可以提前发现契约缺陷，避免在真实实现后期才发现问题，从而大幅降低返工成本。
prime-agent 如何实现对抗审查？审查 agent 与实现者有什么隔离？
在 phase 2/3/4/6/7 结束后，编排器会创建一个全新的云端 agent，从当前 PR checkout，并提示词要求进行对抗性审查。审查 agent 与实现者（主 agent Steve）零共享上下文，确保审查客观性。审查报告会原文反馈给 Steve 进行修复。
prime-agent 如何处理断流和进程中断？
断流时，SDK 的等待流会报错，waitWithReconnect 会识别该错误并用 run id 重连同一个 run 继续等待。进程中断时，由于会话状态在云端，本地进程死了不会丢失数据，可以通过 --resume 列出云上 agent，选择 phase 和模式（phase 或 review），然后从剩余步骤继续执行。
prime-agent 的配置方式是什么？
每个项目只需一个 .prime-agent 文件，内容为 JSON，包含 project（云端 agent checkout 的仓库）和 context（kick-off 自动附带的文件列表）两个字段。流水线模式的上下文则在启动时交互式指定。
prime-agent 有哪些已知的局限性？
合同不通用，需要按项目重写；流水线串行无预算，一个阶段卡住整条停，没有超时和重试上限；审查只有单轮，修复后不复审；上下文全文内联，常驻文件大时烧 token 且无截断；模型硬编码在源码中，换模型需改代码；测试覆盖不全，仅覆盖流水线步骤推导和断流重连。
