企业官网建设流程全解析

最近和我一个做工程化的朋友聊到AI应用落地，他说了句很扎心的话：“单Agent跑Demo炫得飞起，一放到真实业务里就拉胯。”这句话我深有体会。单个大模型Agent确实能搞定不少问题，可一旦任务涉及多个角色、多步骤推理、还要操纵一堆外部工具时，单Agent的上下文窗口、Token成本、推理稳定性都会变成瓶颈。于是“多智能体系统与工具调用”就成了当下AI工程化绕不开的话题。

这篇文章我就用自己的实践经验，聊聊多智能体系统到底怎么设计、工具调用在其中扮演什么角色、以及从零搭一个最小可用的多Agent系统会遇到哪些问题。我尽量不讲虚的，用能复现的代码和踩坑记录来说话，目标读者是正在做Agent应用、想从单Agent往多Agent迁移的开发者朋友。如果你是刚开始接触大模型应用，我保证把关键概念讲得通俗一点，你照着抄也能跑起来。

1. 为什么需要多智能体系统：单Agent的边界与破局思路

很多人的第一反应是：既然一个模型能写代码、能查资料、能做分析，为什么一定要拆成好几个Agent？这个问题问到点子上了。先弄清楚单Agent到底卡在哪，才能理解多Agent存在的意义。

1.1 单Agent单打独斗的局限

单Agent的本质是“一个模型实例、一个上下文窗口、一套系统提示”，所有推理和动作都在这一条链路上完成。短任务是没问题的，比如“帮我把这句话翻译成英文”“总结这篇文档”，但一旦任务链条变长，问题就冒出来了。

我举个真实例子。你让一个Agent去“分析某产品的用户反馈数据，找出差评主要原因，并生成一份周报”。它需要先读取数据文件、理解数据结构，再调用统计工具做聚合分析，然后根据结果写结论，最后把周报保存成文档。这一套流程放到单Agent下，会经历几个坎：

第一，上下文会被“污染”。中间步骤的原始数据、工具返回的大段结果都会堆进同一个上下文，前期的有效信息会被后面的噪声冲淡。模型往往顾此失彼，前面好不容易确定的分析口径，到生成报告时早就忘了。

第二，推理会“精神分裂”。一个Agent既要懂业务，又要懂数据分析，还要会写报告，角色混在一个提示词里，模型很难在不同能力之间做干净切换。我实际测试过，单Agent在这种场景下经常把分析结论和执行动作混在一起，该用工具的时候不动手，该输出最终结果的时候反而乱调用。

第三，改一处要动全身。业务方说“报告格式调整一下”，你改提示词可能影响分析逻辑；要让Agent使用新工具，又担心它在别的环节乱触发。单Agent的耦合度太高，工程维护成本随时间急剧上升。

用一个生活化类比来说，单Agent就像一个人既是项目经理、又是开发、又是测试、又是运维，小项目能扛，项目一复杂，光是自己跟自己的沟通就能乱成一锅粥。多智能体就是打破这种大锅饭：把项目拆给不同角色，每个角色只负责自己那一摊，再有一个协调者把它们串起来。

1.2 多智能体系统的核心优势

多智能体系统的核心思路，是把一个复杂任务按角色、技能或职责拆给多个Agent，每个Agent拥有独立的上下文、独立的目标和独立的系统提示。它要解决的核心问题有三个：分工、协作和状态隔离。

先说分工。每个Agent只关心自己领域的输入输出，比如数据分析Agent只负责看数据、算指标，它不需要知道报告要用什么格式；写报告Agent只接收分析结果，不需要理解底层数据长什么样。角色边界清晰之后，模型在单点上的表现反而会因为“专注”而更好。

再说协作。Agent之间通过消息传递、共享状态、任务队列等方式协同。复杂任务通常由一个协调者Agent统一调度，谁先做、谁后做、结果往哪传，由协调者和管理者设计好的流程共同决定，而不是靠模型自由发挥。

最后是状态隔离。这是最容易被忽视的优势。多个工具调用的中间结果会被隔离在各自Agent的上下文里，不会互相污染。比如计算Agent算错一步，不会影响数据分析Agent的结论；报告Agent没写好，也不用从头重跑一遍全流程。

1.3 什么场景真正适合上多智能体，什么场景反而没必要

多智能体不是银弹，我一向建议大家“先判断，再动手”。根据我自己的经验，可以把场景分成两类：

