原贴链接

我主要使用开源模型（Llama3 8B和Qwen1.5 32B Chat）。让这些开源模型可靠地工作一直是一个挑战。这时，我的研究引导我发现了AutoGen和AI代理的概念。

使用了一段时间后，我发现了一些非常有帮助的模式。想和大家分享一下，

我的学习心得

i. 你通过对话而不是通过提示工程来解决不确定性问题。

提示工程很重要。我并不是要否定它。但很难让同一个提示适用于你的应用程序需要处理的不同类型的输入。

更好的方法是采用双代理模式。在这里，我们不是将一个代理的响应直接转发给用户（或下一个代理），而是先让它与一个同伴代理对话。然后，我们让这些代理相互交谈（1到3轮，取决于任务的复杂程度），以帮助“对齐”答案与“期望”答案。

例如：假设你正在用聊天机器人替换一个UI表单。你可能有一个代理来处理与用户的对话。但与其让它自己找出填充表单的JSON参数，你可以让一个同伴代理来做这件事。同伴代理不会真正跟随整个对话（只关注增量），并会跟踪哪些字段已回答，哪些未回答。它可以告诉聊天代理下一步需要问什么问题。

这有助于聊天代理专注于“对话”方面（处理提示注入、礼貌性、防止对话偏离轨道），而同伴代理可以负责管理表单数据（JSON提取、验证等）。

另一个例子可能是将一个JSON格式化器分成三部分（一个代理以半结构化格式（如Markdown）输出数据 - 另一个将其转换为JSON - 最后一个验证JSON）。这更像是一个顺序聊天模式，但最后两个可以并且可能应该被建模为两个同伴代理。

ii. LLM并不是糟糕的判断者。它们通常足以胜任诸如RAG之类的事情。

双代理模式的一个扩展称为“反思”。在这里，我们让同伴代理验证主要代理的工作并提供改进反馈。

例如：假设你有一个做RAG的代理。你可以让同伴做一个接地性检查，以确保文本生成与检索到的块一致。如果有问题，同伴可以提供额外的提示给RAG代理以采取纠正措施，甚至标记某些块为不相关。你还可以做更多检查，如亵渎检查、相关性检查（这可能很难）等等。如果你问我，这还不错。

iii. 代理只是一个函数。它们不需要使用LLM。

我将代理视为一个函数，它以对话状态（如消息数组）作为输入，并返回一条消息（或修改后的对话状态）作为输出。本质上，它们只是对话中的参与者。

你在函数内部做什么取决于你。调用LLM、做RAG或任何其他事情。但你也可以使用更传统的方法进行基本分类。但它根本不需要是AI驱动的。如果你知道前一个代理将输出JSON，你可以有一个简单的JSON模式验证器并称之为一天。我认为这非常强大。

iv. 代理是可组合的。

代理旨在可组合。就像React的UI组件一样。

所以我最终为简单的提示链解决方案（如果可能的话，这可能更适合通过原始拖拽或使用Langchain来完成）也使用了代理。这让我可以在不重新连接整个链的情况下，用强大的模式改变表现不佳的代理（或步骤）。如果你问我，这很酷。

结论

我希望我能很好地传达我的学习心得。如果你有任何问题或不同意我的任何观点，请告诉我。我在这里学习。

附：分享一个我在YouTube上制作的视频，我在其中更深入地探讨了这些例子！希望你也能去看看。欢迎对我的愚蠢笑话进行吐槽！哈哈！

讨论总结

本次讨论主要围绕AI代理（Agents）的设计模式展开，特别是关于如何通过对话而非单纯的提示工程来解决不确定性问题。原文作者分享了在使用AutoGen和Llama3构建AI系统时的经验，提出了“双代理模式”和“反思模式”等策略。讨论中，有评论者对代理的定义和复杂性提出了质疑，认为代理不仅仅是函数，而是具有更复杂的功能和行为。此外，讨论还涉及代理与工具的区别、代理的可组合性以及如何利用传统方法而非仅依赖LLM来处理某些任务。总体而言，讨论氛围较为技术性，主要集中在AI代理的设计和实现上。

