多Agent协作新范式：代理机构式架构设计与实践-平芜编程栈

看到"agency-agents"这个项目名，做AI应用的人应该马上能get到——这不是简单的"多智能体"，而是"把多个智能体组织成像一家代理公司那样去运作"的架构思路。

这两年LLM的能力越来越强，但单个Agent干复杂活还是容易翻车：要么上下文爆掉，要么一个任务卡死就全部归零。所以大家开始琢磨，能不能像真实世界开公司一样，给不同的Agent安排明确的岗位、汇报关系、SOP，让它们各司其职、互相配合。我最早接触这个方向是因为一个内部工具总是被各种杂活拖垮，每次跑完还要人工清理上下文。后来参考了类似agency架构的思路，重新设计了角色划分和任务流转，效果好了不止一个量级。

这篇文章就把我对这种"代理机构式"架构的完整理解和实操经验整理出来，从核心思路、角色设计、编排策略，到落地实现和问题排查，一次讲透。想搭一套多Agent协作系统的开发者、做AI产品的技术负责人，应该都能从这里找到可以直接抄作业的东西。

1. 代理机构式架构的核心思路：为什么组织方式比模型能力更关键

1.1 真实公司就是最好的多智能体架构参考

先想一个问题：一个十几人的创业公司，创始人能同时搞定产品、研发、销售、客服、财务吗？理论上能力模型差不多，但实际上根本忙不过来。于是要有分工：产品经理管需求、研发写代码、销售跑客户、客服处理售后。这套分工的本质不是"人多力量大"，而是把复杂任务按职责拆解，每个人只处理自己最擅长的那一段。

Agency-agents模式的核心，就是把这套管理学逻辑搬进AI系统。它的典型形态是这样的：

主管Agent（Coordinator/Manager）：接收原始任务、拆解目标、分配子任务、检查结果。
执行Agent（Worker）：根据能力分工处理具体的子任务，比如写代码、搜资料、做分析。
质检Agent（Reviewer/QA）：对执行结果做校验，不合格打回重做。
工具/记忆Agent（Tool/Knowledge）：管理外部API、数据库、知识库，为其他Agent提供支撑。

这样每个Agent的上下文是明确的，职责是单一的，模型只需要专注做好"自己的岗位"，复杂度和失误率都会大幅下降。

1.2 和单Agent、自由多Agent方案的核心差异

市面上常见的多Agent方案通常有两种做法：一种是让一个超长上下文的Agent硬扛所有任务，另一种是让一群Agent自由对话、互相"商量"着来。

第一种的问题很明显：上下文窗口是有上限的，任务一复杂，前面的信息就被截断，而且单点的判断失误没有兜底机制，一个环节出错整个任务就得重来。

第二种听起来自由，实际落地更头疼——没有明确的汇报关系，Agent之间的对话会发散，可能跑着跑着就聊偏了，收敛不到结果上。而且你真的很难追溯"这个结论是谁、基于什么得出来的"，出了问题复盘成本极高。

Agency-agents模式用明确的组织结构（角色、职责、汇报关系）和标准化的任务流转协议（任务拆解-下发-执行-验收-返工），把"自由协作"变成"结构化协作"。就像公司里不是谁想干嘛就干嘛，而是有流程、有SOP。这么做带来三个直接好处：

可控性：每个环节都有明确的责任人，出问题知道找谁。
可观测性：任务的流转路径清晰，每一步都能记录、追踪。
可维护性：想改进某个环节，只需要调对应Agent的策略，不需要全盘重来。

1.3 适用边界：不是所有场景都需要"开一家公司"

把多个Agent组织成agency模式，并不意味着一味堆Agent数量。我见过有人给一个"给文章写摘要"的任务配了6个Agent，这种纯属过度设计。

什么场景真正适合agency架构？我总结下来至少满足这些特征：

任务本身是多步的、有依赖关系的，不是一步到位的（比如"写一篇市场分析报告"）。
任务需要不同类型的能力协同（写作+数据分析+排版）。
结果需要质量把关，允许返工迭代（比如营销文案要反复改）。
执行过程需要审计和追踪（比如复杂策略分析任务）。

如果任务是单步的、确定性的（比如"把这段文字翻译成英文"），用一个Agent加一套好Prompt就够了。agency架构的价值在于复杂度和组织成本成正比，简单任务套复杂结构，反而被流程拖累。

2. 核心细节解析：角色定义与任务编排的实操要点

2.1 关键参数：Agent数量、能力边界与上下文管理

角色拆分层级和数量，决定了系统执行的效率和稳定性。根据我的实践经验，从简单到复杂给出三档参考：

