多Agent系统与Agent蜂群：架构、编排与实战排查

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 调 BB 返回流程写死。多 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_asciiFalse)}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 的历史消息全量塞给下一个 Agenttoken 消耗会直接起飞。我的排查心得是给每个 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 系统最常见的几种故障和排查方向故障现象可能原因排查动作任务一直不结束审查-修改循环无终止检查最大循环次数检查审查 Agent 是否持续提出新问题输出内容质量下降Agent 上下文塞入无关信息检查入参上下文构造逻辑按需裁剪某个 Agent 永远不出结果等待前置任务结果但依赖未满足检查黑板 key 的读写是否一致检查依赖关系是否被正确解析token 成本飙升消息被全量复制到多个 Agent加日志统计每条消息被消费的次数两个 Agent 各说各话任务定义没对齐或术语不统一在共享黑板上加一份术语表和任务字典结果格式反复报错对模型输出的格式约束不够硬改为强制 JSON 输出并做 schema 校验失败则重试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 这条线聊聊蜂群之上的评测体系如何设计到时候我们再见。