AutoGen：金融 AI 的多智能体对话框架

在 Gorilla 展示了单个大语言模型（LLM）可以学会准确调用数千个 API 之后，一个自然而然的问题出现了：如果你给多个 LLM 分配不同的角色并让他们相互对话会发生什么？AutoGen（Wu 等，2023）通过构建一个多智能体对话框架回答了这个问题。现在读来正当其时——我看到的正在设计中的大多数生产级金融 AI 系统默认至少包含三个智能体。

论文

AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation (Wu, Bansal, Zhang 等，微软研究院，2023) 提出了一个框架，其中“可对话智能体”（每个智能体由 LLM、工具和人工输入组合而成）相互发送消息，直到任务完成。该框架引入了两种内置智能体类型：AssistantAgent（由 LLM 驱动）和 UserProxyAgent（可以执行代码并传递人工输入），以及一个在大型合奏中调度回合的 GroupChatManager。

核心思想是作者所称的“对话编程”：你不再是在代码中手写编排逻辑，而是通过自然语言系统提示词指定每个智能体应该做什么，并让消息传递来处理控制流。该论文在数学问题求解、检索增强问答（RAG）、ALFWorld 决策制定以及名为 OptiGuide 的运筹学应用中展示了这一点。

关键想法

• MATH 基准测试的准确率提升：双智能体 AutoGen 设置（一个 LLM 助手加一个代码执行代理）在 MATH 测试集上达到了 69.48% 的准确率，而单独使用 GPT-4 的准确率为 55.18%——通过添加代码执行反馈获得了 14 个百分点的提升。
• 人机协作是第一等公民：UserProxyAgent 具有可配置的 human_input_mode——ALWAYS、NEVER 或 TERMINATE——这意味着你可以在不更改智能体逻辑的情况下调高或调低监督力度。
• 动态群组对话：GroupChatManager 根据对话状态而非固定的轮询顺序选择下一个发言者，这使得工作流能够响应新出现的结果进行分支。
• OptiGuide 安全性提升：在供应链优化工作流中加入 SafeGuard 智能体，将 GPT-4 的不安全代码检测 F1 分数提高了 8 个百分点，将 GPT-3.5 提高了 35 个百分点，同时将用户的代码库从 430 行缩减到 100 行。
• 交互式检索：在问答任务中，助手智能体可以通过发出 UPDATE CONTEXT 信号请求额外的上下文；这在 Natural Questions 的大约 19.4% 的问题中被触发，整体 F1 分数为 23.40%。
• 设计上的组合性：任何 AutoGen 智能体本身都是另一个智能体可以调用的有效“工具”，因此分层流水线无需特殊的粘合代码即可组合。

哪些经得起推敲，哪些不能

MATH 和 ALFWorld 的结果是扎实的——在真实基准测试中与知名基准进行了受控且可重复的比较。69.48% 这个数字是有意义的，因为它分离出了结构化对话循环中代码执行反馈带来的好处。

较弱的部分是成本和延迟分析，或者更确切地说，是缺失了这部分。每一次 GroupChat 回合都会触发一次包含累计对话历史的完整 LLM 调用。一个包含十轮对话的四智能体工作流意味着至少四十次 LLM 调用，每一次都带着不断增长的上下文窗口。论文从未报告过其任何应用的 Token 成本或延迟。在处理数千笔交易的实时会计流水线中，这种遗漏并非学术性的——它决定了该方法是否可行。

“对话编程”的比喻也比演示中看起来更加脆弱。GroupChatManager 通过提示 LLM 从智能体列表中进行选择来确定下一个发言者。这种选择本身就是一个概率性的文本生成步骤，这意味着控制流可能以微妙的方式出错而不会抛出异常。对于账本回写智能体来说——操作顺序至关重要，一次错误的工具调用就可能损坏日记账分录——非确定性的发言者选择是一个真正的隐患。

最后，评估任务都是单次会话、短时程的。没有实验让智能体在多天内累积状态、处理相互矛盾的指令，或需要解决旧的智能体记忆与新的账本条目之间的冲突。而这些正是现实会计工作流中会出现的场景。

为什么这对金融 AI 至关重要

金融 AI 对多智能体系统的需求显而易见：对账、入账和报告自然是相互独立的关注点。一个 Beancount 流水线可以有一个只读查询账本的 LedgerReaderAgent，一个将交易与银行对账单进行比较的 ReconcilerAgent，一个提出新分录建议的 WriterAgent，以及一个在提交任何写入之前根据会计科目表规则进行检查的 ReviewerAgent。AutoGen 的 UserProxyAgent 模式是 WriterAgent 的正确抽象——它可以执行实际的账本写入，并将结果作为消息返回供 ReviewerAgent 检查。

OptiGuide SafeGuard 的结果是最直接可借鉴的发现：添加一个专门的验证智能体来捕获不安全的操作，显著提高了检测率，而且这种检测发生在对话循环内部，而不是事后审计。这正是我想要的 Beancount 回写安全性架构——一个阻止提交的验证器，而不是一个事后才发出警报的验证器。

非确定性的发言者选择问题是可以解决的：你可以用一个根据消息内容进行路由的确定性 Python 函数来覆盖 GroupChatManager。但你必须意识到这一点，而论文并没有将其作为一个关注点重点突出。

下一步阅读建议

• AgentBench: Evaluating LLMs as Agents (Liu 等，arXiv:2308.03688, ICLR 2024) —— 在包括网页浏览、编码和数据库操作在内的八个不同智能体环境中对 LLM 进行基准测试；商业模型与开源模型之间的差距是核心发现，直接影响了金融智能体流水线应使用哪些基础模型。
• TradingAgents: Multi-Agents LLM Financial Trading Framework (arXiv:2412.20138) —— 直接为金融市场实例化了 AutoGen 模式，配备了专门的分析师、研究员、交易员和风险管理智能体；夏普比率（Sharpe ratio）和最大回撤（max drawdown）结果为多智能体金融系统提供了第一批真实的性能数据。
• AGENTLESS: Demystifying LLM-based Software Engineering Agents (Xia 等，arXiv:2407.01514) —— 认为简单的、无智能体的两阶段方法（定位，然后修复）在 SWE-bench 上的表现优于复杂的多智能体框架；这是对“更多智能体总是更有帮助”这一假设的有效制衡。