用元技能设计多智能体系统：让每个代理知道自己该干什么

问题现象：为什么多智能体系统经常“群龙无首”

多智能体系统的核心优势是分工协作，但实际项目中经常出现两种混乱：

• 上下文污染：代理A的中间结果被代理B误读，导致输出偏离任务目标。
• 角色重叠：多个代理重复完成相同子任务，浪费token且结果不一致。

问题根源在于：代理的角色和能力是预先硬编码的，缺少一个“元层”来动态决定谁该做什么以及怎么做。

GitHub上的Harness项目（revfactory/harness）提出了一种解决方案：元技能（Meta-Skill）——一种自我引用的能力，让系统先设计“设计者”，再由设计者生成具体的代理团队和他们所需的技能。

上下文结构分析：元技能如何打破静态僵局

传统多智能体系统的prompt结构通常是平铺的：

[代理A] 你是代码审查者，检查风格、逻辑、安全。
[代理B] 你是测试生成者，根据代码写单元测试。
[代理C] 你是文档撰写者，记录API变化。

这种结构下，如果需求变化（比如需要增加性能分析），必须手动修改每个代理的prompt，且代理间缺乏协调。

Harness的元技能思路是引入一个元代理，它的任务是：

1. 分析当前任务领域（如“构建一个Python数据处理微服务”）
2. 设计一组专业代理（如“架构师”、“编码员”、“测试员”、“文档员”）
3. 为每个代理即时生成它们专用的技能（包括prompt、调用工具、输出格式）

对应在上下文中，元代理的prompt定义了“如何定义代理”，而生成的代理则只关心自己的子任务。这样，上层上下文保持精简，下层上下文高度专注，避免了信息过载。

优化方案：三步实现元技能模式

第一步：定义“团队设计师”元技能

创建一个专门的系统prompt，描述如何根据输入任务生成代理团队。注意：这个prompt本身要清晰、可重复。

差Prompt示例（太抽象）：

你是团队设计师，请根据用户需求创建适用的代理。

问题：没有指定如何创建，代理们没有明确生成规则，容易产生重复或无意义的代理。

好Prompt示例（可操作模板）：

# 团队设计师

你是一个智能体团队设计专家，负责根据用户的原始需求生成多智能体团队的配置。

## 输入格式
- 任务领域：{简要描述}
- 关键约束：{时间/资源/技术栈}

## 输出格式
必须输出一个JSON数组，每个元素包含：
- "agentId": 唯一标识（如 "code_reviewer"）
- "role": 一句话描述该代理的角色
- "skill": 该代理应该执行的详细指令（包含上下文、输出格式、错误处理）
- "dependencies": 该代理依赖哪些其他代理的输出（数组）

## 生成原则
1. 代理数量不超过5个，优先覆盖核心职能
2. 每个代理的skill必须包含明确的输入输出格式
3. 依赖关系形成DAG，避免循环依赖
4. 如果需求简单，可以只生成一个全能代理

第二步：使用元技能生成团队

用户输入原始需求，系统先用元技能生成代理配置。例如：

[
  {
    "agentId": "architect",
    "role": "设计整体系统架构",
    "skill": "阅读用户需求，输出模块划分、关键技术选型。输出为Markdown格式的架构设计文档。",
    "dependencies": []
  },
  {
    "agentId": "implementer",
    "role": "根据架构实现核心代码",
    "skill": "接收架构设计文档，编写符合设计规范的代码。输出为Python文件。注意：只实现架构文档中指定的模块。",
    "dependencies": ["architect"]
  }
]

第三步：动态生成代理skill并执行

将生成的每个agent的skill作为系统prompt分配给对应的LLM调用（可以是同一个模型，但用不同的系统消息）。这里关键点是：skill中包含了对上下文的严格定义，例如：

您是一名代码实现者。您的工作依据是{architect的输出}。请严格遵循以下要求：
- 只实现标记为“To Implement”的模块
- 每个函数必须包含类型注解
- 输出文件名与模块名一致

实验对比效果

我构建了一个测试场景：生成并审查一个Python数据清洗脚本。

对照组（传统硬编码）：手动编写3个代理的prompt（编码员、审查员、测试员），每个代理的prompt包含完整的任务描述和规则。

实验组（元技能）：使用上述模板，让“团队设计师”先输出代理配置，再根据配置动态生成每个代理的prompt。

结果（基于gpt-4o，每个场景运行5次取中位数）：

分析：元技能模式下，每个代理的prompt更精简，因为规则被集中到了“团队设计师”的生成逻辑中；同时，代理之间的依赖关系清晰，减少了重复工作。任务完成率提升是因为审查员能准确知道要检查什么（架构设计已定义了检查点）。

原理：为什么元技能模式有效

1. 关注点分离：元代理只负责“设计团队”，不关心具体执行；子代理只关心“执行任务”，不关心全局协调。这符合结构化编程思想，减少了prompt内部的耦合。
2. 自适应能力：元代理可以根据任务领域动态调整代理角色，而不是硬编码固定模板。对于非典型任务（如“写一首诗并配插图”），传统模式可能缺少相关代理，元技能可以当场生成“诗人”和“插画师”代理。
3. 上下文压缩：元代理的输出是结构化的JSON，子代理只需读取与自己相关的部分，其余信息被屏蔽。这相当于实现了上下文动态剪枝——模型不再需要阅读无关的prompt。

适用场景与边界

适用场景：

• 中大型多步骤任务（> 3个子任务），且子任务分工明确。
• 需要频繁调整任务类型，不想每次都重写prompt。
• 团队成员（开发人员）希望复用代理设计与生成逻辑。

不适合的边界：

• 极简任务（比如“写一句话”），引入元技能反而增加开销。
• 代理之间需要频繁共享上下文时（如持续对话），元技能生成的成本可能超过收益。
• 依赖外部工具且工具调用链路复杂时，需要额外设计错误传播机制。

变体与扩展用法

变体1：递归元技能

如果你需要更高层的抽象，可以让元技能本身也能被设计——即创建一个“元元技能”。这在处理跨领域任务时很有用，例如：先设计一个“市场分析团队”，再设计一个“技术实现团队”，最后让两个团队的输出汇总。

变体2：记忆注入

在元技能prompt中加入历史成功/失败案例，让它生成的代理更稳健。例如：

生成原则中补充：优先选择上次成功使用的架构模式，避免已知的循环依赖错误。

变体3：技能共享与合并

当多个子任务需要相同的工具（如搜索、计算）时，元技能可以生成一个“工具代理”，专门提供公共服务，其他代理通过dependencies引用它，避免重复每代代理中都写相同的工具使用说明。

结语

Harness项目告诉我们，多智能体系统不是简单堆叠agent数量，而是需要精心设计生成agent的策略。元技能模式让你从“为每个任务写prompt”升级到“写一个能生成prompt的prompt”。这不仅是技巧，更是一种思维转变：把系统架构设计的责任交给模型自己，而你只负责定义设计规则。

下次当你觉得多智能体系统难以驾驭时，不妨试试用元技能先画一张“团队蓝图”。