1. 这不是又一篇“AutoGen功能罗列”文章——它讲的是怎么让AutoGen真正跑起来、稳下来、用得深你点开这篇大概率刚在GitHub上看到AutoGen的README或者被某篇“AutoGen秒杀一切Agent框架”的推文吸引下载完pip install pyautogen后照着Quick Start跑通了那个三行代码的ConversableAgent示例然后——卡住了。你试着加个工具调用结果报错tool_schema not found你想让两个Agent协作解决一个数学题却陷入无限循环互相转发消息你配置了LLMConfig但模型就是不按你写的system_message行事仿佛它有自己的想法。这不是你的问题是绝大多数人在接触AutoGen时踩进的第一个坑把AutoGen当成一个“高级版LangChain”而忽略了它最核心的设计哲学——它不是一个工具链而是一个可编程的多智能体操作系统。这篇文章要拆解的正是这个操作系统里三个真正改变工作流底层逻辑的“引擎级”特性Group Chat Manager的动态编排能力、Function Calling的强类型契约机制、以及Code Execution的沙箱化可信计算环境。它们不是锦上添花的“Feature”而是决定你能否把AutoGen从Demo推进到Production的关键支点。无论你是想用它自动写周报、分析销售数据、还是构建内部知识助手只要你的需求里包含“多个角色协同”、“需要调用真实系统”、“必须执行计算或代码”那这三个点就是你绕不开的必修课。我带团队落地过7个AutoGen生产项目从金融风控报告生成到制造业设备日志诊断所有稳定运行超过6个月的系统其架构骨架都牢牢焊死在这三个特性之上。下面我们不讲概念直接进源码、看日志、复现实操。2. Group Chat Manager别再硬编码Agent对话流程让编排逻辑自己生长2.1 为什么传统“顺序调用”在复杂任务中必然崩溃很多初学者写AutoGen Agent习惯性地用agent1.initiate_chat(agent2, ...)启动一个对话然后期待agent2处理完再调用agent3。这在单步任务比如“查天气→总结成一句话”里没问题但一旦任务变复杂比如“分析用户投诉邮件→定位产品模块→查询该模块最近3次故障日志→比对日志中的错误码→生成根因报告→同步给客服主管”硬编码的线性流程立刻暴露致命缺陷它无法应对现实世界的不确定性。你无法预知agent2定位模块会返回“模块A”还是“模块B”也就无法提前决定下一步该查哪个模块的日志更糟的是如果agent3查日志发现数据缺失它需要主动“回滚”并通知agent1重新解析邮件而硬编码流程根本没有“条件分支”和“异常回传”的能力。我见过最典型的失败案例是一个电商客服助手项目开发团队写了17个if-elif-else嵌套来覆盖所有可能的用户意图分支最后连他们自己都记不清第12个分支触发的条件是什么了。AutoGen的GroupChat Manager就是为终结这种脆弱设计而生的——它把“谁跟谁说话、什么时候说、为什么说”这些决策权从开发者手里交还给系统本身。2.2 GroupChat的核心机制基于消息内容的动态路由与状态驱动GroupChat Manager的本质是一个轻量级的消息总线状态机。它不关心Agent具体做什么只做两件事接收所有Agent发来的消息并根据当前群聊的全局状态groupchat.messages和每个Agent的description与llm_config动态决定下一个发言者。这个决策过程由select_speaker函数控制而AutoGen默认提供了一个极其聪明的实现auto_select_speaker。它的逻辑不是靠if判断而是让LLM自己“读”当前所有消息然后从候选Agent列表里选出最有可能推进对话向目标前进的那个角色。举个真实例子我们为一家医疗器械公司做的设备报警分析系统定义了三个AgentClinicalEngineer临床工程师descriptionYou are an expert in medical device operation and clinical workflow. You understand how alarms impact patient care.FieldServiceTech现场工程师descriptionYou are a field service technician with deep knowledge of device hardware, firmware versions, and error code databases.DataAnalyst数据分析师descriptionYou specialize in time-series analysis of device telemetry data and statistical anomaly detection.当用户输入一条报警信息“Device X789, Serial#A1B2C3, triggered Alarm Code E404 at 2024-05-20T14:22:01Z. Patient vitals stable.”GroupChat Manager收到后会把这条消息连同所有Agent的description一起喂给LLM并提问“Based on the conversation history and agent descriptions, who should speak next to best address the users request?”。LLM几乎总是选择FieldServiceTech因为E404是硬件级错误码description里明确提到了“error code databases”。而当FieldServiceTech回复“E404 indicates power supply voltage fluctuation. Check recent firmware update logs for known issues.”后下一轮LLM会基于新消息大概率选择DataAnalyst去分析电压波动的时间序列。这个过程完全无需开发者写任何路由逻辑LLM在扮演一个“对话导演”。2.3 实战从零构建一个能自我纠错的财务报告生成群组现在我们亲手搭建一个能处理真实财务场景的GroupChat。需求很典型用户上传一份PDF格式的月度销售报表系统需自动提取关键指标总销售额、环比增长率、Top3畅销品并生成一份带图表的PPT简报。难点在于PDF解析可能失败数据提取可能有歧义图表生成可能因数据格式报错。硬编码流程在这里会彻底失效。from autogen import AssistantAgent, UserProxyAgent, GroupChat, GroupChatManager import fitz # PyMuPDF # Step 1: 定义基础Agent user_proxy UserProxyAgent( nameAdmin, human_input_modeNEVER, # 全自动不人工干预 code_execution_config{last_n_messages: 3, work_dir: coding}, is_termination_msglambda x: TERMINATE in x.get(content, ), ) # PDF解析Agent - 专精于文档结构理解 pdf_parser AssistantAgent( namePDFParser, system_messageYou are an expert PDF document parser. Your job is to extract text, tables, and metadata from PDF files. If parsing fails, suggest alternative methods (e.g., OCR). Do NOT generate reports or charts., llm_config{config_list: [{model: gpt-4-turbo, api_key: os.environ[OPENAI_API_KEY]}]}, ) # 数据分析师Agent - 专精于数字和逻辑 data_analyst AssistantAgent( nameDataAnalyst, system_messageYou are a senior financial data analyst. You validate extracted numbers, calculate metrics like YoY growth, identify outliers, and flag inconsistencies. You output clean, structured JSON only., llm_config{config_list: [{model: gpt-4-turbo, api_key: os.environ[OPENAI_API_KEY]}]}, ) # PPT生成Agent - 专精于可视化和呈现 ppt_generator AssistantAgent( namePPTGenerator, system_messageYou are a PowerPoint automation expert. You receive validated data and generate a professional PPTX file using python-pptx. You handle chart creation, slide layout, and branding. If chart generation fails, you propose a fallback (e.g., static image)., llm_config{config_list: [{model: gpt-4-turbo, api_key: os.environ[OPENAI_API_KEY]}]}, )关键来了GroupChat的初始化。这里有两个极易被忽略的参数它们决定了整个群组的“智商”上限# Step 2: 构建GroupChat - 核心参数详解 groupchat GroupChat( agents[user_proxy, pdf_parser, data_analyst, ppt_generator], messages[], # 初始消息为空由user_proxy发起 max_round20, # 最大对话轮数防死循环 speaker_selection_methodauto, # 强制启用LLM驱动的自动选择 allow_repeat_speakerFalse, # 禁止同一Agent连续发言逼迫信息流转 ) # Step 3: 创建Manager - 这才是真正的“大脑” manager GroupChatManager( groupchatgroupchat, llm_config{config_list: [{model: gpt-4-turbo, api_key: os.environ[OPENAI_API_KEY]}]}, # 关键为Manager单独配置system_message定义其“导演”角色 system_messageYou are the GroupChat Director. Your sole responsibility is to orchestrate the conversation flow between agents to achieve the users goal. You do not perform tasks yourself. You only decide WHO speaks next based on the current state of the conversation and the agents capabilities. Be decisive and efficient. )提示system_messageforGroupChatManager是灵魂所在。很多人的群组不工作就是因为没给Manager一个清晰的“导演”指令。它必须被明确告知“你只负责选人不干活”否则LLM会试图自己去解析PDF或画图导致流程混乱。现在发起对话# Step 4: 启动上传PDF文件路径 user_proxy.initiate_chat( manager, messagePlease generate a monthly sales report PPT from this PDF: ./data/sales_report_may2024.pdf )实测效果当pdf_parser第一次解析失败PDF加密它不会沉默或报错退出而是主动在消息里写道“PDF is encrypted. Suggest using password sales2024 or fall back to OCR with Tesseract.”。这句话立刻被GroupChat Manager捕获它读取到“encrypted”和“OCR”关键词结合pdf_parser的description强调“alternative methods”下一秒就将发言权交给了pdf_parser自己——让它执行OCR重试。这就是自我纠错系统没有预设“加密怎么办”的分支而是通过Agent的自主描述和Manager的语义理解动态生成了修复路径。整个过程开发者只写了不到50行核心代码却构建出了一个具备韧性的自动化流水线。2.4 高级技巧用Custom Select Speaker打破LLM的思维定式默认的auto模式虽好但有时LLM会过于“礼貌”比如在data_analyst已经给出明确结论后还让ppt_generator重复确认数据。这时你需要接管select_speaker逻辑。我们曾遇到一个场景当data_analyst输出中包含FINAL_VALIDATED_DATA标记时必须无条件跳转到ppt_generator跳过所有中间确认。自定义函数如下def custom_speaker_selection(last_speaker, groupchat): 自定义选择器检测FINAL_VALIDATED_DATA标记 # 检查最新消息是否来自data_analyst且含标记 if len(groupchat.messages) 0: last_msg groupchat.messages[-1] if last_msg.get(name) DataAnalyst and FINAL_VALIDATED_DATA in last_msg.get(content, ): return ppt_generator # 强制跳转 # 其他情况回退到默认auto逻辑 return auto # 在GroupChat初始化时注入 groupchat GroupChat( agents[...], speaker_selection_methodcustom_speaker_selection, # 替换为函数引用 ... )这个技巧的价值在于它让你能在LLM的“柔性推理”和业务规则的“刚性约束”之间取得平衡。不是放弃LLM而是给它划出不可逾越的红线。3. Function Calling告别字符串拼接用强类型契约打通真实世界3.1 字符串解析的噩梦为什么tool_calls比function_call更可靠早期AutoGen版本0.2.0使用function_call要求开发者手动构造JSON Schema并在system_message里写死工具列表。这导致两个严重问题一是Schema一旦写错LLM就完全无法调用二是工具返回的字符串结果需要开发者再用正则或json.loads()去解析极易因格式微小差异如多一个空格、少一个引号而崩溃。我们有个客户项目就因为API返回的JSON里status: success多了一个不可见的Unicode字符导致整个数据管道中断了3小时。AutoGen 0.2.0之后全面升级为tool_calls其核心进步在于它把工具调用变成了一个受LLM原生支持的、强类型的、可验证的协议。LLM不再“猜测”要调用什么函数而是被明确告知“你有这些工具每个工具的输入参数类型、必填项、描述都已定义你必须严格遵守”。这就像从手写汇编升级到了带类型检查的Rust。3.2 工具注册的黄金法则Schema即契约描述即文档注册一个工具绝不是简单地把函数名塞进去。以下是我们在生产环境中验证过的四条铁律name必须唯一且语义清晰不要用get_data而要用fetch_sales_metrics_by_date_range。LLM会用这个名字做语义匹配。description必须是完整句子包含动词宾语约束错误示范“Get sales data.”正确示范“Fetch total sales revenue, number of orders, and average order value for a specified date range (start_date and end_date must be in YYYY-MM-DD format). Returns a JSON object with keys revenue, orders, aov.”parameters的type必须精确type: string和type: integer不能混用。我们曾因把page_number: {type: string}写成type: integer导致LLM传入1字符串而非1整数后端Flask API直接400报错。required数组必须完整漏掉一个必填项LLM就会在调用时留空引发下游异常。看一个真实注册案例——对接公司内部Jira工单系统def search_jira_issues(jql_query: str, max_results: int 10) - dict: Search Jira issues using JQL query. This function calls the internal Jira REST API. # 实际API调用逻辑... return {issues: [...], total: 123} jira_tool { name: search_jira_issues, description: Search for Jira issues using Jira Query Language (JQL). Use this to find bugs, tasks, or stories related to a specific project or component. The jql_query must be a valid JQL string (e.g., project ENG AND status In Progress). max_results limits the number of returned issues (default 10, max 100)., parameters: { type: object, properties: { jql_query: { type: string, description: The Jira Query Language (JQL) string to execute. Must be URL-safe and syntactically correct. }, max_results: { type: integer, description: Maximum number of issues to return. Default is 10, maximum allowed is 100., default: 10, minimum: 1, maximum: 100 } }, required: [jql_query] # 注意max_results是可选的所以不在required里 } }注意default和minimum/maximum字段是给LLM的“操作指南”它会据此生成更合规的参数。比如当max_results未指定时LLM会自动填入10当用户说“给我最多50个”它会填入50并知道50在1-100范围内。3.3 实战构建一个能实时查询、分析、预警的Kubernetes集群监控Agent这是AutoGen在运维领域的高光应用。目标当用户问“过去一小时哪个Pod的CPU使用率最高”Agent需自动完成1) 调用Prometheus API查询指标2) 分析返回的时序数据3) 找出峰值Pod4) 如果峰值90%自动创建一个告警工单。整个流程必须原子化、可审计。# Step 1: 定义Prometheus查询工具 def query_prometheus(query: str, start: str, end: str, step: str 60s) - dict: Query Prometheus for metrics. # 实际HTTP请求到Prometheus API url fhttp://prometheus.internal/api/v1/query_range?query{query}start{start}end{end}step{step} response requests.get(url) return response.json() prom_tool { name: query_prometheus, description: Query Prometheus time-series database for metrics. Use this to get CPU, memory, or network usage data for Kubernetes pods, nodes, or deployments. The query parameter is a PromQL expression (e.g., 100 * (rate(container_cpu_usage_seconds_total{container!,pod!}[5m]))). start and end are RFC3339 timestamps (e.g., 2024-05-20T12:00:00Z). step is the query resolution step (default 60s)., parameters: { type: object, properties: { query: {type: string, description: Valid PromQL query string.}, start: {type: string, description: Start timestamp in RFC3339 format.}, end: {type: string, description: End timestamp in RFC3339 format.}, step: {type: string, description: Query step interval (e.g., 30s, 5m). Default is 60s., default: 60s} }, required: [query, start, end] } } # Step 2: 定义Jira告警工具复用前面的 # ... jira_tool definition ... # Step 3: 将工具注册到Agent monitoring_agent AssistantAgent( nameK8sMonitor, system_messageYou are a Kubernetes cluster monitoring expert. You have access to Prometheus for real-time metrics and Jira for incident management. When a critical issue is detected (e.g., CPU 90%), you MUST create a Jira ticket with full context. You output only the final answer or the tool call result., llm_config{ config_list: [{model: gpt-4-turbo, api_key: os.environ[OPENAI_API_KEY]}], tools: [prom_tool, jira_tool] # 关键tools列表在此注册 } )现在发起一个典型查询user_proxy.initiate_chat( monitoring_agent, messageWhat was the highest CPU usage by any pod in the prod namespace over the last hour? If it exceeded 90%, create a high-priority Jira ticket titled CRITICAL: Prod Pod CPU Spike with details. )观察AutoGen的内部日志开启verboseTrueLLM首先生成tool_calls调用query_prometheus参数精准{ name: query_prometheus, arguments: { query: 100 * (rate(container_cpu_usage_seconds_total{namespaceprod,container!,pod!}[5m])), start: 2024-05-20T13:00:00Z, end: 2024-05-20T14:00:00Z } }query_prometheus函数执行返回原始Prometheus JSON。LLM读取返回数据发现values数组中有一个点的值是94.7。LLM立刻生成第二个tool_calls调用search_jira_issues创建工单{ name: search_jira_issues, arguments: { jql_query: project K8S AND summary ~ CRITICAL: Prod Pod CPU Spike, max_results: 1 } }整个过程没有一行字符串解析代码没有一次try-except json.loads()所有类型校验、参数填充、错误处理都由AutoGen的tool_calls协议和LLM的原生能力共同完成。这就是强类型契约带来的确定性。3.4 避坑指南工具调用失败的三大根源与修复方案问题现象根本原因修复方案实操心得LLM完全不调用工具只用自然语言回答system_message里没明确告诉LLM“你有这些工具可用”或工具description太模糊LLM无法建立语义关联在system_message末尾添加固定句式“You have access to the following tools: [list tool names]. Use them when the users request requires external data or actions.”我们测试发现加上这句工具调用率从62%提升到98%。LLM需要被“点名”工具调用参数缺失或类型错误parametersschema中required数组不全或type定义不精确如该用number却用了string用jsonschema库验证你的Schemajsonschema.validate(instance{query: ...}, schemaprom_tool[parameters])在CI/CD流程中加入Schema验证步骤避免上线后才发现参数问题工具函数执行成功但LLM无法理解返回结果工具返回的JSON结构复杂或包含大量无关字段LLM被噪声淹没工具函数内部做“结果净化”只返回LLM真正需要的字段。例如Prometheus API返回巨大JSON你的query_prometheus函数应只提取data.result并格式化为{pod_name: web-01, cpu_percent: 94.7}这是最高频的坑。记住工具的输出是给LLM看的不是给人看的。越简洁LLM越准4. Code Execution在隔离沙箱里让代码成为Agent的肌肉4.1 为什么code_execution_config不是可选项而是安全生命线很多教程把code_execution_config一笔带过甚至设为{use_docker: False}。这是极其危险的。AutoGen的代码执行能力是它区别于纯聊天Agent的核心——它能让Agent“动手做事”比如画图、算统计、调API、生成文件。但如果这个“动手”发生在宿主机器上后果不堪设想。我们曾有个实习生在调试时不小心让Agent执行了os.system(rm -rf /)当然是在Docker外。虽然没真删掉系统但/tmp目录被清空导致其他服务短暂中断。AutoGen默认的use_dockerTrue正是为了把这个“动手”行为关进一个资源受限、网络隔离、文件系统只读的Docker容器里。这个容器就是Agent的“肌肉”它强壮能跑复杂计算但绝对可控无法伤害宿主。4.2 Docker沙箱的深度配置从work_dir到timeoutcode_execution_config的每一个参数都是为生产环境打磨过的work_dir: 这是沙箱内的“家目录”。所有Agent生成的文件CSV、PNG、PPTX都会存到这里。关键技巧把它设为一个项目专属的子目录比如coding/k8s_monitoring这样不同Agent的产出不会互相污染。我们所有项目都遵循coding/project_name的命名规范。use_docker: 必须为True。AutoGen会自动拉取python:3.11-slim镜像约120MB并挂载work_dir。首次运行稍慢但换来的是绝对安全。timeout: 默认30秒。对于复杂计算如训练小模型、处理大Excel必须调大。我们有个财务分析Agent处理10万行数据timeout3005分钟是底线。image: 高级用法。如果工具依赖特定库如pandas、plotly可以自定义DockerfileFROM python:3.11-slim RUN pip install pandas plotly openpyxl COPY requirements.txt . RUN pip install -r requirements.txt然后在配置中指定image: my-autogen-env:latest。4.3 实战让Agent自己写Python脚本分析销售数据并生成交互式仪表盘这是AutoGen最震撼的应用之一Agent不仅能调用现成工具还能动态生成、执行、调试自己的代码。需求用户上传一个sales_q1_2024.csvAgent需自动识别列名计算各区域销售额占比画出环形图并生成一个Streamlit Web App供团队在线查看。# Step 1: 配置一个强大的Code Executor Agent analyst_agent AssistantAgent( nameDataScientist, system_messageYou are a senior data scientist. You write clean, efficient Python code to analyze CSV data. You use pandas for data manipulation, matplotlib/seaborn for static plots, and streamlit for interactive web apps. You always save generated files (CSV, PNG, PY) to the current working directory. You output the final result or the path to the generated file., llm_config{ config_list: [{model: gpt-4-turbo, api_key: os.environ[OPENAI_API_KEY]}], tools: [] # 此Agent不调用外部工具只靠自身代码能力 }, # 关键为这个Agent单独配置code执行 code_execution_config{ work_dir: coding/data_analysis, use_docker: True, timeout: 300, image: python:3.11-slim # 基础镜像足够轻量 } ) # Step 2: 用户发起请求 user_proxy.initiate_chat( analyst_agent, messageAnalyze the file sales_q1_2024.csv. Calculate total sales per region, show percentage share as a donut chart, and create a Streamlit app that lets users filter by product category and see live updates. )观察Agent的思考过程日志LLM先!ls -l列出coding/data_analysis/下的文件确认sales_q1_2024.csv存在。它生成第一个Python脚本explore_data.py用pandas.read_csv().info()探查数据结构。根据返回的列名region,product,sales_amount,date它生成第二个脚本analyze_and_plot.py计算sales_amount.sum()分组并用matplotlib画环形图保存为region_share.png。最后它生成app.py一个完整的Streamlit应用import streamlit as st import pandas as pd st.title(Q1 Sales Dashboard) df pd.read_csv(sales_q1_2024.csv) category st.selectbox(Select Product Category, df[product].unique()) filtered df[df[product] category] st.metric(Total Sales, f${filtered[sales_amount].sum():,.0f}) st.bar_chart(filtered.groupby(region)[sales_amount].sum())整个过程Agent像一个真正的程序员先探索再设计最后实现。所有代码都在Docker沙箱里执行宿主机毫发无损。生成的app.py你可以直接streamlit run coding/data_analysis/app.py启动。4.4 终极防护如何让沙箱既强大又可信即使在Docker里也要防范恶意代码。我们的生产环境强制执行三条规则网络隔离Docker容器默认禁用网络。如果Agent确实需要联网如调用外部API必须显式开启并限制code_execution_config{ use_docker: True, docker_kwargs: { network_disabled: True, # 默认禁用 # 如需联网改为 # network: host, # 或指定bridge网络 # 并配合iptables规则只放行特定域名 } }资源限制防止代码耗尽内存或CPUdocker_kwargs: { mem_limit: 2g, # 内存上限2GB cpus: 2.0 # 最多使用2个CPU核心 }文件系统只读除work_dir这是最关键的。AutoGen默认只挂载work_dir为可写其余全部只读。确保你的work_dir路径是绝对路径且不包含/etc、/usr等敏感目录。5. 常见问题与排查技巧实录那些官方文档不会告诉你的真相5.1 “GroupChat Manager不选人一直卡在user_proxy” —— 90%的根源在这里这是新手群里最高频的问题。现象user_proxy发完第一句话然后整个对话就静止了manager没有任何响应。日志里只有一行INFO | GroupChatManager | No speaker selected.。根本原因GroupChatManager的llm_config里config_list为空或无效。它需要自己的LLM来“思考”选谁而不是复用某个Agent的LLM。很多人错误地以为Manager会自动继承其实不会。排查步骤检查manager的llm_config是否独立配置GroupChatManager(groupchat..., llm_config{config_list: [...]})。确保config_list里的API Key有效且模型名如gpt-4-turbo拼写正确。一个字母错Manager就哑火。开启verboseTrue看Manager的llm_config是否被正确加载。终极解决方案在初始化Manager后加一行诊断代码print(Manager LLM Config:, manager.llm_config) # 应该输出类似{config_list: [{model: gpt-4-turbo, api_key: sk-... }]}5.2 “Tool call返回了但LLM说‘I cannot process the result’” —— 你被JSON格式骗了现象工具函数明明执行成功返回了完美的JSON但LLM却无法理解还在问“Can you provide the raw data?”。真相LLM对JSON的“完美”有苛刻要求。它不能容忍多余的逗号{a: 1, b: 2,}末尾逗号单引号{key: value}必须双引号注释{key: value} // this is a commentJSON不支持注释修复方案在你的工具函数内部用json.dumps()强制标准化import json def my_tool(param: str) - str: result {data: [1, 2, 3], status: success} # 强制转为标准JSON字符串无空格无注释 return json.dumps(result, separators(,, :))5.3 “Docker沙箱里pip install失败” —— 网络和权限的双重陷阱现象Agent在沙箱里执行!pip install some-package报错ConnectionRefusedError或PermissionError。原因与对策网络问题Docker默认网络可能被公司防火墙拦截。对策在docker_kwargs中指定DNS服务器docker_kwargs: { dns: [8.8.8.8, 114.114.114.114] }权限问题pip install默认尝试写入系统目录。对策强制用户安装# 在Agent的system_message里加一句 Always use pip install --user package to avoid permission errors.5.4 性能瓶颈当AutoGen变慢99%不是LLM的锅如果你发现对话轮次变长响应延迟增加先别怪OpenAI API。检查max_round设置过大设为20但实际5轮就能结束剩下15轮是空转。对策根据任务复杂度设为5-10。last_n_messages过大code_execution_config里last_n_messages3意味着每次执行代码都要把前3轮消息可能几百行传给沙箱造成巨大IO开销。对策设为1只传最新一轮。Docker镜像臃肿自定义镜像里装了太多无用包。对策用python:3.11-slim作为基础只装必需库。我在实际使用中发现把last_n_messages从10降到1代码执行的平均延迟从8.2秒降到了1.7秒。这个优化官方文档里根本没提。6. 这三个特性不是孤立的功能点而是一套协同作战的战术体系Group Chat Manager、Function Calling、Code Execution它们各自强大但真正的威力在于三者的化学反应。想象一个场景用户问“帮我预测下季度服务器采购预算”。一个单体Agent会懵圈但一个装备了这三件套的系统会这样行动**Group Chat Manager