企业官网建设流程全解析

老读者都知道，我这人一向对“堆技术概念”这件事比较警惕。尤其是去年到今年，“多 Agent 系统”基本成了 AI 应用层的流量密码，好像不带几个 Agent 协作就没脸跟人打招呼。说实话，我自己也在这上面栽过跟头：最早做复杂任务拆分时，脑子一热上了 8 个 Agent 并行跑，结果上下文互相污染、Token 烧得飞快、输出结果乱七八糟，最后花了两天擦屁股。所以今天这篇，我就把自己折腾多 Agent 系统的真实经验拿出来聊聊，核心话题只有一个：协作拓扑怎么选，以及选完以后有哪些坑等着你。

这篇文章不会给你堆砌概念，也不会画一堆看起来很高级的架构图，而是直接讲四种我实测用过的协作拓扑，每一种都对应什么场景，选型依据是什么，并发配置怎么调，以及最常见的几个翻车现场。不管是正准备做 Agent 编排的工程师，还是已经被多 Agent 折腾得睡不着觉的算法同学，这篇文章都值得你花十分钟看完。不敢说让你少走全部弯路，但至少能帮你避开我踩过的那些大坑。

1. 四种协作拓扑详解：从排队干饭到三体人

多 Agent 系统说到底就干一件事：把一团大任务拆开，分给多个具有不同能力的 Agent 去执行。但“拆开之后怎么组织”这件事，直接决定了系统的高效还是崩溃。我在实践中接触到的协作拓扑，归纳下来就四种：链式、扇出/并行、路由/编排者、图式/网状。这四种各有各的脾气，用对了是利器，用错了是灾难。

1.1 链式拓扑：最直觉的流水线

链式拓扑的思路非常简单，就是把 Agent 一个接一个排成队，前一个 Agent 的输出，作为后一个 Agent 的输入，形成一条单向流水线。你可以在很多开源框架里看到它的影子，比如有些人把 LangChain 的 LangGraph 里的 Sequential 节点，或者一些工作流引擎的 pipeline 模式，本质都是链式。

这种拓扑最适合的任务，是那些本身就存在严格先后顺序、中间结果有明显层级关系的场景。举个我实际做过的例子：写技术周报。我先用 Agent A 去抓取这周的研发提交记录和会议纪要，然后把 A 整理出的素材交给 Agent B 去提炼成要点，最后再由 Agent C 把要点排版成正式周报格式。整个过程就是 A 到 B 到 C，每一步都依赖上一步的输出，完全没有回旋余地。

链式的好处很突出。第一，逻辑简单，可追踪性强，任何一个环节出错，你直接看是哪个 Agent 的输入输出出了问题就行，不需要全局排查。第二，上下文开销小，每个 Agent 只需要接收直接上游传来的信息，不需要了解全局，所以 Token 消耗是最低的。第三，开发速度快，你不需要设计复杂的调度逻辑，写几行代码串起来就完事。

但链式的短板同样致命。一是单点故障，任何一个 Agent 挂了，整个链路就断了，后面全部白干。二是延迟叠加，如果每个 Agent 要花 5 秒，三个串起来就是 15 秒，用户等得失去耐心。三是错误传导，前面 Agent 一旦输出错误信息，后面的 Agent 会把这个错误当事实继续加工，最后输出一个看起来很合理但完全跑偏的结果。应对办法后面我会专门讲，这里先记住一个结论：链式拓扑适合“短链路、强依赖、可接受延迟”的任务，一旦你的节点超过四五个，就要开始警惕了。

1.2 扇出/并行拓扑：把任务拆给一群人

扇出拓扑，也叫 Fan-out/Fan-in，核心是一个协调者把任务拆成 N 个子任务，分发给多个 Worker Agent 并行执行，再把所有结果聚合回来。这种模式非常适合“大批量、相互独立、结果可合并”的任务。

我做过的典型案例是批量竞品分析。比如要分析 10 家竞品的定价策略，如果用一个 Agent 挨个看，时间和 Token 都扛不住。我就用一个拆解 Agent 先生成 10 个独立的分析指令，然后同时启动 10 个 Worker Agent 分别去处理一个竞品，最后再用一个聚合 Agent 把 10 份报告汇总成一份横向对比。整个耗时从原来的串行 5 分钟降到了 1 分钟以内，效果非常明显。

