多智能体架构：规划者、生成者、评估者

多智能体架构：规划者、生成者与评估者

为什么要依赖一个不堪重负的单一智能体（Agent），而不是协调一支由专家组成的团队呢？在前面的章节中，我们讨论了 AI 协作工具（AI Harness）的核心构造，以及如何管理单个智能体的上下文窗口（Context Window）。然而，随着应用复杂度的增加，试图让一个 AI 成为“万金油”必然会导致表现下滑。本章将介绍多智能体架构这一强大的概念，重点讲解“规划者（Planner）、生成者（Generator）、评估者（Evaluator）”三位一体的模式。

单兵作战的局限性

试想一下，如果聘请同一个人同时担任你的高级产品经理、深入代码一线的软件工程师以及严厉的 QA 测试员，不仅频繁切换任务（Context-switching）会让人精疲力竭，还会产生盲点。AI 智能体也面临着类似的局限性。当一个大语言模型（LLM）被要求编写功能并立即对其进行验证时，它往往会陷入确认偏误（Confirmation Bias）——即对自己编写的错误代码给出通过的评价。

通过将这些职责分配给专门的智能体，我们可以为每个 AI 提供窄而专注的系统提示词（System Prompt）。这能大幅减少幻觉（Hallucinations）并显著提升最终输出的质量。

GAN 的启发：对抗优势

要理解为什么要分离这些角色，我们可以看看现代机器学习的基石之一——生成对抗网络（GAN）。在 GAN 中，两个神经网络进行着猫捉老鼠的游戏：一个“生成者（Generator）”试图制造假数据（例如超逼真的图像），而“判别者（Discriminator）”则试图找出其中的伪造品。久而久之，生成者会变得非常出色，以至于判别者再也无法分辨真伪。

我们将这种对抗哲学应用到了 AI Harness 工程中。我们将代码编写智能体（生成者）与严苛的找茬智能体（评估者）对立起来。这种对抗性的张力会迫使生成者写出更高质量的代码，以通过评估者那冷酷无情的检查。

认识这个三人组

我们的多智能体协作工具被划分为三个鲜明的人格，每个都有其特定的工具和上下文边界：

智能体角色	主要目标	预期输出
规划者 (Planner)	定义“做什么”和“为什么做”。将原始想法转化为结构化规范。	Markdown 文档、架构说明书、分步计划
生成者 (Generator)	定义“怎么做”。根据计划编写实际的实现代码。	源代码、配置文件、数据库迁移脚本
评估者 (Evaluator)	验证“是否成功”。扮演严格的 QA 角色，查找边缘情况和 Bug。	通过/失败判定、修正建议反馈、Bug 报告

规划者：起草蓝图

规划者是整个系统的核心大脑。在编写任何代码之前，规划者会分析用户的需求并编写高层产品规范。成功的关键在于限制规划者对代码执行工具的使用权限。如果规划者可以直接写代码，它可能会忍不住开始直接操作。相反，它的任务应该是深入思考，分解问题，并输出详细的执行计划。

上下文需求： 高层项目目标、现有架构规则及用户需求。
系统提示词重点： 你是一名资深软件架构师。请勿编写实现代码。将问题拆解为小的、可测试的任务块。

生成者：将想法变为现实

一旦蓝图准备就绪，生成者就会接管工作。该智能体是主力军，它阅读规划者的规范并开始修改代码库。生成者应配备读取文件、写入文件以及运行基本编译检查的工具。

上下文需求： 规划者的规范文档、当前文件内容及 API 文档。
系统提示词重点： 你是一名专家级软件工程师。严格执行提供的计划。不要在文档范围之外创造新功能。

评估者：毫不留情的 QA

评估者是该对抗系统发挥魔力的地方。它充当把关人。当生成者声称任务“完成”后，评估者会介入验证。它会运行单元测试、调用 Linter（代码检查工具），并根据规划者的原始规范审查代码差异（Diff）。

如果评估者发现问题，它不会亲自修复代码，而是生成一份严厉但具有建设性的反馈报告，并将生成者打回去重做。这可以防止评估者因为自己动手而模糊了客观立场。

管理基于文件的沟通

构建多智能体系统时的一个常见错误是直接将一个智能体的输出管道接入下一个智能体的聊天历史中。这会导致上下文窗口迅速膨胀，引发“上下文焦虑”和健忘症。

相反，现代 AI Harness 使用基于文件的沟通。智能体通过读取和写入文件系统来进行交流。文件系统充当了“单一事实来源（Single Source of Truth）”。

[用户请求]
      |
      v
(规划者智能体) ---> 写入 `spec.md`
                             |
                             v
                     (生成者智能体) <--- 读取 `spec.md`
                             |              写入 `app.js`
                             v
                     (评估者智能体) <--- 读取 `spec.md` & `app.js`
                             |              写入 `feedback.md`
                             v
[如果反馈为负，循环回生成者]

流畅的移交与反馈循环

要协调这种工作流，你需要一个控制循环——通常被称为状态机（State Machine）。编排器脚本运行在智能体之上，根据项目的当前状态唤醒或挂起智能体。下面是一个简化的 Python 示例，演示了这种编排循环的结构：

# 多智能体编排伪代码

def run_harness(user_prompt):
    # 第 1 步：规划者起草规范
    write_file("spec.md", planner_agent.generate_spec(user_prompt))

    max_iterations = 5
    iteration = 0
    is_approved = False

    # 第 2 步：对抗循环
    while iteration < max_iterations and not is_approved:
        print(f"--- Sprint 迭代 {iteration + 1} ---")

        # 生成者读取规范（以及之前的任何反馈）并编写代码
        generator_agent.implement_feature(read_file("spec.md"), read_file("feedback.md"))

        # 评估者审查工作
        evaluation = evaluator_agent.review(read_file("spec.md"), read_dir("./src"))

        if evaluation.passed:
            print("评估者批准了更改！")
            is_approved = True
        else:
            print("评估者发现了 Bug。正在生成反馈...")
            write_file("feedback.md", evaluation.feedback)
            iteration += 1

    if not is_approved:
        print("Harness 停止：已达最大迭代次数且评估者未批准。")

在这个循环中，编排脚本是完全确定性的。它依赖 LLM 来完成“思考”过程，但使用标准的编程逻辑来强制执行移交。通过利用这种“规划者-生成者-评估者”三人组，你可以将一个脆弱、容易分心的 AI 转化为一个严谨、具备自我纠错能力的软件开发流水线。