目标驱动的 Agent 研发模式
Native 是 Comet 为强模型设计的需求工作流。Fable 5、GPT-5.6 等模型已经能够自主调查代码、制定方案，并根据风险选择测试策略。对这类模型，继续强制套用固定的设计、计划和 TDD 流程，额外收益有限。 Native 只规定两件事：- 把需求固定下来：用
brief.md（记录目标、范围、非目标和已确认的用户决定）和完整目标 Specs 明确“要做什么”。 - 用证据判断是否完成：由 Runtime 运行必要检查，再由独立 Verifier 判断结果是否满足验收标准。
Native Loop 如何完成目标
Shape 把用户目标转化为 brief、Specs 和可验证的验收项；Build 由模型自主实现；Runtime 运行必要检查，再由独立 Verifier 对照验收项判断结果。 任何未通过项都会连同失败原因一起回到 Build，修复后重新验证；只有所有验收项都通过，才进入 Archive。遇到新的用户决定或无法继续的阻塞时，Loop 会立即暂停并交还用户，避免无效重试。与 /goal 的区别
Native Loop 也是一种 Goal Loop。它和 /goal 都让 Agent 围绕可验证的终点持续推进。区别在于，/goal 提供通用的长期执行能力；Native Loop 专门为软件研发定义了固定的阶段、验收标准和状态管理。
换句话说，Native 在通用 Goal 的持续执行之上，补齐了软件研发需要的目标定义、状态恢复、证据验收和交付归档。你也可以组合使用两者：让
/goal 提供长时间持续执行，让 Native 负责研发过程中的目标、工作区、状态和完成判定。
让 Skill 回归本质
过去，我们常用 Skill 写入大量工程规则，让 Agent 按照固定的设计、计划、TDD 和审查流程开发，如 Superpowers。当模型进入 Fable 5、GPT-5.6 这一档后，它们已经具备更强的自主调查、规划和工具选择能力。过于具体的流程规定，反而可能与模型自己的推理路径发生冲突。 我们回到 Skill 的本质：Skill 本身会作为 System Prompt 进入 Agent Harness 流程；Agent 运行时会查看当前任务是否与 Skill 的 name 和 desc 匹配，再决定是否渐进式加载这个 Skill。 因此，Comet Native 刻意没有在 Build 阶段重复写入大段工程执行规则。以 TDD 为例，如果需要让 Agent 在实现时采用 TDD，只需要安装 TDD 的 Skill，并确保 Skill 描述适用于编码任务。 执行 Comet Native 时，Agent 会自主选择适合的工程 Skill。Comet Native Skill 因此可以聚焦 Native 自身的工作流协议，TDD 等工程方法则由对应 Skill 提供。这种 ReAct Agent 的做法对应着过去两年业界 Agent 架构从 Workflow 探索走向全面 ReAct 的转变，Skill 领域也在发生同样的变化。借助这种架构，100 多行的 Comet Native Skill 即可承载过去 Comet Classic 多个 Skill 协同完成的工作。从目标到交付，四个阶段自动推进
四个阶段聚焦四个关键结果：目标清楚、实现可控、验收可信、交付可追溯。模型可以自主决定具体执行方法，Runtime 负责自动衔接阶段，并在需要你决定时暂停。Runtime 的内部构成，见 Native Runtime 的组成。Shape：把模糊需求变成可执行目标
Shape 会先调查仓库，再根据已知信息动态提出需要确认的问题。信息分成三类：- 可调查事实：可以从代码和环境中查明，由 Agent 自己调查。
- 用户决定：会改变最终结果，需要由你确认。
- 实现选择：不影响用户可见结果，留给模型处理。
- Batch（批量澄清）：一次集中展示当前所有彼此独立的问题，适合希望快速完成确认的需求。
- Sequential（线性澄清）：一次只问一个影响最大的关键问题；回答后立即更新决策树，再进入下一层。
Build：强模型自主实现，Comet 负责目标推进与交付验收
进入 Build 后，brief 和 Specs 定义“最终要得到什么”，模型则根据任务自主选择设计方案、测试方式和工程 Skill。Comet 负责工作区、状态、阶段衔接和中断恢复，让模型把注意力留给代码本身。 普通需求可以在一个 Change 中完成。遇到真正适合拆分的大型目标，Native 会使用 Supervisor Change：先明确子任务、依赖和验收范围，再为当前可以开始的子任务准备独立 worktree。不同任务可以并行实现，但只有依赖满足、验证通过的结果才会按顺序集成。 Builder 最后提交的代码不是“已完成”的定论，而是一份候选实现，由 Verify 判断是否通过。深入了解：Supervisor Change。Verify：让每一项完成都有证据
Verify 接手 Builder 提交的候选实现。Runtime 根据完整验收列表运行必要检查，再启动一个全新的只读 Verifier Subagent。它不参与实现，也不能修改代码，先读当前范围的验收场景、brief、完整 Specs、实际实现和 Runtime 检查结果逐项验收，最后才把 Builder handoff 当作辅助线索，保证判断独立。漏项、重复项、未知验收项或失败检查均判为未通过。 如果验收失败，Runtime 会把失败原因带回 Build。Builder 修复时优先检查未通过项和受到影响的范围；局部问题解决后，还要再进行一次覆盖全部验收项的最终验证。连续失败、进展停滞或执行错误达到上限时，Loop 会暂停并说明原因，避免继续消耗轮次。 深入了解：Native Loop 和 验证与修复。Archive：把通过验收的结果沉淀下来
只有所有验收项都通过，Native 才允许进入 Archive。Runtime 会生成可读的verification.md，保留需求、Specs、验收证据和最终结论，并把确认后的规格应用到项目文档中。
Archive 会复用已通过的检查，同时确认代码、规格和验收结果仍然匹配。如果归档前需求或实现发生变化，旧结果会失效，并回到正确的阶段重新处理。
最后，Comet 根据你的交付选择保留当前工作区、合并结果、推送分支或创建 PR。change 的工作区有三种隔离模式：current（直接在你当前所在的分支和目录中完成）、branch 和 worktree。current 工作区的 change 不询问交付方式：Comet 展示当前分支和目录，归档不做任何 merge、push 或 PR，你确认后直接完成归档。branch 或 worktree 隔离的 change 在归档前给出五个互斥选项：仅保留工作区、本地合并、推送、推送并创建 PR、暂缓归档。以后无论换会话还是换设备，都能从项目中的正式产物追溯这次需求如何完成。深入了解：归档与交付、产物与状态 和 连续推进与恢复。
状态与中断恢复
当你关闭会话、换设备或流程中断后，Comet 读取保存在项目里的状态，从上次停下的地方继续。状态分散在三类位置：-
change 目录下的
comet-state.yaml：保存阶段、Loop、验收、handoff、检查摘要、Verifier 结论、阻塞原因、最近 50 条执行记录和下一步。换设备或本机执行状态文件缺失时，Runtime 从这份 YAML 重建。 -
.comet/runtime/native/下的本机文件：state.json、日志、锁和事务。这些文件不跨设备同步，丢失后按上一条从 YAML 重建。 -
.comet/current-change.json：记录当前写入属于哪个 change，避免将后续修改写到其他需求。status和show保持只读，查询期间会继续保留这个指向。如果当前 change 已删除或归档，可以从活跃 change 中重新选择：
和 Classic 的关系
Native 和 Classic 是两套独立的工作流，各自面向不同的模型能力和开发方式，怎么选见 Native 与 Classic 如何选择。/comet 按 .comet/config.yaml 的配置转发，两边分别管理自己的 change、Guard、状态和目录。
继续阅读：Native 快速开始、Native Loop、产物与状态 和 安全与恢复。