企业官网建设流程全解析

1. 先聊清楚：多Agent系统与Agent蜂群到底是什么

做 Harness Engineering 系列笔记做到第五篇，前面大部分篇幅都在解决一个基础问题：怎么让单个模型更可靠、更可控地完成一件事。但做着做着你会发现，单 Agent 的天花板非常明显，它不是模型智商不够，反而越往后用越容易卡在“一个人干了太多角色”这件事上。所以到了这一篇，我想把多 Agent 系统和 Agent 蜂群这个概念彻底掰开揉碎了聊一遍。

先给没接触过的读者一个直观画面。单 Agent 就像一个全能自由职业者，写方案、查资料、改代码、做测试全包，但人的精力有限，同一时间扮演太多角色容易顾此失彼。多 Agent 系统则像组建一个临时项目组，每个成员只负责一摊事，有人专门做调研，有人专门写稿，有人专门挑毛病。而 Agent 蜂群，就是把这个逻辑推向更“散”的形态，强调由大量轻量 Agent 各自行动、简单通信、局部协作，最终涌现出整体能力。

这篇文章我不会只讲概念，会重点聊三件事：为什么你要认真考虑这个架构、有哪些被验证过的协作范式、以及一个最小可落地的多 Agent 系统的完整实现。我还把实操中遇到的各种失控现场整理成了一节排查手册，能帮你少踩很多坑。不管你是在做文档助手、代码审查器还是行业报表生成器，只要开始接触 Agent 应用编排，这篇都值得收藏下来慢慢对照。

1.1 单Agent为什么越来越不够用

先说个不算严谨但非常贴切的比喻：你让同一个实习生既做财务审计又做前端设计，他一定会把报表里的数字写成十六进制颜色码。大模型也是这个逻辑。所谓 Agent 能力的塑造，很大程度取决于上下文里装了什么、工具列表里挂了什么、系统提示强调什么。当你把这些东西全部塞给同一个 Agent 时，会产生三个非常实际的副作用。

第一个副作用是角色冲突。调研任务要求冷静客观、海量收集；写作任务要求风格鲜明、有立场；审查任务要求苛刻挑剔、专找毛病。这三类要求在同一个上下文里互相干扰，导致 Agent 找不到重心。我实测过的结果是，让一个 Agent 同时做“先调研再写报告再自查”，它写出来的东西往往比“调研 Agent 写完、审查 Agent 再改”少一个维度——少了那种真正的批判性审视，因为模型在同一个会话里很难既当作者又当严苛编辑。

第二个副作用是工具膨胀。给 Agent 挂的工具越多，它做工具选择的错误率就越高。你给它挂了搜索、数据库查询、代码执行、PDF解析、邮件发送，它会在一件事没做完时突然决定“发封邮件问问XX”，然后整个流程就跑偏。多 Agent 最直接的价值之一，就是让每个 Agent 的工具盒保持小而精。

第三个副作用是上下文损耗。一个 Agent 处理 20 轮对话后，历史里可能堆了 5 万 token 的中间信息，其中一半早就没用了。它要在这些信息里找最近的一条指令，就像在你堆满杂物的桌面找一把钥匙，找得到但慢，而且容易抓错。过去我们靠压缩、抽取摘要来补救，但本质上是治标不治本。让多个 Agent 各干一段、只传递必要结果，才是更接近人类的协作方式。

所以多 Agent 系统解决的从来不是“模型不够聪明”，而是“组织方式出了问题”。它更像是把一个人能干的活拆成多个专业角色，通过协作来完成更大、更复杂的任务。

1.2 “蜂群”不是玄学，是规模化协作的工程选择

Agent 蜂群这个称呼，最早容易让人联想到科幻片里的机器人大军。但工程语境下的蜂群，本质上指的是大量自治 Agent 通过简单的局部规则交互，替代一个中心化超强 Agent。这个概念脱胎于群体智能，像蚁群找最短路径、蜂群选址筑巢，单个个体能力很弱，群体行为却很聪明。

