使用子代理的自主项目管理
管理具有多个并行工作流的复杂项目令人筋疲力尽。您不断上下文切换，跨工具跟踪状态，并手动协调交接。
此用例实现了一个去中心化的项目管理模式，其中子代理自主处理任务，通过共享状态文件而非中央编排器进行协调。
痛点
传统的编排器模式会产生瓶颈——主 agent 成为交通警察。对于复杂项目（多仓库重构、研究冲刺、内容管道），您需要可以并行工作而不需要持续监督的 agent。
功能
- 去中心化协调：代理读取/写入共享的
STATE.yaml文件 - 并行执行：多个子代理同时处理独立任务
- 无编排器开销：主会话保持精简（CEO 模式——仅战略）
- 自我文档化：所有任务状态持久保存在版本控制文件中
核心模式：STATE.yaml
每个项目维护一个 STATE.yaml 文件，作为单一事实来源：
yaml
# STATE.yaml - 项目协调文件
project: website-redesign
updated: 2026-02-10T14:30:00Z
tasks:
- id: homepage-hero
status: in_progress
owner: pm-frontend
started: 2026-02-10T12:00:00Z
notes: "正在处理响应式布局"
- id: api-auth
status: done
owner: pm-backend
completed: 2026-02-10T14:00:00Z
output: "src/api/auth.ts"
- id: content-migration
status: blocked
owner: pm-content
blocked_by: api-auth
notes: "等待新的端点模式"
next_actions:
- "pm-content: 现在 api-auth 完成后恢复迁移"
- "pm-frontend: 与设计团队审查首页"工作原理
- 主 agent 接收任务 → 生成具有特定范围的子代理
- 子代理读取 STATE.yaml → 找到分配给它的任务
- 子代理自主工作 → 进度更新 STATE.yaml
- 其他代理轮询 STATE.yaml → 拾取已解除阻止的工作
- 主 agent 定期检查 → 审查状态、调整优先级
所需技能
sessions_spawn/sessions_send用于子代理管理- 文件系统访问用于 STATE.yaml
- Git 用于状态版本控制（可选但推荐）
设置：AGENTS.md 配置
text
## PM 委托模式
主会话 = 仅协调员。所有执行都交给子代理。
工作流：
1. 新任务到达
2. 检查 PROJECT_REGISTRY.md 是否有现有 PM
3. 如果 PM 存在 → sessions_send(label="pm-xxx", message="[task]")
4. 如果是新项目 → sessions_spawn(label="pm-xxx", task="[task]")
5. PM 执行，更新 STATE.yaml，报告
6. 主 agent 向用户总结
规则：
- 主会话：最多 0-2 次工具调用（仅 spawn/send）
- PM 拥有它们的 STATE.yaml 文件
- PM 可以生成子-子代理用于并行子任务
- 所有状态更改提交到 git示例：生成一个 PM
text
用户："重构 auth 模块并更新文档"
主 agent：
1. 检查注册表 → 没有活动的 pm-auth
2. 生成：sessions_spawn(
label="pm-auth-refactor",
task="重构 auth 模块，更新文档。在 STATE.yaml 中跟踪"
)
3. 响应："已生成 pm-auth-refactor。完成后我会报告。"
PM 子代理：
1. 创建带有任务分解的 STATE.yaml
2. 处理任务，更新状态
3. 提交更改
4. 向主 agent 报告完成关键见解
- STATE.yaml > 编排器：基于文件的协调比消息传递扩展更好
- Git 作为审计日志：提交 STATE.yaml 更改以获取完整历史
- 标签约定很重要：使用
pm-{项目}-{范围}以便轻松跟踪 - 精简主会话：主 agent 做得越少，响应越快
灵感来源
此模式受 Nicholas Carlini 的自主编码 agent 方法的启发——让代理自我组织而不是微观管理它们。