去年下半年开始我一直在折腾多 Agent 协作方向的东西也就是大家常说的 Agent 编排、Agent 团队、Agent 机构。手头这个代号为agency-agents的项目算是我前后投入精力最深、踩坑最多、也是产出最完整的一个。简单来说它不是一个普通 Single-Agent 应用而是一套能模拟一个数字代理机构运作流程的多 Agent 协作系统。整个项目解决的问题很直接如何让大模型不止步于聊天问答而是以团队分工的方式完成需求分析、方案策划、内容创作、视觉设计、质量审核这一条完整的生产链路。这篇文章我会把这个项目的整体设计、架构选型、核心实现、踩坑记录按照我当时推进项目的时间线和思考过程完整梳理一遍。如果你是打算做 Agent 应用、正在纠结多 Agent 到底怎么落地、或者想了解一套相对完整的 Agent 协作系统长什么样的开发者这篇文章应该能帮你省掉不少试错的时间。1. 项目概述与核心思路解读1.1 到底在做什么一个 AI 版的数字代理机构项目英文名叫agency-agents中文可以理解成代理机构型 Agent 系统。我当时做这个项目的初衷很简单市面上的单 Agent 机器人已经很成熟了你跟一个 Agent 对话它能帮你写文章、写代码、做分析但你一旦提出一个稍微综合一点的需求比如帮我出一套新品上市的营销全案单 Agent 往往就会手忙脚乱——又要调研、又要策划、又要写文案、又要配图最后输出的东西经常散成一盘沙。我当时想的是能不能把一套真实数字营销公司的工作流程映射到大模型 Agent 上真实公司里接到客户需求后会有项目经理拆解需求有策略分析师做市场调研有文案负责写内容有设计师出视觉方案有校对审核做质量把关。如果每个角色都有一个独立的 Agent 来承担并且按照真实业务流程来协作是不是就能得到质量更高、结构更完整的产出这是我做agency-agents的起点。项目最终形成了一套可以运行的多 Agent 协作系统输入一个宏观需求系统自动派发给多个角色 Agent 分工协作最终输出一套带策略文档、文案内容、视觉建议、质检报告的完整方案。说白了就是给大模型搭了一个公司架构。1.2 为什么是多 Agent 而不是单一 Prompt很多朋友第一时间会问既然大模型能力这么强为什么不在一个 Prompt 里把任务描述清楚一次生成完非要拆成多个 Agent不是徒增复杂度吗这个质疑有点道理。单 Prompt 确实能解决一部分需求但解决不了需求复杂度上升后的质量问题。我打个比方你让一个全能型员工同时扮演市场分析师、文案策划、视觉设计师他也能交出东西但很容易出现角色切换不彻底、篇幅分配失衡、前后逻辑打架的问题。因为他要在同一个上下文窗口里反复切换心智模式这对模型的长程注意力挑战非常大。多 Agent 的核心优势不在于人多力量大而在于每个 Agent 拥有独立的上下文空间和独立的角色定位。研究Agent 只关心调研它不会分心去写文案文案 Agent 只拿到研究 Agent 得出的结论不会被原始资料淹没进而出现信息过载。每个 Agent 的输出边界清晰质量可控并且最终由审核 Agent 做整体质量把关。这种隔离 分工 会诊的结构是我觉得多 Agent 真正能打的地方。另外多 Agent 还带来一个工程上的额外好处中间产物是结构化、可追溯的。单 Prompt 的输出是一坨文本里面的调研结论和写作逻辑搅在一起而多 Agent 流程中每个环节的输出都可以单独存档、单独评审、单独修改。这为后续做质量分析和流程优化打好了基础。1.3 适用场景与核心收益聊聊这个系统的适用范围免得大家误以为多 Agent 是万能的。我在实际使用中感觉到agency-agents 这类多 Agent 协作系统最适合的是目标明确、流程相对固定、需要多角色专业输出的内容生产任务。举几个已经在跑的场景营销策划类品牌调性分析、竞品调研、传播策略、内容日历、效果预估一条链跑完。内容创作类从话题规划到素材搜集、初稿撰写、风格优化、最终审校。项目方案类收到一个开发需求由项目经理 Agent 拆解成任务清单架构 Agent 出方案开发 Agent 写代码测试 Agent 设计验收用例。核心收益总结下来是三点产出完整度明显提升多个环节的内容不会因为模型注意力限制而缺失、质量可控性增强审核 Agent 可以针对性地挑毛病、流程标准化同一套流程喂给不同需求输出的结构和交付标准是统一的这在交付型项目里尤其重要。2. 架构设计与技术选型2.1 整体架构从任务流到 Agent 角色在定技术方案之前我先把系统架构画了一个清晰的分层。整个agency-agents可以拆成四个层面交互层接收用户原始需求做初步意图识别判断任务类型和目标。编排层这是整个系统的核心。负责任务拆解、Agent 调度、状态流转、结果汇聚。也是这套系统区别于普通多 Agent 玩具的关键部分。执行层各个具体角色的 Agent 实例比如研究员、文案、设计师、审核官。每个 Agent 有自己的角色设定、能够访问的工具和模型配置。支撑层包括向量数据库、记忆系统、外部API搜索、图片生成等以及各类数据存储。其中编排层的设计我放进了一个核心状态机里。业务过程不是随意跳转的而是有明确阶段理解需求 → 策划方案 → 分步执行 → 评审质检 → 修订交付。状态机的好处是流程可控不会出现 Agent 们乱聊一通就把资源烧光的情况。2.2 底层框架对比与选型逻辑这里聊一下框架选型。我最早的时候试过AutoGen、CrewAI、LangGraph也自己写过一版纯粹靠 OpenAI 函数调用 Python 循环去控制的多 Agent 代码。几个方案的差异在这里框架核心模型适合的场景我在实际使用中的感受AutoGen对话驱动多 Agent 互相聊研究型、探索型任务灵活但自由度太高容易没有边界需要大量约束代码CrewAI角色驱动Task Agent 定义固定流程的角色扮演任务上手快概念直白但复杂分支逻辑需要自己补LangGraph图状态驱动需要精确控制流程、条件分支、循环收敛的任务学习曲线陡但控制力最强适合做复杂生产系统最后我的选择是LangGraph 做底层状态控制 CrewAI 的角色定义语法作为 Agent 构建规范中间用一套自定义的调度逻辑粘合。用熟话讲LangGraph 负责流程的骨架CrewAI 的风格负责角色的血肉。选择这个组合的核心原因是流程的确定性优先于对话的灵活性。在真实业务交付里我不能容忍两个 Agent 因为互相扯皮烧掉几百个 API 调用还跑不出结果。LangGraph 的状态机让每一步都有明确的输入输出和转移条件一旦某个 Agent 卡住或者输出不符合要求我可以及时拦截并走修复分支而不是放任它原地打转。2.3 会话状态设计与消息流转规范多 Agent 系统很容易在消息流转上翻车。最常见的问题是Agent A 的输出直接拼到 Agent B 的上下文里越拼越长最后就是灾难。我在agency-agents里专门设计了一套消息规范。每一轮流转的消息不是裸文本而是结构化数据包格式类似这样{ message_id: msg_xxx_001, from_agent: researcher, to_agent: writer, task_id: task_004, content: ...实际内容..., metadata: { sources: [source_url_1, source_url_2], confidence_score: 0.92, phase: research } }这么做有几个直接的好处第一下游 Agent 可以只消费自己关心的字段不被无关信息干扰第二每条消息都可以追溯到来源 Agent 和任务环节出问题时定位非常快第三可以按字段做策略处理比如当 confidence_score 低于某个阈值审核 Agent 可以自动触发补充调研分支。这比我最早用纯字符串拼接的方式不知道高到哪里去了。3. 核心实现细节与实操要点3.1 Agent 角色定义Role、Goal、Backstory 怎么配在多 Agent 系统里Agent 的人设绝对不是随便写一段你是一个助手就完事。我在调agency-agents时最大的心得就是角色定义的质量直接决定下游产出质量的一半以上。我参考 CrewAI 的思路为每个 Agent 配置了三要素Role角色的职能名比如高端市场研究员Goal该角色在这个任务里需要达到的具体目标Backstory角色的背景故事补充专业知识体系和行为倾向给大家看一个我配置研究员 Agent 的例子researcher Agent( role资深市场研究员, goal基于给定需求全面分析目标市场、竞品情况、用户痛点提炼高价值洞察。, backstory你在消费品行业调研领域有十年经验擅长从碎片信息中提炼用户需求 习惯用结构化方式输出调研结论讲究数据支撑。你不写营销文案不提供创意概念 你的唯一任务是让事实和洞察足够清晰。, tools[search_api_tool], llmConfig.LLM_MODEL, )这里有两个关键细节。第一在 Backstory 里声明你不做什么和你做什么同样重要。很多版本的角色定义只写了正向目标结果 Agent 经常越权去干别的活。我加了一句你不写营销文案不提供创意概念把它框死在调研角色内效果立竿见影。第二Role 命名不能模糊叫市场专家不如叫资深市场研究员来得准确Agent 对自己的行为预期会更强地受到角色名词的影响。3.2 任务编排Planner、Executor、Critic 三阶段模式下面聊整个系统最核心的设计——任务编排。我在agency-agents里实践下来最稳的流程模式是三段式Planner 阶段项目经理 Agent 把用户需求拆解成一个可执行的子任务序列。这个阶段重点解决的是做什么、按什么顺序做。Executor 阶段各个执行 Agent 按照任务序列开工。可能是一个 Agent 完成多个子任务也可能是多个 Agent 平行推进不同子任务。Critic 阶段审核 Agent 对产出结果做整体检查发现问题再丢回相应环节修改。这个阶段决定了最终交付质量。Planner 阶段我在代码上是这样做的from langgraph.graph import StateGraph, END graph StateGraph(WorkflowState) graph.add_node(planner, plan_tasks) graph.add_node(researcher, execute_research) graph.add_node(writer, execute_writing) graph.add_node(designer, execute_design) graph.add_node(critic, review_outputs) graph.add_edge(planner, researcher) graph.add_edge(researcher, writer) graph.add_edge(writer, designer) graph.add_edge(designer, critic) # Critic 有两条出口通过则交付不通过则返回 writer 修订 graph.add_conditional_edges( critic, should_revise, {revise: writer, approved: END} )这段代码有两个值得说道的点。第一我用的是顺序依赖 单循环收敛的结构没有让所有 Agent 自由聊天。自由聊天的多 Agent 系统看起来酷炫但很容易出现双方礼貌性互夸或者越聊越偏的失控情况我直接在设计层面规避掉了。第二Critic 的出口用了条件分支写成should_revise这个判定函数只有当审核通过时流程才会走进 END保证交付产物至少经过了完整的质检查。3.3 工具调用与外部能力接入多 Agent 系统不能光靠模型脑补必须让 Agent 具备工具能力。在agency-agents里我重点接入了三类工具搜索引擎 API给研究员 Agent 做资料搜集和事实核查。图片生成 API给设计师 Agent 做视觉方案配图。内部知识库通过向量检索把团队历史项目资料、品牌规范、术语表接入系统确保产出一致性。工具接入上有一个必须强调的规范工具调用结果必须经过摘要压缩才能放回上下文。这是我的血泪教训。搜索引擎返回的原始网页内容动不动就几万字符如果原封不动塞给模型上下文很快就爆了。我写了一个专门的compress_context函数让模型先对搜索结果做提炼只保留核心事实、数据、来源链接再作为消息传给下游 Agent。def compress_context(raw_results: list[str], max_tokens: int 1500) - str: 将原始搜索结果压缩为结构化摘要 summary_prompt f 请将以下搜索材料提炼为不超过 {max_tokens} 字的调研摘要 只保留核心事实、关键数据和来源链接。禁止加入自己的推断。 材料如下{raw_results} llm get_llm() compressed llm.invoke(summary_prompt) return compressed这种先压缩再传递的思路本质上是让每个 Agent只拿到够用的信息而不是把整个资料库背在身上。这也解释了为什么这套系统在跑长流程任务时上下文消耗依然处于可控范围。3.4 关键参数调优参考多 Agent 系统里有几个参数值得重点调。我把我的经验整理成一张表参数作用我的建议值/参考范围备注温度控制 Agent 输出的随机性策划类 0.7~0.9调研类 0.1~0.3调研类要求事实准确必须低温策划类需要创意发散可以高温最大往返轮次限制 Critic 循环修订的最大次数2~3 次超过就直接跳过或人工介入防止死循环烧钱单 Agent 上下文上限限制每个 Agent 的 Token 预算根据模型调整一般 8k~32k配合压缩策略不要无限加并发 Agent 数量同时执行的任务数3~5 个太多会导致 API 限流问题后面细说检索 Top-K向量检索返回的参考片段数4~6 个太少信息不足太多噪音干忧这里要提醒一句参数没有一劳永逸的方案换一个模型或者换一个应用场景数值往往就要重新调。以温度为例我用 GPT-4o 和用 Claude 3.5 Sonnet 时创意类任务的最佳温度差了大约 0.2。4. 踩坑记录与问题排查实录4.1 Agent 死循环每次都会遇到的第一个坑我几乎是满怀信心地跑通第一个流程以后就撞上了多 Agent 的头号大坑——死循环。特别是 Critic 和 Writer 之间的修订循环Writer 改了一版Critic 觉得不够好又打回去Writer 又改Critic 还是不满意……我见过最多的一次同一篇方案稿被来回打回七次API 费用哗哗地流。解决死循环我用了组合拳第一在状态机层面加了最大往返轮次限制超过限制强制进入 END 并标记为需人工复核第二在 Critic 的 Prompt 里写明了你只能提出一个最关键的问题不要写清单式批注——因为一份反馈里如果列出七八个问题Writer 会无所适从改来改去反而改坏第三如果连续两次修订没有改善我会触发换人机制换一个全新的 Writer Agent 实例来重写有时候推倒重来比缝缝补补更高效。提示一切要烧钱的循环都必须设置硬性中断条件。不要相信模型下次就能改好要用代码兜底。4.2 上下文爆炸任务一长就失忆第二个让我头大的问题是上下文爆炸。表现为任务跑到后半段时Agent 开始失忆忘了前面的需求细节产出内容与最初目标明显偏离。排查之后发现问题出在我把历史消息一股脑全部传给了每个 Agent。当时项目里最夸张的一次某个 Agent 的上下文长度到达了可以支撑几十页论文其中大部分是早已处理过的中间产物。后来我在架构里明确了每个 Agent 只能看到与自身任务相关的信息子集研究员只需要拿到需求摘要和检索结果不需要看到后期视觉方案Writer 只需要拿到调研结论和策划框架不需要看到原始搜索材料。同时我用了一个较轻量的记忆机制把项目全局的关键信息提炼成一条项目状态摘要随流程传递其他历史数据一律不进上下文。做法参考def build_agent_context(agent_name: str, state: WorkflowState) - str: if agent_name researcher: return state.raw_requirement state.sources_compressed elif agent_name writer: return state.research_summary state.creative_brief elif agent_name designer: return state.creative_brief state.copy_text # 其他角色类似...这么一改失忆问题基本绝迹上下文消耗也降了一大截。4.3 角色漂移Agent 干着干着就不演了角色漂移是我自己起的名字指的是一种诡异现象Agent 在流程初期表现得非常符合它的角色定位但到流程中后期随着上下文反复更新它的行为开始变得不专业比如研究员开始输出营销建议文案开始解释技术原理。我一开始觉得很玄学后来想明白了——模型在高 token 量的上下文里对早期系统提示的注意力会被大量中间内容稀释。针对性解决方案有两个一是做上下文重锚定在任务中途把 Agent 的角色提示重新注入一次让人设重新醒过来二是把角色约束写得更强硬一点在每次消息传递时通过 metadata 里的phase字段告诉 Agent你正处在哪个环节、你现在该干什么。代码层面就是在每个 Agent 的 system prompt 前面动态拼接一段当前阶段指令SYSTEM_PROMPT f 你是{agent_role}你的职责是{agent_goal}。 你现在所处阶段{current_phase}。 本阶段你的任务是{current_task}。 注意只做与你角色和本阶段任务相关的事情不要越权行动。 效果非常明显。角色约束从一次性灌输变成了动态提醒Agent 的守序水平高了不少。4.4 幻觉与质量问题验证环节必不可少大模型的幻觉问题单 Agent 有多 Agent 也一样有而且多 Agent 里幻觉还会发生级联传播——研究员如果给了错误的数据文案会基于这个错误数据写出错误的内容设计师还会把这个错误做成视觉元素审核 Agent 如果没有外部知识做对照甚至可能觉得一切都挺好。我的对策是在流程中加入事实核查节点。系统里有一个专门的事实核查 Tool它会把关键数据点比如市场份额、用户量、价格自动提取出来然后用搜索 API 进行交叉验证返回验证通过或存疑标签。只有验证置信度达标的结论才允许被下游使用。这一步我强烈建议所有做多 Agent 生产的团队都加上因为它是防止一本正经胡说八道的最后一道防线。另外在设计审核 Agent 的时候在它的 Goal 里面明确写了一句你的评审必须基于事实依据不能凭借模糊印象给结论。如果发现关键论据无法验证应标记为存疑并要求补充。这比简单地写你是一位严谨的审核专家有效得多。4.5 常见问题速查表现象可能原因排查方向解决方案Agent 来回改个没完反馈信息太杂模型无所适从检查 Critic Prompt 的反馈格式单次只提最关键问题加最大循环轮次后半段产出质量骤降上下文被无关信息塞满检查 Agent 收到的历史消息按角色裁剪上下文注入项目状态摘要Agent 变得不专业角色提示被大量内容稀释查看中间轮次的输出风格消息中动态注入角色指令、阶段任务输出关键数据错误幻觉级联传播检查上游 Agent 的中间输出增加事实核查工具做交叉验证API 调用费用失控死循环或检索结果太长查看任务轮次和 Token 消耗日志设置轮次上限压缩检索内容控制并发两个 Agent 相互礼貌系统提示鼓励了协作但缺乏对抗性检查目标函数设计给 Reviewer 写入挑错导向的指令5. 成本控制与性能优化5.1 Token 费用账单怎么看、怎么省多 Agent 系统跑起来Token 成本是单 Agent 的 3 到 10 倍都不夸张因为你不仅在每个 Agent 上烧 token还有传递中间产物、重复交互的额外开销。我在项目初期就吃过亏——一个复杂的营销全案流程跑下来光 API 账单就够吃好几顿火锅了。省钱的核心思路只有一条让每个 Agent 只做它该做的事只说它该说的话。具体手段包括限制每个 Agent 的输出格式长度比如要求研究员输出要点式结论而非长篇分析报告把中间消息压缩成结构化摘要再传递以及为不同环节选择不同能力的模型。在我这套系统里重活策划、审核用旗舰大模型轻活信息提炼、格式整理用性价比更高的中小模型整体成本大概能省 20%~30%质量几乎没什么损失。另一个注意点是要给系统加单次任务成本预算。我的做法是在编排层记录每轮任务的 Token 消耗一旦超过预算上限就触发降级模式例如把后续环节切换到更经济的模型或者强制停止并输出已完成的部分结果。5.2 并行调度与依赖阻断任务拆解成多个子任务后我最初是老老实实按顺序跑的结果整个流程的耗时被拉得很长。后来我意识到不是所有子任务都有依赖关系。例如在做一份营销方案时竞品调研和用户访谈材料整理是可以并行的文案撰写则必须等在两者之后。我在编排层引入了一个简易的依赖图解析器Planner 输出每个子任务的 dependencies 列表调度器根据依赖关系找出哪些任务可以进入并行队列再用异步方式同时向多个 Agent 分发任务。实测下来当子任务数量在 5 到 8 个时并行调度能缩短大约 40% 的整体耗时。关于并发还要提一个坑API 并发不会无限扩张。我最初把并发数拉满结果吃了不少限流报错重试机制反而让耗时更久。后来我把并发控制在 3~5 个同时给每个请求加了带退避的自动重试整体稳定性提升非常明显。因为并发太大时不仅第三方 API 会限流模型偶尔也会因为输出内容过长而超时一旦超时整个环节都要重来其实非常亏。5.3 轻模型重调度大小模型搭配模型选型上不要千篇一律用同一个模型。我在agency-agents里的模型策略是大小模型搭配、按需分配策划、创意、审核等高认知环节用最强模型如 GPT-4o、Claude 3.5这些环节的产出质量直接决定最终交付价值不值得省。摘要压缩、格式重组、数据提取等低认知环节用中小模型即可。这些任务模式固定不要求创造力中小模型完全够用成本却能差出好几倍。工具调度、路由判定等纯逻辑环节直接走代码逻辑比如正则、字符串解析、规则判断不走 LLM零成本且确定性最强。举个例子最早我在做是否需要修订的判断时也是调用模型的后来发现这本质上是一个简单判定用规则就够了——比如检查审核结果里是否带有通过标记、是否存在标红的待改问题。把这些逻辑判断从 LLM 手里夺回代码层不仅省钱还消除了误判风险。6. 后续扩展与实践心得6.1 下一步可以怎么玩agency-agents目前的状态我自己定义为可以在生产环境稳定交付的版本。后面我还有几个想继续扩展的方向人对多 Agent 流程的人工介入节点在关键审核节点提供一个人工审批窗口让人看一眼中间产物再决定是否放行。这个对于客户交付型项目尤其重要很多客户不放心全自动流程。可追溯的反馈机制把每个 Agent 的产出、审核意见、修订记录完整保留下来做成一个可视化的项目流程回放既可以用作复盘也能在出现问题时快速定位责任环节。多项目并行调度目前的系统面向单任务跑流程我在想把它扩展成一个 CEO Agent 管理多个 Project Manager Agent每个 PM 带一个专属小组实现并行跑多个独立项目。引入记忆沉淀把一次项目执行中积累的知识比如某个客户喜欢的文案风格、某个行业的常用传播渠道沉淀到长期记忆库里让下一次同类项目的启动质量更高。6.2 个人实操中的几点体会到这里我这套agency-agents的设计思路、核心实现和踩坑记录基本聊完了。最后分享一点不吐不快的个人体会。第一多 Agent 系统的工程复杂度是真实的但它换来的质量提升也是真实的。如果你只是做一个演示 Demo单 Agent 就够了但如果你想把它放到真实业务里批量跑那流程控制、消息规范、上下文管理这些不性感的工程细节反而是决定成败的东西。第二以上所有实现里我认为最值得你第一时间抄走的一个是**压缩后再传递的消息策略**另一个是**最大循环轮次的保护机制**。这两个东西花不了多少功夫但却是把多 Agent 从玩具推向工具的关键一步。第三别怕从最笨的方案开始。我最早搞多 Agent 时也是一顿操作猛如虎试了很多框架和模式最后发现管用的往往是结构清晰、逻辑简单、收得住流程的方案。这个项目的名字我一直沿用到今天它提醒我Agent 机构做的是专业分工的活不是开派对的活。每一次让模型输出之前先问一句这一步如果是一个真实团队在做应该由谁来做答案自然就有了。