你试过把一个大任务直接丢给单个智能体结果它先是自信满满地拆了一堆子任务然后卡在中间某一步循环道歉最后给你吐出一篇前后矛盾的长文吗如果你正在折腾 Agent大概率撞过这堵墙。单智能体在复杂、多步骤、需要多类专业知识协作的真实任务面前上下文窗口、工具过载和角色混乱很快就会把它压垮。“agency-agents” 这个概念说白了就是把一个 AI 智能体团队当作一家数字“代理机构”来运营有负责拆单、派单、验收的“主管”有各自只干一行、只握一组工具的“执行专员”有兜底纠错的“质检员”彼此之间通过明确的协议沟通、共享有限度的记忆。它不是某个特定产品而是一套多智能体设计范式帮你在业务场景里搭出真正能接住复杂任务的 Agent 团队。这篇文章适合已经被单个 Agent 坑过、准备往多智能体方向走的开发者或者正在纠结“智能体团队到底怎么分工”的产品与技术负责人。我会把这套“机构化”设计的拆解思路、最小可运行的实战代码、以及我在落地过程中踩过的坑一次性讲清楚。1. 多智能体协作到底在解决什么1.1 单智能体的四个天花板先说为什么一个“全能型”Agent 不够用。模型本身的参数量很大但放到具体任务系统里它依然有四个绕不开的硬约束第一个是上下文窗口。所有主流模型的上下文都有限制。你在一个 Agent 里既塞系统提示词、背景资料、用户原始需求又塞它调回来的网页正文、数据库日志、工具返回结果很快窗口就满了。模型只能“记得”前面的内容模糊化处理开始选择性失忆输出质量断崖式下跌。第二个是工具过载。单个 Agent 上挂的工具越多模型每次决定调用哪个工具的出错概率就越高。实测下来超过 15 个工具时模型经常会把“查天气”的工具用在“查汇率”的请求上。工具之间参数格式类似更容易互相串味。第三个是职责冲突。一个 Agent 既要做市场分析又要写营销文案还要画配图、设计落地页。用户需求稍微拐个弯它自己都不知道当前该以什么身份干活输出风格来回摇摆内容前后打架。第四个是收益不透明。单个 Agent 很难对“分解出来的子任务”做独立验证。它拆完任务自己干完自己验收既是运动员又是裁判。中间任何一步错了只要最终回答听着通顺错误就悄悄溜过去了。所以场景越具体、流程越固定、角色分工越明确的活儿越不适合塞给一个全才 Agent 大包大揽。把“一个全才”拆成“一个管理者 几个专才”正是 agency-agents 这套范式的起点。1.2 把“公司机构”映射成 Agent 架构“agency”这个词的妙处在于它天然带着层级、分工和流程的隐喻。你可以把一个多智能体系统想象成一家小型内容创意公司管理层负责接收客户需求拆解成可执行的项目包分派给对应团队最后回收成果并做质量验收。执行层每个团队只负责一个领域。文案团队只写文案设计团队只做图片数据分析团队只跑报表。每个团队内部甚至连“找资料”和“写初稿”都可能是两个不同的 Agent。支持层提供检索、计算、存储等底层能力。这些能力以工具的形式挂在对应的执行 Agent 上而不是堆在一个人身上。这种结构的核心好处有两个。第一责任边界清晰。任务出错时你可以顺着流程查到是“哪个角色”出了问题定位效率高得多。第二上下文专注。每个 Agent 只需要维护跟自身角色相关的少量上下文次级结果写回共享区后就可以清空窗口利用率大幅提升。从一个“大杂烩 Agent”切换到一整套“机构式多智能体”不是把任务扔给更多的 Agent 就完事而是要把任务本身当成一个项目来管理定义角色、规划流程、设定协议、执行验收。架构上的变化本质上是“把对话系统改造成流程系统”。1.3 集中式编排和对等协商两种模式多智能体协作大体上有两条路线我在项目里都试过各自适用面很不一样。集中式编排Orchestrator-Worker是主流方案。一个中央调度者负责拆任务、指派、回收、汇总工人节点之间不直接对话。这个模式优点是好控制、好排查、好做权限管理缺点是中央节点容易成为瓶颈而且调度者本身的质量上限决定了整个系统的上限。对等协商Peer-to-Peer则是所有 Agent 地位平等通过消息总线互相通信谁有空谁接活遇到分歧开会讨论。好处是灵活、能应对高度动态的需求坏处是极易陷入死循环或“礼貌性争吵”——两个 Agent 互相确认理解就是不动手干正事。没有强流程约束的对等协商在真实业务里基本不可控。我个人的建议是绝大部分业务场景用“集中式为主、有限对等为辅”的混合制。主管 Agent 负责拆单派单执行 Agent 之间如果需要临时沟通比如文案需要数据分析结果必须通过主管转发或经过共享记忆区不搞点对点的自由私聊。这样才能在工程上控制复杂度。2. 核心组件与角色设计2.1 角色定义三要素职责边界、能力声明、沟通协议一个执行 Agent 的角色配置我建议至少包含三块内容。第一块是职责边界。明确“你负责什么不负责什么”。这是一个很重要的约束。比如负责资料检索的 Agent配置里要写明“只负责搜索、筛选、汇总信息不负责撰写最终结论”否则它会忍不住顺手帮你把整篇文章写了导致主管拿到的产出物跟预期完全对不上。第二块是能力声明。列出这个 Agent 可以调用的工具清单以及每个工具的功能、参数、适用场景。更重要的是要写明“什么时候不该用这个工具”。比如一个翻译 Agent 挂了词典工具能力声明里就得说明“仅当遇到专有名词或不确定术语时使用日常语句无需查询”。这能显著减少无效工具调用。第三块是沟通协议。规定这个 Agent 以什么数据结构向外部输出成果、向谁汇报、遇到异常时怎么上报。例如约定所有执行 Agent 一律输出带有statussuccess/error/needs_review和summary字段的结构化结果。这样主管 Agent 的后续流程就好写了不需要每次从自然语言里猜执行结果。2.2 控制层的路由与调度逻辑路由是主管 Agent 的核心动作。它决定了一个用户请求应该交给哪个或哪几个执行 Agent 处理。在机构式架构里路由逻辑我觉得可以分为三个层次。第一层叫意图识别判断用户想要什么类型的产出是写一篇文章、查一批数据、生成一组图还是组合型需求。第二层叫资源匹配把意图映射到具体的 Agent 角色上找到具备对应能力和工具的那个执行者。第三层叫任务拆分对于组合型需求把它拆成多个子任务排好执行顺序和依赖关系。工程上我不建议完全靠模型的自由发挥来做路由。更稳的做法是“规则优先 模型兜底”能通过关键词、用户选择菜单等规则确定的就直接走固定流程规则命中不了的再由主管 Agent 根据角色声明做一次语义判断。这样可以兼顾确定性和灵活性。路由结果务必写入日志至少得清楚每个用户请求最终流向了哪个执行角色。2.3 共享记忆与上下文隔离分寸怎么拿捏多智能体系统里记忆设计是最容易走极端的部分。一端是全局共享所有对话记录结果每个 Agent 都被无关上下文淹没另一端是完全隔离每个 Agent 只从主管手里接一次任务做完了就忘了导致后续 Agent 拿不到前面做好的中间成果。我实践中稳定跑通的方案是“三层记忆架构”。第一层是全局状态区存放任务 ID、用户需求原文、最终产出物等高度抽象的信息。主管 Agent 负责写入和更新所有 Agent 可以只读。这一层信息密度必须高只存“结论”不是“过程”。第二层是工作记忆区存放当前任务拆解出来的子任务列表、状态、执行结果摘要。子任务 Agent 在工作期间可以读写自己的任务卡片但任务结束后详细过程要清除只保留摘要回流给主管。第三层是长期知识区用向量库或结构化文档存放沉淀下来的经验比如“用户偏好的文档风格”、“上轮项目的坑点总结”。这一层不是每次任务都加载只有主管判定相关时才检索注入。我见过不少失败的尝试都是把第二层和第三层混在一起所有 Agent 共享全部历史。结果就是第一个 Agent 吐出的一堆网页正文被第二个 Agent 当成输入继续加工上下文快速膨胀成本飙升质量还更差了。记忆设计的原则很简单需要知道的给不需要知道的坚决不给。2.4 工具注册与权限控制工具在多智能体系统里比在单 Agent 里更需要规范化管理。单个 Agent 挂少量专属工具的收益远大于所有 Agent 共享一大把通用工具。我给每个工具做注册表时固定包含这些字段工具名、说明、参数 schema、适用角色、调用成本、幂等性标识。权限控制也要做成“按角色隔离”。写文案的 Agent 原则上不配访问数据库的权限即使它声称“看一眼数据能写得更好”。这不是不信任模型而是为了安全和稳定。工具越少Agent 越容易做出正确的调用决策出错了也更好追责。工具调用的参数约束也很关键。凡是能用枚举值限定的参数就别让模型自由发挥字符串。比如一个“导出报表格式”参数你写清楚只允许填pdf或csv模型基本不会错你要是放任自由填它今天填PDF明天填pdf格式后天填一个漂亮的PDF文件下游解析直接崩溃。3. 实操从零搭一个最小可运行的 agency-agents 系统3.1 环境与框架选型市面上已经有一些多智能体编排框架比如通用型的 Agent 工作流库或偏向流程编排的工具。不过对于学习或小型业务我建议先自己动手写一个薄薄的调度壳把核心机制理解透回头再用框架会顺手很多。语言上选 Python版本 3.10 及以上。模型调用层我建议做一层抽象不直接绑定某个具体厂商的 SDK而是统一封装成一个函数。这样你换模型、换服务商都只需要改一个文件。基本目录结构是这样的agency_agents/ ├── main.py # 入口读取输入并启动主管 Agent ├── agents/ │ ├── base.py # Agent 基类包含 run/respond 等公共逻辑 │ ├── supervisor.py # 主管 Agent负责拆单派单汇总 │ ├── researcher.py # 资料检索 Agent │ └── writer.py # 文案撰写 Agent ├── memory/ │ ├── global_state.py # 全局状态区 │ └── task_card.py # 工作记忆区任务卡片模型 ├── tools/ │ └── registry.py # 工具注册表 └── config.yaml # 角色配置、模型参数、日志开关我实际跑通这套结构用的是 SQLite 存状态、纯 Python 写的调度循环、没有引入重量级中间件。组件少出问题就少适合先验证流程。3.2 先定义好最小的一组角色主管、研究员、写手角色定义我用 YAML 管理不用代码硬编码。这样调整提示词、修改工具列表时不用重新发布代码。supervisor: name: 主管 description: 负责拆解用户任务、分派给合适的执行 Agent、汇总最终答案 tools: [task_decompose, agent_dispatch, quality_check] researcher: name: 研究员 description: 负责搜索和整理资料输出结构化的事实清单不撰写最终文案 tools: [web_search, content_fetch] output_schema: fact_list writer: name: 写手 description: 负责根据研究员的资料和主管的指令撰写文案不做外部检索 tools: [style_check] output_schema: article_draft值得注意的一个细节是角色描述里的“不做什么”比“做什么”更重要。研究员明确“不撰写最终文案”写手明确“不做外部检索”可以避免两个 Agent 互相越权干活产生一堆冗余中间产物。3.3 实现任务分发与结果聚合主管 Agent 的路由循环要处理的核心逻辑可以用伪代码表示这个结构是一个多智能体系统的骨架。def run_supervisor(user_request: str, registry: AgentRegistry): # 1. 把全局状态初始化成一个新任务 task create_task(user_request) # 2. 主管拆解任务得到子任务列表 subtasks decompose(task, registry.supervisor_prompt()) # 3. 按顺序或按依赖执行每个子任务 for subtask in subtasks: agent registry.match_agent(subtask.agent_role) result agent.execute(subtask, shared_memorytask.memory) task.update(subtask.id, result) if result.status error: # 错误处理先重试一次仍然失败就上报给主管做降级方案 retry_result agent.execute(subtask, retryTrue) if retry_result.status error: task.flag_blocked(subtask.id) break # 4. 汇总所有子任务结果生成最终答复 return aggregate(task)这个循环看起来简单但有几个细节值得展开说。任务拆解那一步我建议让主管 Agent 以 JSON 格式输出子任务列表每个子任务包含id、role、description、depends_on、expected_output字段。依赖关系的设计在后面章节会详细展开。如果主管输出的 JSON 不合法就直接让它重新生成一次不要试图用正则去修正。结果汇总那一步因为每个执行 Agent 的输出格式已经在角色配置里约定了结构化 schema所以主管拿到的不是一团自然语言而是包含状态和数据对象的任务卡片。它只需要把卡片内容调整成用户可读的答案不需要重新理解所有细节。3.4 运行验证与日志追踪一个多智能体系统如果不带日志调试起来像在摸黑走路。我的最低要求是每个子任务执行完都往 SQLite 里写一条记录至少包含任务 ID、子任务 ID、Agent 角色、开始时间、结束时间、token 用量、状态、产出物摘要。这些字段足够你复盘大多数问题。log_sql INSERT INTO task_log ( task_id, subtask_id, agent_role, status, started_at, ended_at, prompt_tokens, output_summary ) VALUES (?, ?, ?, ?, ?, ?, ?, ?) 日志要定期查别等到系统崩了才想起来看。我在实践里通常先让系统跑 10 到 20 个模拟任务拉出日志看几个关键指标每个 Agent 的平均耗时、失败率、token 消耗分布、主管拆出子任务数量是否合理。这些数据会告诉你瓶颈在哪个角色而不是靠感觉拍脑袋优化。3.5 参数与配置的细节选择几个我反复调过的参数直接给经验值但它们都需要根据你的模型和场景重新验证。温度参数主管 Agent 可以稍微高一点0.3 左右因为拆解任务需要一点发散性执行 Agent 建议更低0.1 甚至 0保证产出稳定性。写文案这种主观性较强的任务可以放宽到 0.5但想保持品牌风格统一还是低一点稳。每个子任务的 token 上限必须设硬限制。我在研究员 Agent 上设的是 2500 tokens 输出上限超出就截断并标记告警。模型特别能唠叨不设上限它会洋洋洒洒输出几万 tokens 的“背景研究资料”绝大多数不是你要的。重试策略上面提到了最多重试一次不要无限重试。无限重试不仅烧钱还会把错误状态越搞越乱。第一次失败后重试时把错误信息带上然后重置上下文让 Agent 基于错误反馈重新尝试这比让它盲目再来一次成功率高很多。4. 踩坑记录与排查技巧实录4.1 主管过度拆解把简单问题拆成复杂流程这是我最早踩的坑也是最经典的。主管 Agent 遇到用户问“今天天气怎么样”也能给你拆出“查询天气数据、分析气象趋势、撰写天气报告”三个子任务本质上是把一个一句话就能回答的问题做成了流水线。原因在于你把主管的角色设定写得太“结构化”了。我后来的修改办法是给主管加一条指令“如果用户请求足够简单直接回答不要拆解只有用户请求包含多个领域、多个步骤、或明显需要不同专业技能时才进行任务分解。”同时在路由逻辑里加一个规则前置判断如果用户请求长度很短、意图单一直接绕过拆解流程用一个快速通道回答。排查这类问题看日志里子任务数量最有说服力。正常业务中绝大多数请求拆出 2 到 4 个子任务就够了。如果你发现平均拆出了 7 个以上且产出质量没有明显提升那基本可以判断是过度拆解。4.2 Agent 串音前一个 Agent 的垃圾成了后一个 Agent 的输入多智能体系统里最隐蔽的问题就是串音。研究员找了一堆网页资料整理摘要时可能原样贴了很长一段带格式的文本、甚至有验证码图片的 URL写手拿到这些素材后会误把研究员的“过程性噪声”当成必须保留的核心信息然后写出来的文案里夹杂着一堆“根据某网页显示”之类的车轱辘话。根治办法就是前面说的结构化中间产物。研究员必须只输出事实清单每条事实包含“来源、时间、内容摘要、置信度”四个字段。它不得输出原始网页正文也不得输出“我觉得”“我认为”这类含主观判断的内容。写手只认这个 schema拿不到就不开工。这种强约束可能有人嫌“机械”但它能把系统的出错率压到很低的水平。排查串音要做的第一件事不是优化提示词而是去日志里看两个 Agent 之间实际传递了什么数据。大多数情况下你会发现问题不在“模型理解能力”而在“中间产物没有做 schema 校验”。4.3 死循环与任务重试的边界问题多智能体系统的一个典型崩溃场景是A Agent 输出异常B Agent 请求主管重派主管又派回给 AA 再次异常B 再次请求重派……来回几轮后 token 烧了上万任务还卡在原地。我处理这个问题的方法是在调度循环里加两个硬性计数器。一个是“每个子任务的最大重试次数”设为 1 或 2另一个是“全局重派次数”某个子任务如果被重派超过 2 次就不再把任务派回原角色而是直接标记为“无法执行”并走降级路径。降级路径可以是主管直接调用一个通用 Agent 手动处理也可以是向用户返回“该请求暂时无法完成”的明确提示。死循环的另一个来源是“反馈回路”。比如主管让研究员补充资料研究员补充后主管觉得还不够又让其补充反复打转。解决办法是限定反馈只允许包含“具体缺什么”的指令并要求研究员在一轮内补充齐所有缺口如果主管仍然不满意就必须自己承担判断责任不允许再退回。4.4 常见问题速查表症状可能原因排查方法解决方案子任务反复重试仍失败任务描述歧义太大查看日志中的子任务描述原文细化拆解 prompt要求角色字段必须与注册表一致执行 Agent 输出格式不对schema 约束没落到系统提示词查看输入给模型的完整 prompt在系统提示词中附 JSON Schema 示例并开启结构化输出上下文越用越长共享记忆区写入过多过程数据查看各环节写入记忆区的数据量严格控制只有结构化摘要级别数据可写入共享区主管汇总时遗漏某个子任务结果汇总 prompt 没有收到完整卡片列表检查汇总前状态区中的任务卡片数量汇总前增加“是否所有子任务均已完结”的校验逻辑某个 Agent 频繁调用错误工具工具名相似度过高查看工具调用的日志序列重命名工具让名称差异更明显增加工具描述中的反例说明整体响应太慢串行链路过长查看各环节耗时统计将无依赖关系的子任务改成并行执行这张表里的每一项我都实际经历过。尤其“工具名相似度过高”这条看着不起眼但对模型的迷惑性很强。举个例子你有一个search_web(query)工具和一个fetch_content(url)工具模型在需要抓正文的时候选错前者概率并不低。把后者改成fetch_webpage_fulltext_by_url(url)这种带强语义差异的名字错误率会明显下降。4.5 “主管不背锅”的隐患很多多智能体系统里执行 Agent 的产出质量完全靠主管验收但主管也是模型不是真的裁判。主管可能对一份事实错误百出的调研报告给了“质量合格”的评语原因是它根本没有能力或没有意愿逐条核对。我在自己的系统里加入了一个弱监督机制不是所有子任务结果都让主管判而是抽样让一个独立的“质检 Agent”做交叉验证。质检 Agent 不知道主管的评语只收到子任务要求和执行结果独立给一次通过/失败判断。两个判断不一致时以较严格的结果为准并记录日志。这个办法不能彻底解决问题但至少能拦住一部分漏网之鱼也能帮你持续发现主管验收偏松的问题。5. 进阶让多智能体系统更自律5.1 质量判定与撤回机制多智能体系统运行时间长了之后质量波动几乎不可避免。单靠每个 Agent 各自的努力不够需要在流程层引入“质量门”。一种做法是“关卡闸门”。任务流转的每个关键节点都设置验证步骤比如“资料检索完必须确认事实数量大于阈值且每条有来源”“文案写完必须检测是否超过字数要求”。不通过就退回通过才放行。每道闸门的判定规则要尽可能客观。凡是能被代码判断的字数、格式、字段数量就不依赖模型判断。另一种是“结果撤回”。如果最终产出已经在用户侧展示但后续发现中间环节有错误那么系统要支持按任务 ID 追溯到最初的错误子任务快速重新执行而不是让用户重新提交整个请求。这就要求从小到大的每一条记录都挂在任务 ID 下。提前做好这个设计后期维护成本差距非常明显。5.2 人类介入点的设计再好的编排系统在现实业务里也总会有兜不住的时刻。与其让系统硬着头皮给出可能错误的答案不如提前设计好人工介入的接口。我常用的设计是三层升级机制。第一层自动执行完成后如果质量得分低于阈值就把产出标记为needs_review进入人工复核队列。第二层任务被标记为无法执行或全局重派次数超限时直接转人工处理不让用户看到“系统暂时不可用”之类的空话。第三层涉及高风险操作比如发送对外消息、删除数据、提交订单无论质量得分多高都强制要求人工确认一次。这个设计看起来拖慢了一点响应速度但在生产环境里它避免的麻烦远大于它造成的延迟。Agent 团队和人类团队一样重要事项要有人签字。5.3 把经验沉淀成长期知识多智能体系统跑得越久越需要“记性”。但这里说的记性不是把对话记录堆在向量库里而是把事后复盘结论变成可执行的知识条目。比如某次任务因为“用户要求用 PDF 格式导出而系统只生成 CSV”失败了复盘后可以生成一条知识“用户在首次请求中提到导出时必须通过澄清问题确认目标格式供应商示例不得默认。”这条知识存到长期知识区的结构化条目里下次主管拆解任务时检索到就会在方案里加入确认步骤。这样系统会随着运行越用越贴近你的业务而不是永远只靠通用能力硬扛。经验沉淀的格式我建议用“触发条件 行为建议”二元的表达容易检索也容易控权。不要写成长篇分析文章否则模型反而不知道该在什么时机用它。5.4 一个“预算控制”的额外小技巧最后分享一个我实际用过的小技巧。给整个多智能体系统设置“任务预算”不只按子任务控制 token而是按整次用户请求控制总预算。当总消耗接近预算上限时主管会收到指令要求它降低后续子任务的深度比如研究员从“搜索 10 个网页”降为“搜索 3 个网页”写手从“写 1500 字”降为“写 500 字”。初期我舍不得加这个机制总觉得会牺牲质量。后来发现那些快要超预算的任务就算不管它质量也好不到哪去。提前降级反而能保证核心成果保留只是细节薄一点。预算控制也会倒逼整个团队少做无效动作多做真正提升产出的工作。我在实际观察中还有一个体会这套“机构式”多智能体设计最大的价值还不在于单次任务的质量提升而是让整个系统的行为变得可追踪、可复盘、可迭代。单个 Agent 像一个人表现好坏看状态多个 Agent 组成机构后表现好坏看制度。你在架构上花的心思最后都会从稳定性和可维护性上赚回来。