适合上多Agent的场景，通常具备这些特征：任务需要多种不同技能，比如数据处理、外部检索、代码执行、人工审核；流程有天然阶段，可以拆成先后依赖的环节；需要不同Agent各自保留独立上下文才能避免信息干扰；以及团队需要审计每一环的中间结果，多Agent能把步骤分成可追踪的单元。

不适合的场景也很明确：简单问答、单一工具调用、任务链条短、上下文本身很小。这些都让单Agent处理就足够，强行拆出多Agent只会增加延迟、成本，还凭空多出一堆通信故障。

判断标准其实很简单：如果单Agent在你设定的上下文窗口和预算内能稳定完成任务，就别拆；如果试了三次都因为上下文太长、逻辑混乱、工具误用而崩掉，再考虑多智能体。我之前做过一个内部工具，开始图新鲜上了三个Agent，结果多Agent的协调开销比任务本身还重，最后退回单Agent加了几个工具，又快又稳。

2. 工具调用的本质：给Agent装上手和眼睛

说完了多智能体的必要性，再来说体系里最底层的能力：工具调用。在这个领域里有一个共识，没有工具调用，Agent就是一台只会打字的复读机；有了工具调用，它才能真正“做事”。

2.1 从“只会说”到“会做事”

大语言模型本身的接口是“文本进、文本出”。它能给你一个建议，告诉你“应该调用某个系统去查数据”，但它自己没法真正执行这个动作。要跨越从“建议”到“执行”的鸿沟，我们依赖的机制就是工具调用（有时也叫函数调用、Function Calling）。

工具调用的工作方式可以用一句大白话概括：模型基于现有对话生成一个“调用指令”，指令里包含工具名和参数，宿主程序拿到指令后执行对应函数，再把函数的执行结果作为新消息送回上下文。模型看到结果后继续推理，决定下一步动作。整个过程像大脑指挥手脚：大脑不亲自去搬砖，但它发出指令，手脚动作完再把结果汇报给大脑。

举一个最常见的例子：给Agent注册一个“天气查询”工具，模型面对用户“杭州今天能出门跑步吗”的问题时，会先调用工具拿到天气数据，再基于数据给出建议。没有工具调用时，模型只能根据训练数据瞎编一个天气；有了工具调用，它的回答就有了真实的感知依据。

2.2 工具调用的几种主流实现

现在主流的工具调用实现主要有三种形态，我按实践中的常见程度排个序：

Function Calling是最主流、最稳定的方案。模型在预训练和后续对齐中专门学习了一种结构化输出格式，会在需要时输出一段JSON，包含工具名称和参数字典。宿主程序用JSON解析就能拿到调用意图。它的好处是稳定性高、参数错误率低、便于权限控制。

ReAct模式则不太依赖模型原生支持。它通过在提示词里引导模型“思考→行动→观察”循环，让模型以文本形式输出Thought和Action，宿主程序解析行动内容再执行。好就好在不挑模型，但文本解析容易出错，稳定性稍差。

MCP这类工具协议方案则是在生态层面解决“工具互不通用”的问题。它把各种外部资源和服务封装成统一接口，让不同Agent都能通过同一种协议调用。适合大团队、多服务、多Agent复用同一批工具的场景，但引入成本偏高。

对于大多数项目，我从实践中得到的建议是：优先用Function Calling来承载关键路径，用ReAct做兜底，只有在工具数量庞大、团队协作复杂时才考虑统一协议层。三种方式的对比参考下表：

2.3 工具调用在多智能体里的骨架作用

在单Agent场景里，工具调用是为了“完成一件事”，工具相对孤立。但在多智能体系统里，工具调用承担的其实是“骨架”作用。

多个Agent之间靠消息通信，但Agent本身没手没脚，它们对世界的感知和改变都通过工具完成。数据分析Agent要查数据，靠工具；计算Agent要算数值，靠工具；执行Agent要写文件，还是要靠工具。没了工具调用，多Agent就成了几个“各说各话”的聊天机器人，谁也没法真正推进任务。

我在实际设计中会把工具调用分成两类：一类是“感知型工具”，比如检索、查询、读取文件，用来帮Agent获取信息；另一类是“行动型工具”，比如写文件、发消息、生成订单、触发任务流。两者权限必须分开。一个助理Agent可以同时拥有两类工具，但一个只负责分析的Agent，我通常不给它任何行动型工具，防止它在推理偏差时对外部系统造成不可控影响。

另外，工具调用的日志是整个多Agent系统最宝贵的审计信息。每次谁来调用了哪个工具、传入什么参数、返回什么结果，都应该有完整记录。我在排查系统故障时，十次里有九次是靠工具调用日志定位到具体环节，而不是靠猜模型的“想法”。

