作者：iFwu
Multi-Agent 是指多个 LLM Agent 协作完成任务的系统架构，已是业界成熟概念。Sub-Agent 是其中最常见的模式：一个 Agent 启动并指导另一个 Agent 执行子任务。
现有讨论主要集中在运行时的协作模式（编排、路由、并行执行等），但很少涉及 AI 编写指令时的问题：当一个 Agent 需要为另一个 Agent 编写指令时，如何避免角色混淆和视角串位。
元指令：指导 Agent 如何编写给另一个 Agent 执行的指令。
本指南聚焦这个被忽视的维度：Multi-Agent / Sub-Agent 场景下，元指令的角色建模、视角隔离与结构约束。
常见的元指令载体包括：
SKILL.md— 技能执行指南- SubAgent / Cron / Coding Agent 的启动提示词
- 多层 Agent 协作中的 prompt chain
像 AGENTS.md 这类目标明确、受众单一的全局指导文件，通常不需要本指南的角色建模约束。本指南主要面向涉及多角色（Human / 编写者 / 执行者）且容易产生视角混淆的场景。
这些元指令本质上是持久化、结构化的 prompt。与一次性 prompt 相比，文档化的元指令更适合承载稳定复用的流程、明确分段的责任边界、以及可审计可迭代的长期约束。
本指南不涉及 Skill 的目录组织、触发描述、测试流程等工程规范（见 skill-creator），只讨论元指令的角色建模、视角隔离与结构约束。
Agent 没有 Theory of Mind，无法自动区分：
- 谁在定义需求（Human）
- 谁在编写指令文档（Meta Agent）
- 谁在读取并执行文档（Target Agent）
不显式声明角色，文档就会出现视角混淆。
| 角色 | 标签 | 含义 |
|---|---|---|
| 用户 | Human | 定义需求、审阅 Meta Agent 产出、执行前置配置、验收 Target Agent 执行结果 |
| 当前 Agent | Meta Agent | 编纂指令文档的 Agent，是意图规约者不是自主执行者 |
| 目标 Agent | Target Agent | 读取指令文档并执行任务的 Agent |
角色是递归的：今天的 Target Agent，拿到新任务后会成为 Meta Agent，面对它自己的 Target Agent。
Human → Meta Agent A → Target Agent B（= Meta Agent B）→ Target Agent C → ...
- Skill Builder — 创建 Skill 的 Agent
- Document Composer — 将 Human 意图规约为 Target Agent 可执行的结构化指令
- Policy Author — 编写行为策略文件或启动提示词的 Agent
Meta Agent 不能假设 Target Agent 拥有当前会话的上下文。
Target Agent 通常具备框架提供的基础上下文（身份、workspace 结构、memory 位置等），但不知道：
- 当前对话的讨论过程
- Human 的隐含意图
- 之前的决策历史
任务特定信息（路径、配置项、决策依据）必须显式提供。框架已提供的通用信息无需重复。
如果任务特定信息本身不完整，Meta Agent 不应继续编纂，而应先向 Human 报错并补齐输入。
1. 裸代词
我、你、我们、自己 — 不带角色标注时禁止使用。
❌ 参照你自己的配置文件
✅ Target Agent 读取 /etc/app/config.yaml
2. 所有权混淆
❌ our workspace、for Alice
✅ 用角色标签限定：Human 的 workspace、Target Agent 的输出目录
3. 一次性操作混入 SOP
Human 的前置配置不能混入 Target Agent 的每次执行流程。
❌ Execution Flow 第一步："安装 Node.js 20+"
✅ Preconditions：Human 确保 Node.js ≥ 20 已安装
Execution Flow：Target Agent 从第一个业务步骤开始
4. 泄漏讨论过程
方案讨论、迭代历史、弃用方案不能写入最终产出。
❌ 最初考虑用方案 A，但因为 XX 原因改用方案 B……
✅ 直接写方案 B 的执行步骤
如果方案 A 是常见做法，加一句：不要使用 XX 方式，因为 YY
5. 脑补（Hallucination）
Human 没给的信息，Meta Agent 不能自行捏造。任务特定信息不完整时，必须停止编纂并向 Human 确认。
6. 示例不自包含
示例应使用通用场景或 Alice/Bob 式占位符，确保任何 Agent 无需额外背景即可理解。
- 用角色标签代替代词：
Target Agent 执行以下步骤 - 必须用代词时紧跟标注：
你（Target Agent） - 用绝对路径代替含糊指代
- Preconditions（Human 负责或一次执行）与 Execution Flow（Target Agent 负责）物理分离
- 显式注入上下文：将所有非框架自带的任务特定信息写入文档
- 拒绝脑补（Throw Error）：信息不完整或意图不明确时停止编纂，向 Human 发起明确询问
以下是一种常见结构，不是强制模板：
1. Context & Objectives — Target Agent 当前所处环境与要达成的目标状态
2. Preconditions — Human 负责的前置配置或者只需要执行一次的命令
3. Execution Flow — Target Agent 的执行步骤
4. Failure Handling — 超时、报错、回滚
5. Guardrails — 禁止操作
6. Key Principles — 全局约束
- SKILL.md — 技能执行指南
- SubAgent / Cron / Coding Agent 的启动提示词
- 多层 Agent 协作中的 prompt chain
- 任何涉及多角色（Human / 编写者 / 执行者）且容易产生视角混淆的文档或提示词
- AGENTS.md / CLAUDE.md — 受众明确的全局指导文件，通常不存在角色混淆
- SOUL.md / IDENTITY.md / USER.md — 定义"我是谁"，不需要三角色拆分
- 解释性文档（README、使用说明）— 受众不特定，不涉及视角转换
- 代码和代码注释 — 无歧义的机器指令
- memory / 日志 — 记录性质，不是指令性质
- 直接对话回复 — 即时交互，不是持久化文档
Meta Agent 完成文档后逐条检查：
- 开头有上下文与目标（Target Agent 所处环境与执行目标）
- 有角色声明（读者是谁、服务对象是谁）
- 全文无裸代词
- Preconditions 和 Execution Flow 物理分离
- 路径使用绝对路径或包含占位符的明确路径
- 用户名、Agent 名不出现在通用指令中
- 任务特定信息已显式写入
- 不包含讨论过程或弃用方案（除非为阻止 Target Agent 回退到默认行为）
- 示例自包含，不依赖特定讨论上下文
- 对输入缺口已报错澄清，没有脑补
已落地的元指令应定期审查：
- 角色声明是否仍然准确
- 是否有裸代词混入
- Preconditions 和 SOP 的边界是否被侵蚀
- 路径、工具名、配置项是否与实际一致
- Target Agent 执行时是否出现过因文档不清导致的错误
建议频率：每月一次，或在关联系统发生重大变更后立即审查。
本指南本身是一份 meta-meta prompt — 它指导 Meta Agent 如何编写给 Target Agent 的元指令。meta prompt 本身编写还没有形成业界通识，本文档仅是个人与 AI 协作过程中的经验总结。
现阶段 AI 的能力尚不足以独立写好这种高层级的元指令。常见问题包括：角色串位、上下文泄漏、示例不自包含 — 这些在本指南的迭代过程中反复出现过。
因此，Human 是元指令的最终审阅者和质量把关者。在指导 Meta Agent 编写元指令的过程中，建议：
- 站在 Target Agent 视角审阅 — 假设自己是一个没有讨论上下文的 Agent，从头读一遍产出，看是否每句话都能理解、每条指令都能执行
- 模拟执行过程 — 按文档的步骤在脑中走一遍，检查是否有缺失的前提、歧义的指代、或混入的一次性操作
- 迭代而非一次成型 — 预期 Meta Agent 的初稿需要多轮修正，每轮聚焦一类问题（角色、视角、示例、结构）
元指令本质上是技术文档，应遵循人类技术写作的核心原则。但 AI 在不同原则上的掌握程度差异很大：
- 结构化格式 — 一致的模板、标题层级、列表格式
- 机械性检查 — 对照清单逐条验证、拼写和语法一致性
- 已有模式复用 — 参考现有文档生成同结构的新文档
- 技术背景与最佳实践 — 通用的工程惯例、设计模式、行业术语
- 受众意识 — AI 不清楚 Target Agent 缺少哪些上下文，容易遗漏关键信息或塞入无关信息
- 抽象层级判断 — 容易过于具体（泄漏当前讨论上下文）或过于抽象（失去可操作性）
- 视角自洽 — 倾向于把自己当前的角色（Meta Agent）混入给 Target Agent 的指令中
- 省略判断 — 不确定哪些是框架已提供的（可省略）、哪些是必须显式写入的（不可省略）
- 反事实推理 — 难以预判"如果 Target Agent 没有这段上下文，会怎样误解？"
- 信息密度控制 — 倾向于堆砌内容而非精炼，需要 Human 裁剪冗余
将 AI 擅长的部分交给 Meta Agent 自动化（生成初稿、格式对齐、清单检查），将不擅长的部分留给 Human 重点审阅（受众、视角、抽象层级）。