不过在真实系统里，我不建议一上来就追求“几百个 Agent 满天飞”。大部分业务场景 3 到 8 个 Agent 就能覆盖，蜂群式设计真正有价值的不是数量，而是两个工程特质：一是职责单一化，每个 Agent 只会一个技能，技能边界像模块接口一样清晰；二是去中心化协作，Agent 之间不存在一个事无巨细都要管的总指挥，而是通过消息、任务板或竞标机制自行协调。

把蜂群思维落到实际上，你会发现它对系统设计提出了全新的要求。传统程序调用是确定性的，A 调 B，B 返回，流程写死。多 Agent 协作却是概率性的，Agent A 发出去的消息，Agent B 理解成什么样，取决于模型当时的推理状态。这就意味着你要为“理解偏差”设计冗余和纠错机制。我见过很多失败的蜂群项目，不是模型不行，而是工程层还在用单 Agent 的思维，结果消息满天飞、上下文互相污染，最后产出一堆不靠谱的内容。

这一节想让大家建立的核心认知是：多 Agent 是一种 Harness，也就是模型之外的这层“外骨骼”；蜂群则是一种更极端的 Harness 形态。理解了这层，后面聊编排模式、通信机制、任务分配，你才知道每个设计到底在解决哪个具体问题。

2. 蜂群系统的顶层设计：编排模式、通信机制与任务分配

多 Agent 系统的架构选择，说到底是三种能力的平衡：可控性、扩展性和资源效率。你想让蜂群按规划干活，还是让蜂群自己涌现出行为？这两种思路直接决定了后续所有技术选型。在确定技术方案之前，先想清楚你的组织模式，因为组织模式错了，后面用什么框架都别扭。

2.1 中心化编排：好用，但别让它变成瓶颈

中心化编排是最常见也最容易想到的形态，核心就是有一个 Planner / Orchestrator 角色，它负责接收用户任务、拆解成子任务、分发给各个专业 Agent，收集结果后再汇总输出。就像项目组里的项目经理，需求他来拆，任务他来派，验收他来把关。

这种模式的优点显而易见：流程可控、逻辑清晰、每个环节出了错都好回溯。我最早做的多 Agent Demo 就是这种结构，一个 Orchestrator 加上三个 Worker，调试起来非常舒服。你只需要在编排器里记录每个子任务的派发时间、被哪个 Agent 接收了、返回了什么内容，全程有据可查。对于绝大多数企业级应用，中心化编排是首选，因为业务方要求的是稳定和可预期，而不是混沌中的涌现。

但中心化编排有一个隐患：编排器本身可能会变成新的瓶颈。它有两大负担，一是所有消息都要经它转发，规模大了就成了信鸽中心，吞吐量上不去；二是拆解任务的质量上限完全取决于编排器模型的理解能力，它拆不明白，整个系统就跟着跑偏。

在实际项目中，我对中心化编排做了两个补强。第一，编排器只做任务拆分和结果聚合，不直接参与执行，避免它上下文过载。第二，为编排器配一份明确的“任务拆分规范”，要求它输出 JSON 字段，包含task_id、dependencies、expected_output，从格式上逼着它把任务想清楚。

2.2 去中心化协商：蜂群味道最浓，也最难伺候

如果你确实想让蜂群自己涌现行为，例如几十个 Agent 并行处理一批商品评论、每个评论 Agent 自主决定下一步是追问还是归档，那中心化编排就力不从心了。这时候需要用去中心化协商模式。

去中心化并不是完全没有管理节点，而是把决策权下沉到每个 Agent。常见的实现方式是任务竞标：任务发布到公共队列，Agent 根据自己的技能和能力决定是否“认领”，认领成功后由该 Agent 独立完成。这很像自由市场里的接单平台，需求方不用指定谁来做，有能力的人自然会来。

