上一篇 如何用第一性原理和对抗性审查指挥 Agent Debug 讲的是先拆系统为什么会进入这个状态，再拦住错误诊断。把现象、假设、探针、审查和补丁拆开，是为了别让 Agent 在错的层上打补丁。那套分工解决的是：这一次 bug 怎么查。
但如果任务要连续跑 1 小时甚至数小时，问题会变成另一类。系统会不会挂住，会不会忘了做到哪，会不会慢慢偏离最初的 Goal。
这种时候我会放三个并列的 Agent：Master 管全局状态、定时监督、进度和事件；Development 管开发、测试、Debug 和修复；Acceptance 管查错、查漏、查偏、查越界和验收。三个 Agent 共用一套任务状态，靠状态、事件和阶段结果协作。
三个 Agent 的并列关系
┌──────────────────────┐ │ GOAL │ │ 目标 / 范围 / 约束 │ │ 验收标准 / 阶段目标 │ └──────────┬───────────┘ │ ▼ ┌────────────────────────────────────────────────┐ │ SHARED TASK STATE │ │ │ │ Goal / Progress / Events / Decisions │ │ Blockers / Status / Pitfalls / Acceptance │ └────────────────────────────────────────────────┘ ▲ ▲ ▲ │ │ │ │ │ │ ┌────────────┴──────┐ ┌───────┴─────────┐ ┌───────┴──────────┐ │ MASTER AGENT │ │ DEVELOPMENT │ │ ACCEPTANCE AGENT │ │ │ │ AGENT │ │ │ ├───────────────────┤ ├──────────────────┤ ├──────────────────┤ │ 定时监督 │ │ 开发 │ │ 查错 │ │ 记录进度 │ │ 测试 │ │ 查漏 │ │ 记录事件 │ │ Debug │ │ 查偏 │ │ 记录踩坑 │ │ 修复 │ │ 查越界 │ │ 维护全局状态 │ │ 推进阶段 │ │ 验收 │ │ 异常恢复 │ │ │ │ │ └──────────┬────────┘ └────────┬─────────┘ └────────┬─────────┘ │ │ │ └───────────────────┼────────────────────┘ │ ▼ 持续更新状态 │ ▼ ┌──────────────────┐ │ 下一轮监督 / 执行 │ └──────────────────┘三个 Agent 职责并列，盯的东西不一样。Master 做全局观察，Acceptance 做独立验收，Development 负责开发，围着同一个 Goal。
Master Agent：任务状态管理者和监督者
Master Agent 是整个长任务的全局观察者。它要保证任务始终能被看见、能被追回去、挂了能恢复、停了能接着做。
主要负责：
Master Agent├── 定时巡查 Agent 状态├── 记录整体进度├── 记录关键事件├── 记录开发过程中踩过的坑├── 维护当前阶段├── 维护 Goal / Scope / Constraint├── 维护 Blocker├── 维护关键决策├── 判断整体任务是否偏离└── 发现 Agent 异常时进行恢复定时监督
Master Agent 按固定周期巡查。
Development Agent├── 是否仍在运行？├── 最近是否产生进展？├── 当前正在做什么？├── 是否长时间没有状态变化？└── 是否出现连续失败？
Acceptance Agent├── 是否发现新的问题？├── 是否发现需求遗漏？├── 是否发现范围偏移？└── 是否发现越界修改？根据这些信息更新整体状态，并决定：
- 继续运行
- 提醒 Agent
- 恢复挂起 Agent
- 重新分配任务
- 触发额外分析
- 进入下一阶段
记录进度和事件
长任务最怕的是：Agent 自己知道发生了什么，系统不知道。
所以 Master Agent 要持续记录：
Progress├── 当前阶段├── 已完成任务├── 正在执行任务└── 下一步任务
Events├── Agent 启动├── 阶段完成├── 测试失败├── Bug 修复├── 方案变更├── Agent 异常└── Agent 恢复任务跑几个小时之后，仍然能很快回答：现在做到哪里了？中间发生过什么？为什么选现在这个方案？哪些问题已经解决？还有哪些没解决？
记录开发踩过的坑
这一点在长期 Agent 工作流里特别重要。Master Agent 要同时记下：为什么之前失败，以及以后应该怎么避开。
比如 Development Agent 曾经遇到：
问题：某个 API 在高并发情况下出现死锁。
尝试：第一次通过修改锁顺序解决，但导致另一个测试失败。
最终方案：调整任务队列的生命周期管理。
根因：原来的锁持有范围过大。
经验：后续修改该模块时禁止在 IO 操作期间持有该锁。可以收成：
Pitfalls├── 问题现象├── 根因├── 错误尝试├── 最终解决方案└── 后续注意事项下一轮 Agent 开始工作时，可以直接读到已有经验。一次任务里的失败，能变成下一次任务的知识。
如果某个坑反复出现，还可以再往上收一层：
- 开发规范
- Check Rule
- Hook
- 自定义 Skill
- 项目级文档
最终是：
踩坑 ↓记录 ↓总结 ↓形成规则 ↓自动检查 / Skill ↓后续任务避免再次踩坑我觉得这是 Master Agent 真正值钱的长期能力。普通任务管理只记进度，它还记这个团队是怎么把坑踩出来的。
Development Agent：真正干活的人
Development Agent 是主要执行者，负责把当前阶段的目标做完。
Development Agent├── 读取任务和当前状态├── 阅读代码├── 分析问题├── 实现功能├── 修改代码├── 运行测试├── Debug├── 修复问题└── 推进当前阶段Development 和 Debug 由同一个长期 Agent 承担。真实的软件开发本来就是：
开发 ↓运行 ↓发现问题 ↓Debug ↓修复 ↓重新运行 ↓继续开发同一个 Agent 保持整个上下文，更容易理解：为什么当初这么实现、哪个修改引入了问题、当前 Bug 和前面的代码有什么关系、为什么之前的方案失败。
所以 Development Agent = Dev + Test + Debug + Fix + Continue。它是任务的主要生产者。
Acceptance Agent：独立找问题的人
Acceptance Agent 的核心是尽可能证明当前结果仍然有问题。可以把它看成一个独立的反向思考者。
主要从四个方向检查：
Acceptance Agent├── 查错├── 查漏├── 查偏└── 查越界查错
已经实现的东西有没有问题：
- 逻辑错误
- 异常情况
- 边界条件
- 性能问题
- 回归问题
- 测试覆盖不足
查漏
需求是否全部实现。
PRD├── 功能 A ✅├── 功能 B ✅├── 功能 C ❌└── 功能 D ?Development Agent 认为“功能已经完成”之后，Acceptance Agent 仍要对照需求逐项确认。
查偏
Agent 是否逐渐偏离最初目标。
原始 Goal 可能是：
实现一个轻量级登录模块开发过程中却慢慢变成：
重构整个用户系统修改数据库架构替换认证框架重写权限系统这就是典型的 Scope Drift。Acceptance Agent 应该及时指出：当前工作已经超出 Goal 的必要范围。
查越界
Agent 是否改了明确禁止修改的区域。
允许：src/auth/*src/api/login/*
不允许：数据库核心结构支付模块用户权限系统避免长任务跑得越久，修改范围越大。
三个 Agent 共享一套持久化状态
三个 Agent 围着一套持久化任务状态工作。
.agent/├── GOAL.md├── STATUS.md├── PROGRESS.md├── EVENTS.md├── DECISIONS.md├── BLOCKERS.md├── PITFALLS.md└── ACCEPTANCE.md各自放什么：
GOAL.md→ 最终目标、范围、约束
STATUS.md→ 当前阶段、Agent 状态
PROGRESS.md→ 已完成、进行中、下一步
EVENTS.md→ 关键事件和时间线
DECISIONS.md→ 重要技术决策及原因
BLOCKERS.md→ 当前阻塞问题
PITFALLS.md→ 已踩过的坑、根因、解决方案、后续注意事项
ACCEPTANCE.md→ 验收标准和验收结果即使 Agent 因为 Context 压缩、进程退出或其他原因重启，也可以通过状态把任务接回来。
三个 Agent 应该长期并行存在
它们可以同时在。
┌─────────────────┐ │ Shared State │ └───────┬─────────┘ │ ┌───────────────┼───────────────┐ │ │ │ ▼ ▼ ▼ Master Agent Development Agent Acceptance Agent │ │ │ 定时巡查 持续开发 持续审查 │ │ │ └───────────────┼───────────────┘ ▼ 状态持续更新Development Agent 在干活的时候，Acceptance Agent 可以同时审查；Master Agent 周期性观察整个系统。Acceptance 不必等 Development 完成一个“大阶段”才开始。
Master Agent 的监督循环
Master Agent 按固定周期巡查：
┌──────────────────┐ │ Master Agent │ └────────┬─────────┘ │ ▼ 读取共享状态 │ ▼ 检查 Agent 状态 │ ┌────────────┼────────────┐ │ │ │ ▼ ▼ ▼ 正常 长时间无进展 异常退出 │ │ │ ▼ ▼ ▼ 记录状态 分析原因 恢复 Agent │ │ │ └────────────┼────────────┘ ▼ 检查整体进度 │ ▼ 更新事件 / 进度 │ ▼ 记录新的踩坑 │ ▼ 下一次巡查这里的“定时”很重要。长任务里更常见的问题不是报错，而是什么都没报错，但已经半小时没有任何有效进展。Master Agent 得能认出这种情况。
/goal：固定长期目标
长任务跑几个小时后，最容易发生的是目标漂移。所以我会把最终目标显式固定下来：
GOAL
完成 XXX 功能。
必须满足：1. ...2. ...3. ...
允许修改：1. ...2. ...
禁止修改：1. ...2. ...
最终完成标准：1. ...2. ...Master、Development、Acceptance 三个 Agent 都以这个 Goal 作为共同基准。
/paseo-loop：持续运行的循环机制
Paseo Loop 更适合承担“让任务不断向前推进”的职责：
当前状态 │ ▼ 执行当前任务 │ ▼ 验证结果 │ ▼ 更新任务状态 │ ▼ 是否完成？ │ │ 否 是 │ │ ▼ ▼ 下一轮执行 结束它把一个长任务拆成很多个可验证的小循环。同时应该设置：
- 最大迭代次数
- 最大运行时间
- 明确完成条件
避免 Agent 因为判断失误进入无限循环。
/paseo-loop 是调度层，不是这套架构本身。Paseo 怎么当 runtime、/paseo-loop 怎么落地，我写在 我怎么使用 Paseo 里。
Hook：把关键检查自动化
Hook 适合做那些每次都该执行、不该漏掉的检查。
代码发生变化 ↓ Hook ├── lint ├── typecheck ├── test └── build以及：
阶段完成 ↓ Hook ↓更新状态 / 记录事件 / 执行验证Loop 负责“继续做”，Hook 负责“自动检查”。具体怎么接到 Paseo 的调度上，同样见 我怎么使用 Paseo。
Subagent：尽可能并行，但限制层级
长任务中，我会尽量用 Subagent，把可以并行的工作拆出去。
Development Agent├── Research Subagent├── Test Subagent└── Analysis Subagent但一般控制在 2 层以内：
Main└── Agent └── Subagent任务树过深会导致上下文失真、责任边界模糊、状态难追、重复劳动、故障难定位。所以我的原则是尽可能横向并行，层级压在两层以内。
遇到复杂问题时，再临时增加认知能力
正常情况下 Master、Development、Acceptance 三个就够了。
当某个问题明显复杂，比如根因不明确、两套技术方案选不下来、Agent 连续多次失败、怀疑已经走错方向，才临时调用其他 Subagent / Skill：
Advisor→ 第二意见
Committee→ 多角度 Root Cause Analysis
Handoff→ 把任务交给另一个更适合的 Agent额外的 Agent 资源，集中用在真正困难的问题上。/paseo-advisor、/paseo-committee、/paseo-handoff 的日常用法，见 我怎么使用 Paseo。这里只关心它们在长任务架构里的位置：平时不占坑，卡住了再请进来。
长任务最重要的是失败经验可以积累
整个系统最后应该形成这样的反馈：
开发 │ ▼ 踩坑 │ ▼ Master 记录事件 │ ▼ 记录到 PITFALLS │ ▼ 总结根因 / 解决方案 │ ▼ 提炼成规则 / Skill │ ▼ 下一次任务直接复用Agent 系统在不断积累：
项目 1 ↓踩坑 ↓经验
项目 2 ↓复用经验 ↓新的踩坑 ↓经验升级
项目 3 ↓……慢慢会形成一套自己的工程知识库和 Agent Skill 库。Master Agent 和普通“任务管理 Agent”的差别也在这里：它同时记录任务做到哪里了，以及这个团队是怎么把坑踩出来的、以后怎么避免再踩。
最终的长期自治架构
一个要跑数小时甚至更久的任务，可以抽象成：
┌──────────────────┐ │ GOAL │ │ 目标/范围/约束 │ │ 阶段目标/验收标准 │ └────────┬─────────┘ │ ▼ ┌──────────────────────────────────────────────────────┐ │ SHARED TASK STATE │ │ │ │ Goal / Status / Progress / Events / Decisions │ │ Blockers / Pitfalls / Acceptance │ └──────────────────────────────────────────────────────┘ ▲ ▲ ▲ │ │ │ │ │ │ ┌────────┴────────┐ ┌────────┴────────┐ ┌────────┴────────┐ │ MASTER AGENT │ │ DEVELOPMENT │ │ ACCEPTANCE │ │ │ │ AGENT │ │ AGENT │ ├─────────────────┤ ├──────────────────┤ ├─────────────────┤ │ 定时监督 │ │ 开发 │ │ 查错 │ │ 记录进度 │ │ 测试 │ │ 查漏 │ │ 记录事件 │ │ Debug │ │ 查偏 │ │ 记录踩坑 │ │ 修复 │ │ 查越界 │ │ 维护状态 │ │ 推进阶段 │ │ 阶段验收 │ │ 异常恢复 │ │ │ │ 最终验收 │ └────────┬────────┘ └────────┬─────────┘ └────────┬────────┘ │ │ │ └────────────────────┼─────────────────────┘ │ ▼ 状态 / 事件持续更新 │ ┌───────────┴───────────┐ │ │ 正常推进 出现问题 │ │ ▼ ▼ 下一轮 Loop 修复 / 恢复 / 重规划 │ │ └───────────┬───────────┘ │ ▼ 是否达到 Goal？ │ │ 否 是 │ │ └──继续 ▼ 最终完成长时间自主运行靠的是一个能转起来的闭环：Master 看全局，Development 持续干活，Acceptance 持续挑错；Paseo Loop 保证循环推进，Hook 保证关键检查自动执行，Shared State 保证任务不会失忆，Pitfalls 让每一次踩坑变成下一次任务的经验。
这是长任务的架构层。调度层——Paseo 怎么跑 /paseo-loop，以及 handoff、advisor、committee 怎么用——在 我怎么使用 Paseo。