假设你正在开发一个代码审查助手，需要三个智能体：代码审查员、安全分析员、报告生成员。传统做法是：逐个定义 LLM 调用、工具绑定、上下文窗口、消息路由——每个领域都重复这套模板。今天要讲的 Harness 项目提供了一种“元技能”范式：把“设计智能体团队”本身变成一个可被 LLM 调用的技能。实现后的效果是：你只需输入“代码审查团队”，Harness 自动生成所有智能体定义和它们使用的技能。

问题现象：多智能体系统的“配置地狱”

为什么开发者会陷入重复劳动？因为每个多智能体系统都需要显式定义：

  • 角色名称与系统提示（System Prompt）
  • 可用的函数/工具列表
  • 角色间的通信协议
  • 决策路由（谁先发言、如何汇总）

这些配置使得即便只有 3 个 Agent，启动代码也超过 200 行。更麻烦的是，如果领域需求变化（从代码审查变成合同审核），所有配置需重写。Harness 观察到的核心痛点在于：设计智能体团队的决策过程本身具有模式，但开发者没有将其抽象为可复用的“元技能”。

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

Harness 的元技能可以理解为“使用 LLM 来设计 LLM 的工作组”。它的上下文结构分为三层：

  1. 领域描述：一句话描述任务目标（如“自动化代码审查”）。
  2. 元技能模板：预定义的“团队设计”策略，包含如何拆分角色、分配工具、设定交互逻辑。
  3. 技能生成：LLM 根据元技能模板自动编写每个 Agent 的技能代码（即实际函数调用）。

其核心是将“团队结构”作为中间产物，让 LLM 自己去填充。 对比传统方法，相当于把“硬编码配置”变成了“LLM 规划 → 代码生成”。

优化方案：一个可直接复用的 Harness 配置模板

下面是一个使用 Harness 风格的 YAML 配置，你只需修改 domain 字段即可适配不同领域。

yaml
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 
# harness_team_config.yaml
meta_skill: true
domain: "代码审查"
goal: "对 PR 提交的代码进行风格、安全和性能检查，并生成结构化报告"

agent_constraints:
  - max_agents: 5
  - communication: "pipeline"  # 顺序执行，后一个 Agent 消费前一个的输出

tools_pool:
  - name: "run_pylint"
    description: "运行 pylint 静态分析"
  - name: "run_bandit"
    description: "安全漏洞扫描"
  - name: "format_output"
    description: "将结果格式化为 Markdown"

Harness 将读取此配置，调用 LLM 自动生成类似下面的 Python 代码（你无需手写）：

python
1 2 3 4 5 6 7 8 9 
# 自动生成的 agent_team.py
from harness import AgentTeam, Skill

agents = AgentTeam()
agents.add("代码风格检察员", skills=[Skill("run_pylint")])
agents.add("安全分析员", skills=[Skill("run_bandit")])
agents.add("报告生成员", skills=[Skill("format_output")])
agents.set_pipeline()
agents.run()

差 Prompt vs 好 Prompt 对比：

差 Prompt（手动定义每个 Agent）

text
1 
你是一个代码审查助手。先执行 pylint，然后执行 bandit，最后生成报告。请定义三个角色……（以下省略 20 行角色描述）

这种写法每次换领域都要完全重写，且容易遗漏交互逻辑。

好 Prompt（使用 Harness 元技能）

text
1 
使用元技能模式。领域：代码审查。目标：检查风格/安全/性能并生成报告。可用工具：run_pylint, run_bandit, format_output。请设计 3 个串行 Agent 并生成对应技能代码。

Harness 会动态解析，生成恰好合适的 agent 数量和执行顺序。

为什么这样有效？ 因为元技能利用了 LLM 的规划能力——它不是让 LLM 直接执行任务，而是让 LLM 先设计任务分解方案，再自动生成执行代码。这种“设计+生成”分离减少了单次调用的复杂度，同时让结果可复用。

实验对比效果

我在一个包含 300 行 Python 代码的 PR 上测试了两种方法：

  • 传统手动配置：编写代码耗时 45 分钟，每次修改领域配置需 10 分钟。
  • Harness 元技能：编写 YAML 配置耗时 2 分钟，切换领域只需修改 domain 字段（1 分钟）。

最终生成的 Agent 团队在准确率（通过人工检查报告完整性）上基本一致，但 Harness 自动生成的代码额外添加了错误重试和日志记录，这是手动配置容易遗漏的。

适用场景和边界

Harness 的元技能模式非常适合以下场景：

  • 快速原型：你想验证一个多智能体思路是否可行，不需要深入优化。
  • 需求变化频繁：团队需要经常切换不同领域的 Agent 组合。
  • 非专业 LLM 开发者：不懂提示工程的业务人员可以通过 YAML 描述业务，自动获得可用系统。

边界：

  • 需要精细控制时（如调整每个 Agent 的 temperature 或 top_p），Harness 的自动生成可能不符合预期，建议回退手动。
  • 工具数量超过 20 个时，LLM 规划质量可能下降，需要显式约束 agents 数量。
  • 当前 Harness 主要面向单轮流水线（pipeline）模式，复杂 DAG 依赖尚未原生支持。

变体和扩展用法

  1. 增量式团队：在已有 Agent 团队上添加新角色，只需在 YAML 中追加 new_agent 字段，Harness 自动调整通信顺序。
  2. 多目标并行：设置 mode: parallel，生成多个并行的 Agent 组处理不同子任务，最后汇总。
  3. 技能注入：如果你已有封装好的函数（比如 run_pylint），可以将其注册到 tools_pool，Harness 生成代码时自动引用。

LLM meta agent pipeline in code review

以上所有示例均基于 Harness 的公开仓库（https://github.com/revfactory/harness），建议 clone 后运行 examples/domain_team 目录下的测试文件直接体验。核心收获：下次构建多智能体系统时，先问问自己——能不能用元技能把团队设计本身自动化？