为什么需要多 Agent

很多接触过 AI 辅助，写过 skill 的同学，或多或少都会看到很多高手都会在一个任务里引入多个 Agent 来完成这个任务。相信大家在一开始都会有一个疑问，为什么要搞这么多 Agent 出来？把这个任务里所有的步骤都在一个 Agent 里完成不行么？事实上很多同学一直以来也是这么干的，单个 Agent 跑起来似乎也没什么问题。

但当我们的任务越来越复杂，涵盖了需求分析，代码分析，代码生成，文档落盘（为了自学习），代码检查（语法，风格，架构检查）与运行测试。我们就会慢慢开始发现任务的运行总会在一些步骤上出问题。 比如：

• 我在 skill 中明明写了生成自动化测试用例后，要检查代码风格，架构，语法并真实运行测试用例进行验证。 为什么 Agent 没有做（跳步）
• 我在 skill 中明明写了先理解测试需求，生成代码复用和扩展的分析报告，让用户确认后再实现代码， 为什么它直接跳过开始生成代码了。（跳步）
• Agent 运行了一段时间后，任务还没有完成， 但为什么它没有继续探索下去，而是曲解我的意思，甚至直接修改了需求（上下文腐坏，且上下文快满了，大模型急于完成任务）

以上都是所有使用 AI 辅助的同学一定都会遇到的问题。为什么大模型没有按我们的提示词来完成工作呢？这里涉及到了我一直在说的上下文腐坏的概念，当 Agent 的上下文过长之后，就会开始干扰大模型的判断。

我在学习大模型原理的时候， 接触了 transformer 模型，事实上早在这之前，大概在 2016 年的时候通过吴恩达的视频学习深度学习，就知道了一件事情：序列模型的一个缺点，它很难有效且快速的关联上下文。所以科学家们实现了一种名为注意力机制的算法。它会通过一种方式决定对于当前处理的 token，之前出现的哪些字对当前最重要，大概意思就是比如有一句话：我喜欢的是苹果。 当大模型计算到是这个字的时候，它为了正确的推算下一个字应该是什么，它就要充分考虑之前出现的文字。但之前出现的问题可能非常长，都考虑进去的话，算力是扛不住的。所以它只能用一种算法来决定，应该把注意力放在较少的哪些字上，这就是注意力机制（我大概就只能翻译成这样了~ 原文说的词很专业）。 这种算法能在上下文很长的时候有效提取其中重要的地方进行推理。 但这种算法总归有限制， 当上下文太长的时候，这个注意力机制还是会被干扰，从而让大模型忽略了真正重要的东西。 这，就是我们经常说的上下文腐坏。

所以大家别看现在的模型动不动就 1M 上下文，但如果你真把上下文打满 1M 了，那个效果能让你崩溃，你会发现大模型越用越笨。这也是为什么我在过往的文章中建议大家：

• 一个 Agent 窗口只做一个任务，或者一个类型的任务。之后立即清空上下文或者启动新 Agent 跑其他任务。
• 如果确实需要做很长线的任务，一定要多做 compact（上下文压缩，其实就是大模型总结摘要能力，让大模型只保留最重要的信息，所有 AI 辅助工具都有这个指令。）这里额外提一嘴，很多 AI 辅助工具，比如 CC，当它发现上下文要满的时候，就会自动的触发 compact。 但这仍然会触发上面我提到的问题，大模型发现上下文快满了，它就会急于完成任务，从来做出一些自己骗自己的事情。

所以对于很多比较复杂的任务，大多数老手，熟手，都会选择把任务拆分成几个阶段， 每个阶段使用独立的 Agent 来完成，它们使用完全独立的上下文，互不干扰。这样有效避免的了大模型自己骗自己的行为发生。

注意：多 Agent 会显著增加 token 的消耗和执行时间，尽量建议只有要隔离上下文的时候才使用。所以在复杂任务中使用，简单任务单 Agent 足够。

对于测试来说，一般有两种多 Agent 模式最常用

编排者 - 子 Agent 模式

• 分析 Agent：根据用户提供的测试用例步骤，扫描当前项目代码，判定哪些步骤可以复用过往函数，哪些步骤需要编写新函数。
• 代码实现 Agent：读取分析 Agent 产出的结果，读取当前项目的架构文档。当这些知识完备后，就开始编写测试代码。这里需要注意的是，代码实现 Agent 有能力自己判断出哪些逻辑可以做一个业务流程封装成通用的方法，以供下一轮生成中，代码分析 Agent 读取并分析。
• 检测 Agent：首先需要针对代码实现 Agent 产出的代码进行审查，是否严格按照架构来编写代码，是否有语法错误，是否有良好的代码注释等等。然后，真正的执行测试脚本，验证测试用例可以通过。 这两步检查中的任何一个失败，就会打回给代码实现 Agent 进行修改（需要带上为什么会失败的信息）。

分析，生成，检测，各司其职。我们只需要把每个 Agent 的制作和工作流告诉大模型， 大模型会调用 skill-creator 来帮我们创建可以串联多个 Agent 的 skill 的。

生成 - 检测模式

这是上面那个模式的退化，我们把分析和生成进行合并，减少上下文传递的开销。但检测 Agent 仍然保留，毕竟大家要记住一句话：既当裁判又当运动员是不靠谱的。这这句话不仅对人类来说正确，对 AI 来说同样正确。不要相信 AI 的底线，因为它没什么底线。

这个模式适合不那么复杂的自动化测试项目，用户也可以容忍一些错误，但总体来说，我用这个模式实践下来，正确率也还不错。适合 token 没有那么富裕的同学。

结尾

下次我会以 UI 自动化来演示多 Agent 协同的设计。 下回见~

这里在宣传一下我得星球：