★ FEATURED ARTICLE 做了一年多大模型应用落地我有个很深的体会凡是能稳定跑在生产环境里的Agent项目几乎都离不开两件事——多智能体协作和工具调用。单模型单轮对话早就不是瓶颈真正让系统“活”起来、能实际干活的关键是让程序学会拆解任务、调用外部工具并且让多个各司其职的智能体配合起来。这篇文章我想结合自己做过的项目把多智能体怎么设计、工具调用怎么落地、两者怎么衔接讲透。适合已经跑通基础对话、想把大模型接进真实业务场景的开发者参考。1. 多智能体到底在解决什么问题1.1 单智能体的天花板在哪里很多人在第一步就会困惑一个智能体明明也能装一堆工具为什么非要拆成多个角色我见过不少项目就是这样开始的——把十几个工具全塞给一个Agent让它又是查数据库、又是算指标、又是写邮件、又是调第三方接口。表面上功能齐全跑起来全是问题。第一个问题是角色混乱。同一个模型既要扮演“理解业务的数据分析师”又要扮演“严格的风险审查员”这两个角色对同一份数据的处理方式可能完全相反。模型会在严格和宽松之间反复摇摆输出的可靠性很差。这种问题很难通过调提示词根治因为冲突的根源来自角色本身不是措辞。第二个问题是上下文爆炸。十几个工具的描述、系统提示词、每轮调用返回的结果全都堆在一个上下文窗口里。上下文一长模型开始“顾头不顾尾”该用的工具不用不该用的乱用Token成本翻着倍涨响应延迟也跟着上来。第三个问题是错误隔离能力差。单Agent架构下一个工具抛异常往往整个对话流程就崩了。没有别的角色来兜底、重试或纠偏系统非常脆弱生产环境根本不敢放心用。1.2 多智能体的本质是职责分离多智能体不是“人多力量大”这么简单。它的核心逻辑是职责分离和专业化——就像一个小团队有人管数据、有人管文案、有人管质检每个人只带着自己需要的工具和知识出场。这样做的好处非常直接每个Agent的提示词和工具集都精简模型注意力更集中指令遵循率明显更高上下文互相隔离不会因为一个环节的数据污染整条链路某个环节出错可以由上游重试或协调者重新调度不用把整个流程推倒重来。更关键的是每个Agent可以独立测试、独立迭代团队协作开发时互不阻塞。用生活里的类比说单智能体像是一个什么都会一点的杂工什么都能干但什么都不精多智能体像一支分工明确的施工队瓦工管砌墙、电工管线路、监理管验收出了问题能找到具体责任人。这里要提醒一句拆分的粒度不是越细越好。每个Agent都有自己的系统提示词和工具描述这些内容在每次调用模型时都要占用Token。角色拆得过多光是开场那堆系统提示词就能吃掉一大截上下文预算协调成本反而高于收益。我的经验是刚开始宁可少拆先用一个编排者加两到三个执行者把流程跑通等发现某个环节确实成为瓶颈再单独拆出来细化。1.3 什么场景真的需要多智能体不是所有项目都需要多智能体这是我最想强调的观点。如果任务就是一个问答、一次翻译、一次简单的总结一个Agent加一两个工具完全够用。强行上多智能体只会增加延迟、成本和排查难度属于典型的过度设计。真正适合的场景有几个特征。任务包含多个专业环节比如“先取数、再分析、再出报告”这种明显分段的流程。任务需要不同角色视角比如既要生成内容又要审查内容两边互相制衡。单个流程过长一个Agent在有限上下文里难以全程把握中间结果容易丢失。我参与过一个“每周运营报告”的模拟项目需求是从数据库取各渠道数据、计算环比指标、生成图表、最后写成带结论和建议的周报。一开始用单Agent从零做到尾结果经常是取数取到一半忘了要算什么或者写报告时把数据编错。拆成三个角色之后稳定性和输出质量明显改善。这类任务就是多智能体的典型适用场景环节多、角色不同、流程固定。2. 工具调用让智能体从“会说”到“会做”2.1 没有工具的智能体只是聊天机器人工具调用是让大模型连接外部世界的关键机制也是多智能体系统里每个Agent的“手脚”。没有工具的模型只能根据训练数据里的记忆回答问题。它查不了实时的库存、改不了数据库里的记录、发不了网络请求信息有时效性问题也执行不了任何实际操作。很多刚接触这个方向的人会以为“模型能写代码就等于能干活”这是个大误区。模型确实会生成代码但这段代码不会自动运行在你想要的机器上。运行环境、权限、依赖、数据源连接这些事都需要程序去编排。工具调用解决的就是这个“最后一公里”模型做决策程序做执行。在多智能体系统里工具调用还是Agent之间协作的重要介质。能力边界就是靠工具划出来的——一个Agent会什么取决于它带了哪些工具。工具设计得好不好直接决定整个系统的上限。2.2 函数调用是如何工作的工具调用在主流大模型服务商那里通常被称为“函数调用”。它的工作方式是一个循环我拆成五步讲清楚。第一步你在请求里附上工具清单。每个工具包含名称、描述、参数Schema参数Schema用JSON Schema格式描述包括字段类型、是否必填、允许的枚举值等。第二步模型阅读对话内容判断当前是否需要调用工具。如果需要它不会真的执行任何代码而是返回一个结构化的调用意图包含要调用的函数名和参数值。第三步你的程序解析这个调用意图在本地实际执行对应的函数。这个执行可能是查数据库、调接口、算指标什么都行。第四步把执行结果作为一条新的消息回传给模型。结果可以是结构化数据也可以是执行成功的提示。第五步模型看到结果后要么继续发起下一次工具调用要么认为信息足够生成最终回答。循环一直持续到模型停止调用或者程序设置的最大轮数用尽。我整理过一张文字版的流程图大家可以对着看用户请求 ↓ 模型判断是否调用工具 ├─ 是 → 输出函数名与参数 │ ↓ │ 程序执行工具返回结果 │ ↓ │ 结果作为新消息回传模型 → 回到“模型判断” └─ 否 → 输出最终回答这个循环看起来简单但有一个关键点很容易被忽视模型返回的工具调用参数属于“不可信输入”必须经过校验和规整再执行。模型偶尔会生成不存在的字段、错误的日期格式、超出枚举范围的参数值。程序侧必须有一层参数校验和格式归一化否则工具执行会频繁报错。提示模型发出的工具调用请求本质上和你写代码时调用的外部API参数一样属于不可信输入。这是工具调用工程化的第一条铁律。2.3 工具描述与参数Schema怎么写才有效工具调用的成败一半取决于模型本身的能力另一半取决于工具描述的质量。我踩过最大的坑是函数名和描述写得太“敷衍”。比如一个函数叫query_data描述写“查询数据”参数只写一个condition。模型面对这种工具时根本不知道什么时候该调用、参数该填什么结果就是该用的时候不用不该用的时候乱用。有效的工具描述要做到三点。第一函数名要语义化让人和模型一看就知道用途比如get_daily_channel_metrics比query_data明确得多。第二描述要写明调用场景和边界比如“当用户询问渠道每日指标时调用仅支持近90天内的数据超出范围请告知用户无法查询”。第三参数Schema要完整类型、必填项、枚举值、默认值每个字段都写清楚。我拿一个真实的工具定义说明一下伪代码示意tools [ { name: get_channel_metrics, description: 查询指定渠道在时间范围内的每日营销指标。当需要渠道的曝光、点击、转化数据时调用。channel_id必须来自get_channel_list的返回值。start_date和end_date格式为YYYY-MM-DD跨度不能超过90天。, parameters: { type: object, properties: { channel_id: {type: string, description: 渠道ID例如 channel_001}, start_date: {type: string, description: 开始日期格式YYYY-MM-DD}, end_date: {type: string, description: 结束日期格式YYYY-MM-DD不得早于start_date} }, required: [channel_id, start_date, end_date] } } ]还有一点非常实用工具返回结果时尽量返回“程序可以继续处理的结构化数据”而不是一段给人类阅读的文字。比如查询工具内部先把明细聚合好返回{channel_id: channel_001, total_impressions: 12345, daily_rows: [...]}下游Agent直接拿这个结构体去计算不用再解析一段自然语言。这个习惯能省下大量Token也明显降低出错概率。3. 多智能体的架构设计与协作模式3.1 三种主流协作方式怎么选多智能体之间怎么配合直接决定整个系统的复杂度和稳定性。常见的有三种模式我结合自己的实践逐个说。第一种是编排者-执行者模式。一个总控Agent通常叫规划者或协调者负责理解任务、拆解子任务、分发给不同的专业Agent再汇总它们的结果做最终整合。这就像一个小公司的老板自己不亲自干活但清楚谁擅长什么分派任务、收回结果、汇总交付。这个模式最灵活也最容易扩展我建议从它入门。第二种是流水线模式。任务按固定顺序流转比如先由数据Agent产出数据再由分析Agent解读最后由报告Agent成文。每个环节只处理上一个环节的结果。它的优点是流程清晰、容易理解适合业务流程特别固定的场景缺点是遇到分支任务就不好处理。第三种是辩论/评审模式。两个或更多Agent扮演不同角色互相质疑比如一个负责生成方案、一个负责挑毛病迭代几轮后产出质量更稳的结果。适合内容生成、方案设计这类对正确性要求高的场景代价是调用轮数多、成本高。选型上我没有什么“银弹”可以给但有一个原则供参考优先保证流程可理解、可调试。越是花哨的协作方式越要往后放先把最基础的编排者-执行者模式跑通后面有了具体痛点再做演进比一上来就搭建复杂的辩论结构要稳得多。3.2 任务怎么拆、工具怎么分多智能体设计的核心工作是把一个大任务拆成边界清晰的子任务再把合适的工具分配给合适的Agent。这个过程没有自动化的捷径基本靠业务理解和对模型能力的把握。我常用的拆分原则是按“能力域”分不按“步骤”分。什么叫按步骤分比如“先做A再做B再做C”把一个连续过程强行切成三段这种拆法效果往往不好因为步骤之间依赖太强上游产出不理想下游全崩。按能力域拆是让每个Agent负责一类能力比如“检索类”“计算类”“写作类”具体的任务队列由上游统一调度每个Agent只对一类输出负责。工具分配的原则我总结为“最小权限、最少干扰”每个Agent只携带自己用得到的工具。数据Agent不应该携带发送邮件的工具因为它在错误判断下可能做出危险操作报告Agent也不应该携带修改数据库的工具它只需要读现成的分析结果就够了。这条原则既降低安全风险也减少模型在多个工具之间选错的可能。3.3 上下文怎么传、结果怎么收敛多Agent协作里最容易忽略的环节是上下文管理。每个Agent有自己独立的上下文但它们需要共享任务的中间结果这个共享方式设计得不好整个系统会变得一团糟。我推荐一个简单可靠的做法定义统一的消息协议规定所有Agent的输出都包含三部分——结果摘要、完整结果、结构化字段。摘要用于下游快速判断要不要细看完整结果用于需要细节的场景结构化字段方便程序做逻辑判断和分支处理。另一个高频问题是“上下文滚雪球”。有些实现会把所有Agent的全部中间结果一直往下传最后一个Agent面对的是一个巨大无比的历史包袱既费Token又影响判断。正确做法是压缩中间结果比如数据Agent返回了1000行明细下游分析Agent其实只需要聚合后的指标那就让数据Agent内部先把聚合做完只把关键指标往下传。每传一步就做一次“摘要化”整个链路会清爽很多。4. 实操示例一个数据分析与汇报的多智能体实现4.1 场景设定与整体设计说了一堆理论我拿一个实际做过的模拟项目来串一遍。某公司的运营团队提出了这样一个需求“帮我分析最近三个月各渠道的营销数据输出一份周报摘要包含环比变化和异常渠道提醒。”我把系统拆成了三个Agent外加一个编排层数据查询Agent负责从数据库拿渠道列表和指标数据携带get_channel_list、get_channel_metrics两个工具分析Agent负责算环比变化、做渠道排行携带calculate_change、rank_channels两个工具报告Agent负责按固定模板生成周报文本携带render_markdown一个工具编排层的职责是先让数据Agent拿到渠道列表和指标再把结果交给分析Agent计算变化和排行最后交给报告Agent生成周报。整个流程是一个典型的编排者-执行者结构。4.2 工具定义与参数设计这里贴一下工具的核心逻辑示意。为了让代码不依赖特定实现我把它写成独立的函数大家替换成自己的实际逻辑即可。def get_channel_list() - list: 返回系统内所有渠道的ID与名称列表。 result db.query(SELECT channel_id, channel_name FROM channels WHERE statusactive) return [{channel_id: row.channel_id, channel_name: row.channel_name} for row in result] def get_channel_metrics(channel_id: str, start_date: str, end_date: str) - dict: 查询指定渠道在时间范围内的每日营销指标。 channel_id 必须来自 get_channel_list 的返回值。 start_date 与 end_date 格式为 YYYY-MM-DD跨度不能超过90天。 如果数据为空返回 {empty: True}。 rows db.query( SELECT date, impressions, clicks, conversions FROM metrics WHERE channel_id? AND date BETWEEN ? AND ?, channel_id, start_date, end_date ) if not rows: return {empty: True} return { channel_id: channel_id, daily_rows: rows, summary: { total_impressions: sum(r.impressions for r in rows), total_clicks: sum(r.clicks for r in rows), total_conversions: sum(r.conversions for r in rows) } }注意get_channel_metrics这个工具内部已经把每日明细聚合成summary这就是我前面说的“工具返回结构化聚合结果”。上游拿到的是简洁的汇总数据而不是几十上百行明细后续分析Agent处理起来又快又不容易出错。4.3 编排层核心循环代码编排层的核心其实就是第2节讲的那个“模型决策—程序执行—结果回填”循环。多智能体场景下我在这个循环外面再加了一层任务调度让同一个循环体服务于不同Agent。AGENTS { data_agent: 你是一个数据查询助手只负责查询营销数据不进行主观分析。查询不到的数据请明确说明。, analyst_agent: 你是一个数据分析师使用工具计算环比变化和渠道排行输出结构化结论。, reporter_agent: 你是一个运营周报撰写者基于分析师结论生成简要周报。报告中所有数字必须来自输入数据严禁自行估算。 } def run_agent(agent_name: str, prompt: str, tools: list) - str: messages [ {role: system, content: AGENTS[agent_name]}, {role: user, content: prompt} ] for _ in range(MAX_STEPS): response call_model(messages, toolstools) if response.tool_calls: messages.append(response.message) for call in response.tool_calls: result execute_tool(call.name, call.arguments) messages.append({role: tool, tool_call_id: call.id, content: json.dumps(result)}) else: return response.text raise TimeoutError(f{agent_name} 超过最大调用次数{MAX_STEPS}) channels run_agent(data_agent, 请列出所有渠道ID。, TOOLS_DATA) metrics run_agent(data_agent, f请查询这些渠道最近三个月的指标{channels}, TOOLS_DATA) analysis run_agent(analyst_agent, f请基于以下指标数据进行环比分析和渠道排行\n{metrics}, TOOLS_ANALYST) report run_agent(reporter_agent, f请根据以下分析输出周报摘要\n{analysis}, TOOLS_REPORT)这段代码是简化示意但它展示了多智能体系统的真实骨架所有Agent共享同一个“决策-执行”循环区别只在系统提示词和工具集不同。真正上线时还需要在这个循环之外补上日志、指标采集、限流、重试这些工程化能力。4.4 质量把控与效果复盘这个模拟项目跑起来之后我遇到了一个非常典型的质量问题报告Agent偶尔会“发挥”出不存在的数据。它明明拿的是分析Agent给的指标写报告时却会脑补出一些数字比如把环比变化从5%写成15%。我试过在提示词里加强约束效果有改善但偶尔还会犯。后来换了一个更彻底的思路报告模板里把数字留成占位符由程序在渲染阶段填入不让模型自己写字。模型只负责生成结论性文字和上下文衔接具体数字一律从结构化字段里提取后由代码填充。这个“程序填充模型润色”的方案稳定很多推荐遇到类似问题的朋友直接采用。实际跑下来处理一次完整周报任务大概需要调用模型4到6次包含多轮工具调用耗时在十几秒到几十秒之间。因为每个Agent的上下文都控制得很小整体Token消耗比单Agent实现省了40%左右。这个数字不一定有普适性但趋势很明确上下文隔离能显著降低无效Token消耗。5. 常见问题与排查要点5.1 工具调用失败的三个典型原因工具调用是实操中翻车最频繁的环节我总结了三类高频问题。第一类是参数幻觉。模型生成了工具定义里根本不存在的字段或者日期格式不对、枚举值不合法。排查思路很直接把模型返回的原始调用参数完整打到日志里对比工具定义的JSON Schema一眼能看出差在哪。规避手段是在工具入口统一做参数规整做类型强转和格式归一化比如把“2024年3月1日”统一转成“2024-03-01”。第二类是工具歧义。两个工具功能相似模型容易选错。比如之前我定义了query_channel_daily和query_channel_weekly两个工具模型经常把周粒度数据当成日粒度传给下游。规避手段是合并同类工具与其让模型在两个工具之间纠结不如做成一个工具加一个“聚合粒度”参数由程序内部根据参数执行不同查询。工具数量越少选错概率越低。第三类是超时与重试。工具本身可能很慢比如第三方接口要好几秒才返回模型侧容易超时。规避手段是在工具里设置明确的超时阈值超时后返回一条结构化错误信息比如{error: timeout, message: 查询超时请缩小时间范围后重试}让模型自己决定下一步而不是让整个流程抛异常崩溃。5.2 多智能体协作里的上下文污染多智能体最常踩的坑是上下文污染。典型场景编排者把数据Agent的完整中间结果原样丢给分析Agent分析Agent被大量无关的明细数据干扰判断力下降偶尔还会引用不属于自己的字段。我的习惯是给每个Agent定义一个“输入摘要规范”。上游传下来的消息先做摘要化只保留下游真正需要的字段。同时每个Agent的任务描述要做到“自包含”它拿到的消息里既要有足够的背景又不能有会干扰判断的冗余信息。这个度需要在实际测试里反复调没有一劳永逸的办法多跑几轮就能找到规律。还有一个容易被忽略的点Agent之间的消息格式一定要统一。如果数据Agent返回的是一个JSON数组分析Agent的系统提示词里就要明确写“输入是一个JSON数组”否则模型可能把数组当字符串处理造成一连串的格式错误。5.3 成本与延迟的账怎么算最后聊一下钱和时间。多智能体系统最大的成本风险在于“无谓的多轮调用”。编排逻辑写得宽泛、任务边界不清的时候Agent会反复调用工具确认同一个小问题Token和延迟都上去了。我常用的控制手段有三个。第一设置最大调用次数上限到达上限后强制模型基于已有信息作答不许再发起新调用。第二在编排层做任务预判能用程序直接判断的就不丢给模型比如日期范围、渠道ID合法性这类校验逻辑完全不需要模型参与。第三尽量复用工具结果同一个查询结果在缓存里放一段时间避免多个Agent重复查询同一份数据。延迟方面建议把可并行的子任务并行执行。比如数据Agent要查多个渠道的指标就一次性返回多个工具调用让程序并发执行再统一回填结果。很多模型服务支持一次响应里包含多个工具调用用起来能省掉一大半等待时间。我自己做下来最深的体会是多智能体和工具调用不是两个独立的技术点它们是一件事的里外两面。工具调用是地基地基不牢智能体再多也是花架子多智能体是结构结构不合理工具再强大也调度不起来。所以我的建议是先把工具设计和调用循环做稳确保每个工具拿出去单测、参数校验、容错都过关了再考虑拆分多Agent。顺序反了你会花大量时间在“到底是哪个Agent把数据搞错的”这种毫无意义的排查上。如果你也正在这个方向上踩坑不妨按这篇文章的骨架先跑一版最小实现再逐步加复杂度。
阅读完成 · 觉得有帮助？