3. 多智能体框架选型与核心设计

确认了需要多Agent，又理解了工具调用的地位，接下来就要面对一个很实际的问题：自己写调度代码，还是用现成框架？我先说结论：新手建议从自研一个最小调度器开始，理解原理后再看框架，这样遇到问题时才有足够的掌控力。

3.1 三种框架选型路线

我接触过的多智能体实现路线大致有三类，各有各的脾气。

第一类是“图状编排”风格的框架。它把Agent当成图里的节点，把任务流转条件当成边，通过显式定义好的图结构来控制流程。优点是流程清晰、可控性高、每一步都有迹可循；缺点是复杂流程写起来繁琐，流程一变就要改图结构。

第二类是“群聊协作”风格的框架。多个Agent在一个共享对话环境里互相发送消息，协调者Agent负责引导讨论方向。优点是自由度极高，适合头脑风暴、开放协作类任务；缺点是容易失控，Agent经常在群里聊跑偏，调试起来比较头疼。

第三类是我最推荐的“自研轻量调度器”。它只用一个循环加一个简单的状态机：调度器根据当前状态决定交给哪个Agent，Agent拿到任务后调用工具、返回结果，调度器更新状态。优点是完全掌控逻辑、没有任何框架包袱、出了问题一眼能看穿；缺点是功能要自己做，但多Agent的核心功能其实没有想象中那么复杂。

我并不是反对框架。当项目复杂度上到一定程度，团队大、流程多、需要可视化和运维功能时，图状编排的框架能省不少事。但我坚持认为，不要一上来就套框架，先用自研方案把一个Demo跑通，清楚每一步的意图，框架选型和二次开发才谈得上有依据。

3.2 核心模块拆解

不管用什么路线，多Agent系统都离不开几个核心模块，它们直接决定整个系统的稳定性和扩展性。

规划器是大脑。它的职责是根据当前任务和已完成状态，决定下一步动作是哪一类、该交给哪个Agent执行。最简单的规划器是一张硬编码的流程表，复杂一点的是另一个Agent动态做计划。我的建议是：能用硬编码流程解决的，就不要用动态规划，动态规划虽然炫酷，但出问题的概率也是指数级上升。

执行器是手脚。它负责真正调用工具、把结果格式化为标准消息投入上下文。执行器必须做好异常捕获和超时控制，否则一个工具卡住，整个Agent流程都会卡死。

工具注册表是仓库。它统一管理所有工具的名称、参数字段、返回值结构和权限范围。注册表存在的意义在于：每个Agent只能看到自己被授权的那部分工具，从而减少模型误选工具的概率。我见过最典型的翻车现场，就是所有Agent共享一份全量工具清单，结果负责写总结的Agent突然调用了删除接口。

记忆与状态组件是档案室。它管理每个Agent的独立上下文、以及多个Agent之间需要共享的状态信息。共享记忆我用一个简单的“黑板”结构：任何Agent都可以往黑板上写数据，但谁才能读、读到哪一层，必须提前规划清楚，否则就又回到上下文污染的坑里了。

3.3 一个最小可落地的架构示例

下面我用一段简化Python代码展示核心结构，不依赖任何第三方框架，只依赖模型接口的抽象。生产环境里你需要把call_llm()替换成真实模型调用，其他逻辑可以直接套用。

# 工具注册表 TOOLS = {} def register_tool(func): TOOLS[func.__name__] = func return func @register_tool def get_weather(city: str) -> str: # 实际项目这里会请求天气API return f"{city} 今天晴，气温 22℃" @register_tool def add_numbers(a: float, b: float) -> float: return a + b # Agent定义 class Agent: def __init__(self, name, prompt, tools): self.name = name self.prompt = prompt self.tools = {name: TOOLS[name] for name in tools} # 模型调用抽象：生产环境替换为真实API def call_llm(messages, available_tools): # 这里演示简单逻辑：遇到“天气”字样就返回工具调用 content = messages[-1]["content"] if "天气" in content: return { "type": "tool_call", "tool": "get_weather", "args": {"city": "杭州"}, } if "相加" in content: return { "type": "tool_call", "tool": "add_numbers", "args": {"a": 1, "b": 2}, } return {"type": "final", "content": "任务已完成"} # 调度循环 def run_agent(agent, task): messages = [ {"role": "system", "content": agent.prompt}, {"role": "user", "content": task}, ] for step in range(MAX_STEPS): # 1) 模型基于上下文生成下一步意图 msg = call_llm(messages, agent.tools) # 2) 模型认为任务完成，退出 if msg["type"] == "final": return msg["content"] # 3) 解析工具调用并执行 tool_name = msg["tool"] args = msg["args"] result = TOOLS[tool_name](**args) # 4) 把工具结果加入上下文 messages.append({ "role": "tool", "name": tool_name, "content": str(result), }) return "达到最大步数，任务未完成"

