如何用第一性原理和对抗性审查指挥 Agent Debug 讲的是：先拆系统为什么会进入这个状态，再拦住错误诊断。查清楚之后，还得有人把 Agent 真正跑起来。这篇讲运行层：我怎么用 Paseo 调度 Claude Code 和 Codex。
超过一小时的长任务怎么拆 Master / Development / Acceptance，写在 如何让 Agent 持续自主执行一段较长的任务。
Paseo 是我日常开发里的 Agent 运行和管理层。要解决的事很具体：Agent 怎么跑起来、怎么交接、怎么连续工作几个小时而不失控。
Desktop 端我主要用 Paseo 管理 Agent，Harness 则是 Claude Code 和 Codex。Paseo 把它们统一调度起来，我再按任务决定谁分析、谁实现、谁验证。
Paseo 在我工作流里的位置
日常开发环境是：
Desktop├── Paseo → Agent 管理、任务编排、多 Agent 协作└── Orca → 成果 Review、文档 Edit
Harness├── Claude Code → 复杂任务的分析、开发、Debug、重构└── Codex → 辅助开发、代码分析、Review、交叉验证Paseo 管的是基础设施：在本机跑一个 daemon，统一管理 Claude Code、Codex 等 Coding Agent。Agent 可以并行，可以指定不同 provider，也可以用 worktree 隔离。
实际会用到的 CLI 大致是：
paseo run --provider claude/opus-4.6 "implement user authentication"
paseo run --provider codex/gpt-5.4 --worktree feature-x "implement feature X"
paseo lspaseo attach abc123paseo send abc123 "also add tests"分工可以看成：
Paseo = Agent 怎么运行、怎么隔离、怎么互相发消息Paseo Skills = 教 Agent 自己去 spawn、交接、循环、找第二意见Claude / Codex = 真正干活的模型我会根据任务给不同 Agent 分配角色。Paseo 把这套分工变成可以稳定调度的东西。
我真正在用的几层能力
实际用到的是三层。
第一层：Agent Runtime
paseo runpaseo lspaseo attachpaseo sendAgent 怎么运行。
第二层：Agent Orchestration
handoffadvisorcommitteeloopAgent 怎么协作。
第三层：长期自治
Goal+ Loop+ Verifier+ Hook+ Shared State+ SupervisorAgent 怎么连续工作几个小时。
日常短任务只用到第一层和第二层。超过一小时的开发任务，才会把第三层叠上去。
我实际用到的 Paseo Skill
官方的定位是：教 Coding Agent 用 Paseo 的工具和 CLI 去创建、协调、管理其他 Agent，再用 Slash Command 封装常见编排流程。
我直接调用这些 Skill。真正会用的是：
| Skill | 我拿它做什么 | 我什么时候用 |
|---|---|---|
/paseo | Agent 编排的底层说明书 | 几乎不直接调用，其他 Skill 会依赖它 |
/paseo-handoff | 把任务连同上下文交给另一个 Agent | Claude 分析完，要交给 Codex 实现时 |
/paseo-advisor | 要一个只分析、不改代码的第二意见 | 方案拿不准、探索型任务需要挑盲区时 |
/paseo-committee | 两个高推理 Agent 同时做根因分析 | 卡住、方案争论、怀疑自己已经 tunnel vision 时 |
/paseo-loop | Worker / Verifier 循环推进 | 明确目标、需要连续跑较长时间的实施任务 |
组合起来：handoff 负责交接，advisor 负责第二意见，committee 负责困难问题分析，loop 负责持续推进，paseo 本身负责底层 Agent 管理。
/paseo：底层编排说明书
这个 Skill 最基础。官方定义是：
Paseo reference for managing projects, workspaces, and agents.
它告诉 Agent：
- 怎么创建 Agent
- 怎么发送任务
- 怎么查看 Agent
- 怎么管理 worktree
- 怎么做 workspace 隔离
- CLI 有哪些能力
- 不同 Agent 如何协作
官方也把它当作其他 Paseo Skill 的基础依赖。可以看成：
/paseo ↓定义“Agent 可以怎么被调度” ↓handoff / advisor / committee / loop在这个基础上工作这也是为什么 /paseo-loop 启动前会先读 Paseo Skill。所有编排都建在它上面。
/paseo-handoff：我用它做 Claude → Codex 的上下文交接
这是我在 Claude Code + Codex 组合里用得最多的 Skill 之一。
handoff 会形成一份自包含的任务简报，把这些东西一起交给接手 Agent：
- 当前任务
- 上下文
- 相关文件
- 当前状态
- 已经尝试过什么
- 已经做出的决策
- 验收标准
- 约束条件
然后再交给指定 provider，并且支持 worktree 隔离。
常见用法：
Claude ↓分析问题、形成方案 ↓/paseo-handoff ↓Codex ↓在独立 worktree 里实现长任务里，上下文一旦丢，后面的实现就会开始猜。handoff 把交接做成一份完整简报，任务状态就能接上。
分析的人和干活的人可以换模型，任务状态不能断。
/paseo-advisor：我要第二意见，但不让它改代码
探索型任务里，我会完整看完 Agent 的搜索和分析，再自己做决定。Advisor 正好对应这个习惯。
它会启动一个 Agent，站在旁观者角度给第二意见。关键点是 Advisor 不负责执行。
官方要求 Advisor 是 analysis-only，结束时带 no-edits 约束。这很重要，因为我要的是盲区。
比如：
我现在的方案：A → B → C
/paseo-advisor“检查一下这个架构有没有明显问题”得到的是：
Advisor：问题 1问题 2风险 3建议 4然后主 Agent 或我自己决定采不采用。它帮我找盲区，但不替我做决定。
适合：
- 方案已经有了，但不确定有没有明显坑
- 探索型任务里需要一个独立视角
- 第二意见保持独立，不直接改当前实现
/paseo-committee：卡住时才上
正常开发里，Master / Development / Acceptance 三个角色就够了。
这些问题出现时，我才会用 committee：
- 卡住
- 多个方案在争论
- 根因不明确
- 架构级问题
- Agent 已经循环很多次
- 怀疑自己陷入 tunnel vision
官方定义是：
Form a committee of two high-reasoning agents to step back, do root cause analysis, and produce a plan.
委员会成员只分析，不改文件。最后由主 Agent 综合再实施：
Committee Agent A ──┐ ├→ 主 Agent 综合Committee Agent B ──┘ ↓ 实施 ↓ Review这是我在探索型任务里用的“多角度搜索”，放到开发卡住时的一个标准化版本：两个 Agent 从不同角度看同一个问题，我或主 Agent 再做决定。
额外的 Agent 资源，只集中用在真正困难的问题上。
/paseo-loop：长时间任务里我最依赖的机制
超过一小时的开发任务，我会用 Paseo Loop 做持续推进。完整的 Master / Development / Acceptance 长任务架构，写在 如何让 Agent 持续自主执行一段较长的任务；这里只写 Loop 本身。
核心是：
Worker ↓Verification ↓是否完成？ ├── 否 → Worker └── 是 → Stop官方把它定义为 worker / verifier cycle：启动 Worker → 检查结果 → 再启动下一轮 → 直到满足退出条件或达到限制。
我把它理解成：
当前状态 │ ▼ 执行当前任务 │ ▼ 验证结果 │ ▼ 更新任务状态 │ ▼ 是否完成？ │ │ 否 是 │ │ ▼ ▼ 下一轮执行 结束也就是把一个长任务拆成很多个可验证的小循环。
Worker 和 Verifier 必须分开
这是我使用 Loop 时最坚持的一点。
Worker：
修复所有后端测试失败Verifier：
只有当所有测试都通过，并且修改文件合理时，才返回 done=true形成：
Worker ↓ 修改代码 ↓ 测试 ↓ Verifier ↓ ┌─────┴─────┐ ↓ ↓ Done Not Done ↓ ↓ 结束 下一轮 Worker官方建议：对实施型 Loop，Worker 和 Verifier 使用不同 provider，减少互相盲区。
这和我一贯的做法一致：做事的 Agent 和审核 Agent 应该分工。所以我通常会：
Worker → Codex / Claude 里负责实现的那一方Verifier → 另一个模型，只判断“有没有做完、做对没有”Loop 必须设上限
官方明确要求至少设一个：
--max-iterations--max-time
原因很直接：Open-ended loops are how runaways happen.
无限循环是 Agent 失控最常见的来源。我会写成：
paseo loop run \ "...任务..." \ --max-iterations 10 \ --max-time 1h这样即使判断失误，也不会无限烧资源。长任务可以设到数小时，但必须有墙。
同时我会给明确完成条件，避免 Agent 因为“还差一点”就永远不退出。
我怎么做验证：机器检查 + Agent 判断
Paseo Loop 的验证我分成两类，而且经常一起用。
A. Shell 验证：客观、可机器判断的东西
npm testpytestcargo testgh pr checksnpm run build比如：
--verify-check "npm test"这是客观验证。测不过就是没完成，没有商量。
B. Verifier Agent：需要判断的语义问题
代码是否完整？实现是否符合需求？修改是否合理？有没有明显回归？有没有遗留 TODO？
我会把完成条件写死：
只有满足以下条件才返回 done=true：
1. 所有测试通过2. 修改文件符合需求3. 没有明显回归4. 没有遗留 TODO两者一起用时：
Shell Check +Verifier Agent机器检查确定性问题，Agent 检查语义问题。长任务里两边一起卡更稳：测试覆盖能不能跑通，Agent 判断需求有没有做完。
Loop 负责推进，Supervisor 负责看护
这是我自己用下来需要分清的一点。
Paseo Loop 原生的 worker/verifier 循环负责当前阶段的持续推进：
Worker → Verification → Worker → Verification长任务里我同时会放三个并列角色：
Master Agent 定时监督、记进度、记事件、记踩坑、异常恢复Development Agent 开发、测试、Debug、修复Acceptance Agent 查错、查漏、查偏、查越界、验收三个角色并列，共享同一套任务状态。Loop 负责当前阶段的推进。怎么拆这三个角色、共享状态怎么写，展开在 如何让 Agent 持续自主执行一段较长的任务。这里只写它和 Paseo Loop 怎么叠：
Goal ↓ Master Agent （状态 / 监督 / 恢复） │ ┌─────────┴─────────┐ ↓ ↓ Development Agent Acceptance Agent │ │ └─────────┬─────────┘ ↓ /paseo-loop │ Worker → Verify → Worker ↓ Hook ↓ test / build / lint对应关系：
Loop → 让当前阶段不断向前推进Hook → 代码一变就自动检查Master → 看全局，防止挂起和失忆Acceptance → 独立挑错，防止“测过了就算完”Development → 真正干活Loop 负责继续做，Master 负责看住整个系统。
Loop 和 Hook 一起用
Loop = 任务级持续推进Hook = 事件级自动触发Hook：
Agent 修改代码 ↓Hook ↓自动 lint / test / buildLoop：
Worker ↓Verifier ↓不通过 ↓Worker组合起来：
Paseo Loop │ Worker ↓ 修改代码 / 执行任务 ↓ Hook ↓ lint / test / build ↓ Verifier ↓ 是否完成？ ↙ ↘ 否 是 ↓ ↓ 下一轮 Loop 完成能自动完成的检查，全部交给 Hook；Agent 只负责还需要判断的那部分。
按任务类型，我实际怎么选 Skill
需求完整、目标明确的开发任务
开发规范 / 架构雏形 ↓ 主 Agent 拆任务 ↓ 需要换模型实现？ ├── 是 → /paseo-handoff └── 否 → 当前 Agent 继续 ↓ 需要连续推进？ ├── 是 → /paseo-loop └── 否 → 单轮完成 ↓ Hook 自动检查 ↓ Acceptance / Review探索型任务
问题 │ ├→ Agent A：成熟 / 传统方案 └→ Agent B：前沿 / 新方案 ↓ 我完整阅读结果 ↓ 需要独立挑问题？ → /paseo-advisor ↓ 方案对比，我做最终决策 │ ┌────┼────────────┐ ↓ ↓ ↓ 完整初始化 基于现有架构 多方案并行验证 接入工作流一 独立 worktree 每个方案一个 worktree │ │ │ │ └──────┬─────┘ │ ↓ │ 功能验证完成 │ ↓ │ 合并到 main └────────────────┘已经跑起来、但卡住了
连续失败 / 根因不清 / 方案争论 ↓ /paseo-committee ↓ 两个 Agent 只分析 ↓ 主 Agent 综合后再实施超过一小时的长任务
/goal 固定目标 │ ↓ Master / Development / Acceptance │ ↓ /paseo-loop │ Worker → Verify → Worker │ ↓ Hook │ test / build / lint │ ↓ 达成 Goal这条长任务链路的角色拆分，同样见 如何让 Agent 持续自主执行一段较长的任务。
我怎么把 Paseo 嵌进整套工作方式
Paseo 在我这里是整套 Agent 工作流的调度层：
任务 │ ┌───────────┴───────────┐ ↓ ↓ 需求完整 / 明确 探索型任务 │ │ 建立开发规范 多角度搜索 │ │ 拆任务 advisor 挑盲区 │ │ handoff 交接实现 我做决策 │ │ paseo-loop ┌────────┼────────┐ │ ↓ ↓ ↓ Worker / Verifier 完整初始化 现有架构 多方案并行 │ 接入工作流一 独立wt 各走独立wt Hook │ │ │ │ │ └───┬────┘ Master 监督 + Acceptance │ ↓ │ │ 验证完再合 main │ │ └───────────────┴──────────────┘ ↓ 卡住再用 committee ↓ 持续迭代 ↓ 可复制流程沉淀成 Skill短任务用 runtime + handoff 就够。要第二意见就上 advisor。真正卡住再用 committee。需要连续跑才上 loop，而且必须有上限、有 Verifier、有 Hook。再长，才叠 Master / Development / Acceptance 和共享状态。
这篇是调度层：把 Agent 的运行、交接、验证和长时间推进，收成一套能反复用的方式。三个角色怎么看护一个连续跑几小时的任务，写在 如何让 Agent 持续自主执行一段较长的任务。干活的 Agent 连续跑，旁边得有人验证、有人看护，踩过的坑也得留下来。