扇出拓扑最大的优点就是并行度高、吞吐量大。而且因为各个子任务之间天然隔离，错误爆炸半径小，一个 Worker 出了问题，重跑那一个就行，其他 Worker 不受影响。

但这个拓扑有个容易被忽略的难点：拆解的质量。如果协调者没有一个清晰、不重叠、可执行的任务拆解能力，分给 Worker 的任务互相有交集，或者边界模糊，最后聚合的时候就会乱成一锅粥，甚至出现同一个事实两个 Agent 给出不同结论的情况。聚合这一步也是难点，多个结果合并时，如果各结果之间格式不一致或存在事实冲突，你很难让聚合 Agent 自动判断谁对谁错。所以我的经验是，用扇出拓扑之前，先想明白三件事：任务能不能拆成互不依赖的子任务？子任务的输出格式能不能强制统一？聚合阶段有没有人工兜底的机制？这三个问题只要有一个答不上来，扇出很可能就是灾难。

1.3 路由/编排者拓扑：一个聪明的调度大脑

路由拓扑，也叫编排者模式，是当前工业界最实用、最常见的一种多 Agent 组织方式。它的核心思路是有一个中央调度 Agent（也常被称为 Router、Orchestrator、Planner），它自己并不直接完成业务任务，而是负责“看菜下饭”：接收用户的输入，理解意图后，决定由哪个子 Agent 或哪条执行链路来处理。

这个模式特别适合那种“入口统一、场景多样”的业务系统。最典型的例子就是智能客服。用户进来可能问退款、查物流、开发票，你说让一个 Agent 全权负责，很容易因为知识库太杂而答非所问。更好的办法是：入口 Agent 先判断这是一个物流问题、支付问题还是售后问题，然后把它路由到对应的专项 Agent。每一个专项 Agent 的知识库和工具都是高度定制的，回答质量和效率都会高得多。

路由拓扑的好处是扩展性好。你每接入一个新的业务领域，只需要新增一个子 Agent，并在路由规则里加一个分支即可，不需要改动其他 Agent 的逻辑。同时，边界清晰，子 Agent 之间不需要互相感知，责任划分非常明确，出了问题可以直接定位到对应的 Agent。

但路由拓扑也并非没有代价。首先，中央编排者本身成了系统的单点和瓶颈。如果路由 Agent 死了，整个系统就瘫了。其次，路由判断一旦出错，任务就会被送到错误的 Agent 手里，轻则答非所问，重则引发连锁错误。我见过很多系统，子 Agent 本身做得不错，但路由准确率只有七成，整体体验立刻崩盘。所以路由拓扑对编排者的意图识别能力要求极高，而且必须设计兜底分支，当置信度低时要能退回人工或通用 Agent，而不是硬着头皮给个错误答案。

1.4 图式/网状拓扑：全连接的高成本自由

图式拓扑，也叫网状拓扑，是所有拓扑里最复杂也最“性感”的一种。在这种模式下，Agent 之间可以任意通信，可以自由协商，任务的分工和协作关系不是预先写死的，而是由 Agent 们在执行过程中动态规划出来的。你可以把它想象成彼得·帕克体内的那种能力，整个系统像是有三体人的感觉，彼此实时互通，共同演进。

一开始我对这种拓扑寄托了很大的幻想：让多个 Agent 像一群人开会一样自己去拆解问题、互相检查、迭代优化，岂不是能把复杂任务解决得很漂亮？后来实际试了一次我才明白，这种自由是要付出惨痛代价的。

图式拓扑首要的代价就是上下文爆炸。N 个 Agent 两两通信，意味着信息量呈指数级增长。你需要维护一个巨大的共享记忆池，每个 Agent 读取和写入时都会消耗大量 Token。我做过一个实验，用三个 Agent 做图式协作，每轮每个 Agent 都要同步全部对话历史，才跑了三个回合，Token 消耗已经让我肉疼了。

其次是调试地狱。链路是动态生成的，意味着你无法预测 Agent 们下一刻会走哪条路。系统出了问题，你想复现都难，因为你甚至说不清出错时 Agent 之间经历了什么对话。我后来翻 trace 日志翻了两个小时，才勉强定位到问题是 Agent B 误解了 Agent C 的消息。但这种定位能力，并不总是靠得住。