这段代码虽然简单，但包含了多Agent调度最关键的三件事：上下文用消息列表累积、工具调用用结构化JSON表示、执行结果回灌上下文。你把它跑通以后，再去看那些开源框架，会发现自己已经在用它们的核心思维了。工业化要做的事只是把call_llm()换成真实模型、给工具调用加上参数校验和重试、并给调度器加上状态持久化。

3.4 通信协议：Agent之间怎么说话

多Agent系统里最容易被忽视、又最容易出问题的，是Agent之间的“语言”。如果让两个Agent直接用大段自然语言互怼，当初拆分Agent省下的上下文空间又会被聊天记录吞回去。我建议用结构化消息来控制通信，消息类型至少包括这些：

任务派发消息负责描述“要做什么、约束是什么”。结果回传消息负责携带最终结果和必要状态。信息请求消息用于一个Agent向另一个Agent要补充信息。状态更新消息则用于进度同步，方便协调者掌握全局。

一个典型的结构化消息长这样：

{ "msg_type": "task_dispatch", "from": "coordinator", "to": "data_analyst_agent", "task_id": "20240516_001", "payload": { "action": "analyze_feedback", "data": "feedback_data_0506.csv", "requirements": "输出差评主要原因TOP3" } }

好处很明显：coordinator和data_analyst_agent是固定角色标识，程序就能可靠路由；动作和参数是结构化字段，Analysis Agent不必“理解”一段话再去猜任务，而是精准地执行；再加上固定格式，后续如果要记录审计日志、做断点续跑、接入其他系统，都方便得多。一句话总结：Agent之间能说人话，但最好只在“人机审查界面”说，内部通信一定要结构化。

4. 实操：搭建一个“分析+计算+执行”的三Agent演示系统

讲了一堆原理，我直接上实操。下面这个演示系统我用过很多次，非常适合对多Agent系统做概念验证。它由三个Agent和一个协调者组成，对应一个典型的业务分析流程。

4.1 系统需求与角色设计

场景是这样：用户提供一个业务问题，系统需要经历“读取数据结构、分析数据、计算关键指标、把结论写入最终文件”这四个步骤。

协调者负责接收用户任务，按固定流程拆解子任务，依次派发给对应Agent并接收结果。数据分析Agent负责查看数据字段，并基于字段结构给出初步分析建议，它只拥有查看类的工具。计算Agent负责执行数值运算，把模糊的分析建议变成精确的数字结论。执行Agent负责把最终结论保存为文档，它额外拥有写文件工具。

角色和工具之间的对应关系我用一张权限表管理：

权限隔离在这里不是形式主义。写文件动作如果暴露给数据分析Agent，模型可能在“观察到可疑数据”时直接生成文件，这显然是严重越权。我见过生产事故的起点，就是这种小细节。

4.2 工具注册与权限控制实现

我直接给出可运行的代码。为了照顾没有模型API key的朋友，call_with_tools()这段用了规则逻辑模拟模型的工具调用意图，你在真实项目里替换成模型接口即可。

# 模拟数据文件结构 SAMPLE_STRUCTURE = { "user_feedback.csv": ["用户ID", "反馈内容", "反馈时间", "评分"], "order_records.csv": ["订单号", "金额", "城市", "商品类目"], } # 最大迭代步数：防止死循环 MAX_STEPS = 10 # 工具一：查看数据字段 @register_tool def list_fields(source: str) -> str: keys = list(SAMPLE_STRUCTURE.keys()) if source not in SAMPLE_STRUCTURE: return f"无效数据源，可选：{keys}" return ",".join(SAMPLE_STRUCTURE[source]) # 工具二：计算 @register_tool def calculate(expression: str) -> str: # 生产环境这里要做表达式校验，不能直接eval用户输入 try: # 这里只用四则运算，实际项目建议用解析器库 result = eval(expression, {"__builtins__": {}}, {}) return f"计算结果：{float(result):.2f}" except Exception as e: return f"计算失败：{str(e)}" # 工具三：写报告 @register_tool def write_report(filename: str, content: str) -> str: with open(filename, "w", encoding="utf-8") as f: f.write(content) return f"已写入文件 {filename}" # 三个Agent实例 analyst = Agent( name="analyst", prompt="你负责分析数据源结构，只允许查看字段，不负责计算。", tools=["list_fields"], ) calculator = Agent( name="calculator", prompt="你负责根据分析结论进行精确计算，输出数字结果。", tools=["calculate"], ) writer = Agent( name="writer", prompt="你负责把最终结论整理成报告并写入文件。", tools=["write_report"], )