这种模式最大的好处是扩展性好，新增一个 Agent 等于往市场里注入一个新的劳动力，系统无需改写任何调度逻辑。但代价是行为不确定性显著增加。两个 Agent 可能同时认领同一任务，造成重复劳动；也可能所有 Agent 都认为自己不适合，任务在队列里无人问津。

去中心化协商适合任务量大、任务边界清晰、单个任务独立性强、失败容忍度高的场景。例如把 10 万封工单按类型打标，如果某几条处理错了，影响范围可控。而如果你做的是金融报告生成，我强烈不建议去中心化，因为失控的代价实在太高。

2.3 通信协议选型：别让Agent们鸡同鸭讲

无论中心化还是去中心化，Agent 之间总要通信。通信设计是蜂群工程里最容易被低估的一环，很多人拿 prompt 字符串直接传来传去，传着传着就乱了。

我的建议是：不管内部用不用现成框架，消息一定要结构化。我习惯定义一种极简的消息格式，核心字段就 4 个：from、to、task_id、payload。payload里再区分content（正文内容）和meta（元信息，比如时间戳、置信度、来源）。这套格式看着简单，但它做了三件重要的事：一是让每条消息有了归属，方便审计；二是让消息能被路由识别，不至于发到所有 Agent 那里造成轰炸；三是给上下文化的裁剪提供了抓手，你可以按 task_id 精准召回某一段对话记录。

通信模式上，我偏好“黑板上”加“直邮”的组合。黑板是一个共享工作区，所有 Agent 可以把阶段性结果发布上去，比如调研 Agent 把资料摘要更新到黑板，写作 Agent 直接拉取最新版；直邮用于点对点的指令传递，比如编排器明确指示审查 Agent 去检查某个报告。这种组合既避免了全量广播的混乱，又保留了信息共享的效率。

如果你用现成的大模型工具协议，也建议再做一层自己的封装，确保消息在进入模型上下文时经过剪裁和去重。我见过不少系统，一股脑把黑板上所有内容全塞给每个 Agent，结果上下文窗口被共享信息塞满，真正有用的专业指令反而被挤掉了。

3. 一次可落地的实操：从零搭一个最小蜂群式多Agent系统

说了这么多理论，是时候上一个能跑的例子了。接下来我会带着你从零实现一个迷你多 Agent 系统，场景是“生成一份行业趋势调研报告”。我会故意把它拆成蜂群形态：一个编排器、一个调研 Agent、一个写作 Agent、一个审查 Agent。任务链路是编排器拆解需求，调研 Agent 产出资料包，写作 Agent 基于资料包写初稿，审查 Agent 对初稿提意见并返回，如果有修改意见则回到写作 Agent 循环一次。

这个例子很小，但足够覆盖任务拆解、消息传递、结果回收、循环控制、终止条件等核心逻辑。掌握之后，你完全可以把它扩展到更多角色和更复杂的场景里。

3.1 架构与目录设计

先看整体文件布局，我习惯把逻辑分层，方便后续扩展：

swarm_demo/ ├── agents/ │ ├── __init__.py │ ├── base_agent.py # Agent 基类，定义调用接口 │ ├── researcher.py # 调研 Agent │ ├── writer.py # 写作 Agent │ └── reviewer.py # 审查 Agent ├── core/ │ ├── orchestrator.py # 编排器 │ ├── message.py # 消息结构 │ ├── blackboard.py # 共享黑板 │ └── llm_client.py # 大模型调用封装 ├── tasks/ │ └── task_schema.py # 任务拆分的 JSON Schema 定义 └── main.py # 入口演示

为什么要把 Agent 和核心逻辑分开？因为 Agent 本质上是被 prompt 和工具配置“调教”出来的角色，而编排、消息、黑板这些基础设施是复用的。这样分，以后新增一个 Agent 只需要在agents目录下加一个文件，不会污染底层逻辑。