图式拓扑真正适合的，是那种没有固定方法论、需要探索和反复试探的问题，比如开放式的科学研究辅助、复杂的多目标优化。如果你做的是一个流程相对固定的业务系统，用图式拓扑纯粹是给自己找罪受。我的观点很明确：图式拓扑是存在适当时机的，但不是现在，不是大多数业务场景。大多数情况下，它是研究项目或炫技 Demo，离稳定可用的工程系统还差得很远。

2. 选型决策框架：什么项目该选什么拓扑

说完了四种拓扑的脾气，接下来就是最关键的问题：我怎么知道自己的项目该用哪一种？我见过不少团队，一上来就照抄网上的“SuperAgent”架构，弄一堆 Agent 满天飞，最后发现根本维护不住。其实选型没那么玄乎，你只需要问自己三个问题，答案基本就出来了。

2.1 三个关键问题：依赖、容错、成本

第一个问题，也是最核心的：任务之间的依赖是串行还是并行？如果业务本身的流程就是前后相继的，比如“先收集再分析再输出”，那链式拓扑就是天选。如果业务可以被拆成多个互不依赖的独立任务，比如“同时分析 10 份文档”，那扇出拓扑明显更合适。如果业务既有依赖分支又有并行节点，那你就考虑用一个编排者去动态组合，也就是路由/编排者拓扑。

第二个问题，出错时你能否接受部分失败？换句话说，你对“精确性”的要求有多高。链式和扇出都比较好做失败隔离，因为每一步的输入输出是可预期的，你可以在关键节点做校验。图式拓扑最难做容错，因为流程不是固定的，你没法定点校验每一步。如果你做的是医疗咨询、法务分析这类容错率极低的任务，我强烈劝你远离图式，老老实实用链式加人工审核。

第三个问题，你的资源和预算有多大？这里说的资源，不仅仅是钱，还包括时间。图式拓扑需要大量的调试时间和 Token 预算，链式和路由拓扑则相对省。你如果是一个小团队，预算有限，就不要在初始阶段追求“全自动智能体集群”，起步用最简单的模型，把成本压到最低再说。

2.2 复杂度由简到繁的原则

项目推进过程中，很多人容易犯一个毛病：想一步到位，一开始就设计一个“完美”的多 Agent 架构。我以前也这样，后来发现这是绝对的反模式。正确的做法是：先用最简结构把业务逻辑跑通，再根据瓶颈和痛点逐级升级拓扑。

具体来说，我提倡“由简到繁、按需升级”的路线。第一版，如果你判断业务的步骤是固定的，就用链式拓扑，甚至直接用单 Agent 加提示词模板，不要急着上多 Agent。跑一段时间，发现某个独立环节耗时太长，而且可以并行，就把这个环节拆出去做成扇出。再跑一段时间，发现用户的问题领域太分散，单一流程无法覆盖，那就加一个路由 Agent，按意图分流。你要是对 Agent 之间的动态配合有强烈需求，再考虑图式，而且要控制在一个很小的子任务范围内。

我给你打个比方。做多 Agent 系统就像创业开公司，你一开始肯定是一个人干所有事，等业务量大了你才招第一个员工，再忙不过来就招第二个，而不是一上来就搞一个几十人的大公司。贪大求全的结果，往往是系统复杂度失控，最后谁都不知道这个系统为什么会出问题。

2.3 架构演进的信号（什么时候该换拓扑）

什么时候需要考虑从一种拓扑切换到另一种拓扑？我总结了几个实际运维中会遇到的信号，你对照自己的系统看看有没有中招。

第一个信号是延迟超标。你发现某个环节的处理时间明显拖了整体后腿，而且这个环节的任务是相互独立的，这就是扇出/并行介入的信号。我优化竞品分析那一次，就是靠这个信号把整体耗时缩减了 80%。

第二个信号是某个环节经常被重复执行。比如链式拓扑里，Agent B 频繁因为输出不符合规范被要求重写。这说明 B 不是一个稳定的单节点，它的判断逻辑其实很复杂，需要再细分。这时候你可以考虑把 B 内部拆成一个小的路由拓扑，让 B 自己成为一个微型的多 Agent 系统。

第三个信号是上下文窗口频繁不够用。如果你发现每次调用的 prompt 都长到快要触及模型的上下文窗口上限，这说明你的链路太长或者信息太杂。解决办法不是单纯换更大的上下文窗口，而是要考虑拓扑级的信息过滤。比如增加一个专门的“上下文压缩”Agent，或者把长链路拆成多个短阶段，让每个 Agent 只负责处理聚焦的信息，从而缩短上下文长度。