这里structure和eval只为演示，生产环境一定要用AST解析等安全方案，直接eval用户字符串是高风险动作，绝不能当成默认操作。

4.3 调度器编排逻辑

需要说明的一点是，这三个Agent在主流程里是顺序执行，我用“协调者”作为编排核心。真实的调度器应该像下面这样，具备清晰的阶段转移：

def main(): task = "分析用户反馈数据字段，计算差评率，并生成一份结论报告" # 第一阶段：分析师查看字段 analysis_prompt = f"{task}，第一步请先查看 user_feedback.csv 的字段结构" fields_result = run_agent(analyst, analysis_prompt) # 第二阶段：计算Agent基于分析结果做计算 calc_prompt = ( f"根据数据字段，计算评分为1分和2分的记录占总记录数的比例。" f"数据结构说明：{fields_result}" ) calc_result = run_agent(calculator, calc_prompt) # 第三阶段：执行Agent写报告 report_content = f"分析结论：{calc_result}" run_agent(writer, f"请将以下内容写入 report.md：{report_content}") print("流程完成，报告路径：report.md") if __name__ == "__main__": main()

这段代码展示的流程虽然简单，但三个阶段各自上下文隔离，中间产物不混在一起。如果某一步报错，我们很容易定位到是哪一段逻辑出了问题。实际系统中，我会在这个顺序流程之上加一个循环：当计算结果不满足预期时，协调者可以自动把结果打回给计算Agent重新算，最多重试三次。

4.4 运行结果与效果观察

运行上面这段代码，你会看到分析Agent先返回字段列表，计算Agent算出比例，执行Agent生成文件。整个过程看起来平淡，但“平淡”本身就是多Agent系统设计成功的标志：每一步都明确、可预期、可审计。作为观察者，我建议记录三件事：

第一，每一步的输出和Token消耗。要在真实模型接入时监控每个Agent占用的Token，我见过不少项目在数据分析Agent上省了Token，结果计算Agent因缺少上下文反复重试，总成本反而暴涨。第二，每个Agent的响应时间。多Agent天然增加延迟，如果某一步工具调用极慢，你需要考虑并行化改造。第三，中间状态的流转是否符合预设。如果计算Agent擅自决定不调用工具直接胡编结果，或者分析Agent突然产生“写文件”的意图，调度器要能拦截并告警。

5. 常见问题与排查技巧实录

多Agent系统最劝退人的，就是问题发生时你根本不知道锅在哪：是模型变蠢了？是工具没写好？还是调度逻辑有Bug？我把自己踩过的高频问题整理成一份避坑清单，分五类讲透。

5.1 Agent陷入死循环

最常见的问题就是Agent反复调用同一个工具、传同一批参数，像被困在时间循环里。根本原因是模型没有意识到“工具结果已经拿到，可以继续下一步了”，流于重复动作。

解决办法有几层：第一层在调度器层面加MAX_STEPS上限，这是最后兜底；第二层在系统提示里写明“如果工具返回结果与上次一致，无需重复调用”；第三层在代码里做工具结果去重，检测到连续两次相同调用时，直接跳过执行并提示模型“结果无变化，请推进到下一动作”。三者配合，基本可以消灭可见的死循环。

5.2 工具调用失败后的处理策略

工具调用失败难以避免。参数格式错误、外部接口超时、权限不足……我见过的最糟糕处理方式是“遇到异常直接终止整个任务”，实际上模型完全有能力自己修正。

正确做法是把失败信息放回上下文，让模型根据错误信息调整参数或换方案，但要加一个重试次数上限。示例逻辑如下：

def safe_tool_call(tool_name, args, error_messages, max_retry=2): for attempt in range(max_retry): try: return TOOLS[tool_name](**args) except Exception as e: error_messages.append(f"第{attempt + 1}次调用失败：{str(e)}") return f"连续{max_retry}次失败，请更换工具或终止"