3.2 Agent 角色的定义与参数配置

每个 Agent 我建议用统一的配置结构来定义，至少包含四样东西：角色名称、系统提示词、可用工具列表、模型参数。以调研 Agent 为例，它的核心配置是这样：

RESEARCHER_CONFIG = { "name": "researcher", "system_prompt": """ 你是行业调研员。你的任务是根据给定主题，收集并整理关键信息。 限制： 1. 只输出结构化的事实条目，不要抒发观点。 2. 每条信息必须注明来源或依据。 3. 输出格式为JSON数组，字段包括title, summary, source。 """, "tools": ["web_search", "fetch_url"], "temperature": 0.2, "max_tokens": 2000, }

有几个细节值得注意。第一，系统提示词里明确写了“输出必须是 JSON 数组”，这不是可有可无的要求，而是为了让下游写作 Agent 方便读取，减少解析错误。第二，调研 Agent 的温度我调得比较低（0.2），因为调研任务要的是准确、稳定，不需要创造性。第三，工具列表只挂了搜索和抓取，避免它分心去干别的。

反观写作 Agent，温度就会高一点（0.7），系统提示词里会强调“基于输入的资料包撰写，观点鲜明，结构清晰”，工具列表为空。审查 Agent 的温度再调低，提示词里专门写“寻找逻辑漏洞、事实矛盾、表述模糊问题，逐条列出修改建议”。

这里有一个我反复强调的原则：Agent 的个性和能力边界是在配置阶段定死的，而不是靠对话中临时要求。一旦角色临时出现“你再帮我查个数据”这种跨越边界的请求，正确的做法是让它回到编排器请求调度，而不是自己上手。

3.3 消息结构与黑板实现

在核心代码里，消息用一个 dataclass 表示：

@dataclass class AgentMessage: msg_id: str task_id: str sender: str recipient: str # 可以是具体 agent 名，也可以是 "blackboard" content: dict timestamp: float def to_prompt_block(self): # 进入模型上下文前，把消息渲染成一段可读文本 return f"来自 {self.sender} 的消息:\n{json.dumps(self.content, ensure_ascii=False)}"

to_prompt_block这个方法很关键。它统一了消息进入不同 Agent 上下文时的格式。建议所有发往模型的消息都经过这个方法，不要在业务代码里用 f-string 直接拼消息，否则后续想加日志、加裁剪逻辑时会非常痛苦。

黑板的实现则非常简单，本质上就是一个带锁的字典，提供publish和read两个方法：

class Blackboard: def __init__(self): self._store = {} self._lock = threading.Lock() def publish(self, task_id: str, agent_name: str, content: dict): with self._lock: self._store[task_id] = { "agent": agent_name, "content": content, "updated_at": time.time() } def read(self, task_id: str): with self._lock: return self._store.get(task_id)

你可能会问，为什么用这么简单的字典而不是上 Redis？因为最小系统里，单机单进程就够用了。我自己搭过好几版，发现过度设计是入门者最容易犯的错。等真正有分布式需求时，再去换成消息队列或 Redis Stream 都不晚，接口设计成 publish/read，迁移成本也很低。

3.4 编排器的完整实现逻辑

编排器是整个蜂群的中心，它维护一个任务状态机。每个子任务会有pending、running、done、failed四种状态。核心流程如下：

class Orchestrator: def __init__(self, llm_client, blackboard): self.llm = llm_client self.blackboard = blackboard self.agents = {} def register_agent(self, agent): self.agents[agent.name] = agent def run(self, user_request: str) -> str: # 1. 任务拆解 plan = self.llm.decompose_task(user_request) # plan 是 JSON，包含 main_goal, subtasks[], final_deliverable # 2. 按依赖顺序执行 results = {} for sub in plan["subtasks"]: agent_name = sub["assigned_to"] agent = self.agents[agent_name] # 3. 构造上下文 context = self._build_context(sub, results) # 4. 调用 Agent output = agent.run(context) # 5. 写黑板 self.blackboard.publish(sub["task_id"], agent_name, output) results[sub["task_id"]] = output # 6. 审查-修正循环 for _ in range(MAX_REVISION_ROUNDS): review = self.agents["reviewer"].run( {"draft": results["draft"], "task": user_request} ) if review.get("passed"): break results["draft"] = self.agents["writer"].run( {"draft": results["draft"], "review": review} ) # 7. 汇总最终报告 return self.agents["compiler"].run({"inputs": results})