3. 实操：agent 并发配置与工程化调参

拓扑选型定了，接下来的重头戏就是落地时的工程参数配置。这块网上说得比较零散，我结合自己的项目经验，把并发配置、超时重试、上下文管理、可观测性这四个维度一次性讲透。

3.1 并发配置的关键参数

多 Agent 系统的并发配置，本质上是一道资源规划题。你去调用模型服务的时候，上游通常有并发限制（比如每秒请求数或每分钟 Token 数），你的 Worker 并发数不是想开多大就开多大，而是要基于上游限制和任务特性来推算。

我常用的一个经验公式是：合理并发数 = 上游服务允许的最大并发请求数 × 0.8。留出 20% 的余量，是为了应对突发流量和重试导致的瞬时并发高峰。比如上游 QPS 限制是 20，那我一般把 Worker 并发设成 16。

在实际编码中，我会给并发池设定四个关键参数：max_concurrency（最大并发数）、queue_size（等待队列长度）、timeout（单次任务超时）、retry_times（失败重试次数）。下面这个 Python 伪代码片段是我近期的项目里的一个配置示例，你可以参考着改：

import asyncio from asyncio import Semaphore MAX_CONCURRENCY = 8 # 同时最多执行的子任务数 QUEUE_SIZE = 100 # 等待队列上限，超过则拒绝新任务 TASK_TIMEOUT = 30 # 单个子任务超时（秒） RETRY_TIMES = 3 # 单任务失败重试次数 semaphore = Semaphore(MAX_CONCURRENCY) async def run_worker(task): async with semaphore: for attempt in range(RETRY_TIMES): try: return await asyncio.wait_for(execute_agent(task), timeout=TASK_TIMEOUT) except asyncio.TimeoutError: logger.warning(f"task {task.id} timeout, retry {attempt + 1}") raise RuntimeError(f"task {task.id} failed after {RETRY_TIMES} retries")

注意，我这里用的是协程（asyncio），因为多 Agent 场景下主要瓶颈是等待模型 API 的 IO 响应，而不是 CPU 计算。你用多线程甚至多进程也能实现，但协程的资源开销最小。除了并发数，还要严格控制队列长度。实际项目中我见过有人把队列设为无限大，结果上游一抖动，积压了海量任务，全部在超时边缘反复重试，直接把整个系统拖垮。

3.2 超时与重试的工程化

聊到超时和重试，很多人的第一反应是“超时报错就重试呗”。但是重试有很多讲究，这里最容易踩坑的地方在于：不是所有的失败都适合重试。如果是上游模型因为过载返回 429 错误，那过一会儿重试通常是有效的，这叫瞬时故障。但如果是你的 prompt 根本设计有问题，导致模型每次返回相同的不合规结果，那你重试一百次也没用，纯属烧钱。

我的方法是分层超时与重试。第一层，单次 API 调用超时设置成 30 秒，超过 30 秒就当失败，触发指数退避重试。指数退避的策略是：第 1 次重试等待 2 秒，第 2 次等待2^2=4秒，第 3 次等待2^3=8秒，最多重试 3~5 次。这样做的好处是，上游短暂过载时，我们不会用高频重试把下游彻底打挂。第二层，整个任务级别超时，比如一个大任务总体不能超过 120 秒。这一层是兜底，防止某个子任务里的重试逻辑无限循环，最终把整个任务拖死。第三层，业务校验重试，当模型返回结果无法通过 JSON 格式校验或逻辑校验时，我们重新生成，但这个重试最多只做 1 次，因为大概率是 prompt 问题而不是随机错误。

另外，做重试机制时一定要注意幂等性设计。如果 Agent 在执行业务动作时不只是读数据，还会写数据（比如发邮件、建工单），那重试就可能导致重复执行多次，产生严重副作用。解决办法是给任务生成一个唯一次请求 ID，上游在处理请求时先检查这个 ID 是否已经处理过，处理过就直接返回旧结果，坚决不重复执行。这种幂等设计在真正的生产环境里是刚需，很多人一开始不做，等到线上出现重复工单就晚了。

3.3 上下文管理与 token 控制

