2023 年 AutoGen 教程：本地智能体设置与代码执行

我之前介绍过 AutoGen，现在想逐行演示本地 Python 配置。其思路是让 AI 智能体相互通信，并代表用户使用工具或代码。这段视频录制于 2023 年 10 月：其中的库接口和模型选择属于历史版本，后续 AutoGen 版本可能需要不同代码。

我将 AutoGen 描述为一种组装可定制智能体、让它们协作完成任务的方法。助手可以生成回答或代码，另一个智能体可以代表用户，也可能运行代码。这些能力取决于配置，并不意味着智能体能可靠地完成任何任务。

演示中我使用 VS Code、Anaconda 和 OpenAI 账户。我创建项目文件夹与 `app.py`，打开终端，并创建名为 `autogen`、使用 Python 3.11.4 的 conda 环境。我激活环境，并检查 VS Code 选中的解释器是否与该环境一致。

我安装当时显示为 `pyautogen` 的软件包并导入 `autogen`。不要把这一历史命令理解为安装其最新版本的建议：Microsoft 表示已不再管理该软件包，后续版本不由 Microsoft 提供。其迁移指南解释了受支持的软件包选择及重大 API 变化。

旧版配置列表包含模型名称，最初是 GPT-3.5 Turbo 16k，以及 API 密钥。我在视频中生成并粘贴密钥，并表示会在发布前将其撤销。实际项目中，应将凭据保存在环境变量或密钥管理器中，避免写入源码仓库和录屏；这里不复现视频中的密钥。

`llm_config` 包含请求超时、该版本缓存行为使用的种子、配置列表，以及值为零的温度。我在编程示例中使用低温度。温度影响采样，并不能保证创造性或正确程度。

当找到匹配请求时，缓存可以避免重复调用 API，节省时间和成本。我展示了与种子 42 关联的缓存，并将其清除以强制重新运行。缓存行为取决于请求匹配和版本：后续 AutoGen 文档区分了 `cache_seed` 与模型服务商的采样 `seed`。

我创建一个带名称和模型配置的 `AssistantAgent`。可以通过系统消息为多个助手设定不同角色，例如 CTO 和 CEO。这个例子只使用一个助手和一个用户代理；赋予角色名称并不会让它们自动成为独立专家。

`UserProxyAgent` 代表用户行事，可以发送回复或执行生成的代码。旧版教程展示了三种人工输入模式：`ALWAYS`、`TERMINATE` 和 `NEVER`。根据旧版文档，`TERMINATE` 可以在收到终止消息或达到自动回复上限时提示用户，而不只是任务真正完成时。

我把 `max_consecutive_auto_reply` 设为 10，并定义终止消息检查。上限可以限制没有进展的对话及其成本，但不能保证任务已经完成。`web` 工作目录保存演示生成的文件。

代理的代码执行设置允许运行生成的代码，这会对文件和环境产生真实影响。工作目录并非安全边界。应审查生成的代码并限制执行；旧版 AutoGen 文档建议用 Docker 隔离代码执行，也可以禁用执行。

我编写一个要求总结文章的任务，然后通过用户代理的 `initiate_chat` 方法发起对话，将助手和任务作为消息传入。展示的 2023 年 API 只是旧版设计示例；较新的 AutoGen 版本改变了智能体和执行接口。

最初的 GPT-3.5 运行没有完成文章任务，智能体反而交换了无帮助的消息。我指出，10 次自动回复的上限有助于防止对话过长，并展示了此次运行创建的缓存。

为了进行更简单的测试，我切换到 GPT-4，清除缓存，并要求编写 Python 输出 1 到 100 的数字，将结果保存到文件。智能体生成了包含数字的 `numbers.txt`。作为写文件任务它成功了，但那不是我想要的代码文件。

我不小心在提供反馈前退出，于是修改提示词，明确要求将代码保存到文件。我清除先前输出并重新运行。这次演示在工作目录中生成了一个 Python 文件，说明准确的指令和实际产物都需要检查。

我添加第二个任务，要求智能体把代码从输出 1–100 改为输出 1–200，并发起另一段对话。这次我把人工输入切换为 `NEVER`。这移除了工作流中的批准机会，但并不会使自动执行代码没有风险。

第二次运行没有完全遵循我的预期指令：原有 Python 文件仍在，智能体创建了一个包含 1 到 200 的文本文件，以及更新该文件的代码。我认为部分偏差来自提示词不够精确，但观察到的结果也说明生成式智能体可能误解任务。

我建议把模型和 API 密钥移到环境变量或单独的配置文件中，避免将秘密提交到仓库，并整理智能体定义。示例还可以扩展其他任务或智能体，但当前用户应遵循对应版本的文档，并核验生成的代码和输出。