你有没有遇到过这种情况同时维护好几个项目每个项目都有一堆重复又琐碎的开发任务。改接口、补文档、写测试、修 bug单看哪一件都不大可全部加起来能把人活活耗死。我之前带过一个小团队三个人配合着干刚好能转起来后来因为种种原因团队散了活儿还在账面上又不可能立刻招人。那段时间压力特别大我就在想一个问题——既然一个开发小组的分工协作机制这么成熟能不能把产品经理提需求、架构师拆任务、工程师写代码、测试人员验质量这套流程直接搬到 AI 智能体上去后来我花了几周时间真的把这个想法落地了。也就是这篇博文要聊的Agency Agents 多智能体协作系统。它不是某个现成的开源框架而是我基于大模型能力自己设计、搭建的一套多智能体协作系统。核心思路很简单把不同职责的智能体组合成一个虚拟开发团队让它们像真实团队那样通过消息传递、任务分派、结果审查来协作完成具体项目。这篇文章我会把整体架构、设计思路、落地实操和踩坑记录全部拆开讲适合被重复开发工作淹没的个人开发者、小团队技术负责人以及对多智能体系统感兴趣的开发者。1. 为什么我决定把开发团队重构为多智能体协作系统1.1 传统开发协作的核心矛盾传统软件开发的协作模式本质上依赖人作为信息传递和任务执行的核心节点。需求评审要开会任务拆解要开会代码评审要开会上线前还要开会。会议本身没问题问题在于人的精力是有限的而且上下文切换成本极高。我当时的真实情况是一个项目正在改支付模块另一个项目的用户反馈要处理第三个项目的版本要发布。每次切换脑子都得重新加载一整套上下文至少 15 到 30 分钟才能回到状态。一天 8 小时工作光是上下文切换就损耗掉一大块。更难受的是很多任务本身并不需要多么高深的创造力——按已有规范写接口、按测试用例修 bug、按模板补文档这些活儿重复性很强但又必须有专人盯。我试着靠各种效率工具去改善比如自动化脚本、代码模板、CI/CD 流水线。但工具解决的是执行效率问题解决不了分工协作问题。依然需要一个角色去理解需求、拆解任务、把结果串起来而这个角色只能是人。1.2 多智能体协作系统到底能做什么多智能体协作系统的核心不是用一个更强的 AI 去替代人而是用一组有明确分工的 AI 智能体去模拟一个团队。它和我之前尝试过的单一大模型处理任务的方式有本质不同。单个大模型处理复杂任务时最大的痛点在于上下文窗口有限而且模型在超长任务链中容易忘记最开始的目标。比如你让一个模型开发一个用户注册功能它会尝试做需求分析、架构设计、写代码、写测试、写文档但做到一半往往就跑偏了——要么实现方式偏离原始需求要么写出来的代码和之前约好的技术栈不一致。这就是典型的全能单点模式所有事都丢给一个模型它承受不了认知负载。Agency Agents 的思路是把任务按职责拆开。需求分析智能体只负责把模糊表述转化为清晰的需求条目它不用写代码编码智能体只负责按照给定的技术方案和任务描述实现功能它不用纠结产品定位审查智能体只负责找问题它的目标是挑出代码里的缺陷和隐患不必考虑怎么修改更合理。就像真实团队里测试人员的思维方式和开发人员本来就该不一样。这样做有四个直接好处上下文隔离每个智能体只处理与自己职责相关的信息不被无关细节干扰。专业化每个智能体的系统提示词和工具集都针对单一职责深度优化而不是什么都会但什么都不精。可追溯每个任务从创建到完成的流转过程全部有记录问题可以精准回溯到某个环节。并行扩展多个任务可以同时在不同智能体之间流转理论上可以线性扩展处理能力。1.3 我的设计目标与整体思路搭建之前我给自己定了五个目标后来证明这五个方向基本都踩对了第一必须能真实落地不能停留在 demo 层面。也就是说这套系统必须能接入真实的代码仓库、能运行测试、能产出可合并的代码。第二人在环中。AI 智能体可以负责脏活累活但关键节点必须有人审批。没有人把关的自动编程在当前阶段就是给自己埋雷。第三流程可配置。不同项目、不同任务类型需要的协作流程不一样。修 bug 和开发新功能流程应该不同。第四成本可控。大模型 API 调用不是免费的多智能体系统天然比单次调用消耗更多 Token所以必须从架构层面做好成本控制。第五可观测。智能体之间到底在聊什么、每个智能体为什么做出某个决策这些日志必须能看到。黑箱系统没法排查问题。带着这些目标我开始了整体架构设计。接下来重点拆解这套系统的核心模块。2. Agency Agents 核心架构深度拆解2.1 角色智能体把岗位职责写进系统提示词角色智能体是整个系统最基本的单元。每个智能体本质上由四部分组成角色定义、系统提示词、工具集、记忆空间。角色定义解决的是这个智能体是什么的问题。我给每个智能体取一个明确的角色名比如需求分析师、架构师、编码工程师、测试工程师、代码审查员、发布管理员。角色名不是随便取的它直接影响了后续任务路由和管理层调度。系统提示词是角色智能体的灵魂。就以编码工程师为例它的提示词里明确规定了使用规范的项目目录结构和命名约定必须遵循架构师给出的技术方案不得擅自更换技术栈输出代码时需要附带简要说明解释关键实现逻辑如果发现需求描述不清晰必须向任务发起方反馈不能强行猜测我见过不少用多智能体系统的开发者在设计提示词时犯一个错误把提示词写得非常长事无巨细都往上堆。实测下来太长的提示词并不会让智能体变得更强反而会稀释核心指令的权重。这里的关键是少数关键约束 清晰的角色边界。每个智能体只需要深懂自己的职责不需要把所有其他角色的工作规则都装进脑子里。工具集的配置要跟着职责走。编码工程师只挂代码读写、命令执行、搜索这些工具测试工程师除了代码工具还额外挂了测试框架调用、覆盖率统计的工具发布管理员则挂打包、构建、通知类工具。给每个智能体配工具的原则是够用就好权限最小化。挂一堆用不上的工具一方面浪费上下文空间另一方面增加了误调用的风险。角色智能体的定义我会在第三节用配置样例详细展示。2.2 通信机制消息队列与共享黑板的取舍多智能体系统要协作就必须有一套可靠的通信基础设施。我在设计初期考虑了两种主流方案也建议所有做多智能体的朋友都认真权衡一下这两种方案。第一种是消息队列模式。每个智能体独立运行通过一个中心化的消息总线收发消息。智能体A 完成某个任务后把结果以消息形式发到总线上订阅了相关主题的智能体B 会自动收到这条消息并开始工作。这种模式的优点是解耦干净、天然支持异步和并行缺点是需要额外维护一套消息基础设施而且消息流转链路过长时排查问题会比较费劲。第二种是共享黑板模式。所有智能体共用一个状态存储空间——也就是黑板大家都往上面写内容也从上面读取自己需要的信息。这种模式非常直观适合任务链路相对固定的场景。但它有个明显的坑黑板内容一旦多起来每个智能体读取时都会被无关信息干扰Token 消耗也会跟着涨。我最终采用的是混合模式。整体协作框架用消息队列驱动但每个任务在队列中流转时会附带一个共享的任务黑板里面只记录当前任务的核心数据比如需求描述、技术方案摘要、代码变更清单、检查报告。智能体之间不直接传递大段内容而是传递指向黑板某条记录的引用。这样做的好处是消息体很小、传输快同时需要上下文时又能快速从黑板上拿到完整信息。通信协议的标准化也很重要。我定义了一套统一的任务消息结构包含task_id、sender、receiver、task_type、content_ref、status这些字段。所有智能体发送和接收的消息都遵循这套结构。这样一来后续做日志分析、任务追踪、异常回溯都会轻松很多。2.3 任务编排从流水线到动态路由有了智能体和通信机制接下来就是怎么安排工作流。任务编排方式直接决定了系统的灵活度和稳定性。我最开始用的是固定流水线。以开发一个新功能为例需求分析 → 架构设计 → 编码实现 → 测试验证 → 代码审查 → 合并发布一个接一个执行。这种模式的好处是简单可靠每个环节都知道自己的前序和后续。但很快我就发现了问题并不是所有任务都需要走完整条流水线。修一个小 bug功能范围非常明确压根不需要需求分析和架构设计。如果也走完整流水线来回调用六七个智能体成本高、周期长纯属浪费。所以我在流水线基础上引入了任务类型路由。系统启动时预定义了几类常见任务模板简单修复、功能开发、技术调研、文档编写每类任务走不同的智能体组合。这有点像真实团队里的工单系统不同类型的工作单派给不同的人而不是所有人都走同一套流程。再进一步在一些特别复杂的任务里固定路由也会不够用。比如架构师拆分任务时发现某个模块技术风险较高需要先做一个技术验证。这时系统不能机械地按原计划走而需要动态路由。我的做法是让架构师智能体在拆解任务时有权在输出中标记需要前置验证的子任务并把该子任务单独路由给编码工程师验证结果再回到架构师手里作为后续设计的依据。任务编排的复杂度要逐步增加不要一上来就整一套完全动态的图编排系统。除非你的场景确实需要否则固定流水线加少量路由规则已经能覆盖绝大多数开发协作需求。2.4 记忆分层短期会话、长期档案与全局知识库多智能体系统另一个容易被忽视但又极其重要的模块是记忆管理。没有记忆的系统每个任务都像失忆症患者一样重新学习一遍项目背景效率和正确性都会很差。我按信息类型和生命周期把记忆分成了三层第一层是短期会话记忆。指单个智能体处理单个任务时的对话上下文任务结束就清空。这一层直接吃 Token也是成本控制的主要对象。我通过控制每轮最大 tokens、自动总结中间过程来控制增量成本。第二层是长期档案记忆。给每个项目建一个档案记录项目的技术栈倾向、代码风格约定、已完成模块清单、常见坑位记录。智能体在执行任务前会主动检索档案获取在这个项目里应该怎么做的项目级规范。这些档案由专门的文档智能体定期更新来源是代码审查记录和发布总结。第三层是全局知识库。跨项目的通用知识比如团队规范、行业标准、常见算法模板、公司内部组件库用法。我用向量数据库存储通过语义检索按需取出最相关的内容。三层记忆配合起来实测效果非常明显。同样一个增加一个列表页需求如果编码工程师能在一开始就检索到项目里已有的分页组件规范和 API 封装模式它写出来的代码和项目现有代码风格高度一致审查智能体挑出的问题也少得多。3. 落地实操从零搭建一套可用的多智能体开发团队3.1 基础环境与组件选型理论讲再多不落地都是空谈。我把自己从零搭建这套系统的过程完整记录在这里你可以直接照着做。首先说基础环境。我用的是一台普通的开发服务器32G 内存Linux 系统。多智能体系统本身对硬件要求不高大部分计算发生在大模型 API 端本地主要跑调度逻辑、消息队列和工具执行。真正吃资源的是代码执行沙箱所以我会建议服务器至少 16G 内存以上。组件选型上我坚持一个原则不引入自己维护不起的复杂组件。消息队列我用了轻量级的方案——基于 Redis 的 Stream 实现。Redis 很多开发者都很熟部署简单Stream 数据结构天然支持消息持久化和消费者组足够支撑小团队的多智能体调度需求。大模型接入我选的是某主流大模型服务具体是哪家不重要关键是它提供了稳定的 API 接入和函数调用能力。函数调用是多智能体系统的核心能力模型需要能够根据工具描述决定调用哪个工具、传什么参数。整体架构分为四层接入层接收外部任务请求比如来自项目管理系统、Git 提交钩子、或者手动提交的开发指令。编排层核心调度逻辑负责任务模板匹配、状态维护、智能体路由。执行层角色智能体运行时每个智能体一个独立工作进程通过消息队列接收任务。工具层各类外部工具封装包括代码文件读写、Shell 命令执行、Git 操作、代码搜索、API 调用等。3.2 定义智能体角色、工具与目标约束智能体的定义我用的是 YAML 配置加少量代码实现。每个智能体配置包含角色元信息、系统提示词路径、工具清单、输出格式约束。下面是一个编码工程师智能体的简化配置示例agent: name: coder role: 编码工程师 description: 负责按照任务描述和架构方案实现代码变更 system_prompt: prompts/coder.py memory: short_term: shared_task_blackboard long_term: project_archive global_kb: vector_store tools: - read_file - write_file - run_command - git_diff - code_search output_schema: type: object_fields fields: - summary - changed_files - test_results - notes配置里有个容易被忽略的点output_schema。这是我在踩了好几次坑之后加上的。没有强约束时编码智能体的输出五花八门——有时候输出一大段废话有时候只给一个代码写完了的结论根本没法程序化解析。给每个智能体定义严格的输出字段后续流程才能稳定串联。编码工程师的核心执行逻辑也不复杂简化后的伪代码如下async def run_coder_agent(task): # 1. 从任务黑板加载任务上下文 context load_context(task.content_ref) # 2. 检索项目档案获取项目规范 project_spec retrieve_archive(task.project_id) # 3. 构建消息序列 messages build_messages(agent_prompt, context, project_spec) # 4. 循环调用大模型直到工具调用结束或达到最大轮次 while not task_finished and round max_round: response call_llm(messages, toolsagent_tools) if response.has_tool_calls: messages.append(run_tool_calls(response.tool_calls)) else: break # 5. 按输出 schema 格式化结果 result normalize_output(response) # 6. 发布消息到下一个环节 emit_task_completed(task.id, result)这里最核心的是循环调用大模型那一步。大模型不是一次调用就能完成整个编码任务的它需要先看代码仓库结构、再读某个文件、做一下搜索然后才决定怎么写。这个过程就是靠模型返回工具调用请求 → 执行工具 → 把结果传回模型 → 模型再决策的循环来实现的。这个循环一定要设置最大轮次限制我一般设置为 20 轮超过就自动终止并把当前状态上报给人工。3.3 协作流程落地以自动实现用户注册功能为例理论说够了我带你走一遍完整流程。假设外部系统提交了一个任务——在某跨平台消息系统中实现用户注册接口支持手机号和验证码方式。任务进入编排层后编排器识别出这是一个功能开发类型任务于是实例化一条功能开发流水线。第一步需求分析智能体处理原始需求。它检索了项目档案中关于用户体系的文档发现系统已有短信服务模块于是在需求说明中补充了一项约束验证码发送复用现有短信服务接口不得新接第三方服务。这个判断很关键它避免了后续编码阶段重复造轮子。第二步架构师智能体接手产出技术方案。它拆解出三级任务清单新增用户表结构、实现注册接口、编写验证码校验逻辑。每个子任务标注了涉及的文件和接口约定。架构师还特别标记了注册接口需要事务控制创建用户和初始化用户配置必须同事务。第三步编码工程师智能体领取任务。它先在工作分支上更新代码通过代码搜索定位到用户模块的现有代码发现项目里统一使用某种 ORM 框架于是按照现有风格写好了实体类、Mapper 接口和 Service 实现。执行完单元测试验证通过后它会提交一个 merge request并附带变更说明。第四步测试工程师智能体开始干活。它并不仅仅看已有的单元测试而是会先审查需求分析然后补写用例覆盖异常分支——验证码过期、手机号已注册、短信服务超时。过程中它发现编码实现中有一处潜在的空指针风险于是把它记录下来。第五步代码审查员智能体把编码实现和测试报告放在一起做终审。它的职责是找问题而不是修问题所以它的输出是一份审查报告列出必须修复项和建议优化项。编码工程师根据报告修复后再提交审查通过后发布管理员智能体合并代码并触发 CI 流水线任务完成。整个流程里我作为人在环中的角色只需要在流水线开始时确认需求边界以及在最后合入生产分支前做一次人工审批。中间所有脏活累活都是这套多智能体协作系统完成的。实测下来一个中等复杂度的接口功能从提交需求到代码合入大约 10 分钟。同样的工作量我手动做大概需要一上午。3.4 人在环中人工审批与干预机制的嵌入设计多智能体系统时最容易犯的错是过度自动化。以为系统能自动把活干完人就彻底撒手不管了。我的经验是自动化的边界应该划在纠错成本较高的节点之前。我在系统里嵌入了三类人工干预点第一类是需求确认节点。任务启动后需求分析智能体产出的需求说明会推送到我的终端我做一次确认才继续。这个节点不能省因为后续所有环节都以这份需求为最高依据一旦方向错了返工成本极高。第二类是高风险操作审批节点。涉及生产分支的合并、数据迁移脚本的执行、依赖包的升级这些操作无论前面智能体做得多么顺利都必须过人工审批。我实现了两个独立审批通道一个是常规审批 API另一个是紧急情况下的全停开关。全停开关一旦触发所有智能体暂停任务等待人工接管。第三类是异常上报节点。虽然我想尽办法让流程自动化但总会有意想不到的情况。我的处理是任何智能体在执行过程中遇到 schema 校验失败、工具连续报错、任务轮次超限等异常不是自己无限重试而是立即把异常信息上报到人工队列。宁可人肉处理慢一点也不要让错误自动蔓延。3.5 监控与观测让每次协作都有迹可循多智能体系统上线第一天我就意识到没有监控系统寸步难行。因为智能体之间大量通过消息队列通信如果某个环节消息丢了或者处理卡住了不看到完整链路根本不知道问题出在哪。我做的第一件事是给每个任务分配全局唯一的trace_id并且要求所有日志都带上这个 ID。从任务创建、每次智能体调用模型、每次工具执行、每次消息转发全部记录时间戳和状态。排查问题时只需要按照trace_id拉取整条链路的时间线一眼就能定位瓶颈和故障点。第二件事是统计所有智能体的 Token 消耗和耗时。我按任务类型、按智能体角色做了汇总。比如功能开发任务里哪个角色消耗 Token 最多是编码工程师吗实测下来往往不是反而是审查类智能体因为审查需要读取大量上下文。这个数据非常有用后面做成本优化全靠它。监控面板上我主要看四个指标任务吞吐量每小时完成多少个任务。环节耗时单个智能体环节的平均耗时。错误率工具回调失败占比和 schema 校验失败占比。成本消耗按任务模板维度展示 Token 费用分布。4. 真实运行中的踩坑与排查技巧4.1 任务漂移智能体做着做着就跑偏了任务漂移是我在整个系统运行中遇到最频繁的问题。举个具体例子我对系统说修复订单列表页的排序功能需求分析智能体还能稳住到了编码工程师那里它开始顺手重构订单列表页的组件结构还重命名了几个方法。单看它的输出每一步似乎都有道理。但合到一起一个本来 20 行代码能改完的分支变成了涉及 12 个文件的巨型改动。这种发挥过头的行为在真实开发中很危险因为改动面越大回归风险越高。我排查之后发现问题根源是系统提示词里关于任务边界的定义太模糊。后来我在每个智能体的提示词里都加了一段强约束你的任务是完成被分派的具体变更不要进行超出范围的重构、重命名、格式调整。如果发现必须做额外变更才能完成任务停止操作并上报。同时在审查智能体的配置里加了一项硬性检查比较改动文件和任务描述中提到的文件是否匹配偏差超过一定数量就自动打回。这套组合拳下来任务漂移问题减少了八成以上。4.2 上下文污染多智能体共享记忆的信息噪音信息在多个智能体之间传递时会不可避免地被污染。最典型的场景是某个智能体在黑板上记录了一句临时的推测可能是缓存问题这个推测被后续智能体当真了导致排查方向整个跑偏。我的解决方案是分级信息标注。黑板上每条记录除了内容本身还包括一个type字段取值是fact事实、assumption假设、question待确认、reference参考。后续智能体读取黑板时可以按类型过滤只有fact内容才作为决策依据assumption只能作为参考线索。另一个污染源是细节噪音。编码工程师往往会输出很长的实现说明但下游测试工程师真正关心的只是改了哪些文件、哪些接口行为有变化。我在消息传递时加了一层摘要器任务进入下一环节前自动对上一环节的长输出做结构化摘要只把关键字段传给下游。4.3 工具调用失控与死循环工具调用是智能体操作真实世界的通道但也可能是灾难入口。我遇到过几次印象深刻的异常。第一次是编码智能体在循环里反复调用读取文件工具每次读的都是同一个大文件。大量重复内容反复进入模型上下文Token 消耗哗哗上涨任务却一点进展都没有。后来我加了去重缓存相同参数的工具调用在短时间内的重复执行直接返回缓存结果不再喂给模型。同时限制单任务工具调用轮次超过 20 轮自动上报。第二次是智能体在做 git 操作时遇到当前分支有未提交改动它的应对策略居然是自动执行git checkout -- .强制丢弃所有变更。这个操作太危险了稍有不慎就把辛苦写的代码全丢了。机器学习模型对重置类操作的危险性缺乏直觉判断。我在工具层加了两层防护一是危险命令白名单git checkout这类破坏性操作必须经过二次人工确认二是工作区保护任何智能体提交的批量丢弃类命令都会被拦截并告警。4.4 成本失控Token 消耗的全链路治理多智能体系统的运行成本在架构设计初期就决定了。前期如果不对 Token 消耗做预估后期账单能看哭你。我的建议是把它当成系统设计的一部分来治理。第一层治理是模型分级路由。不是所有智能体都需要最高级别的模型。需求分析和架构设计这类重逻辑任务用高能力模型简单代码搜索、文本格式化、消息摘要这类任务用能力稍弱但便宜很多的模型。一个功能开发任务走下来成本可以因此下降 40% 左右。第二层治理是上下文瘦身。每次调用模型前对要发送的历史消息做压缩。超过一定轮次的历史对话不再直接送进模型而是先做一轮结构化摘要用摘要替换原始对话。实测对低难度任务影响很小成本却能省不少。第三层治理是结果复用。类似读取某个文件内容这种高频工具调用结果缓存起来同一任务链路里直接复用。多智能体协作时同一个文件被不同智能体重复读取是常态。做一层透明缓存效果立竿见影。我把成本治理放在最后讲是因为我踩的代价比较大。刚开始上线时没设任何成本预警等月底看到账单才反应过来。现在已经养成了习惯每周看一次成本报表按任务模板逐项对比发现某个模板成本异常上涨就立刻分析是哪一层上下文失控了。写在最后的一点个人体会这套系统运行到现在我的体感是有得有失。得到的是大量琐碎开发任务可以并行自动处理我从写代码的人慢慢变成了把关的人。失去的则是作为开发者亲自一行行写代码的那种掌控感。刚上手的那段时间我总觉得不踏实代码不是自己写的总怕里面有隐藏雷。后来习惯了审查智能体报告 抽查关键实现的模式心里才慢慢有底。如果你也想搭这样一套系统我的建议是别一上来就求大求全。挑一个你手里最重复、最模板化的开发任务先试跑比如自动生成单元测试、自动修 lint 告警、自动生成接口文档。跑顺一条流水线再逐步扩展。多智能体系统是把双刃剑它确实会放大你的生产力但同时也会放大系统设计上的缺陷。架构上偷的懒都会在运行成本和错误率上加倍还回来。最后分享一个我使用下来的小技巧给每个智能体起名时用真实的岗位名称比如测试工程师比tester更好。因为大模型在训练语料中见过太多测试工程师在团队中扮演什么角色的内容使用拟人化的岗位名能让模型更自然地激活专业的协作模式。这个细节不是我一开始就发现的是做完一组对比测试后得出的规律实测下来稳定有效。