我见过不少多 Agent 项目，功能和效果都跑通了，一看账单傻眼了：Token 消耗高到吓人。这里面的核心原因，就是上下文管理没做好。

多 Agent 系统最常见的 Token 浪费点有三个。第一，链式拓扑里，把上一轮 Agent 的完整对话历史直接传给下一个 Agent，历史越长消耗越离谱。第二，扇出拓扑里，每个 Worker 都把完整的任务背景和资料库内容拷贝一份带进上下文，导致同样的背景被重复读取 N 遍。第三，路由拓扑里，编排者为了做判断，把用户的所有历史记录全部塞给模型，但真正有用的可能只有最后一条消息。

我的应对策略是“二级压缩”。第一级，在把上游 Agent 的输出传给下游之前，用一个轻量级的总结 Agent 把信息压成结构化摘要。这个摘要只包含下游任务的必要信息，比如结论、置信度、关键数据，其余冗长的推理过程通通丢弃。第二级，设置全局 Token 预算。我给每个子任务分配一个 Token 上限，比如 8000 Token，用来放置 prompt 和输出。如果任务进行中 Token 快要用完，Agent 就要主动做“遗忘”操作，把最久远、最不重要的记忆从上下文里替换出去。

这里还有一个小技巧：模型调用时，尽量把temperature调低（比如 0.1），尤其在链式传递的环节，需要尽量减少随机性。你想想，如果每个 Agent 都有自己的一点“小个性”，那经过三层传递，错误就会像滚雪球一样被放大。

3.4 可观测性：多 Agent 系统调试的命脉

很多团队把多 Agent 系统做出来以后，最头痛的问题就是调试。传统单体程序出错有堆栈、有日志，多 Agent 系统呢？错误可能发生在任何一个 Agent，而且每个 Agent 的输入输出都是动态的，传统的日志系统根本不够用。

我强烈建议每一个 Agent 环节都记录标准化的结构化日志，至少包含以下字段：agent_id、task_id、span_id、parent_span_id、input_summary、output_summary、token_usage、latency_ms、status。有了这些字段，你才能像查链路追踪一样，把一个大的任务请求串起来，看到它经过了哪些 Agent，每个 Agent 花了多少时间和 Token，卡点在哪。

另外，定期抽样人工审查 Agent 的 prompt 和输出也非常重要。机器是不知道自己跑偏了的，你必须在早期就建立一套抽查机制，尤其在上线初期，最好每一个请求都留存 prompt 和 response，用人工判断模型输出是否符合预期。你说不定会发现很多模型自己根本意识不到的诡异逻辑，而这些发现往往是系统迭代方向的重要依据。

4. 踩坑清单与排查实录

最后这部分，是这篇文章最实战的部分。我把做多 Agent 系统以来踩过的最典型的坑整理了出来，每一个都附上排查思路，希望能给你省出大量时间。

4.1 典型踩坑场景（附排查思路）

坑一：上下文污染/错误传导。这是链式和图式拓扑最常出的问题。早期做一个信息提取项目，Agent A 在提取时漏了一个字段，Agent B 拿到缺字段的数据后没有报警，而是脑补了一个看似合理的值填了进去，最后 Agent C 拿着这个编造的值做分析，得出了一个完全错误的结论。排查过程用了很久，因为单看每一步的日志都好像没问题，直到把三个 Agent 的输入输出放一起对比，才发现数据是 A 开始就丢了。解决办法：在 A 和 B 之间加一道结构化校验，对必填字段进行强校验，缺了就抛错，绝不把不完整数据传给下游。

坑二：死循环。这是在图式拓扑里最容易遇到的。两个 Agent 因为对一个问题的理解不一致，互相发送澄清消息，你发给我一条“请解释”，我回你一条“请参考上文”，一来一回，日志刷了几百条，Token 烧了不知道多少，系统就是不往下走。后来我加了最大轮次限制和循环检测机制，任何一个 Agent 如果发现自己收到的上一条消息内容和若干轮之前完全一样，就自动停止。这个机制救了命，现在我的系统里任何图式子流程最多只允许跑 6 轮，超过就强制结束并交由人工处理。

