“agency-agents”这个标题我第一次看到时以为是某个组织机构的项目代号后来才意识到它说的是一套多智能体Multi-Agent协作架构。这几年大模型能力越来越强单Agent能做的事也越来越多但真要把一个复杂的任务交给AI完整落地单靠一个Agent总会卡在“上下文不够用”“自我纠错能力弱”“任务一多就开始东一榔头西一棒子”这几点上。所以社区里开始流行一个思路不训练一个万能大模型而是设计一个能调度多个单一职责Agent的“代理机构”让它们像真实公司里的岗位一样各司其职、互相校验、逐级递进。今天这篇就把我搭建类似系统时的设计思路、踩过的坑和最终沉淀下来的方案完整写出来给也在做Agent编排的朋友一个参考。1. “agency-agents”到底指什么从一个全能Agent到一个Agent团队先说清楚概念本身。“agency”可以理解成“代理机构”它在工程上并不是说要在本地跑一堆模型实例而是指一套负责分配任务、协调角色、汇总结果的编排框架。这个名字起得很形象——你手头有一批能力各异的AI代理agents它们不是独立散装的而是像同一家公司里的员工有策划部、执行部、质检部都挂在同一个组织架构下干活。为什么单Agent方案越来越不够用我实测下来最典型的问题是把“做一个市场调研报告”这样的大任务丢给一个Agent它当然能一口气生成文字但过程中经常出现三种情况。第一上下文窗口被无关内容塞满开头查到的资料到后面已经被遗忘第二没有天然的分工压力Agent会习惯性地用同一套语气、同一个视角处理所有环节导致报告的前半部分是“深度分析”后半部分变成了“资料堆砌”第三缺少独立的校验机制Agent自己写出来的结论它自己很难客观反驳。Agency-agents的价值就在于通过架构机制解决这三件事。核心思想是按流程拆角色而不是按步骤拆提示词。比如同样做市场调研系统里可以存在三个Agent一个专门做信息采集与数据筛选一个专门做逻辑分析与结构编排还有一个专门做事实核查与风险提示。它们各自只负责一个环节前后交接的是结构化的任务书而不是让一个Agent从头干到尾。我建议团队在评估要不要引入这套架构时先看一个硬指标你的任务是不是需要三个以上不同知识领域的专业判断交错进行。如果只是“生成一段文案”“总结一篇文章”单Agent加一个写好的System Prompt完全够了强行拆出一堆Agent反而是增加延迟和成本。但凡任务链条里存在“采集→分析→生成→校验”这样明显的工序差异让一个Agent全程处理就会让结果打折。agency-agents适合的正是后者这也是它跟普通Agent项目最本质的区别它不是更强的一个模型而是更强的一个组织。2. 角色编排是骨架规划、执行、验证三类Agent的职责边界经过几次迭代我把系统里的Agent收敛为三类规划型Planner、执行型Executor、验证型Verifier。这个三角结构是我目前认为最稳定、也最容易扩展的配置少于三类会缺监督多于三类又会增加协调成本。2.1 规划型Agent把模糊需求翻译成可执行任务规划Agent是整套流程的入口。它要做的事情不是自己动手而是把用户那句“帮我分析一下目前市场上智能手表的竞品情况”翻译成一张任务清单包括需要采集哪些维度的数据、应该拆成几个调研子任务、每个子任务由哪一类执行Agent承接、产出物以什么格式汇报。它输出的不是一段话而是结构化任务书Task Brief。这里有一个非常容易踩的坑让规划Agent输出过于细碎的任务。我初版设计时规划Agent会把“竞品情况”拆成十几个小任务结果执行层频繁切换上下文效率反而比单Agent还低。后来我给规划Agent加了一条约束子任务数量控制在3到7个之间且每个子任务必须有一个明确的完成判据。比如“收集竞品价格区间”的判据是“至少列出5个品牌带价格的表格”而不是一句模糊的“尽量多收集”。规划Agent还需要负责标记依赖关系。有些任务可以并行执行比如同时收集“价格信息”和“渠道信息”有些任务必须串行比如“分析竞品定价策略”必须等“价格数据表”返回之后才能开始。这个依赖关系如果让执行Agent自己判断很容易出现两边互等的情况所以我会在规划阶段直接规定依赖顺序后续调度器只按这个DAG执行。2.2 执行型Agent按角色卡片专精于单一环节执行Agent是实际产出内容的角色它唯一要做的就是把规划任务书里的那一个环节做到专精。我采用的做法是给每个执行Agent预置一份高度定制化的System Prompt里面只包含它职责范围内的能力描述、输出格式标准、知识边界声明。举个例子负责“行业信息采集”的执行Agent它的System Prompt会规定只输出结构化事实条目每条带来源与时间戳不得进行主观评价如果信息不足必须输出“缺失项清单”而不能自己编造。负责“文案生成”的执行Agent它的System Prompt会规定只基于输入材料进行转写不新增未经验证的数据风格口语化但必须逻辑连贯。这种“单一职责”的设计有几个立竿见影的好处。一是上下文消耗大幅下降——执行Agent看不到整个项目背景每次只需要加载任务书和相关材料窗口占用通常能控制在合理范围。二是模型产出更稳定——一个只负责写行业分析的Agent比一个既要分析又要写作又要查资料的Agent在输出格式和语气一致性上要好得多。三是Agent可以随时被替换——如果发现某类执行效果不好只需要调整对应角色卡不影响其他环节。2.3 验证型Agent独立质检不做执行的附庸验证Agent是最容易被忽视、但最能拉开效果差距的角色。它的任务是挑毛病检查执行Agent的产出是否遗漏任务书里的要求、是否有事实性错误、格式是否符合下一步流程的输入标准。如果发现问题把不符合项清单退回给执行Agent并附上修改建议。我早期设计的时候偷懒让执行Agent自己同时扮演“创作”和“审查”两个角色结果审查环节形同虚设——Agent很少否定自己的产出。后来改成独立的验证Agent效果立刻提升了一个档次。这里有个细节验证Agent的System Prompt里我特意强调了一句“你是对结果负责的最后一道防线发现问题必须明确指出不要为了礼貌而放过瑕疵”。给Agent赋权让它有“否决权”是质检环节真正发挥作用的前提。三类角色的衔接我用一份任务状态机来管理。初始任务进入backlog规划Agent拆解后置为ready执行Agent取走后变为in_progress完成并交付后变为in_review验证Agent通过后变为done不通过则退回rework。整个状态流转由调度器统一控制不同状态的合法迁移是写死的这样既不会出现“验证还没过就被拿去生成最终稿”的问题也让每一步的产出都有据可查。3. 让Agent之间能顺畅“对话”消息总线与任务状态机的关键设计角色只解决了“谁来做”的问题真正决定这套多智能体系统是丝滑还是卡顿的是Agent之间的通信机制。如果每个Agent的产出都是一大段散文式的自然语言下游Agent解析起来非常痛苦而且信息损耗严重。我踩过这个亏之后把所有Agent间的交接物统一成了两种结构结构化消息Structured Message和任务产物Artifact。3.1 结构化消息给每个Agent配一套统一信封我定义了一个通用的消息Schema所有Agent之间的通信都严格按这套结构来。它长这样{ message_id: uuid, task_id: task_20250101_x, from_agent: planner, to_agent: executor_data_collector, type: task_assignment, payload: { task_goal: 收集主流品牌智能手表公开价格范围覆盖入门级到旗舰级, output_format: table_5_columns, data_source: 公开电商页面与品牌官网, constraints: [价格单位统一为元人民币, 每条数据标注当前日期] }, timestamp: 2025-01-01T10:00:00Z }字段含义很直白但有两个设计经验值得一提。第一个是from_agent和to_agent必须显式写明不要让消息在系统里“漂流”。我见过一些项目把任务发布到一个公共池子里哪个Agent空闲就接哪个结果同一份任务被两个Agent重复执行浪费了token还搞乱了状态。指定明确的发送方和接收方让路由逻辑变得非常简单调试时也能直接看到消息链路。第二个是payload里一定要携带受控的constraints。执行Agent看到约束会主动调整自己的行为边界比如上面的例子要求“价格单位统一为元”就是防止执行Agent在查询过程中把美元价格直接拿来用或者把历史价格和当前价格混在一起。3.2 任务状态机把流程控制权集中到调度器我把所有流程变更加到了信息流里由调度器统一编排而不是放给各Agent自行协商。这样可以避免一个问题多个Agent在消息里互相“讨价还价”一个说“数据不够要不要我再查一遍”另一个说“不用你编一下就行”两个Agent一来一回不仅浪费调用次数还可能偏离原始目标。状态机设计如下核心节点包括backlog待拆解、ready可执行、in_progress执行中、in_review验证中、rework退回修改、done已完成、failed确认失败。每条合法迁移我都做了限制只有in_progress可以迁移到in_review只有in_review可以迁移到done或rework只有rework可以迁移回in_progressfailed只能从in_progress或rework状态进入且需要记录失败原因调度器核心代码其实就是一张状态迁移表和对应的处理逻辑# 状态迁移表current_state - (event, next_state) TRANSITIONS { backlog: [(decompose, ready)], ready: [(assign, in_progress)], in_progress: [(submit, in_review)], in_review: [ (approve, done), (reject, rework), ], rework: [(resubmit, in_progress)], in_progress: [(fatal, failed)], rework: [(fatal, failed)], } def transition(task, event): if not any(e event and next_state in task.allowed_next for _, e, next_state in TASKS_META): raise IllegalTransition(ftask {task.id} cannot move from {task.state} via {event}) # 实际状态更新逻辑...如果出现非法迁移比如任务还在in_review就想跳到done调度器直接抛异常并记录到日志里。这个设计看起来死板实际运行中帮了大忙——它能暴露很多Agent行为异常。比如我出现过一次“验证Agent还没收到产物状态却被改成了in_review”的情况检查日志发现是消息里的task_id写错了本来要发给验证的消息发回了归档队列。状态机的约束让我能快速定位这类问题而不是等最终结果不对了才到处排查。3.3 任务产物的版本化归档每份任务产物我都存了多版本并在Artifact头部记录“基于哪个版本的输入”。这个设计最初是为了满足追溯需求后来发现它也是prompt调试的利器——当最终结果不对时我可以一级一级地往前查具体是哪个执行Agent产出了错误数据它是基于哪个上游材料的哪个版本中间是否有某个版本被验证Agent退回过修复后又是从哪个版本续的一般而言我会保留最近3代的Artifact版本。版本太多会占用存储太少了又可能在回溯时找不到原始依据。对文本类产物来说每一代的增量其实不大存储成本可控但排查问题时省下的时间非常可观。4. 实测三座大山上下文膨胀、死锁循环与成本失控的修复实录理论设计做得再漂亮跑起来才是验证。我在把系统从Demo推到可用阶段的过程中扎扎实实撞了三座大山每一座都值得单独讲。4.1 上下文膨胀执行Agent手里材料越积越多第一个问题出现在跑了大概三十几轮任务之后执行Agent的响应速度越来越慢结果质量明显下降。查日志发现执行Agent在每次接收新任务时系统会把该任务关联的全部历史消息都塞进它的上下文里——因为我想让Agent“对全局情况有了解”。结果就是Agent在看消息列表上花了大量窗口真正用来写内容的空间被挤占了。修复方案是给上下文增加一个“物料清单”机制。执行Agent收到的不是原始历史消息而是一份由调度器生成的上下文清单里面显式列出“本次任务需要依赖哪些Artifact版本、每个版本里和当前任务直接相关的段落有哪些”。Agent拿到的是剪裁后的核心片段而不是一串完整的聊天记录。剪裁规则不难按关键词和相关度过滤出与本任务目标字段匹配的内容再用摘要模型对超长段落进行压缩保留关键结论与数据。修复后执行Agent的平均有效上下文占用大概降了50%响应延迟缩短了约三分之一产出质量也在人工抽样评估中有所回升。这里我得到的教训是不要假设Agent能自己从海量上下文里找到重点架构层面替它做好信息降噪效果稳定得多。4.2 死锁循环执行Agent和验证Agent互相踢皮球第二个问题更典型也更让人抓狂某次任务中执行Agent产出的报告被验证Agent连续退回了四次理由分别是“数据来源标注不完整”“第三部分逻辑跳跃”“表格缺少单位”“结论措辞不够严谨”。每次执行Agent都按意见修改了但验证Agent总能在新版本中找到新的小问题然后再次退回。这实际上形成了Agent之间的死锁循环——两边都在按字面规则办事但没有一方有权叫停。我在项目里临时加了一个重试上限同一个任务在rework状态最多循环两次超过后自动升级给“人工裁决队列”同时调度器会把新旧两个版本的差异摘要一并附上方便人快速判断。升级之后这类问题基本都能在1分钟内被人为拍板解决不会再让两个Agent无限对线。从根上想这个问题产生的根源在于验证Agent缺少“受理边界”。它被设计成“挑毛病”但没有被设计“判断毛病是否重要到需要退回”。后来我优化了它的Prompt只有“影响任务完成判据”的问题才能打回其余小问题作为备注记录在Artifact的批注区不影响主流程继续。这个调整之后rework率明显下降同时也保留了验证Agent的纠错能力。4.3 成本失控高精度模型不该参与每个环节第三个问题是账单带来的物理痛感。初版系统为了让结果尽可能高质量给所有Agent都配了当时最强的模型。实测跑一个中大型任务光调用费用就让团队讨论要不要砍掉几个角色。后来我按“环节精度需求”重新分配了模型规格执行层的信息采集Agent换成性价比更高的模型因为它的任务是结构化提取对大模型推理能力要求没那么高规划Agent和验证Agent保留高精度模型因为它们的职责涉及复杂判断文案生成类执行Agent用中档模型配合验证Agent的检查兜底最终效果与全高配模式差距很小。我给一个同类型任务跑了两组对比数据很直观配置方案单任务平均成本相对值人工评测通过率平均响应时长全角色高配大模型100%92%100%按环节分级配置38%90%84%成本降到原来的三分之一出头评测通过率只降了2个百分点但响应时长还因为低配模型速度更快而缩短了。这个数据进一步说明**多智能体系统的优势之一就是可以把不同难度的任务分给不同档次的模型让每一分钱都花在刀刃上。**而且因为验证Agent独立存在低配执行Agent的错误可以被拦截并不需要担心降级后质量雪崩。5. 一套可复用的轻量落地参考方案组件清单与扩展方向到这里框架性的设计基本就完整了。最后分享一套我目前在实际项目中使用的轻量落地方案它不依赖重量级框架用普遍的开发工具就能搭起来适合想快速上手的团队。5.1 组件清单与职责一览模块推荐实现核心职责调度器Python异步任务队列维护状态机、路由消息、触发迁移消息总线Redis Stream / 数据库消息表持久化消息、按task_id路由、记录全链路执行Agent大模型API调用 角色卡模板单环节任务执行按限定格式产出验证Agent大模型API调用 独立校验提示词对照完成判据检查产物产出修订意见或确认通过上下文管理器向量检索 摘要缓存剪裁任务材料生成精简上下文包人工仲裁队列维护表格任务处理超限循环、确认失败、疑难升级这套方案全部跑在通用云服务和开源组件上没有平台绑定。调度器是核心它可以用Python写一个长期运行的服务消费待处理任务队列并执行状态迁移。其他Agent本质上都是“输入任务书产出结果”的HTTP接口调度器负责调用和结果回写。5.2 从一个最小闭环开始先跑通规划到验证我的建议是不要一开始就追求全家桶。先把最简单的三角形跑通规划Agent拆出两个子任务 → 两个执行Agent并行执行 → 验证Agent统一校验。这一步成功了再慢慢加通信协议、版本归档和成本控制。下面是一个简化的伪代码骨架展示这条最小闭环def run_agency_cycle(user_request): task create_task(user_request) briefs planner.decompose(task) # 规划Agent产出子任务书 for brief in briefs: artifact executor.run(brief) # 执行Agent接收任务书并产出结果 task.attach(brief.id, artifact) verdict verifier.check(task) # 验证Agent对照判据校验 if verdict.approved: return task.final_report() # 通过则产出最终汇总 else: feedback verdict.feedback_list task.enter_rework(feedback) # 不通过则退回修改 # 循环直至通过或达到重试上限超限转人工仲裁这个骨架虽然简单但已经把三个核心角色的静态关系体现得很清楚了。真正生产化时需要往里加状态日志、异常重试、成本统计等模块——但这些都是增量工作不会改变整体架构。5.3 后续扩展从串行到异步、从纯文本到多模态如果验证Agent效果稳定了还有几个方向值得探索。一个是异步任务编排把调度器从同步等待Agent返回改成事件驱动执行Agent完成任务后通过回调或者消息通知调度器这样多个任务可以真正并行流转。另一个是多模态产物支持目前的Artifact还是以文本为主如果任务涉及图片生成、音频处理就需要在消息Schema里增加二进制对象的引用与版本管理调度器的校验逻辑也会更复杂。还有一个我更看重的方向是长期记忆。当前系统的上下文管理还是任务级别的任务结束之后执行Agent不保留任何历史经验。如果能让Agent把每轮任务中的“有效做法”和“失败教训”沉淀到一个共享知识库后续同类任务执行时先把经验摘要注入上下文整个系统的自我进化能力会明显上一个台阶。这个方向我带团队验证过初步版本效果不错线上任务的返工率能再降一些但知识库的召回与去重还需要打磨。最后聊聊这套架构的“组织智慧”我在落地agency-agents这套系统时最深的体会是**多智能体系统的难点从来不是让单个Agent变聪明而是让一群各有所长的Agent在协作时不互相拖后腿、不重复劳动、不无限内耗。**规划、执行、验证这三个角色的划分本质上就是人类组织中“定方向、干活、把关”的映射只不过我们把这套管理智慧固化成状态机和消息协议。它不能替代模型能力但它能让模型的每一次调用都更聚焦、更可控、更可追溯。如果你也在尝试类似的架构建议先别纠结于把每个Agent的Prompt写得多华丽先确保角色边界清晰、消息结构统一、状态流转严谨——这三点做到位整条链路自然能转起来后续优化也才有稳定的地基。