agents-subagents

通用 Agent 技能（Claude Code + Codex）

本仓库中 Agent 工作的默认入口。

使用此技能作为在 Claude Code 或 Codex 上进行 Agent 工作的主要入口：

• 复用已安装在 ~/.claude/agents/ 或 ~/.codex/agents/ 中的全局 Agent
• 在 .claude/agents/ 或 .codex/agents/ 中创建或更新仓库本地 Agent
• 安装或完善共享成员和仓库团队配方
• 原生分发成员和工作流：插件从其根目录下的 agents/ 提供 Agent，从 workflows/ 提供工作流（命名空间为 plugin-name:agent-name）；将 .claude-plugin/plugin.json 放入技能文件夹，即可将其加载为 <name>@skills-dir，使技能本身能够打包 agents/、钩子和 MCP 服务。scripts/deploy-preset.sh 是用于已安装成员配对项的批量／旧版方式
• 运行结构化辩论
• 针对特定场景选择合适的 Agent、成员、团队或辩论模式
• 准备初始启动提示词，以便顺利启动所选 Agent 或团队
• 定义委派边界、上下文交接质量、工具和安全边界

对于并行执行计划、波次分派和冲突解决，请升级到 ../agents-swarm-orchestration/SKILL.md。对于技能打包和 SKILL.md frontmatter，请使用 ../agents-skills/SKILL.md。

快速参考