复杂度档位	Agent数量	角色配置	适配场景
轻量级	2-3个	主管 + 执行 + 质检（可选）	内容生成、单轮分析
中量级	4-6个	主管 + 多个专职执行 + 质检	跨领域综合任务、批量生产
重量级	7个以上	主管 + 规划Agent + 多个执行Agent + 质检 + 工具Agent	大型项目、多阶段复杂流程

这里有个非常重要的经验：Agent数量绝不是越多越好。每多一个Agent，就多一层上下文传递的延迟和出错概率。我见过最夸张的一个项目配了12个Agent，结果光是在Agent之间传递字段就频繁出错，最后不得不砍到5个。

另一个容易被忽视的点是能力边界。每个Agent的Prompt里，写清楚"你只负责XXX，不处理XXX"比只写"你可以做XXX"更关键。就像公司里研发别去随便承诺客户交付时间，Agent的能力边界如果模糊，它就会越权处理自己不懂的问题，结果往往惨不忍睹。

2.2 三种常用编排策略：顺序、层级与协商

有了角色，还要有编排策略——也就是任务怎么在这些角色之间流动。三种基础模式各有适用场景：

顺序编排比较简单，任务按固定流程流转，适合流程稳定的场景。比如：分析需求 → 搜集资料 → 撰写内容 → 质量检查。优点是好追踪，缺点是流程死板、不能并行。

层级编排是agency模式最核心的形态。主管Agent负责拆解和调度，执行Agent并行干活，主管汇总结果。我在实际项目中用的最多的就是这种结构，它最接近真实公司的运作方式。比如一个"生成行业分析报告"的任务，主管会把任务拆成"行业背景收集""竞品数据整理""趋势研判""报告撰写"四个子任务，分给四个执行Agent并行处理，最后统一汇总。

协商编排很灵活，让Agent之间通过消息总线自由沟通、自主协调，但收敛性差。我基本只在探索性任务中使用。协商模式很容易跑偏——Agent讨论半小时后话题已经偏离原始目标。如果要用，最好加上严格的"最终决策人"机制。

2.3 结构化输出：协作接口设计与校验机制

在agent协作里，频繁出错的核心原因往往是消息传递格式不一致。所以给每个Agent定义严格的输入输出格式，是第一优先级的事。

我常用的做法是给每个Agent定义一个JSON的接口schema，比如：

{ "agent": "data_analyst", "input": { "raw_data": "...", "analysis_focus": "..." }, "output": { "summary": "...", "charts": [], "issues": [] } }

这么做有个立竿见影的好处：每个Agent不需要"理解"其他Agent，只需要"对接"格式，大大降低了对Prompt的依赖。实践中发现，无论是GPT还是开源模型，对明确定义的JSON输出都比自然语言输出要可靠得多。

校验也不可少。我在主管Agent汇总结果之前，会对执行Agent的输出做一次结构性校验——检查必填字段是否存在、类型是否匹配、长度是否合理。不符合要求的直接打回重跑，而不是等所有任务完成之后才发现中间某个环节输出的格式不对。

3. 实操过程：从零搭建一套agency-agents系统

3.1 明确场景与任务流程

我们用一个具体案例来讲：搭建一个"批量生成产品营销文案"的agency多Agent系统。

先画任务流程：

接到一个产品描述、目标受众和推广渠道的输入。
市场分析Agent进行受众洞察与卖点提炼。
文案撰写Agent生成不同风格的多版初稿。
评审Agent按统一标准审查文案质量。
不合格的返回文案Agent修改，合格的最终输出。

这个场景足够典型，它既有分工协作（分析+创作+评审），又有决策环节（是否通过），还能看到"返工"的闭环。

3.2 定义Agent角色、职责与Prompt边界

把这个流程落到具体角色上，需要为每个Agent写清楚四条核心信息：岗位目标、输入、输出、行为准则。

主管Agent（Campaign Manager）

目标：接收客户需求（产品信息+目标人群+推广渠道），输出一份明确的任务简报。
输入：原始需求，不限于文本。
输出：结构化简报，包含产品卖点、受众画像、文案要求、交付标准。
行为准则：必须将需求转化为可执行的子任务，分配给下游Agent；不得自行撰写文案或分析数据。

市场分析Agent（Market Analyst）

目标：基于产品信息产出受众洞察和卖点提炼。
输入：主管下发的任务简报。
输出：受众痛点清单、核心卖点列表、竞品参考、语气建议。
行为准则：只提供分析结果，不撰写最终文案；所有判断需基于输入信息，不得编造。

