1 Agent 怎么选

1.1 引言

可以说，agent 是一种解决问题的思路（道），具体的工具（术）并不重要。但在程序中，它仍需要一个具体的形态。由于时间有限，我只调研了目前 GitHub 上最热门的 agent 工具，也查看了一些项目中自行实现的 agent 代码。最终选择了 autogen。

1.2 目标

首先，明确选型的目的是什么：

  • 支持我需要的所有功能，减少自定义开发。
  • 易于理解和使用，学习成本低，安装和打包方便。
  • 高稳定性和灵活性。
  • 便于未来扩展。

具体选择还要根据所需功能来决定。如果只是做一个以闲聊为主、偶尔调用现有工具的聊天机器人，可以使用 langchain。如果涉及较多功能、偏重于 Agent 应用、工具之间有复杂逻辑，或者觉得 langchain 无法满足需求，可以尝试 autogen。

1.3 选择工具

langchain 就像一家初创公司，只有几个员工，扁平化管理。在事务简单人也少的时候还能应付，但一旦人多事杂，就会变得混乱。即使没有一个主管，也至少一套制度规则，满足常用功能。Langchain 的 agent 主要在结构上较弱，而不是功能性差。其它一些更偏应用的工具则是完全定制好的 Agent，用户可以直接调用。

1.3.1 Langchain

Langchain 提供了丰富的工具和功能，但在 Agent 方面相对简单。它主要是对 LLM 工具/函数的简单封装，示例比较零散，网上的教程大多只介绍最基础的用法，上手较慢。Langchain 包含很多工具集，由于考虑了代码重用和逻辑统一性，如果仅使用 Agent，会有点重；对于复杂的逻辑，需要手动修改的也比较多。对于简单使用 Agent 的情况，选择 Langchain 也是可行的。

由于 Langchain 出现较早且功能全面，对其 API 熟悉的人不少。我的代码中已经使用了 LangChain 的其他功能，所以一开始我选择的也是 LangChain 的 agent。

1.3.2 AutoGen

AutoGen 是由 Microsoft 出品的。它的文档和示例非常完整，还有一篇论文介绍其原理和功能（AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation）。初次使用接口非常方便，只需十行代码即可搞定。对于较复杂的用法，由于接口参数设计得较为充分，其绝大部分功能都可以通过接口调用实现。除了需要跟踪基本的调用关系和了解类的父子关系外，不需要理解太多内部代码。

另一个亮点是，它集成了 Python 环境，并且可以在独立的 Docker 容器中运行代码。简单的工具可以边生成边执行，提供更好的运行时体验，不仅能调用最初设计好的工具。

此外，还允许用户参与与多个 Agent 的对话，引导这些 Agent 完成任务，非常灵活。

1.3.3 自己实现 Agent

我也查看了一些代码中自行实现的 Agent（有些利用了 Langchain 的 LLM 部分和 Memory 部分，并自行实现了 Agent 部分）。对于简单的功能来说，这样做是可行的，代码量也不多。但要在短时间内实现一个良好的抽象是很难的。随着功能的增加，可能需要重写或大幅修改，还会出现各种各样的 bug，不如直接使用一个相对成熟的工具。

如果只考虑调用工作，还有更底层的方法是直接调用 LLM 的 API 中 Tool/Function 的功能，但这需要自己构造很多东西，还要考虑支持多个 LLM，非常麻烦。

1.3.4 易用性

从大模型支持来看，LangChain 和 AutoGen 都支持保留对话上下文。常用的 LLM 接口，如 OpenAI、Gemini 和 Claude，也都提供支持。

从安装方面看，这两个库都可以通过 pip 安装。LangChain 目前被拆成了多个包，因此相对较重，而 AutoGen 则相对更简单一些。

1.3.5 框架切换

我的程序将逻辑和框架分开，因此可以随时替换代理框架而不影响功能。从 LangChain 切换到 AutoGen 非常迅速。也可以在调试工具时使用 AutoGen，而其他对话场景可以继续使用 LangChain。两者同时使用也没问题。

从 LangChain 转向 AutoGen，之前在使用 LangChain 时遇到的一些疑问或不便，AutoGen 基本都有所改善。特别是程序员能够控制整个流程，它包含控制层（多层控管），而不是全部交由初始的提示和 LLM 控制。这种方式具有更大的可控性，从而提升了稳定性。

1.4 当前问题

1.4.1 稳定性

  • 稍微改动 prompt 就会出错
  • 还需要严格把关

1.4.2 可控性

  • 我觉得大部分时间，不需要让它思考，只要选择工具并进行操作即可。
  • 可设置：只有在需要时的时候思考

2 当前的 Agent

2.1 为啥要用多 Agent

  • 问题复杂：无法在一个提示中描述所有 100 步和 50 种工具。
  • LLM 无记忆功能，只能依赖提示信息。
  • 信息越简单单一，LLM 越容易处理；信息多了容易混乱。
  • 提示可以包括：问题、步骤分解、当前进度、可用工具、结束条件等。
  • 提示的主要内容和结构需事先确定，不应随意更改，而每次问答的侧重点可能不同。
  • 多个代理，每个代理的提示管理本次问答的主旨和上下文，有效解决上述问题。每个代理可专注于内部处理，减少按下葫芦起了瓢的问题。
  • 多个代理就像多人协作，通过设定交互规则，可以组织成串型、中心化或小组为核心，每次只专注处理一小部分。

2.2 当前 LLM 能解决哪些问题

  • AI 目前主要处理一些非核心问题，如接口问题、外围问题和简单任务，更多是起到辅助作用，减轻工作量。
  • 核心问题仍需程序员解决，包括：可能需要微调模型、结构设计、大问题拆分成小问题，或边探索边调整。
  • AI 缺乏整体能力，只能独立解决单个问题。

2.3 Agent 可以改善什么

  • 无代码编程，之前为什么不行
    • 复用问题：高耦合
    • 接口问题：不同设备、不同数据库、不同界面、不同格式
    • 人为建造的壁垒
  • 搭积木到底行不行
    • 在模型、业务、当前工具之间建立桥梁。
    • 出现了好的 Agent 框架，基于这个架构，用搭积木的方法完成各种功能。
    • 每个 Agent 是一个模块，内部封装所有功能，只提供输入输出和使用场景，最终变成面向 Agent 的编程。
    • 所有东西都是 Agent。拆分计划是 Agent，存储是 Agent，搜索是 Agent，审查是 Agent，接口也是 Agent。各个 Agent 非常强大，然后把它们对接起来，就像 Coze 和 Dify 一样，谁都能用。
    • 程序员是那些提供和售卖 Agent 或提供整体解决方案的人。

2.4 新技术是否取代 Agent

  • OpenAI O1
    • 解决小领域的复杂问题
    • 原理：自我强化学习（Self-RL），通过奖励和惩罚来教导模型自行解决问题，并通过“思维链”（chain of thoughts）来处理用户查询的问题。
    • 询问完整思维链会导致账号被封。