# Agent Taskgraph > 在 Codex 或 Claude Code 中建立有共同目标、角色、任务关系、协作协议和生命周期的原生 Agent Team，并负责拆分、并行、监督、交接、审查与集成。适用于用户明确要求 Agent Team、多 Agent、subagents、任务图、PMO、并行开发，或复杂工作存在多个可独立推进且需要协调的任务；简单任务仍由当前会话完成。 - Skill: `wu736139669/agent-taskgraph` (Agent Skill, multi-file: 8 files) - Install (CLI): `npx skillmds@latest add wu736139669/agent-taskgraph` - Raw SKILL.md: https://api.skillmd.com/api/skills/wu736139669/agent-taskgraph/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - Author: wu736139669 (https://skillmd.com/u/wu736139669) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/wu736139669/agent-taskgraph --- # 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 必须具备： 1. 一个可观察的共同目标、非目标和完成条件。 2. Lead、Integrator 和当前任务真正需要的执行/审查 Roles。 3. 包含 Owner、Needs、Produces、Consumer、Writes、Acceptance 的 Task Graph。 4. `READY / BLOCKED / HANDOFF / REVIEW` 协作事件和决策升级边界。 5. `forming → briefing → executing → reviewing → integrating → complete/stopped` 生命周期。 实际进入 Team 模式时读取 [`references/team-protocol.md`](references/team-protocol.md)，按其中的 Charter、角色、任务和阶段合同执行。需要一个完整示例时读取 [`references/development-team-example.md`](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`](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/`： ```text PROJECT.md 稳定项目事实 TEAM.md Team Charter 与 Roster PLAN.md Task Graph 与集成路径 STATUS.md 生命周期和当前状态 DECISIONS.md 改变团队合同的决策 tasks/.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 `，把 ≤5 条、每条 ≤3 行的经验摘要注入派发消息；召回见 2+ 条同场景 `failure` 时，先处理该风险再派发。 - **验收后**：以真实验收为准跑 `lesson-record.sh` 回写（通过=success / 失败=failure，失败必须蒸馏成「避免:」短句，不堆长文）。 - 经验字段、schema 与纪律见插件内 `skills/agent-gep-lite/SKILL.md`；经验库随 git 仓库走，换机器 clone 即继承。不开插件不影响本 Skill 任何流程。