本地运行 AutoGen：哪些可行，哪些 casse

#对话模型

链式框架要求定义步骤，而 AutoGen 要求定义参与者。助手智能体提出建议；用户代理智能体代表你，可能执行代码并返回结果；群组讨论让多位专家参与，由管理者决定谁发言。行为从这些交流中涌现。

这对于开放式任务确实很强大——例如调试、反复完善分析——而这也正是成本难以预测的原因。固定流程会调用模型 N 次。对话则会按需要不断调用，而“需要调用多少次”恰恰由您正在质疑的那个模型决定。

这种设计对角色选择有直接影响：对话中不同的智能体越多，在得出最终回答之前可能经历的交互轮次就越多，偏离目标的风险也越高。在本地运行时，最常见的问题是两个智能体不断相互回复，却始终无法收敛到一个结论，原因恰恰是在第一次尝试之前没有设定任何限制。因此，智能体数量不仅是一项架构选择，还会直接成倍放大您自己的显卡所消耗的计算时间。

#AutoGen 进入维护模式：发生了哪些变化

这是大多数在线教程都忽略的关键点。微软官方仓库 microsoft/autogen 自2025年10月2日起明确宣布：该项目已进入维护模式，不再接收新功能，将由社区维护。微软建议新项目直接采用 Microsoft Agent Framework (MAF)，该框架作为继任者，将 AutoGen 和 Semantic Kernel 的组件融合为一个统一的开发套件，已于2026年4月初正式发布。

AutoGen 的原始创建者王驰和吴青云于2024年底离开微软，此后以 AG2 的名称继续开发，该版本基于 Apache 2.0 许可协议，由 ag2ai 组织托管。AG2 被定位为项目的持续发展，而非断层式更迭：历史代码仍可通过 AG2 Classic 访问，以满足不希望修改现有代码的用户需求；而 AG2 1.0 则在架构上向代理间更明确的通信协议演进。对于新启动的项目，若希望保持与原始 AutoGen API 的紧密兼容，AG2 是最一致的选择；若已身处微软生态，并且关注 Semantic Kernel 工具的整合，应关注 Microsoft Agent Framework。

#连接本地模型

1. 01
   提供模型服务

   通过兼容OpenAI的端点提供服务。多个智能体同时交互时，专为并发设计的服务器比面向单台工作站设计的服务器表现好得多。
2. 02
   配置客户端

   基础地址（例如 http://localhost:11434/v1 用于 Ollama），模型名称必须与本地下载的完全一致，使用虚构密钥。本地服务器忽略密钥；客户端库通常要求密钥存在。
3. 03
   如实声明能力

   这些框架会询问模型是否支持函数调用或 JSON 模式。如果声明模型具备实际不存在的能力，后续就会出现难以理解的错误，而不是以清晰、可控的方式失败。
4. 04
   扩展上下文窗口

   对话历史会随着每一轮交互不断增长。默认上下文窗口会悄无声息地截断开头，导致智能体重复已经完成的工作。

#代码执行：需要隔离

AutoGen 吸引人的工作流程——一个智能体编写代码，一个受托执行的智能体运行代码，错误反馈回来后，编写代码的智能体进行修正——也意味着模型编写的代码会在您的机器上运行。应在容器中运行这些代码，不提供任何凭据；如果任务不需要网络，就禁用网络；绝不要让代码对您的个人目录执行操作。而且，任何从外部获取的内容——工单、网页、文档文件——都应被视为可能具有恶意。

可观测性与隔离同样重要。在涉及三个或四个智能体的对话中，诊断故障需要逐轮重新查看每个智能体收到的确切提示词，而不是事后的摘要。没有完整记录，就无法知道某个智能体是误解了指令，还是仅仅因为内存不足而收到了被截断的上下文。记录每次交互，包括工具调用及其确切参数，成本很低，也能避免在显卡恢复空闲后只能猜测发生了什么。

#模型大小，还是这个问题

优先选择经过工具调用和结构化输出训练的模型。所有本地 AI 智能体框架都会遇到同样的能力上限：生成自然语言文本很容易，遵守严格格式却不容易。在群组讨论中，管理者角色通常值得交给您手头能力最强的模型：它决定接下来由谁发言，而每次错误的路由决策都会浪费一整轮；只要对话继续兜圈子、无法收敛，这种代价就会反复出现。

• CrewAI：角色与交付成果的有序安排
• 本地智能体的架构
• 使用 Python 和 LangChain 创建本地智能体
• 用于搭建本地智能体的 QuelLLM 工具包
• 官方代码仓库：维护模式公告
• AG2：活跃开发的分支
• Ollama的官方OpenAI兼容API

#AutoGen、AG2 或 CrewAI

对于已经使用 AutoGen 旧版 API 编写的代码，迁移到 AG2 通常只需小幅调整：原有的 autogen.* 命名空间仍在专用分支（AG2 Classic）中保留，让您可以按自己的节奏完成迁移。而如今从零开始则是另一种选择：不如直接选择 AG2，或评估 Microsoft Agent Framework，而不是学习一套连其发布方自己都称为由社区维护的代码库。

#一次对话的实际成本

使用付费 API 时，三个智能体进行长达二十轮的对话，开销会体现在账单上。在本地运行时，代价则体现在机箱风扇的运转和墙上时钟流逝的时间里。每一轮都是一次完整的生成：如果在您的显卡上，每轮平均耗时五秒，那么在没有停止条件的情况下，二十轮至少意味着一分四十秒的连续计算。随着上下文增长，每次生成重新读取的历史记录都比上一次更长，实际耗时往往会远超这个数字。在这一过程中，不会有任何提醒——没有计数器，没有阈值，只有持续发热的 GPU。

因此，轮数限制并非众多配置项中一个无关紧要的细节：它是将可能无限增长的成本转化为有上限、可预测成本的唯一机制，作用与商业 API 的 token 预算完全相同。在第一次尝试之前就设定这一限制，而不是事后才意识到它的重要性，决定了您进行的是五分钟的测试，还是让显卡被一场从第十条消息起就毫无进展的对话独占一整晚。在同时承担其他用途的机器上——例如工作站，而非专用服务器——这种独占还会带来实际的机会成本：当多智能体对话在后台无限制运行时，就无法启动其他需要大量 GPU 资源的任务。

#FAQ