这个版本我已经把很多细节简化掉了，但核心骨架是对的。有两点压力测试的经验分享给大家。第一，任务拆解结果一定要做格式校验，decompose_task返回的 JSON 如果缺字段，后面全部会崩。我在任务 Schema 里加了严格校验，失败的默认行为是“不继续执行、直接向用户要更明确的需求”，而不是瞎猜。第二，审查循环必须有最大轮数限制，给MAX_REVISION_ROUNDS赋一个值，比如 3。没有这个限制，一个死循环可以让你的成本和延迟直接爆炸，后面实战排查部分我会再展开。

3.5 运行与效果观察

把上面这些模块组装起来跑一次，输出大体长这样：

[orchestrator] 收到任务：生成一份关于边缘计算在工业场景应用的调研报告 [orchestrator] 拆解出 4 个子任务： 1. 调研行业市场规模与增速 -> researcher 2. 调研典型应用案例与厂商动态 -> researcher 3. 基于资料撰写报告初稿 -> writer 4. 审查报告并给出修改意见 -> reviewer [researcher] 完成 2 个调研任务，共发布 18 条结构化信息到黑板 [writer] 基于黑板数据生成 2600 字初稿 [reviewer] 发现 3 处事实依据不足，2 处结构问题，返回修改意见 [writer] 按意见完成第 1 轮修改 [reviewer] 通过审查，报告定稿

第一次跑通这个流程的体验非常奇妙，因为你会明显感觉到“团队感”出现了：调研 Agent 写得严谨干燥，写作 Agent 文风活泛，审查 Agent 一针见血。它们组合在一起，产出的报告质量，比我让单个 Agent 直接写要高出不少。这个现象背后有一个值得深思的原因：任务拆分让每个 Agent 面对的上下文负担大大下降，它只需要在“简单问题”上做到最好，自然比在“复杂问题”上一通操作更可靠。

4. 蜂群失控的五个征兆与排查手记

理论说再好，实操才是检验标准。我前后做了好几个多 Agent 项目，坦白讲，没有哪个是一次跑通的。下面这些坑我几乎全踩过，我把它们整理成了一份“失控征兆与排查对照”，希望能帮你节省至少一周的调试时间。

4.1 上下文爆炸：每个Agent都在背全量历史

蜂群系统最常见的失控方式，是上下文占用呈乘法级增长。假设你有 5 个 Agent，每个 Agent 每轮对话产生 2000 token，编排器来回调度 3 轮，那么总 token 消耗不是 5 乘以 2000 再乘以 3，而是要算上每轮消息被复制到多个 Agent 上下文里的扩散效应。如果代码写得粗心，比如每次循环都把所有 Agent 的历史消息全量塞给下一个 Agent，token 消耗会直接起飞。

我的排查心得是：给每个 Agent 入参之前加一个 context 审查函数，打印出这段上下文由哪些部分构成、各占多少 token。审查几次之后，你自然会做出三个优化：消息只传给需要它的 Agent；历史消息默认做截断，只保留最近 N 轮；大段调研资料在进入写作 Agent 之前先让调研 Agent 自己浓缩成摘要。

这个优化不是可有可无的。我做过一次对比，未优化前生成一份 3000 字报告消耗约 9 万 token，优化后降到 3 万以内。对生产环境来说，这个差距直接决定了项目能不能盈利。

