团队里来了五个“虚拟工程师”代码照样出问题但你再也找不到人来背锅——因为锅被拆成了五份每一份都来自同一个大模型。这就是我最近在推进的多智能体协作系统Agency Agents落地的真实体感。先说清楚这篇东西写给谁看你已经用过大模型写代码、写文档觉得单人单Agent的体验已经到瓶颈了或者你正在规划把AI Agent引入研发流程但不确定多Agent到底解决什么问题、架构怎么定、落地哪些坑又或者你纯粹好奇“AI开发团队”是怎么运作的。这篇不会复述官方文档只讲我们在做“重构开发团队”时从架构设计到真实落地踩过的坑、用过的方案、定下来的配置以及一个很重要的认知多Agent不是把多个AI凑在一起而是要把“软件开发”这件事拆成一套可编排的流程。1. 为什么“开发团队版”的多智能体系统会成为一个选项1.1 单Agent的瓶颈不是能力不够是目标太模糊用GPT-4级别的模型写代码单个Agent最大的问题并不是“写不出来”而是“没人管它写出来的东西符不符合上下文要求”。举个例子让一个Agent开发某个订单系统的结算模块。它会很乖地生成一个结算类的代码文件但大概率会漏掉前一个模块里已经定义好的金额精度约定、数据库表字段命名规则更不会主动去看测试目录里已有的测试风格。为什么因为单Agent的上下文窗口再大也装不下“整个项目全部上下文”而且它没有内在动力去主动拉取那些约束信息。我一开始的解法是穷举提示词把命名规范、模块依赖、测试风格全部写在一个system prompt里。效果是提示词长到几千字模型输出质量反而下降加上新需求后提示词越来越难维护换一个项目之后几乎不能复用。这不是提示词工程能解决的问题这是架构问题——你需要把上下文拆解开让不同角色各自关注不同切片再通过协作动作合并最终结果。1.2 多Agent协作到底解决什么问题多Agent协作系统本质上是在做“软件开发流程的编码化”。它把传统研发中PM产品经理、后端工程师、前端工程师、测试工程师、代码评审员各司其职的方式映射到多个各带独立提示词和工具权限的Agent实例上。这样做得到的几个直接收益上下文聚焦。每个Agent只关注自己职责范围内信息上下文窗口压力大减输出质量显著提升。责任可追溯。哪个模块出了问题可以定位到是哪个Agent在哪个环节产出的错误。流程可编排。从需求解析到编码再到测试验证整个流程变成了一套可定义、可重复执行的流水线。但这背后也隐藏着一个关键代价编排复杂度。多个Agent之间如何通信、如何共享上下文、如何避免冲突、如何收敛结论这些单Agent时代完全不存在的问题会全部爆发出来。1.3 落地前必须想清楚的三个问题在动手搭建之前先想清楚三个关键问题否则后面大概率翻车。第一团队重构的目标到底是“效率”还是“质量”如果是效率那多Agent不一定比单Agent更快因为编排层会带来额外的token消耗和系统开销主要提升的是并行处理能力。如果是质量比如减少低级错误、提升代码规范一致性那么多Agent的效果会非常明显。第二你是否已经跑通单Agent的最小闭环我见过不少团队直接上多Agent结果分不清问题出在模型能力还是编排逻辑。理性的路径是先用单Agent把某个任务做到“能用”再拆成多Agent来优化“质效”。第三你的任务是否是可分解的多Agent适合的是能清晰拆分成多个独立关注点的任务——写一本书、开发一个模块、分析一份财报。如果任务本身几十行代码搞定强行拆成多个Agent纯属浪费token。注意多Agent不是银弹它是把“流程复杂度”和“模型能力不确定性”做了一次解耦。流程乱了可以改编排模型抽风了可以换模型但如果你的任务本身不可拆分这整套架构就是负担。2. 核心架构拆解五个角色与三层编排2.1 角色设计模仿的不是组织结构是信息流先看我们最后定下来的角色结构一共五个角色核心职责需要的关键信息是否接工具需求分析师解析输入需求产出用户故事用户原始输入否架构师确定技术方案、模块划分、接口设计用户故事 代码库结构是读取项目树编码工程师按架构设计生成代码实现用户故事 接口定义 模块规范是写入文件、执行命令测试工程师编写测试用例并验证实现代码 用户故事 测试规范是执行测试脚本评审员审查代码质量与需求覆盖全部产出物 质量规则是读取产出物这里要说明关键决策我们没有照搬一个真实的软件公司组织架构而是按“信息流”来设计。需求分析师产出的用户故事是给架构师看的架构师产出的接口定义是给编码工程师看的编码工程师的代码是给测试工程师和评审员看的。每相邻角色之间存在清晰的“契约接口”这样每个Agent的输入输出都是结构化的。如果你照搬真实组织架构加一个“项目经理”角色去催进度加一个“文档工程师”角色去写说明——你会发现Agent之间通信的token开销远远大于它带来的信息增益。真实公司里加角色是为了管理人和利益Agent系统里加角色是为了切分上下文场景完全不同。2.2 三种编排模式的取舍多Agent协作系统的核心是编排层Orchestrator。我们实践中对比过三种编排模式各有适用场景。第一种是“顺序流水线”。Agent A的输出直接作为Agent B的输入依次执行。优点是流程简单逻辑清晰调试方便缺点是任何一步失败整个任务终止且无法并行。适用于流程稳定、上下游依赖强的任务。第二种是“星型协调”。一个主控Agent负责任务调度把不同子任务分发给多个专门Agent并行执行最后汇总结果。这种模式在提升并行度上非常有效但要防止主控Agent成为瓶颈同时对模型能力要求极高——主控输出的调度指令质量直接决定全局结果。第三种是“图状编排”。任务被建模为有向图节点是Agent动作边是数据依赖。它能够支持条件分支、循环、并行分支汇合等复杂流程灵活性最高但调试成本也最高。我们最终采用了一种混合方案宏观上用图状编排定义主流程微观上在单个节点内部采用顺序流水线。举个实际例子需求解析节点内部先让需求分析师拆解用户故事再由架构师产出技术方案这两个动作严格串行而跨模块的编码节点中不同模块的编码Agent会被并行调度。2.3 通信机制与共享记忆最容易翻车的部分这是整个架构里最核心也最容易踩坑的环节。Agent之间的通信有两种方式一种是“完全共享上下文”把前面所有Agent的输出全部拼接给下个Agent另一种是“结构化传递”只传递约定的输出字段。共享上下文的问题是token消耗呈线性增长且大量不相关信息会干扰模型判断。特别是评审Agent当我们把需求文档、代码实现、测试报告全部塞进去后它的审查质量反而急剧下降——因为它的注意力被无关信息稀释了。结构化传递则要求设计好“中间产物协议”。我们参考了函数式编程的思路——每个Agent的输出函数签名是固定的评审Agent输入{原始需求, 用户故事, 代码diff, 测试结果} 评审Agent输出{是否通过, 问题列表[], 修改建议[]}这样每个Agent都像一个定义良好的函数可单独测试、可Mock、可替换。代价是需要多花一点时间定义中间格式但长期看收益巨大。关于共享记忆我们踩过坑后发现每个Agent需要完全隔离的记忆只有经过“发布动作”的信息才能传给下游Agent。就像真实团队里后端工程师不会直接看用户原始吐槽记录他拿到的应该是产品经理整理后的需求文档。这是我们最终保留的共享上下文信息流用户需求 → 需求解析结构化 → 架构设计接口文档 → 编码代码diff → 测试测试报告 → 评审结论3. 从零搭建这套系统核心环节的实操记录3.1 搭建Agent工厂一切皆配置不写死Agent逻辑而是把Agent定义建模成一份JSON配置由工厂函数加载生成。这个设计让我后续调试节省了大量时间。配置文件的核心结构不复杂但有几个字段特别值得设计model不同角色用不同模型。需求分析师和架构师我们用推理能力最强的模型编码工程师用代码能力最好的模型评审员用综合能力最强的模型。全用同一个模型不仅浪费在某些环节效果还更差。system_prompt这是区分角色最核心的地方。需求分析师的prompt强调不做过度设计、只提取关键业务诉求编码工程师的prompt强调接口文档先行、不擅自修改契约评审员的prompt强调只评不修、但须给出具体修改建议。tools按角色精确控制工具权限。测试工程师有执行python脚本的权限编码工程师有写文件的权限需求分析师则完全没有工具权限。memory每个Agent独立维护自己的对话历史。经验数值测试工程师的上下文保留最近10轮对话就够了评审员需要完整保留从需求到代码的全链路所以它用的是持久化存储而不是上下文传递。3.2 中间产物协议任务拆解是核心引擎系统设计中最耗时的不是写Agent提示词而是定义中间产物的数据结构。我们最后采用了“四层产物”方案第一层是“用户故事”列表需求分析师输出。每个用户故事格式固定为“作为XX角色我希望XX能力以便获得XX收益”。这个格式看起来老套但它非常有效——架构师读起来信息提取效率极高。第二层是“架构方案”架构师输出。必须包含模块划分、核心数据结构、接口签名草案。关键约束是架构方案必须能覆盖所有用户故事如果有用户故事没有对应技术实现方案属于不通过。第三层是“接口与契约文档”架构师输出。这是编码Agents的唯一技术依据。我们遇到最大问题是编码Agent经常会“自由发挥”比如擅自修改数据库表字段名称、补一个自以为更好的函数参数。解决办法很简单——契约文档一旦发布编码Agent的prompt中明确标注“只能按契约实现不得修改已有接口定义”。第四层是“测试报告”与“评审结论”分别由测试Agent和评审Agent输出。测试报告包含通过率、失败用例清单评审结论包含是否通过、问题列表和修改建议。3.3 循环终止防止Agent陷入“修改-再评审”死循环多Agent系统中最让人崩溃的问题是死循环。编码Agent提交代码后评审Agent发现一堆问题编码Agent改完再提交评审Agent又发现新问题……我们一开始直接限制最大循环次数为3轮效果很差——要么在质量问题还没解决时就强行退出要么在已经解决时白白多跑一轮。改进后的方案是“信号灯机制”。评审Agent的输出不仅包含问题列表还包含问题严重度标记P0阻断级、P1重要级、P2轻微级。循环终止的条件修改为没有P0/P1级问题或已达到最大循环次数。更细的调整是编码Agent在生成修改方案前先输出“问题理解摘要”把我们计划通过回合校验收敛第1轮评审找出P0/P1问题要求解除评审Agent的“只评不修”限制直接给出建议修复的代码片段。第2轮确认修复后新增问题是否为零并且P2级问题的“风险提示”是否有必要处理。第3轮以后只做P0阻断级问题的跟踪。对Agent的prompt里明确写了“你将收到多轮评审意见请优先处理P0和P1问题对P2问题如无明确修改理由可标注为暂缓”。3.4 外部工具集成沙箱带来的收益和代价编码Agent直接写本地文件风险极大我们必须让它在一个隔离的沙箱环境中执行工具调用。操作系统用的是轻量级容器每个Agent执行一个独立实例。实践中有两个细节值得记录第一个是代码执行权限控制。测试Agent执行测试脚本时给它配置了“只能运行tests/目录下的文件”的白名单规则并且在沙箱内设置网络禁用。这直接阻止了几次测试脚本尝试联网下载依赖的情况。第二个是文件写入路径隔离。每个Agent有独立工作目录Agent之间不能直接读取对方目录必须通过共享产物协议传递数据。这样每个Agent的工作内容都是显式的输入输出map映射方便审计也方便回溯。代价是沙箱环境与本地开发环境的依赖不完全一致可能出现“沙箱里跑通了本地跑不通”的情况。我们的缓解方案是同步项目依赖锁定文件到沙箱每次沙箱初始化时先执行一次依赖安装。4. 常见问题与排查实录4.1 上下文污染最隐蔽的质量杀手这是全套系统中出现频率最高的问题。症状表现评审Agent明显偏心对编码Agent产出总是给出“通过”。排查后发现是因为评审Agent与编码Agent共享了部分对话历史评审看到了编码Agent的思考过程在做客观判断时被影响了。彻底解决方案所有Agent之间的通信只能通过结构化产物协议禁止任何Agent直接访问其他Agent的对话历史。共享信息只有“发布”到内存总线上的结构体其他Agent读取到的是序列化后的JSON字段而不是原始的推理过程文本。4.2 Agent“自说自话”导致流程空转出现过一次印象深刻的故障编码Agent输出了大量代码文件但测试Agent迟迟不执行测试而是重复输出“我已经检查了代码逻辑完整性”。原因是测试Agent的prompt中同时包含了“检查代码”和“执行测试”两个职责模型决策策略混乱选择了风险更低的行为。修复方式是把“检查”和“执行”拆成两个独立Agent或者用工具调用强制绑定。最终我们选择了强制绑定——测试Agent的prompt中明确写“只有执行工具调用返回结果后你才能输出测试报告”。4.3 token成本失控一天烧掉三倍预期这个问题非常现实。多Agent协作模式下同一份需求会被多个Agent重复处理token消耗成倍放大。我们统计过一个中等复杂度功能模块需求解析消耗约5k token架构设计约12k token编码实现约25k token测试评审约20k token整体下来一个模块要消耗6-8万token。成本优化做了三件事模型分级把token单价最低的模型分配给需求分析师最贵的模型只用于关键评审环节。摘要压缩Agent之间的传递数据不保留完整对话记录向下游Agent传递的是“结构化摘要”而不是“完整记录”。例如编码Agent的上下文只保留契约摘要而不是架构师的完整推理过程。输出格式强约束要求Agent必须输出固定格式的JSON结构避免输出无关的“思考过程”。在prompt里加了一句话“不要输出任何解释只输出JSON字段”token消耗直接降了约20%。4.4 并发冲突多个Agent写同一个文件的“竞态问题”当两个编码Agent被并行调度时可能出现同时写入同一个文件、互相覆盖的问题。初期的粗放做法是加全局锁——同一时间只允许一个Agent写文件。但这样并行度就没了多个Agent的优势被削弱。后来的方案是“文件级锁 写前合并”。每个Agent在写入文件前先检查目标文件是否有其他Agent正在修改如果有先pull最新版本到本地工作区再基于最新版本做修改。这就模拟了真实团队中常用代码管理工具的操作习惯——先同步主干再改分支。文件锁的粒度需要按实际情况调。如果锁粒度太大整个仓库一个锁相当于回到串行锁粒度太小单行锁实现复杂度飙升且死锁概率增大。我们最终定的是“目录级锁”至少同一目录下只有一个Agent在执行写操作。5. 工程化落地经验多Agent系统投入研发流程的取舍5.1 团队工作流消化不是替换人是替换“局部重复劳动”把多Agent系统接入实际研发流程之后我最深刻的一个体会是它不会直接取代任何一名开发工程师它取代的是工程师身上“局部重复劳动”的部分。举个例子在我们内部某个业务模块的需求流转中过去需要人工整理用户反馈、编写规格说明、拆分模块依赖、检查代码风格。这套系统接进去之后需求分析师和架构师两个Agent基本承担了“从用户反馈到技术需求卡片”的整理工作相当于把一个技能熟练但重复度高的初级分析师角色自动化了。开发工程师拿到的是一份结构化的输入而不是原始的用户反馈认知负担直接降低。但要注意这套系统并不擅长“大需求”。需求模糊度高、涉及跨多个模块重构、团队内部政治因素强需要调和不同组利益的任务我建议还是人工主导。Agent适合的是“需求边界比较清晰、产出物可以客观验证”的任务。5.2 评估指标体系不能只看“生成了多少代码”用线性的“生成代码行数”来衡量多Agent系统价值是极其危险的。我们初期踩过这个坑——编码Agent在无测试约束的情况下生成了大量冗余代码看起来“产出很丰富”实际有一大半不可能通过评审。后来我定了一套评估口径需求覆盖率用户故事列表中的每个子项是否都有对应的代码实现。测试通过率新代码能否通过已有的自动化测试。评审返修率第一次评审就通过的模块占总任务的比率。人均产出效率对比引入系统前后同规模团队处理类似需求的天数变化。有意思的是“测试通过率”是最灵敏的指标——只要把这一个指标卡住代码质量就有保障。因为编码Agent为了让自己提交的代码通过测试会主动约束自己的输出质量不再无脑生成“看起来对但跑不通”的代码。5.3 边界意识什么坚决不能交给Agent在投入这套系统半年之后我整理了一份“坚决不交给Agent”的清单供你评估时参考涉及用户隐私数据读取、鉴权逻辑变更的任务。Agent在沙箱中能操作的只是脱敏数据但真实的鉴权变更涉及安全评审不适合自动化。对外承诺变更。比如改API返回值、变更数据模型的字段含义这类决策可能影响其他团队下游系统人工评审不可跳过。生产环境的直接变更。Agent执行的所有步骤限定在测试副本环境生产环境发布仍坚持人工确认加审批。价值判断型决策。比如“这个功能是否值得做”这类业务价值判断模型并不能理解战略背景做了也只是“基于概率的预测”。这套系统真正能帮到人的是缩短从“需求到手”到“初步产出物可评审”这个阶段的时间而不是替你做决策。6. 结语当前认知与下一步实验方向6.1 我对多Agent系统的重新理解经历了从单Agent到多Agent的架构升级后一个重要的认知转变是多Agent系统本质上是一套“上下文管理协议”而不是“模型能力叠加协议”。让我解释一下单个模型的推理能力在任务难度上是有明确上限的即使你叠加10个Agent每个Agent调用的还是同一个模型家族单个Agent的推理能力并不会变强。多Agent真正改变的是信息如何流动——把大量信息切碎后按需分发有效缓解了单次推理的上下文过载让每一次推理都更聚焦。所以如果你发现单Agent回答质量不行别急着上多Agent先检查是不是任务描述不清晰、上下文太冗长。如果单Agent质量已经可接受只是想处理更大规模的信息、更长的任务链、更复杂的过程控制那么多Agent是值得投入的方向。6.2 几个可以深入扩展的方向最后分享一下后续我打算继续推进的几个方向第一跨Agent的长期经验沉淀。目前每个任务完成后经验只保存在评审Agent的结论中没有被系统性地沉淀到Prompt库。我在尝试做一个“经验回写”动作——每个任务结束后自动抽取“哪些规则值得固化”更新到后续任务的Prompt模板中。这就相当于不断积累团队规范而不是每次从零开始让Agent摸索。第二自适应编排。现在的图状编排是人工定义的哪一步失败就重试哪一步成功就继续。下一步我计划引入一个“调度Agent”来自动决策编排路径——它能根据当前任务的上下文执行情况动态决定是不是需要额外拆解、是不是要增加一轮评审。第三多模态Agent的引入。目前的系统完全是文本和代码。但对于一些涉及UI界面还原、图像内容理解的任务测试Agent和评审Agent往往表现得不好因为它们看不到实际界面长什么样。下一步计划引入视觉能力直接让评审Agent“看”渲染后的UI效果和交互结果这会大幅提升前端相关任务的完成度。这套系统的架构与落地经验本质上是把软件开发团队中“信息流转、角色分工、质量校验”这套行之有效的组织方法论做了一次工程化迁移。它是有边界的也是快速迭代的。在做这类系统的迭代时保持对“失败归因”的耐心比追求一次性完美更重要。