调用以下任何基础模块前先设好关卡： 每个基础模块都有 When to Apply / When to Skip 部分。如果你的任务符合跳过条件，请转到其中指定的基础模块，而不要引入任务并不需要的原语。 | 决策 | 默认选择 | |----------|---------| | 需要为 Agent、团队和辩论提供统一入口 | 首先使用此技能 | | 需要根据场景选择合适的 Agent 或团队 | 使用此技能先对任务分类，再启动任何操作 | | 需要一条清晰的首条提示词来启动团队或辩论 | 使用此技能起草启动提示词，明确上下文、责任归属、综合规则和清理要求 | | 已构建应用／产品，但不知道如何打入市场或吸引真正的用户 | 在 growth 模式下运行 expert-board，并使用市场渗透工作流契约 | | 一项边界明确且输出清晰的任务 | 使用内置或自定义子 Agent | | 现有的长期运行 Claude 会话需要直接交接 | 使用跨会话消息传递。只有在队友需要共享任务列表并自行认领任务时才使用 Agent Teams；除非当前界面支持点对点消息传递，否则 Codex 仍由父级主导 | | 需要专家在选择方向前展开辩论 | 优先使用带有明确触发条件的辩论团队；若不太可能出现分歧，则跳过辩论 | | 需要并行编辑不同文件 | Claude 子 Agent 使用 isolation: worktree；Agent Team 队友共用主导者的检出目录。启用 Agent Teams 时，在 Agent 调用本身中传递 isolation（仅在 frontmatter 中设置会被忽略），以启动隔离于 worktree 的子 Agent，而非队友。在 Codex 上，明确分配各自负责的文件 | | 有多项彼此独立的任务需要交接，并稍后回来检查 | 第三种界面：后台会话（agent 视图、/bg、claude --bg）；每个会话都会在编辑前于 git worktree 中隔离自身。机制说明：references/runtime-surfaces.md §"Background sessions and routines" | | 运行时界面、功能矩阵或内置子 Agent 列表 | references/runtime-surfaces.md + ../agents-swarm-orchestration/references/platform-patterns.md | | 需要长期运行的托管 Agent，操作者不在终端前（收件箱分流、定时研究、文档处理） | 在构建运行框架之前，先尝试 Claude Code routines（/schedule）。工具范围应按不存在审批提示来设定，精简连接器，只保留该 routine 所需的项，并让已保存的提示词将触发载荷视为不可信数据。机制说明及升级到 Claude Managed Agents 的方式：references/runtime-surfaces.md §"Background sessions and routines" | | Agent 文件字段 | 目录设置 name、description、tools/disallowedTools、maxTurns、model、effort、skills，以及（仅 implementer 类）permissionMode / isolation。值得采用的字段：color（区分并发行）、experimental.cacheTtl，以及选择启用的 memory（它会将 Read、Write 和 Edit 添加到 Agent 的工具中，而非限制在 memory 目录内）。mcpServers、hooks、background 和 initialPrompt 则有意保持未设置。请在 references/agent-tools.md 中查看当前运行版本支持的字段；模板：agents/templates/member-claude.md.template | | 需要调用方在继续之前使用子 Agent 的结果 | 前台和后台的区别取决于会话模式（interactive、fork mode、-p、Agent SDK），且在不同版本间有所变化，因此绝不要依赖默认行为。在使用结果的步骤之前，先确定此会话是否会将子 Agent 置于后台（查看当前运行版本的文档和运行时冒烟测试）；如果会，则在有相应控制选项时强制使用前台模式，或明确等待完成通知。同一定义在后台可能会解析为不同的工具集。控制选项：references/agent-tools.md §"background"；阻塞式 fork 技能：references/skill-subagent-patterns.md | | 可重复的扇出、确定性循环或验证阶段 | Claude：使用 agents/workflows/ 中已保存的 Workflows；这些工作流已同步到 ~/.claude/workflows/。运行时控制、上限和 agent() 选项说明：references/workflow-runtime.md。Codex：运行 run-workflow 技能，该技能从父会话启动、等待并跟进执行生成的 <id>.codex-plan.json；除 validate-library 命令外，每个工作流都有对应文件。计划是适配器，并非原生的已保存工作流。两者都解析同一份清单和具名成员名单 | | 即将编辑已保存的工作流 | agents/workflows/ 中的库工作流为生成文件：其 .js 文件头说明，应编辑清单或 scripts/ 中的运行时模板，然后使用 scripts/generate_workflows.py 重新生成（expert-board.js 由 scripts/generate_expert_board.py 生成）（--check 用于查找过时输出）。切勿手动编辑 .js 或 .codex-plan.json。对于你自己编写的脚本，请先运行捆绑的 /workflow-authoring 技能。保留 export const meta 作为首条语句，并将其设为包含 name 和 description 的普通对象字面量，否则 /<name> 不会出现在 / 自动补全中；包含 import() 的脚本会在运行开始前失败。在确定规模之前，请先阅读 references/workflow-runtime.md §"Runtime caps" 中当前的并发、每次调用项目数和每次运行 Agent 数量上限 | | 技能 ↔ 子 Agent 委派（skills: 预加载、context: fork） | references/skill-subagent-patterns.md | | 团队／成员／辩论场景、提示词和安装 | references/team-selection-guide.md、references/team-scenarios.md、references/team-prompt-patterns.md | | 在策略／模板更改后，仅刷新现有且由安装程序管理的成员 | 使用 scripts/deploy-all-teams.sh --refresh-installed-managed --platform both --user --dry-run 预览；实际写入还需要 --confirm-bulk-deploy。不会接管或覆盖缺失、已修改、不归安装程序管理或不安全的文件 | | 可视化团队图表（每个团队对应一个 Mermaid 流程图，根据清单自动生成） | references/team-diagrams.md — 使用 python3 scripts/generate-team-diagrams.py 重新生成 | | 验证新的细分领域或从零起步的机会 | 请参阅 references/team-selection-guide.md §"Niche Validation"，了解此仓库特定的团队映射 | | 辩论、拓扑结构、决策掩码、上下文、成本和治理详情 | references/navigation-index.md | 长尾场景条目（覆盖图、生命周期、冒烟测试、系统图）编入了索引，见 references/team-coverage.md；成员／团队清单见 references/team-member-matrix.md。

运行时术语防火墙

• 原生 Claude： 子 Agent 定义、子 Agent、Agent Team、队友、实时团队状态。
• 原生 Codex： 自定义 Agent、子 Agent 工作流、Agent 线程。
• 仅限仓库： 成员、团队配方、team.yaml、辩论叠加层、工作流契约、family 元数据。