4.2 循环依赖与“改不完的稿子”

多 Agent 系统容易出现一种特殊的死循环：审查 Agent 总能在文章里找到新问题，写作 Agent 改完之后，审查 Agent 又提出一个新问题。本质上是两个 Agent 的评判标准不一致，或者审查 Agent 的提示词里没有“基于原始任务目标来判断”的全局约束。

解决这个问题，我用了三层办法。第一层是硬性控制：最大修订轮数，到了就停止并保留当前版本，不再追求完美。第二层是给审查 Agent 增加“修改清单必须有优先级排序，且只列出会实质性影响交付价值的问题”这样的约束，避免它为了找问题而找问题。第三层是给写作 Agent 增加“对于未通过审查的版本，如果你认为某条意见与原始目标冲突，可以在交付说明中反驳”的权限。

这三层下来，循环明显减少。我统计过，未加约束前平均要改 4 到 5 轮，加完约束后大多在第 2 轮就可以收敛。

4.3 成本失控：蜂群省的是效果，不是钱

很多人以为上了多 Agent 就能降低成本，这是个常见的误解。单 Agent 干一件事可能只要 3 万 token，多 Agent 协作干同一件事可能要 8 万甚至更多，因为消息来回传递本身就有开销。多 Agent 的价值从来不是省钱，而是在同样甚至略高的成本下换取更高质量的产出。

如果成本是敏感项，有几个实测有效的控制手段。第一，给每个 Agent 都配上 token 配额，超了就拒绝执行。第二，优先使用“轻量模型跑量大、重型模型做关键思考”的混合策略，比如调研 Agent 用快速模型也够了，审查 Agent 用更强的模型。第三，所有中间结果都做好缓存，相同任务不要重复调用模型，这个在批量生产场景尤其重要。

4.4 可观测性缺失：不知道谁说了什么、为什么

单 Agent 调试起来很简单，看输入输出就行。多 Agent 系统是一条复杂的信息链路，一条消息从编排器出发，经过调研 Agent、黑板、写作 Agent，最后到审查 Agent。如果中间任何一个环节出了理解偏差，你很难靠猜来定位。

所以从第一天起就要把日志做好。我不管项目多小，都会给每条消息带上trace_id和msg_id。trace_id关联一次完整任务，msg_id定位单条消息。日志里固定输出四个字段：时间、发送方、接收方、消息类型。这样排查问题时，只需要按trace_id过滤，就能拼出整张流程图。

另外，我强烈建议把每次调用的输入和输出都落盘，尤其是失败时的输入。没有这些快照，你根本没法复现问题。我在团队内部有个不成文的规定：任何 Agent 报错，第一件事不是查代码，而是翻出它当时看到的上下文。

4.5 评估困难：蜂群到底变好了没有

如果你无法度量系统改进前后的差异，那所有优化都是在碰运气。多 Agent 系统比单 Agent 难评估，难就难在“最终产出质量”只是结果的一部分，协作过程中的高效性也值得关注。

我的做法是建一个三层评估表，每次跑完系统都打分。第一层是最终交付物质量，用客观项打分，比如结构完整性、事实准确度、表达流畅度，每一项 1 到 5 分。第二层是协作效率，统计平均修订轮数、任务耗时、token 利用率。第三层是异常频次，记录上下文溢出次数、死循环次数、解析失败次数。几轮优化后横向对比这三层数据，哪些改动有效，一目了然。

下面是我整理的一个速查表，基本涵盖多 Agent 系统最常见的几种故障和排查方向：

4.6 一个容易忽略的坑：小模型做编排器可能扛不住

编排器要理解全局，还要做任务拆解，这个角色对模型能力的要求往往被低估。我早期贪便宜，用快速轻量模型当编排器，结果拆出来的子任务经常缺斤短两，比如把“既要数据又要有案例”拆成只有数据调研，导致后面写作 Agent 缺素材。

