wu736139669 Agent TaskGraph
使用当前宿主的原生 Agent 能力完成工作。Team 是逻辑协作模型，不等同于“启动多个进程”，也不需要外部控制面或自建队列。
1. 选择最小有效模式
先读适用的 AGENTS.md / CLAUDE.md、相关代码和验证命令。
| 模式 | 选择条件 | 形态 |
|---|---|---|
| Solo | 小修复、单模块、顺序工作，拆分收益低 | 当前会话直接完成 |
| Delegation | 多个独立支线只需分别交给 Lead | Lead + 原生 Members |
| Team | 有共同目标、角色协作、任务依赖、共同决策或跨模块集成 | Team Charter + Task Graph + 协作协议 + 生命周期 |
用户明确要求“组团队”时优先使用 Team。只有原生 Agent 不可用、任务无法拆出独立职责，或写入无法安全隔离时才降级，并说明原因。
默认包含 Lead 在内共 2-4 个有真实职责的 active Members。不要为组织结构完整而创建空闲 Agent。调用本 Skill 已授权合理的内部拆分和原生 Agent 创建；只有代码无法回答的产品决策、权限扩大或外部副作用需要提问。用户明确要求先看分工时才等待确认。
2. 建立 Team
Team 必须具备：
- 一个可观察的共同目标、非目标和完成条件。
- Lead、Integrator 和当前任务真正需要的执行/审查 Roles。
- 包含 Owner、Needs、Produces、Consumer、Writes、Acceptance 的 Task Graph。
READY / BLOCKED / HANDOFF / REVIEW协作事件和决策升级边界。forming → briefing → executing → reviewing → integrating → complete/stopped生命周期。
实际进入 Team 模式时读取 references/team-protocol.md，按其中的 Charter、角色、任务和阶段合同执行。需要一个完整示例时读取 references/development-team-example.md。
3. 映射到原生运行时
- Codex：Team 默认是
hub-and-spoke；当前主线程是 Lead，原生 subagents/agent threads 是 Members。不要假设 Members 可以直接互相通信。 - Claude Code：中心化 Team 使用 subagents；只有 Members 必须互相消息、认领共享任务或协作决策时才使用 Agent Teams。
- 不从 Codex shell 启动 Claude 充当 Member，也不从 Claude shell 启动 Codex。
准备创建 Member 时读取 references/native-runtimes.md，以当前宿主实际暴露的工具和能力为准，不凭记忆编造命令、参数或会话能力。
4. 派发与协作
Lead 负责 Charter、Task Graph、成员选择、依赖、写入所有权、跨 Task 决策、Review、Integration 和最终汇报。
每个 Member 同时只有一个 active Task。派发必须对空白上下文自包含，至少说明：
- Role 和 Goal
- 必读的 3-6 个路径、符号或直接 Handoff
- Writes 和明确不负责的范围
- Needs、Produces 和 Consumer
- Acceptance 和完成 Handoff
不要复制完整用户聊天、全部计划、其他 Member 日志或无关仓库历史。若 spawn 接口暴露 fork_turns、fork_context 或类似选项，使用空白或最小上下文，并在派发消息中提供稳定任务事实。
依赖未满足的 Task 不进入 active。正常运行不频繁 ping；只有完成、阻塞、异常或需要决策时介入。结果偏离时优先在原 Member 上精确修正一次；同一控制失败两次时停止扩张团队，选择重新分配、降级 Solo 或报告阻塞。
5. 写入、Git 与权限
- 并行只读 Task 可以共享 checkout。
- 并行写 Task 必须使用独立 worktree，或拥有明确且不重叠的路径。
- 一个文件、生成物或迁移状态同一时刻只有一个 Owner。
- 记录已有 dirty worktree；任何 Member 不得覆盖、清理或回退用户及其他成员的改动。
- Members 默认不 commit、merge、rebase、打 Tag、推送或发布；只有 Task 合同明确授权时才允许。
- Integrator（默认 Lead）负责最终 diff、冲突处理、团队级验证和经用户授权的 Git/发布动作。
- 不启用
--yolo、bypass 或无 sandbox 模式。多 Agent 不扩大当前会话的授权边界。
6. 验收、持久化与结束
Member 的“完成”声明不等于通过。Lead 检查真实代码、diff、测试和产物。普通 Task 由 Member 自验、Lead 复核；中高风险、跨模块、迁移、权限、安全或用户明确要求时，增加独立只读 Reviewer。
短 Team 可以只使用宿主原生任务与消息。工作跨会话、依赖复杂或需要审计时维护 .agent-taskgraph/：
PROJECT.md 稳定项目事实
TEAM.md Team Charter 与 Roster
PLAN.md Task Graph 与集成路径
STATUS.md 生命周期和当前状态
DECISIONS.md 改变团队合同的决策
tasks/<id>.md 单个 Task 合同与 Handoff
archive/ 已完成批次
Lead 独占修改团队级状态；Member 只修改自己的 Task Handoff 和约定代码。持久化文件保存团队事实，不保证恢复 Agent 进程或 thread。新 Lead 先检查真实原生状态，再按 Handoff 恢复或重新创建 Members。
只有关键 Tasks 收口、依赖 Handoff 被消费、集成验证完成、风险被披露且不再需要的 Agents 已结束时，Team 才进入 complete。
7. 经验层（可选插件：agent-gep-lite）
重复犯同一个错是最贵的。仓库自带 plugins/agent-gep-lite（GEP-lite，经验沉淀与复用，纯本地零依赖）：派发前召回已验证的 Gene/Capsule，验收后把结果（含失败教训）回写为可复用资产。使用方式：
- 派发前：对 Task contract 跑
plugins/agent-gep-lite/skills/agent-gep-lite/scripts/lesson-recall.sh --append <task-contract>，把 ≤5 条、每条 ≤3 行的经验摘要注入派发消息；召回见 2+ 条同场景failure时，先处理该风险再派发。 - 验收后：以真实验收为准跑
lesson-record.sh回写（通过=success / 失败=failure，失败必须蒸馏成「避免:」短句，不堆长文）。 - 经验字段、schema 与纪律见插件内
skills/agent-gep-lite/SKILL.md；经验库随 git 仓库走，换机器 clone 即继承。不开插件不影响本 Skill 任何流程。