设置 CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 后，Claude 启动的任何以名称指定的子 Agent 都会作为队友启动，因此，即使没有人将其视为团队工作，普通的具名成员委派也可能组建团队：在用户的 settings.json 中将该变量设为 0，即可让具名成员继续作为子 Agent（每次启动时都会重新读取该变量，无需重启；优先级更高的项目／本地／托管设置仍可重新启用它）。

绝不要把 team.yaml 称为原生运行时清单。安装配方会安装原生成员定义并存储启动器元数据；运行时不会自行发现 YAML 文件。

何时不应使用

• 跨多个阶段执行计划，或解决多名工作者之间的合并冲突 → ../agents-swarm-orchestration/SKILL.md
• 设计 SKILL.md 文件、技能打包或技能 frontmatter → ../agents-skills/SKILL.md
• 构建钩子或 MCP 服务本身 → ../agents-hooks/SKILL.md、../agents-mcp/SKILL.md
• 父线程无需委派、几轮即可完成的一次性任务

工作流

1. 按照 场景选择规则 中的规范路由顺序进行。
2. 创建 Agent 前，清点已安装的全局／插件及项目 Agent：~/.claude/agents/、.claude/agents/、~/.codex/agents/、.codex/agents/。
3. 选择运行时目标，并定义工具、MCP、隔离和上下文产物边界。将实际启动模式记录为 fresh、forked 或 runtime-defined；切勿仅凭“子 Agent”一词推断对话记录、技能、记忆或权限的继承情况。
4. 对于团队或辩论，使用 team-selection-guide.md 映射场景，然后使用 universal-team-playbook.md 选择执行顺序。
5. 起草启动契约：目标、必需和可选上下文、所有权、执行模式、上下文启动模式、辩论触发条件、综合负责人、证据和清理工作。
6. 当仓库验证不足以满足要求时，运行适用的运行时冒烟测试。

并行分派与验证

• 不要委派主线程通过几次工具调用就能完成的工作。
• 避免泛泛的自我验证指令；仅在难以逆转的决策中使用具名的干净上下文验证者。
• 即使运行时协调有所改善，也要维持单一写入者所有权。

模型生成行为陷阱和 MAST 故障分类法见 references/traps-and-antipatterns.md 和 references/mast-failure-taxonomy.md。

陷阱与反模式

关键故障模式（将工具输出当作指令、没有证据却接受“已完成”、上下文窗口尚未填满就已严重劣化、父级中的 MCP 令牌膨胀、运行时升级后 Agent 文件过时、审批疲劳、重复使用同级技能的模式）见 references/traps-and-antipatterns.md。启动工作者或团队前，以及审查现有 Agent 时，请先查阅此文档。

运行时升级后，请重新审查 Agent 文件；递归、后台执行、字段支持和模型默认值都不是可移植的不变量。请使用 references/runtime-surfaces.md、references/agent-tools.md 和 references/model-governance-and-maintenance.md。

与群体编排的关系

请先使用此技能。

• 使用 agents-subagents 选择合适的全局 Agent、仓库本地 Agent、共享成员、共享团队或辩论模式。
• 使用 agents-subagents 准备初始启动提示词和上下文约定。
• 只有当计划需要多轮扇出、工作者依赖关系、验证者检查或合并／冲突协调时，才切换到 ../agents-swarm-orchestration/SKILL.md。

简单规则：

• agents-subagents = 运行什么
• agents-swarm-orchestration = 如何安全地运行多个工作者

场景选择规则

用户给出场景时，此技能应帮助选择满足需求的最小模式。

按顺序使用以下路由阶梯；遇到第一个足够的选项时即停止：