主要观点

  1. 👍 通过对话而非提示工程解决不确定性问题

    • 支持理由：提示工程难以应对不同类型的输入，而通过对话可以更好地“对齐”答案。
    • 反对声音：无明显反对声音，但有评论者对代理的定义提出了更广泛的讨论。

  2. 🔥 采用双代理模式来“对齐”答案

    • 正方观点：双代理模式可以让一个代理专注于对话，另一个代理处理数据管理，提高效率。
    • 反方观点：无明显反对声音，但有评论者对代理的复杂性提出了质疑。

  3. 💡 LLM在RAG中表现良好，但不是完美的判断者

    • 解释：通过“反思模式”，可以让代理相互验证并提供改进反馈，确保生成内容的质量。

  4. 👀 代理可以作为函数，不一定要使用LLM

    • 解释：代理可以采用传统方法进行分类或验证，不一定需要依赖LLM。

  5. 🚀 代理是可组合的，类似于React的UI组件

    • 解释：代理可以像React组件一样组合使用，便于调整和优化。

金句与有趣评论

  1. “😂 代理不仅仅是函数，而是具有更复杂的功能和行为。”

    • 亮点：评论者对代理的定义提出了更广泛的讨论，强调了代理的复杂性。

  2. “🤔 代理可以被视为一种设计模式，帮助AI更加可组合。”

    • 亮点：强调了代理在AI系统中的设计模式作用，有助于系统的模块化和可扩展性。

  3. “👀 代理从根本上说是将对话状态映射到下一个回复的函数。”

    • 亮点：简洁地概括了代理的基本功能，强调了其在对话系统中的核心作用。

情感分析

讨论的总体情感倾向较为技术性和中立，主要集中在AI代理的设计和实现上。虽然有评论者对代理的定义和复杂性提出了质疑，但整体氛围较为友好，讨论者们愿意分享和学习。主要分歧点在于代理的定义和复杂性，可能的原因是代理在学术和日常用语中的定义有所不同，以及不同应用场景下代理的实现方式各异。

趋势与预测

  • 新兴话题：代理的定义和复杂性可能会引发更多学术讨论和技术探讨。
  • 潜在影响：随着AI代理设计模式的不断发展，可能会推动AI系统在模块化、可组合性和效率方面的进一步提升。

详细内容：

标题：关于 AutoGen 和 Llama3 构建中的代理设计模式引发的热门讨论

在 Reddit 上，一篇题为“These Agentic Design Patterns helped me out a lot when building with AutoGen+Llama3!”的帖子引起了众多关注。该帖子获得了大量的点赞和众多评论。

原帖作者主要分享了在使用开源模型（如 Llama3 8B 和 Qwen1.5 32B Chat）时，通过 AutoGen 和 AI 代理的概念所总结出的一些有用的设计模式。

帖子引发的主要讨论方向包括对不同设计模式的理解、应用以及相关工具的使用等。

文章将要探讨的核心问题或争议点在于对代理设计模式的具体定义和应用方式的不同看法。

讨论焦点与观点分析：

有人认为原帖中第三部分关于代理和工具的区别需要进一步澄清。有人解释说这里的“函数”是从计算机科学理论或数学意义上理解的，代理本质上是对话状态到下一个回复的映射。还有人认为原帖作者对代理所应具备的复杂性有所高估，认为代理更像是一种有助于使 AI 更具组合性的设计模式。

关于原帖中提到的 YouTube 视频，有人称赞其不错，询问使用的编辑工具。原帖作者表示动画在 powerpoint 中制作，编辑更倾向于 Davinci Resolve。有人询问是否有推荐的学习制作 YouTube 视频的频道，以及 Davinci Resolve 是否能处理出现的文字。还有人提到自己的设备配置，并询问是否尝试过 kdenlive 等较轻便的编辑软件。原帖作者认为编辑软件的选择不是特别重要，挑一个开始就行。

讨论中的共识在于大家都对原帖中分享的内容表现出了兴趣，并就相关技术和工具展开了积极的交流。特别有见地的观点如对代理本质的深入解释，丰富了对这一概念的理解。

总的来说，这次关于 AutoGen 和 Llama3 构建中的代理设计模式的讨论，展现了大家对于新技术和工具的热情探索以及不同观点的碰撞，为相关领域的发展提供了更多的思考。