很多接触过 AI 辅助，写过 skill 的同学，或多或少都会看到很多高手都会在一个任务里引入多个 Agent 来完成这个任务。相信大家在一开始都会有一个疑问，为什么要搞这么多 Agent 出来？把这个任务里所有的步骤都在一个 Agent 里完成不行么？事实上很多同学一直以来也是这么干的，单个 Agent 跑起来似乎也没什么问题。
但当我们的任务越来越复杂，涵盖了需求分析，代码分析，代码生成，文档落盘（为了自学习），代码检查（语法，风格，架构检查）与运行测试。我们就会慢慢开始发现任务的运行总会在一些步骤上出问题。 比如：
以上都是所有使用 AI 辅助的同学一定都会遇到的问题。为什么大模型没有按我们的提示词来完成工作呢？这里涉及到了我一直在说的上下文腐坏的概念，当 Agent 的上下文过长之后，就会开始干扰大模型的判断。
我在学习大模型原理的时候， 接触了 transformer 模型，事实上早在这之前，大概在 2016 年的时候通过吴恩达的视频学习深度学习，就知道了一件事情：序列模型的一个缺点，它很难有效且快速的关联上下文。所以科学家们实现了一种名为注意力机制的算法。它会通过一种方式决定对于当前处理的 token，之前出现的哪些字对当前最重要，大概意思就是比如有一句话：我喜欢的是苹果。 当大模型计算到是这个字的时候，它为了正确的推算下一个字应该是什么，它就要充分考虑之前出现的文字。但之前出现的问题可能非常长，都考虑进去的话，算力是扛不住的。所以它只能用一种算法来决定，应该把注意力放在较少的哪些字上，这就是注意力机制（我大概就只能翻译成这样了~ 原文说的词很专业）。 这种算法能在上下文很长的时候有效提取其中重要的地方进行推理。 但这种算法总归有限制， 当上下文太长的时候，这个注意力机制还是会被干扰，从而让大模型忽略了真正重要的东西。 这，就是我们经常说的上下文腐坏。
所以大家别看现在的模型动不动就 1M 上下文，但如果你真把上下文打满 1M 了，那个效果能让你崩溃，你会发现大模型越用越笨。这也是为什么我在过往的文章中建议大家：
所以对于很多比较复杂的任务，大多数老手，熟手，都会选择把任务拆分成几个阶段， 每个阶段使用独立的 Agent 来完成，它们使用完全独立的上下文，互不干扰。这样有效避免的了大模型自己骗自己的行为发生。
注意：多 Agent 会显著增加 token 的消耗和执行时间，尽量建议只有要隔离上下文的时候才使用。所以在复杂任务中使用，简单任务单 Agent 足够。
分析，生成，检测，各司其职。我们只需要把每个 Agent 的制作和工作流告诉大模型， 大模型会调用 skill-creator 来帮我们创建可以串联多个 Agent 的 skill 的。
这是上面那个模式的退化，我们把分析和生成进行合并，减少上下文传递的开销。但检测 Agent 仍然保留，毕竟大家要记住一句话：既当裁判又当运动员是不靠谱的。这这句话不仅对人类来说正确，对 AI 来说同样正确。不要相信 AI 的底线，因为它没什么底线。
这个模式适合不那么复杂的自动化测试项目，用户也可以容忍一些错误，但总体来说，我用这个模式实践下来，正确率也还不错。适合 token 没有那么富裕的同学。
下次我会以 UI 自动化来演示多 Agent 协同的设计。 下回见~
这里在宣传一下我得星球：