1. 如果主线程通过几次工具调用就能完成工作，或任务高度依赖当前对话，则留在主线程中。
2. 如果通用研究、规划或实现工作者合适，则使用内置子 Agent（Claude Code 中的 Explore、Plan、general-purpose；Codex 中的 default、worker、explorer）。
3. 如果某个已安装的专业 Agent 正好适用，则使用全局或插件提供的 Agent。
4. 对于仓库约定或临时覆盖，使用仓库本地 Agent；对于可复用的专业 Agent，使用共享成员。
5. 对于控制流已知且不需要同级协调的可重复脚本化扇出，使用已保存的 Workflow。选择能覆盖扇出需求的最小层级；在选择前，请查阅工作流文档或 /config 中当前的层级限制和并发上限。此界面可能需要计划授权，也可能由组织禁用；创建新工作流需要明确选择启用；而 claude -p／Agent SDK 启动需要允许规则 Workflow 或 Workflow(<name>)，因为它们不会显示审批提示。详情和 /workflow-authoring 规则见：references/workflow-runtime.md。
6. 只有此时才查阅 references/team-selection-guide.md 和 references/team-scenarios.md。当多个专家需要分别产出结果或直接协调时，使用共享团队。
7. 只有在异议、质疑和综合能创造价值时，才使用启用辩论的团队或辩论叠加模式。

从零开始探索细分市场（“我是否应该在细分市场 Y 构建 X”）时，应以 founder-blindspot 模式进入第 5 步的 expert-board；补充必需的上下文，并要求输出 references/team-selection-guide.md 中列出的评分卡，以便成员返回规范的创业产物，而非叙事视角。

如果多个团队都可能合适，请优先选择其输出约定与用户请求最直接匹配的团队。

运行时界面

运行时详情存放在参考文档中，以保持技能精简：

• references/runtime-surfaces.md — Claude Code 路径、Codex .toml 格式、字段映射、跨平台规则、会话范围的 --agents、整个会话范围的 --agent <name>、插件优先级、Claude Agent SDK、OpenAI Agents SDK。
• ../agents-swarm-orchestration/references/platform-patterns.md — 字段矩阵、内置子 Agent 表格、Agent 团队的可用性（实验性，由 CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS 环境变量控制）、Codex 多 Agent 模型示例、OpenAI Agents SDK 管理器／交接。

Claude 与 Codex 的主要区别在于编排方式，而非角色设计：

• 在启用了运行时 Agent 团队的情况下，Claude 可支持队友之间直接协作。
• Codex 使用 spawn、follow-up、wait 和 synthesis 原语。委派可以遵循用户的直接请求，或适用的 AGENTS.md／技能策略；如果策略已要求委派，就不要要求用户输入 spawn 命令。
• 两者都应复用相同的上下文优先输入、团队选择逻辑和初始提示词约定。

特定平台的设置仅适用于运行时，并非可移植的默认设置。权威字段矩阵见 ../agents-swarm-orchestration/references/platform-patterns.md — 请先在此处更新。

初始提示词约定

此技能负责首次启动提示词。使用 references/initial-prompt-contract.md 中的 8 字段约定，确保每个子任务的预算都低于父任务的剩余预算，并使任务简报无需父任务的对话记录也可执行。对于检索工作者，传入目标，评估每次返回结果，并在有限次数的后续跟进后停止（检索后续跟进）。可复用的提示词和场景见 references/team-prompt-patterns.md 和 references/team-scenarios.md。

共享成员与团队