坑三：把 Agent 数量当成性能指标。这是我见过最多的认知偏差。早期的项目，为了显得功能强大，硬塞了 12 个 Agent，结果系统响应慢、Token 费用高、错误率也居高不下。后来在一次重构里，砍掉了 6 个冗余 Agent，把剩下 6 个的职责重新划清，效果反而全面提升。这里我想强调一个铁律：多 Agent 的复杂度是呈指数级上升的，每增加一个 Agent，你的系统复杂度和调试成本都会翻倍。能用 3 个解决的事，坚决不用 4 个。

坑四：并行任务进度丢失。扇出拓扑最怕的不是某一个任务失败，而是失败后你不知道其他任务进行到哪一步了。有一次跑一个含 100 个子任务的批量分析，跑到一半个别任务因为上游限流失败，重试逻辑因为超时设置太短也失效了，最后 100 个任务里丢了 8 个，整个结果集少了一块。后来我给任务列表加了持久化队列，任务从分发到完成的状态都记录在数据库里，失败的任务可以重新入队，不再依赖内存状态，彻底解决丢任务的问题。

坑五：路由误判。路由 Agent 的准确率不可能是 100%，总会有一些用户输入模棱两可，它判断错了方向，导致任务被送到错误的 Agent 里。这个问题在客服机器人类系统里尤其致命。我吃过亏后，为路由加了一个“置信度阈值”机制：当路由 Agent 对意图的判断置信度低于 0.7 时，不直接路由，而是先抛给用户做二次确认，或者转交给一个兜底通用 Agent。这个机制虽然增加了一次交互，但整体体验明显提升。

4.2 多 Agent 并发配置常见问题速查表

鉴于并发配置是工程落地中最容易出现故障的环节，我把实操中最常见的故障和排查方案整理成一个速查表。

4.3 项目复盘：一次从“人海战术”到“精准编排”的经历

讲一个真实项目，也是我印象最深的一次多 Agent 架构重构。

最早做一个综合信息分析系统时，我的初始方案是：让 8 个 Agent 同时干活，有的负责抓新闻，有的负责提取产品信息，有的负责分析竞品，有的负责生成报告……听起来很震撼，实际跑起来简直是一场灾难。首先是上下文互相污染，每个 Agent 都从一个巨大的共享池里读数据，经常读到过期的、被其他 Agent 改错的内容；其次是 Token 消耗高得惊人，一个分析任务跑下来，光 Token 成本就要好几美元；更烦的是输出质量很不稳定，有的 Agent 给出的报告和另一个 Agent 的数据对不上，我整天忙着协调它们之间的矛盾。

后来我痛定思痛，把整个架构彻底推倒重来，按照本文说的方法重新设计。我先梳理了真实业务场景的依赖关系，发现实际上只有“采集、清洗、分析、成稿”四个核心环节，于是我把 8 个 Agent 砍成 4 个专项 Agent，让它们之间呈清晰的链式关系，然后在采集环节内部做了一个扇出并行，再在成稿之前加了一个路由判断，根据报告类型选择不同的输出模板。

重构之后的结果让我很震撼。Token 消耗比原来下降了 60%，任务完成率从 82% 升到 96%，平均处理时延从 45 秒降到 18 秒。最让我欣慰的是，系统不再是“薛定谔的稳定”，而是变成了一套随时可以预测、可以调试的工程系统。这次经历让我彻底明白了一个道理：多 Agent 系统的重点不是“多”，而是“准”，是把合适的任务、合适的上下文、合适的模型放到合适的拓扑里。

还有一个可以省的坑：如果你用的是各种开源框架，一定要先确认它对并发控制、超时设置、上下文压缩的支持程度。有的框架为了演示效果，默认配置很激进，盲目照搬就是送钱。

最后再分享一个我个人的小习惯。每做一个多 Agent 项目，我都会先画一张业务流程图，哪怕是在纸上随便画都行。图上的节点不是 Agent，而是任务步骤。画完之后，我再把这些节点自然组合，该串的串、该并的并、该加路由判断的加判断。先用业务角度思考，再用 Agent 角度实现，这条顺序一旦搞反，你的系统基本就埋下隐患了。

就我个人经验来说，多 Agent 系统真正考验人的，不是你会不会调用模型，而是你有没有足够强的工程能力去约束和控制这些智能体。拓扑选型、并发配置、超时重试、上下文管理、可观测性，每一块都是细节活。希望这篇文章能帮你把那些我趟过的坑提前避掉，把你的多 Agent 系统从“玩具”推向“工具”。