文案撰写Agent（Copywriter）

目标：根据分析结果产出至少3个版本的营销文案。
输入：市场分析Agent的输出。
输出：3个文案版本，每个版本附带标题、正文、行动号召。
行为准则：文案必须贴合输入中的受众画像和语气建议；可以自由发挥，但不得脱离事实基础。

评审Agent（Quality Reviewer）

目标：对文案进行审查打分，判断是否符合交付标准。
输入：文案撰写Agent输出的3个版本。
输出：每个版本的评分表+通过/退回+修改意见。
行为准则：评审标准按照主管Agent下发的任务简报逐条核对；必须给出可执行的具体修改意见，不能只说"写得不好"。

这种清晰的职责划分，其实就是在AI系统里复刻了真实广告公司的部门架构，让每个环节都能"到位不越位"。

3.3 编排流程与上下文传递机制

任务编排最关键的机制是消息传递。虽然每个Agent是独立的LLM调用，但它们之间通过共享的"任务状态"来沟通。我实践中用的是一种"共享黑板"模式：

每个任务实例有一个全局的上下文对象（可以用JSON文件或数据库记录）。
主管Agent在上下文中写入任务简报。
市场分析Agent读取简报、写入分析结果。
文案Agent读取分析结果、写入文案。
评审Agent读取文案、写入评分和修改意见。
如果评审不通过，文案Agent重新读取评审意见，修改后再次提交给评审Agent，形成闭环。

这个"黑板"机制的好处是：每个Agent只管"读我需要读的，写我需要写的"，不需要直接感知其他Agent的存在，降低了耦合度。就好像公司里设计部不需要知道法务部内部怎么讨论，只需要拿到合同模板就行。

3.4 完整代码实现示例（基于函数调用的轻量实现）

我不会直接把整个框架的代码贴出来（篇幅原因），但可以给一个最小可运行的骨架，你们拿回去改改就能跑通第一个版本。

import json import re from typing import Callable, Dict, Any class Agent: def __init__(self, name: str, run_fn: Callable[[Dict[str, Any]], Dict[str, Any]]): self.name = name self.run_fn = run_fn def execute(self, context: Dict[str, Any]) -> Dict[str, Any]: result = self.run_fn(context) return result class Agency: def __init__(self, agents: Dict[str, Agent], pipeline: list[str], blackboard: Dict[str, Any] = None): self.agents = agents self.pipeline = pipeline self.blackboard = blackboard or {} self.trace = [] def run(self, task: Dict[str, Any]): self.blackboard["task"] = task for agent_name in self.pipeline: agent = self.agents[agent_name] step_input = {k: v for k, v in self.blackboard.items() if k != "task"} # 简化：读全部黑板 result = agent.execute(step_input) self.blackboard[agent_name] = result self.trace.append({"agent": agent_name, "result": result}) return self.blackboard # 模拟三个Agent def manager_run(context): task = context["task"] brief = { "product": task["product"], "audience": task["audience"], "selling_points": ["省时省力", "降低人工成本"], "delivery_standard": ["标题有吸引力", "每个版本不少于3段"] } return {"brief": brief} def analyst_run(context): brief = context["manager"]["brief"] insights = { "pain_points": ["日常事务占用大量时间", "处理效率低"], "recommended_tone": "专业、亲切、有行动指导性" } return {"insights": insights} def copywriter_run(context): insights = context["analyst"]["insights"] copies = [ {"title": "告别繁琐事务", "body": f"针对{insights['pain_points'][0]}，我们推出了新的解决方案...", "cta": "立即体验"}, {"title": "效率翻倍的秘密", "body": "一套流程自动完成...", "cta": "预约演示"}, ] return {"copies": copies} def reviewer_run(context): copies = context["copywriter"]["copies"] scores = [] for c in copies: scores.append({ "title": c["title"], "score": 4.5, "decision": "pass" if len(c["body"]) > 10 else "rework", "comments": "标题吸引人，正文可再具体化" }) return {"scores": scores} if __name__ == "__main__": agents = { "manager": Agent("manager", manager_run), "analyst": Agent("analyst", analyst_run), "copywriter": Agent("copywriter", copywriter_run), "reviewer": Agent("reviewer", reviewer_run), } agency = Agency(agents=agents, pipeline=["manager", "analyst", "copywriter", "reviewer"]) task = { "product": "某自动化办公软件", "audience": "中小型企业管理者", "channel": "社交媒体广告" } result = agency.run(task) print(json.dumps(result, ensure_ascii=False, indent=2))