规范成员位于 agents/；agents/teams/*/team.yaml 将其组合为仓库元数据，而非运行时配置。当成员的原生模型、工具或技能绑定很重要时，请安装持久成员。工作流会优先调度这些具名成员，只有在当前运行时表明无法选择具名 Agent 时，才使用内嵌角色简报。完整规则见：references/members-and-teams.md 和 references/team-lifecycle.md。

Codex 安装会在每个作用域生成受管理的 TOML，包含模型层级、[[skills.config]] 和重写后的链接。委派仍需用户或适用的 AGENTS.md／技能策略授权。依赖具名 Agent 前，请先确认当前 Codex 界面支持此功能。

共享上下文模式

对于工程套件，优先使用共享产物，而不是反复从头读取。每个子 Agent 启动时都应收到自包含的任务简报，而非父任务的对话记录——这是当前的操作规则。

完整模式（新鲜上下文原则、优先采用来自 dev-context-* 技能的输入、默认交接顺序、发现规则）见：references/context-first-protocol.md。

当前运行时模型

路由阶梯中尚未涵盖的工作规则：

• 优先使用上下文干净的辅助角色进行审查、验证和范围明确的研究；不要默认让这些角色使用持久记忆
• 除非文件和接口彼此隔离，否则保持写入职责由单个线程承担
• 将隔离、技能接线、已保存的工作流和对等通信视为特定运行时才具备的能力
• 保持常驻名单精简；默认安装团队核心成员，只有在有意传入 --include-candidates 时才安装扩展候选成员
• 仅在处理临时任务或明确指出指定 Agent 不可用时，使用通用角色简介

尤其是在辩论中，现有领域 Agent 通常比通用包装器更适合作为参与者，因为它们已有合适的角色身份和技能上下文。

Agent 文件字段和 Frontmatter

Claude Code Agent 文件是带 YAML frontmatter 的 Markdown 文件。Codex Agent 则是 .toml 文件，包含类似字段，但名称不同。

字段参考和选择规则见 references/agent-tools.md（工具允许列表、permissionMode、maxTurns、mcpServers、memory、background、isolation、Codex sandbox_mode 映射，以及完整的反模式列表）。

由两个维护方分别负责，按问题划分，避免相互矛盾。../agents-swarm-orchestration/references/platform-patterns.md 负责字段格式：有哪些字段、可接受的值、skills/hooks/initialPrompt/color、插件 Agent 限制，以及 CLAUDE_CODE_SUBAGENT_MODEL 的解析顺序。references/cost-control.md 负责 effort 和成本：应使用哪些调节手段，以及如何查询每种模型的默认值。如果 platform-patterns 引用了 effort 默认值，以 cost-control 为准。

安全默认值：

• 优先使用 tools 允许列表，而非宽泛继承；一般范围限定时使用 tools 或 disallowedTools 其一，不要同时使用。两者都设置时，会先应用 disallowedTools，再从剩余工具集合中解析 tools，因此同时列入两者的工具会被移除。唯一经认可的例外：叶级角色可在其允许列表旁添加 disallowedTools: [Agent]，参见 §陷阱 — 禁止生成子 Agent 是一项策略声明，不属于工具范围限定，且不得依赖允许列表的继承行为。
• 审查和研究 Agent 的 maxTurns 应保持较低。
• 将 memory 视为可选功能。它会将 Read、Write 和 Edit 添加到 Agent 的工具中；除非拒绝规则限制 Write 和 Edit，否则不要为只读 Agent 设置它。
• 将 mcpServers 限定为确实需要它的单个工作者。stdio 服务会按设计将其启动配置转化为 OS 命令（CVE-2026-30623 是 2026 年的一个实例）：切勿将工作者连接到启动配置源自模型或工具输出的 stdio 服务；应对宿主进行沙箱隔离。
• 在 Claude Code 中，对并行或高风险的子 Agent编辑使用 isolation: worktree。Agent Team 队友不会获得 worktree 隔离，并且会共享主 Agent 的工作副本，即使其启动时使用的定义声明了 isolation 也是如此。启用 Agent Teams 时，在 Agent 调用本身传入 isolation（或进行分叉）会启动子 Agent，而不是队友，因此 worktree 隔离会生效（子 Agent 文档，已于 2026-09-27 核实）。
• 扇出任务前检查 worktree 基准：隔离的 worktree 可能基于默认分支启动，而非父级的 HEAD。先提交父级状态（需要时推送），或将基准设为 HEAD，然后确认每个工作者的基准 SHA 都等于父级 HEAD；否则工作者会在无提示的情况下遗漏尚未推送的工作。详情见：references/agent-tools.md §“isolation”。

技能 ↔ 子 Agent 委派

技能和子 Agent 可以通过两个方向相互引用：

• 角色模式：子 Agent 在 Agent 前置元数据中使用 skills: 预加载技能，使该角色始终在相同的领域上下文中启动。
• 任务模式：技能使用 context: fork + agent: <type> 启动子 Agent，因此技能正文会成为任务提示词，子 Agent 则在隔离环境中运行。

完整的选择指南、限制和示例：references/skill-subagent-patterns.md。

将父级上下文分叉到子 Agent

默认情况下，Claude Code 子 Agent 从空白上下文开始。启用 Agent 视图后，/subtask 会基于当前上下文创建一个后台子 Agent；而 /fork 会将整个会话复制到单独的后台会话中（参见 agent-view 和 sub-agents 文档，已于 2026-10-10 查阅；这些入口受版本限制，请查看当前文档）。Anthropic 说明分叉上下文可以复用提示词缓存，但并未承诺固定的成本倍数。

默认使用空白上下文。只有在能够明确指出父 Agent 已建立、且子 Agent 需要但无法以较低成本重新推导的理解时，才进行分叉。审查者和验证者应始终从空白上下文开始。分叉可能会泄露父 Agent 的机密；分叉前请审核允许使用的工具。

完整的操作规则和内置的 Explore/Plan 流程：references/subagent-context-forking.md。分叉技能的已知模型固定问题：references/skill-subagent-patterns.md。会话生命周期方面的影响：../ai-coding-agents-state/references/context-forking.md。命令运行时方面的影响：../ai-coding-agents-runtime-core/references/command-dispatch-forking-and-remote-safety.md。

按上下文而非角色拆分

按上下文边界拆分，而不是按角色标签拆分。如果两个任务共享深层上下文，就让它们留在同一个 Agent 中。按规划者／开发者／测试者拆分，会在每次交接时造成上下文丢失。一个例外是：子 Agent 会运行至完成，无法在运行中暂停以等待用户批准计划。因此，当用户必须在实现前签字确认时，应在主线程中制定计划，或让子 Agent 返回计划后停止；将获批的计划写入文件，并把该文件交给实现者和审查者。完整的框架说明和架构决策指南：references/subagents-vs-teams-architecture.md。

单个强力 Agent 胜过团队的情况

将以下两项结果作为组建团队前的门槛：

• Token 预算等效规则——在 Token 预算相同的情况下，默认选择一个强力 Agent：只要单个 Agent 能有效利用其上下文，在多步推理任务上的表现就能达到或超过多 Agent（数据处理不等式；Tran & Kiela，2026 年，arXiv:2604.02460；单团队预印本，仅供参考方向）。只有当工作上下文超出单个 Agent 的有效处理能力，或子任务之间上下文互不相关时，才改用团队；不要仅仅因为任务包含多个角色就采用团队。
• 专家利用差距——在报告的基准测试中，自组织团队的表现不如其中表现最佳的单个成员。作者将此归因于“整合性妥协”：团队追求共识，导致专家和非专家的观点被平均处理，而非根据专业能力赋予不同权重。当某位专家明确具备专业优势时，优先选择单个 Agent（arXiv:2602.01011，2026 年；单团队预印本，仅供参考方向）。

这两篇预印本均未经同行评审；研究范围分别仅限于文本，以及自组织团队。完整分析和“何时不应使用多 Agent”的规则：references/subagents-vs-teams-architecture.md。

描述编写规则

使用 [它的作用]。在 [具体触发条件、产物或任务形式] 时使用。生成 [输出]；不负责 [边界]。 仅当运行时应在无需路由决策的情况下自行触发某个角色（审查者、验证者）时，才使用 Use proactively when。目录中通过路由分派的成员由负责人或工作流调度，因此通常使用普通形式。明确职责和边界；避免使用泛泛的助手描述。详细模式和触发条件评估见：references/agent-patterns.md。

设计检查清单

启动前，确认职责单一、触发条件具体、工具/MCP 精简、轮次有界、输出明确、文件归属清楚、上下文启动模式明确，并采用适合运行时的隔离方式。完整检查清单见 references/agent-patterns.md 和 references/initial-prompt-contract.md。

推荐模式

• 审查者/研究者：以读取为主、范围有限、证据优先。
• 实施者：明确负责的文件、验证命令，不做无关清理。
• 辩论：2-4 个独立视角，另设一位负责综合总结的负责人。
• 工程交付：并行工作前准备好共享上下文产物。

从 agents/templates/ 和 references/agent-patterns.md 开始。

Harness 架构模式

编排器-工作者、评估器-优化器、规划器-生成器-评估器、管理者/交接、反思、辩论和蓝图选择，请参阅 references/harness-patterns.md。多轮投票和分层集群属于 agents-swarm-orchestration。限制重试次数，并在达到上限时升级能力。

资源

参考资料、模板、成员、团队、脚本和来源的完整分类列表：references/navigation-index.md。

最常用的入口：

• 决策：references/team-selection-guide.md
• 启动：references/team-prompt-patterns.md + references/initial-prompt-contract.md
• 运行时：references/runtime-surfaces.md + references/agent-tools.md
• 成本：references/cost-control.md + references/model-governance-and-maintenance.md
• 陷阱：references/traps-and-antipatterns.md
• 模板：agents/templates/
• 添加工作流（引擎、清单规则、生成、同步）：references/add-a-workflow.md
• 来源：data/sources.json

其他参考资料（加载与你当前待决策事项相关的资料）：

• 目录条目和 frontmatter 约定：references/README.md
• 团队协议：澄清问题、辩论快速入门、动态扩展团队、协商（ZOPA/BATNA）、预测市场置信度押注
• 评审周期：多 Agent 反思、OODA 循环评审周期、紫队（持续红队 + 蓝队）
• 记忆与上下文：共享上下文模式、子 Agent 中断恢复
• 设计原理：团队设计原理、主代理—代理委派、方法、面具与机制手册
• 图表：运行时拓扑、初创公司增长系统
• 团队场景手册（索引）：
  • 工程：AI 知识机器人构建器、AI 系统、架构 RFC、代码评审、上下文工程、功能开发、迁移图谱
  • 数据与文档：数据分析、数据科学、文档知识
  • 运维与发布：事件响应、运维平台、支付平台、发布就绪度、企业就绪度
  • 产品与增长：产品探索、产品界面、移动产品、增长实验、营销诊断
  • 初创公司董事会：创始人盲点、增长、变现、战略、小众消费品创始团队

相关技能

• ../agents-swarm-orchestration/SKILL.md - 并行执行、波次和冲突解决
• ../agents-skills/SKILL.md - 技能打包和 SKILL.md 约定
• ../agents-hooks/SKILL.md - 钩子防护措施和生命周期自动化
• ../agents-mcp/SKILL.md - MCP 服务设计与安全
• ../agents-memory/SKILL.md - 用于共享约定的项目记忆策略
• ../ai-agents/SKILL.md - 本技能参考资料中所述的 Agent SDK 模式、上下文轮换和主代理—代理理论

导航

完整分类索引：references/navigation-index.md。

只有当某项基础理论能够解决具体的编排决策时才使用；对于常规的独立委派，不要展开理论内容。

• 规划/搜索 — 当需要处理相互影响的动作前置条件、效果、依赖关系或资源冲突时加载。返回初始/目标状态、动作契约、资源边界，以及可重放的有效计划或明确的不可行性结论；仅提供任务列表并不充分。
• 形式化方法 — 当需要检查具体的交接、取消、租约或重试协议中的不变量时加载。返回不变量、有限模型边界，以及反例或有界结果。图检查既不能证明实现符合要求，也不能证明活性。
• 数学优化 — 当分配/并发选择涉及明确的竞争目标和约束条件时加载。返回变量、目标、约束、可行候选方案，以及证书/求解器限制。对于常规的扇出任务，使用考虑所有权的简单分配；不要凭空设定目标权重。
• 理论应用参考 — 仅当其中明确标注的决策尚未确定时才加载（主题标签见 navigation-index.md）：控制、排队论、分布式系统、控制论/VSM、网络科学、决策理论、约束理论、行为经济学、团队理论、落地沟通、博弈论。

经验总结循环

如果以往的决策或陷阱与当前任务相关，且 learnings.consolidated.md 存在，请查阅它；仅在需要查看历史记录或其是现有可用备选时，才使用 learnings.md。否则，跳过这两个文件。

应用经验后，如果遇到值得记住的模式、值得避免的错误，或令你意外的领域事实，请通过 agents-skills-feedback-loop/scripts/append_learning.py 向 learnings.md 追加一条带日期的条目。不要修改 SKILL.md 本身。