这里还有一个坑：工具返回的错误信息对模型来说也是上下文，我建议把错误格式化得结构化一些，比如返回“{{"error_code": 400, "message": "缺少参数city"}}”比返回一大段堆栈有用得多。

5.3 上下文太长与记忆丢失

多Agent一样会遇到上下文限制，尤其是当工具返回结果又大又杂时。比如一份数据分析工具返回了五千行明细，模型还没开始思考，上下文窗口就快满了。

我的实操经验是“两板斧”：一是给每个工具的输出加截断策略，比如只返回前100条记录和统计摘要，明细单独落到文件让Agent按需读取；二是给跨Agent共享的“黑板”结构加摘要责任，每个Agent在往黑板上写内容时，同时写一版压缩摘要，其他Agent默认读摘要，只有需要细究时才去读全量。这个模式我们在项目里反复验证过，稳定得很。

5.4 多个Agent互相推诿或职责重叠

多Agent并不是天然边界清晰。在一些自由度较高的协作式编排里，两个Agent都可能认为自己该负责“生成最终结论”，于是结果出现重复；或者都认为该由对方去做工具调用，结果任务卡在中间。

解决的思路藏在任务分解协议里：协调者派发任务时必须在消息里给出明确的验收标准与责任人，不能只说“分析一下这个数据”，要说“由data_analyst_agent分析数据源字段，并输出一个包含字段清单和初步建议的结构化JSON”。同时，我还会在调度器里加一个“裁决函数”，当两个Agent都返回最终结果时，以协调者的预定义顺序为准。一旦后续流程出现错误，裁决日志能告诉我们到底是哪个Agent给的结论导致的问题。

5.5 排查工具箱：日志、追踪与Token统计

排查效率取决于你留给系统的“痕迹”够不够多。我总结的排查工具箱有三件套：

第一件，流转日志。保留每一条Agent消息、每次工具调用的入参和出参，用统一格式打印到日志或数据库。排查死循环时，按时间倒序看调用链即可。第二件，Trace链路。给一次完整任务分配一个TraceID，所有Agent消息、工具调用、状态变更都带同一个ID，这样才能把散落的日志串成完整故事。第三件，Token消耗明细。记录每个Agent每轮调用的输入输出Token。我见过很多项目因为“某个工具返回太长”导致成本翻倍，没有明细根本发现不了。

这三件套缺一个，排查问题都要靠猜。靠猜是工程师最痛苦的工作方式，多Agent系统尤其不能猜。

6. 实操心得与扩展方向

写到这里，技术与避坑都聊得差不多了，最后收几个我自己的体会和扩展建议。

6.1 我踩过的几次“大坑”总结

第一次是大而全地堆工具。早期做多Agent，我恨不得把所有API都注册成工具让模型自由选择，结果是模型经常在简单问题上选到错误工具，反而是“每条Agent只授权两三个工具”之后，准确率明显上升。工具选择也是选择，可选集越大，出错的概率越高。

第二次是太迷信框架。用了一个开源的群聊式框架做原型，模型好几个Agent在群里聊得热火朝天，但任务却迟迟收不了尾。后来我把流程改为调度器硬编排，效率反而大幅提升。自由协作看着聪明，工程上却需要极强的约束机制，没有足够经验前慎用。

第三次是没有给工具层做超时保护。一个外部检索工具偶尔卡住，整个调度流程就整体卡死，看起来像Agent变笨了，实际是底层工具拖垮了全局。所有工具都要包上超时和异常兜底，这是进来就要守的纪律。

6.2 复用与扩展方向

如果你已经跑通了一个最小多Agent系统，后续扩展方向我个人比较推荐这几个：把流程配置化，用一份JSON描述每个Agent的角色、权限和协作顺序，这样增减节点不用改代码；引入人机协同，在关键执行动作前设计人工审核节点，比如写报告前先由人确认结论；构建回归评估集，把一批历史任务存起来，每次改动调度器后统一跑一遍，防止修了A问题又弄坏了B环节。

我在实际使用中发现，多Agent系统真正考验人的不是模型能力，而是工程化功底。任务拆解得是否干净、工具权限是否合理、上下文管理是否高效，决定了这个系统能跑多久。奉劝各位一句话：不要为了“多Agent”而多Agent，如果单Agent加几个工具能解决，那它就是最优雅的方案；如果确实需要多Agent，从本文这个最小演示系统开始，把它跑扎实，再往复杂的方向演进。等你把调度器、工具注册表和日志体系都跑顺了，那些大而重的框架在你眼里也不过是一套配置化的实现而已。