这个骨架把"黑板模式"简化到极致——每个Agent都能看到全部上下文。生产环境中不会这么粗暴，要考虑权限隔离（分析Agent没必要看到评审内部逻辑），但作为理解核心思想的第一课，这个代码足够了。

生产级实现再往后走，无非是三件事：把黑板改成真正的数据库或Redis、把Agent调用改成异步并行、把trace写成结构化日志。思路完全一致。

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

4.1 上下文漂移：跑着跑着忘记最初目标了

这是多Agent系统里最普遍的问题。Agent在执行长链条任务时，经过多轮传递，原始目标在后续环节中逐渐模糊。

症状非常典型：主管让分析Agent做"目标用户画像分析"，等传到文案Agent那里，文案已经变成"产品功能说明书"了。

排查思路：检查每个Agent的Prompt里的"输入摘要"环节。我建议在主管Agent的任务简报里加一个reminder字段，明确写清楚"本任务的核心目标是XXX"，并且要求所有下游Agent在执行前先复述这个目标。在代码实现上，就是在消息传递时把原始目标字段始终保留在黑板的顶层，不让它被各种中间结果淹没。

4.2 死循环：评审不通过 → 修改 → 评审还是不通过

评审Agent和执行Agent之间可能卡死循环，每次都提新的修改意见。真实原因通常是修改意见太过模糊，或者评审标准本身不统一。

解决办法是给评审Agent加两个硬约束：

修改意见必须是"可执行的行为描述"，比如"给第二段添加一个具体的数据支撑案例"，不能是"内容不够生动"这种没法落地的评价。
设置最大返工次数（比如2次），超过次数自动降级为"由主管Agent仲裁通过并记录原因"。避免系统无限空转烧钱。

4.3 角色冲突：多个Agent抢做同一件事

当任务拆解不够清晰时，可能出现多个执行Agent都在做相同的工作。比如既让市场分析Agent写卖点，又让文案Agent自己提炼卖点，最后两边输出打架。

这个问题的根源在职责边界声明没写清楚。我给每个Agent的Prompt都加了"你不需要做的三件事"这样的负面清单。实验下来，负面清单比正面描述更能约束模型的行为边界。

4.4 关键前提：任务拆解质量决定系统上限

最后必须强调一点：上面的所有机制都建立在"主管Agent能正确地把任务拆解成子任务"这个前提上。如果拆解本身是错的，下游执行再漂亮也是白搭。

如果你发现整个系统产出质量一直上不去，先别急着调执行Agent的Prompt，回头看看主管Agent的任务拆解逻辑。我一般会做一个小实验：让主管Agent单跑一次拆解，把拆解结果打印出来人工检查，看看子任务是否完整、是否重叠、是否能被下游理解和执行。这一步检查花不了几分钟，但往往能省下大量排查时间。

4.5 问题速查表

症状	可能原因	优先排查项	解决方案
输出内容偏离原始目标	上下文漂移	检查每轮传递是否包含task摘要	在黑板上保留原始target字段
任务卡在评审环节	评审标准模糊	检查评审Agent的评分维度	增加可执行修改意见约束
多个Agent做重复事	职责边界不清	检查角色Prompt中的负面清单	补充岗位边界声明
系统整体速度慢	串行调用过多	检查pipeline中的顺序依赖	无依赖环节改为并行执行
输出格式不规范	缺少schema校验	检查Agent输出是否走pydantic	统一接入结构化输出校验
上下文爆炸	消息累积全量传递	检查黑板读取粒度	按需读取，细化input权限

5. 个人经验与踩坑总结

做agency-agents这类系统最重要的是"上一步想清楚下一步怎么做"。

我刚开始做这个项目的时候，犯过最大的错就是把Agent当作独立的"专家"来用，给每个Agent加了一大堆背景知识和复杂Prompt，结果互相之间配合得乱七八糟。后来我换了个角度——把每个Agent当成新入职的员工，给它们极简的岗位说明书、明确的工作表格和清晰的交接流程，系统的稳定性和产出质量反而明显提升了。

另外，日志和复盘比模型本身更值得重视。每次任务结束，我都会把完整的trace存下来，定期过一遍，看看哪一步的任务流转时间最长、哪一步的返工率最高。这些数据才是优化系统的真正指南针，而不是拍脑袋猜"是不是模型能力不够"。

如果你正准备搭自己的多Agent系统，建议先从两三个Agent、一条主线流程开始跑通，再逐步加角色、加并行分支。不要第一步就想搭一个完整的"数字公司"——复用性不一定好，但复杂度一定是实实在在的负担。先让最小的闭环转起来，再让这台机器长出更复杂的组织能力。