后来我总结出一个判断标准：如果任务拆解后，子任务之间还需要复杂的互相依赖说明，那就说明编排器模型不够强，拆得不到位。真正高质量的任务拆分，子任务之间的边界应该是清晰的，逻辑上基本是并列或简单串行。用这个标准去评测你的编排器，比看单个测试用例准确得多。

5. 什么场景千万别碰多Agent

我写这么多方案，不是想让你觉得多 Agent 是万能的。实际上在我的项目里，真正采用多 Agent 架构的可能不到四成。剩下六成需求，用单 Agent 加工具循环、或者简单的工作流脚本，反而更快更稳。所以这最后一节我想泼点冷水，聊聊哪些场景不要硬上蜂群。

5.1 先做复杂度收益评估，再决定要不要上

我在决定是否采用多 Agent 时会问自己一个问题：把任务拆给多个角色，到底是降低了每个角色的复杂度，还是引入了一套新的协作复杂度？如果原本的单 Agent 只需要三步就能完成，拆成三个 Agent 后，光是编排调度和消息格式处理就要多写几百行代码，那这就是负优化。

一个更具体的判断标准是看失败率。如果你用单 Agent 直接跑，成功率已经有 85% 以上，先别急着上蜂群。先把那些 15% 的失败案例归类，如果原因是“上下文太长记不住”或“角色要求互相冲突”，多 Agent 才有意义；如果只是单纯某一步模型理解错了，那调整提示词或换更强模型，成本低得多。

我从实际经验里总结了一个“该上多 Agent 的信号清单”：

• 任务可以被拆成 3 个以上边界清晰、可并行或串行执行的子任务
• 不同子任务需要明显不同的专业背景和输出格式
• 单 Agent 因为上下文超载或角色冲突，质量已经无法通过调提示词提升
• 你愿意为更稳定的产出投入额外的 token 成本和开发时间

如果四条里少于两条，老老实实写单 Agent 就好。没有必要为了“技术新潮”而在博客里整活，生产环境里稳定压倒一切。

5.2 轻量替代方案：路由Agent加工具循环

有时候我们需要的其实不是一群 Agent，而是一个聪明的“路由”加上几个专用的处理模块。单 Agent 可以通过一个工具选择循环实现类似多角色的效果：模型先判断当前任务属于“调研”“写作”还是“审查”，然后调用对应的工具或提示模板。这种方式没有消息传递、没有编排器，代码简单很多，出问题也好修。

这个方案的原理是，当你要处理的子任务之间没有太多协作依赖时，路由单 Agent 就够了。比如用户在公司官网问“退货流程是什么”，你只需要一个能判断意图并调用退货流程文档的 Agent，不需要调研 Agent 和写作 Agent 一起上。很多客服型场景都是这种，看似复杂，实际上是单点查询。

我自己的经验是：把“多 Agent”当作一种可插拔的 Harness 方案，而不是架构的默认选项。从单 Agent 开始，当它确实承载不了的时候再升级，升级时也优先做局部替代，比如只把其中某一个“角色”拆出去，而不是一次性拆成七八个。脑子和代码一样，重构最怕一步到位。

说到最后，我想分享一个这个系列里反复体认到的观点：多 Agent 系统真正考验的不是模型的能力，而是你把任务拆得够不够干净、消息传得够不够精准、循环控制得够不够严。蜂群之所以有生命力，不是因为“人多力量大”，而是因为每个 Agent 都真正专注地做好了一件事。我在实际操作中最大的体会是，少即是多——Agent 的数量宁缺毋滥，协作的边界宁清晰不要灵活，循环的保险丝宁保守不要激进。这套准则让我从第一版蜂群的失控状态，慢慢走到了后面几版的可控状态，希望你也能在动手前，先把这些边界想明白。下一次我会继续沿着 Harness Engineering 这条线，聊聊蜂群之上的评测体系如何设计，到时候我们再见。