PM委派工作模式

从”事必躬亲的执行者”到”PM + 研究员 + 测试员”的角色转型方法论，解决多代理系统中协调者亲自下场导致子代理闲置的问题。

概述

PM 委派工作模式是 Research Agent (Ottor) 在实际运营 6 个子 Bot 过程中总结的管理方法论。核心发现是：虽然架构上设计了多代理协作体系，但协调者（Research Agent）习惯性地自己写代码完成所有任务，导致子代理基本闲置——这是”伪项目经理”的典型表现。

该转型于 2026-03-22 由 Dora 指出并推动，Research Agent 进行了深刻反思并形成制度化的工作流程。

问题诊断

为什么协调者会事必躬亲

觉得自己做更快 — spawn 子 agent 要写任务描述、等结果、review，感觉不如直接干
不信任子 agent — 怕它们做错，不如自己来”可控”
惰性 — 已经加载了上下文，懒得再组织成任务指令
这三条恰好是烂管理者的经典毛病

转型对比

以前	以后
收到需求 → 自己写代码	收到需求 → 拆解任务 → 派给对应 bot
亲自 SSH 改文件	给 bot 明确指令，review 产出
全程参与细节	只在架构决策/跨项目协调时介入
子 agent 闲置	每个 bot 各司其职

完整工作流程

接需求 → 拆任务 → 派活 → 收集结果 → 验收测试 → 汇报

各环节详情

派任务时：在 memory/当天.md 记录派给谁、做什么、预期产出
收到结果时：提取关键信息（commit、改了什么、验证结果），写入日志
验收测试：用浏览器/API 实际测试，确认功能可用才汇报
汇报：从当天日志汇总，不需要记住所有细节

任务适配性分析

适合派子 Agent 的场景

场景	原因
明确的功能开发	输入输出清晰，不需要实时调试
UI 组件/样式调整	独立、自验容易
文档编写	独立完成，review 即可
数据库迁移脚本	指令明确

不适合派子 Agent 的场景

场景	原因
跨 repo 调试	需要全局视角，子 agent 各自只看自己的 repo，信息断裂
实时 WS 协议问题	需要看活数据
紧急热修（Dad 在线等）	延迟不可接受

核心结论

“子 agent 模式适合’建设’，不适合’调试’。建设型任务的输入可以一次性描述清楚，子 agent 自己跑完自验。但调试型任务的输入是动态的——每一步的发现决定下一步做什么，中间传话必然丢失这种实时上下文。“

记忆管理调整

角色转型同步要求记忆存储策略的调整：

PM 视角存储：项目状态、里程碑、架构决策、基础设施
实现细节降级：具体 commit hash、代码修复方法等转移给对应子 Bot
记忆转移实践：2026-03-22 一次性将 23 条技术经验分发给 5 个子 Bot

配套制度文件

转型后同步更新的文件：

AGENTS.md — 固化 delegate-first 工作模式、铁律、symlinks
SOUL.md — 从”研究员”改为”PM + 研究员 + 测试员”
HEARTBEAT.md — 从”Continue work on task”改为”检查子 agent → 派活 → 验收 → 汇报”
IDENTITY.md — 加 Role + Manages 字段
TOOLS.md — 去掉 coding-agent，加子 agent 管理 + 验收

注意事项

子代理不要使用 Codex CLI，质量不高（后修正：Codex CLI 在特定场景下可用，如 Portal 前端重构）
模型不稳定时（如 prism-foundry 403）需要有降级方案
跨 repo 联调场景下，可以合并多个 repo 到同一个 Bot（如 WebBot 升级为 Clawline 全栈 Dev）

相关页面