1. 为什么研发协作需要多 Agent 而不是一个大模型1.1 单模型处理研发流程的三个硬伤很多团队一开始的想法很朴素既然大模型能写代码、能读日志那我直接拿一个通用模型把 Issue 内容、PR diff、CI 日志全塞进上下文让它一次性给出结论不就行了我最早也是这么干的实测下来有三个绕不过去的硬伤。第一个是上下文污染。Issue 里往往夹杂着用户情绪化的描述、无关的截图说明、历史遗留的讨论串PR diff 里是几百行结构化代码CI 日志动辄几千行且大部分是噪音。这三类信息的语言风格和关注重点完全不同塞进同一个上下文后模型很容易被无关信息带偏。比如你让它审查 PR它却开始复述 Issue 里用户抱怨的某个功能因为它分不清当前任务边界。第二个是职责冲突。分析 Issue 需要的是归纳诉求、判断优先级、识别复现步骤审查 PR 需要的是代码规范、逻辑漏洞、边界条件、测试覆盖CI 排障需要的是日志模式匹配、错误链路定位、环境差异推断。这三套能力对模型的提示词、输出格式、甚至温度参数要求都不一样。用一个模型一套提示词硬扛结果就是每样都做得差不多但不够好。第三个是可观测性差。单模型一把梭出了问题你根本不知道是哪一步错了——是 Issue 理解偏了还是 PR 审查漏了关键文件还是 CI 日志解析时把关键行截断了整个链路是个黑盒调试成本极高。1.2 多 Agent 分工的核心逻辑让每个 Agent 只做一件事多 Agent 架构的本质是把上面那团乱麻拆成几条清晰的流水线。每个 Agent 有自己的系统提示词、自己的工具集、自己的输出契约彼此通过结构化的消息传递协作。这样做的好处非常直接每个 Agent 的上下文是干净的。Issue 分析 Agent 只看到 Issue 相关内容PR 审查 Agent 只看到 diff 和仓库规范CI 排障 Agent 只看到日志和构建配置。每个 Agent 可以独立调优。你觉得 PR 审查太宽松就单独调它的提示词和阈值不影响其他环节。每个 Agent 可以独立观测和替换。某个 Agent 效果不好直接换掉或升级其他部分不动。打个比方这就像把一个全科医生换成分诊台 专科医生的组合。分诊台负责判断你该去哪个科专科医生只处理自己领域的问题效率和准确率都高得多。1.3 DevFlow AI 的整体架构长什么样我设计的 DevFlow AI 由四个核心 Agent 加一个协调器组成整体数据流是这样的组件职责输入输出协调器 Orchestrator任务分发、状态管理、结果汇总事件触发新 Issue / 新 PR / CI 失败调度指令Issue 分析 Agent归纳诉求、分类、优先级、复现步骤提取Issue 标题、正文、评论结构化 Issue 报告PR 审查 Agent代码规范、逻辑风险、测试覆盖检查PR diff、仓库规范文件审查意见列表CI 排障 Agent日志解析、错误定位、修复建议CI 日志、构建配置排障报告汇总 Agent把各 Agent 结果整合成人类可读的评论各 Agent 的结构化输出最终评论/通知协调器不直接做推理它只负责什么时候叫谁干活。这种设计让整个系统像一个流水线工厂而不是一个什么都干的杂货铺。提示协调器的状态管理建议用简单的状态机而不是复杂的编排框架。我一开始用了某编排框架结果发现调试成本比收益还高后来退回用几十行状态机代码反而更稳。2. Issue 分析 Agent从一堆抱怨里提炼出可执行的需求2.1 Issue 文本的脏乱差是常态真实的 Issue 从来不是规规矩矩的需求描述。我统计过我们仓库近半年的 Issue大概分布是这样的约 30% 是纯 bug 报告但描述模糊点了没反应约 25% 是功能请求但夹杂大量个人偏好约 20% 是重复或已解决的问题剩下的是文档问题、环境问题、以及完全跑题的讨论。如果直接把原始文本丢给模型让它分析一下输出往往是一段正确的废话。所以 Issue 分析 Agent 的第一步不是理解而是清洗和结构化。2.2 分步提示词设计先抽取再判断最后归纳我的做法是把 Issue 分析拆成三个串行的子步骤每个子步骤用独立的提示词调用而不是一个提示词搞定所有事。第一步信息抽取。让模型只做一件事——从文本里抽出这些字段问题现象、复现步骤、期望行为、实际行为、环境信息、附件链接。这一步不要求模型做任何判断只做找出来。提示词里明确要求找不到的字段填未提供不要脑补。第二步分类与去重判断。拿到结构化字段后再让模型判断这是 bug / 功能请求 / 文档问题 / 环境问题 / 其他并给出置信度。同时把标题和摘要与历史 Issue 库做向量相似度比对相似度超过阈值的标记为疑似重复。第三步优先级与可执行性评估。最后一步才做价值判断影响范围多大有没有 workaround是否阻塞核心流程综合给出 P0-P3 的优先级建议并明确标注信息不足需要补充哪些内容。这样拆的好处是每一步的输出都可以单独验证。如果最终结果不对你能快速定位是抽取错了、分类错了、还是优先级判断错了。2.3 结构化输出的字段设计Issue 分析 Agent 最终输出一个 JSON字段设计如下{ issue_id: ISSUE-1234, category: bug, category_confidence: 0.92, priority: P1, priority_reason: 影响核心登录流程无 workaround, symptom: 用户点击登录按钮后页面无响应, reproduce_steps: [打开登录页, 输入正确账号密码, 点击登录], expected: 跳转到首页, actual: 按钮无响应控制台报错, environment: Chrome 120, Windows 11, missing_info: [是否有网络请求发出, 控制台完整报错], duplicate_candidates: [ISSUE-1180], suggested_labels: [bug, auth, P1] }这个 JSON 就是 Issue 分析 Agent 的产品。下游的汇总 Agent 直接读这个结构不需要再去理解自然语言。2.4 实测中容易翻车的两个点第一个坑模型过度脑补复现步骤。用户只写了登录不了模型却编出了五步复现步骤。解决办法是在提示词里加硬约束复现步骤必须能在原文中找到对应描述否则返回空数组并在 missing_info 中标注。加了这条之后脑补现象基本消失。第二个坑优先级判断受情绪词影响。用户写紧急崩溃了模型就给 P0。但实际上那个崩溃只是某个边缘页面的样式错位。我的处理是让优先级判断只看客观字段影响范围、是否阻塞、有无 workaround把情绪化的原文单独隔离不参与优先级推理。注意Issue 分析 Agent 的输出建议先以草稿评论形式发到 Issue 里让人确认后再打标签。全自动打标签在早期很容易误伤人工确认一轮能积累大量修正样本反过来优化提示词。3. PR 审查 Agent不是让 AI 挑刺而是让它守住底线3.1 PR 审查的目标要收敛别指望 AI 做架构评审很多人对 PR 审查 Agent 的期待是帮我找出所有问题这个期待本身就是错的。AI 做不了架构评审也判断不了业务逻辑是否符合产品意图。它能做且应该做的是守住那些明确、可规则化、容易遗漏的底线。我把 PR 审查 Agent 的职责收敛为四类规范类命名规范、文件组织、提交信息格式、是否更新了文档。风险类明显的空指针、未处理的异常、硬编码密钥、危险的 SQL 拼接。测试类新增逻辑是否有对应测试、测试是否覆盖了边界条件。一致性类改动是否与仓库既有的模式一致比如别人都用某个工具函数你却又写了一个。超出这四类的一律不报。宁可漏报不可误报——误报多了开发者就会直接忽略所有 AI 评论这个 Agent 就废了。3.2 diff 的预处理先切块再逐块审查直接把整个 diff 丢给模型效果很差因为一个 PR 可能改了 20 个文件。我的做法是先把 diff 按文件切块再按改动类型分组纯新增文件纯删除文件修改文件再细分为只改逻辑、只改样式、改配置、改测试然后对每一块单独调用审查提示词最后合并结果。这样做的好处是模型每次只需要关注一小段代码注意力集中判断更准。对于超大 PR超过 500 行改动我会先让模型做一个改动摘要识别出这个 PR 主要动了哪些模块然后只对核心模块做深度审查边缘改动只做规范检查。这是基于实践的取舍——超大 PR 本来就该拆分AI 没必要为它兜底。3.3 审查意见的措辞直接影响采纳率这一点是我踩了很多坑才悟出来的。同样一个问题措辞不同开发者的反应天差地别。差的措辞好的措辞这里有空指针风险第 42 行user.profile.name在 user 为 null 时会抛异常建议加可选链或前置判空缺少测试新增的calculateDiscount函数有 3 个分支当前测试只覆盖了 1 个建议补充边界用例命名不规范变量d建议改为discountRate与仓库其他文件的命名风格保持一致核心原则指出具体位置、说明具体后果、给出具体建议。模糊的批评只会引发防御心理具体的建议才会被采纳。3.4 如何避免狼来了效应PR 审查 Agent 最大的敌人不是漏报而是误报导致的信任崩塌。我做了三件事来控制误报第一建立白名单机制。某些文件如自动生成的代码、第三方库的封装直接跳过审查。某些规则如行长度如果团队本来就不在意直接关掉。第二分级输出。把意见分为必须修改和建议考虑两档。必须修改的才阻塞合并建议考虑的只是评论。这样开发者不会因为一堆鸡毛蒜皮的建议而烦躁。第三定期复盘误报。我每周会看一遍 AI 评论被开发者标记为无效的记录把高频误报模式加到提示词的负面示例里。这个反馈闭环是让 Agent 越用越准的关键。提示PR 审查 Agent 的提示词里一定要放几段仓库自己的代码范例让模型学习本仓库的风格。通用规范模型都知道但本仓库的习惯只有喂了范例它才懂。4. CI 排障 Agent把几千行日志变成一句话结论4.1 CI 日志的噪音比例高得离谱一个典型的 CI 失败日志真正有用的信息可能只占 5%。剩下的 95% 是依赖下载进度、测试用例的通过输出、编译器的正常警告、以及各种时间戳和路径。如果直接把原始日志丢给模型token 消耗巨大且效果差。所以 CI 排障 Agent 的第一道工序是日志压缩。我的压缩策略分三层第一层按行过滤。用正则先剔除明显无用的行下载进度、纯时间戳、已知的正常警告。第二层按块聚合。把连续的测试通过输出聚合成一行XX 个测试通过。第三层错误上下文提取。定位到第一个 ERROR 或 FAILED 关键字后向前后各取 50 行作为错误上下文这是最关键的输入。经过这三层压缩几千行日志通常能压到 100-200 行信息密度大幅提升。4.2 错误分类先判断是不是代码问题CI 失败的原因五花八门但大致可以分成几类处理策略完全不同失败类型典型特征处理策略代码错误编译失败、测试断言失败定位到具体文件和行给出修复方向环境问题依赖下载失败、端口占用建议重试标注为疑似环境抖动配置问题变量未定义、路径不存在指出缺失的配置项资源问题超时、内存不足建议调整资源或拆分任务偶发失败无明确错误重跑即过标记为 flaky建议重试这个分类非常重要因为不是所有 CI 失败都需要开发者改代码。如果 Agent 把环境抖动也报成代码有 bug开发者会疯掉。我的做法是让 Agent 先做这个分类判断只有代码错误和配置问题才 相关开发者环境问题和偶发失败只建议重试。4.3 从错误日志到修复建议的推理链CI 排障 Agent 最有价值的部分是把错误日志翻译成人话 修复方向。我要求它的输出必须包含这条推理链失败发生在哪个阶段安装依赖 / 编译 / 测试 / 打包 / 部署直接错误信息是什么原文引用关键行根因推断是什么基于错误信息的合理推断建议的修复动作是什么具体到改哪个文件、加什么配置举个例子日志里出现ModuleNotFoundError: No module named xxxAgent 的输出应该是阶段测试阶段直接错误导入 xxx 模块失败根因推断依赖未安装或 requirements 文件未更新修复建议检查 requirements.txt 是否包含 xxx若缺失则添加并重新提交这种结构化的输出比一句CI 挂了请检查有用一百倍。4.4 重试决策什么时候该自动重试什么时候该叫人这是 CI 排障 Agent 里最需要谨慎的部分。我的策略是明确的环境抖动如依赖源超时、网络错误自动触发重试最多 2 次重试成功则不打扰任何人。疑似偶发失败无明确错误但失败标记为 flaky自动重试 1 次若仍失败则通知。明确的代码/配置错误不重试直接通知相关开发者附上排障报告。这个策略的核心是减少无效通知。开发者最烦的就是CI 挂了的通知点进去发现重跑一下就好了。自动重试能过滤掉大部分这类噪音。注意自动重试一定要有次数上限和冷却时间否则遇到持续性的环境问题会陷入无限重试。我设的是最多 2 次、间隔 5 分钟超过就转人工。5. 多 Agent 之间的协作与状态管理5.1 事件驱动还是轮询我为什么选事件驱动协调器怎么知道该干活了两种方式轮询每隔几分钟检查有没有新 Issue/PR/CI 失败和事件驱动平台 webhook 触发。我选的是事件驱动理由是延迟低且不浪费资源。轮询在仓库活跃度低的时候纯属空转活跃度高的时候又可能漏掉事件。事件驱动则是有事才干活响应快成本低。但事件驱动有个坑事件可能重复投递或乱序。所以协调器必须做幂等处理——每个事件带唯一 ID处理过的 ID 记录下来重复的直接丢弃。这个幂等层是必须的否则同一个 PR 可能被审查两次发出两条重复评论。5.2 Agent 之间的消息契约多 Agent 协作最容易出问题的地方是 Agent 之间的接口不清晰。我的做法是给每个 Agent 定义严格的输入输出契约用 JSON Schema 约束。比如 PR 审查 Agent 的输入契约要求必须包含pr_id、diff_chunks已切块的 diff 数组、repo_conventions仓库规范文本。输出契约要求必须包含pr_id、findings意见数组每条含文件、行号、级别、描述、建议。有了这个契约任何一个 Agent 都可以被替换或升级只要它遵守契约其他部分完全不用改。这就是多 Agent 架构的可维护性优势。5.3 失败处理某个 Agent 挂了怎么办真实系统里Agent 调用失败是常态超时、限流、返回格式错误。我的处理原则是降级而非中断。Issue 分析 Agent 失败发一条自动分析暂不可用请人工处理的评论不阻塞 Issue 流程。PR 审查 Agent 失败跳过 AI 审查正常走人工 review不阻塞合并。CI 排障 Agent 失败只发原始日志链接不做分析。核心思想是AI 是辅助不是关卡。任何 AI 环节挂掉都不能阻塞研发主流程。这个原则在系统设计初期就要定下来否则后期会变成AI 一挂全组停工的尴尬局面。5.4 成本控制不是每个 PR 都值得全量分析多 Agent 系统跑起来之后token 成本是个现实问题。我做了几层控制小改动跳过深度审查。改动少于 10 行的 PR只做规范检查不做深度逻辑审查。草稿 PR 不触发审查。标记为 draft 的 PR 不消耗资源。同一 PR 的重复推送做增量分析。只分析新增的 commit不重复分析已审过的部分。设置每日预算上限。超过上限后降级为只做基础检查。这些策略让成本可控同时不影响核心体验。6. 落地过程中的真实踩坑记录6.1 提示词里的示例比规则更管用我一开始写提示词喜欢列一堆规则你必须检查 A、B、C、D……结果模型经常顾此失彼。后来我改成给示例放 3-5 个好的审查意见和差的审查意见的对比让模型模仿。效果立竿见影。原因是规则是抽象的模型需要自己翻译成具体行为而示例是具体的模型直接模仿就行。对于输出格式要求高的任务示例的效果远好于规则描述。6.2 别让 Agent 输出自由文本强制 JSON早期我让 Agent 输出自然语言然后自己写正则去解析。结果模型今天用建议明天用推荐后天用可以考虑正则改到崩溃。后来全部改成强制 JSON 输出配合 JSON Schema 校验解析问题彻底消失。如果模型偶尔输出非法 JSON加一个修复重试环节把非法输出和错误信息一起发回给模型让它修正。通常一次就能修好。6.3 人工反馈闭环是系统进化的唯一途径多 Agent 系统上线只是开始真正的价值在于持续优化。我在每个 Agent 的输出旁边都加了有用/无用的反馈按钮收集到的反馈每周复盘一次。复盘时重点看两类误报AI 报了但实际没问题和漏报人工发现了但 AI 没报。误报加到负面示例里漏报加到正面示例里。这个闭环跑上几周Agent 的准确率会有肉眼可见的提升。6.4 不要追求全自动人机协作才是正解最后说一个心态上的坑。我一开始总想着全自动让 AI 直接打标签、直接阻塞合并、直接关闭 Issue。结果出了几次误判团队对系统的信任度骤降。后来我调整了定位AI 做初筛和建议人做最终决策。AI 把 80% 的重复劳动干掉人只需要处理那 20% 需要判断的部分。这个定位下团队接受度高得多系统也真正融入了工作流。环节全自动做法人机协作做法推荐Issue 打标签AI 直接打AI 建议人确认PR 审查AI 阻塞合并AI 评论人决定是否阻塞CI 排障AI 自动重试并通知AI 自动重试失败才通知人优先级AI 直接定AI 建议人调整这套人机协作的边界是我踩了无数坑之后总结出来的。核心就一句话AI 负责快人负责准。两者结合才是研发协作效率提升的正解。7. 从零搭建这套系统的实操路线7.1 先跑通单 Agent再谈多 Agent如果你也想搭一套类似的系统我的建议是千万别一上来就搞多 Agent。先选一个最痛的场景通常是 PR 审查或 CI 排障用单 Agent 跑通验证价值积累提示词经验。等单 Agent 稳定了再考虑拆分和协作。多 Agent 的复杂度主要来自协作而不是单个 Agent。如果单 Agent 都没跑明白多 Agent 只会让你更混乱。7.2 技术选型的几个务实建议模型选择不要迷信最大的模型。Issue 分类、日志解析这类任务中等模型加好的提示词就够了成本低很多。只有 PR 审查这种需要深度推理的才值得上大模型。向量库Issue 去重需要向量检索用轻量级的本地向量库即可不必上重型方案。编排如前所述简单的状态机代码往往比编排框架更实用。部署先跑在单机上用定时任务或 webhook 触发。等稳定了再考虑容器化和高可用。7.3 衡量效果的三个指标系统上线后怎么判断它有没有用我盯三个指标采纳率AI 提出的意见中被开发者实际采纳的比例。低于 30% 说明误报太多需要优化。响应时间从事件触发到 AI 给出结果的时间。超过 5 分钟体验就差了。人工节省粗略估算 AI 帮团队省下了多少重复劳动时间。这个指标用来向团队证明价值。这三个指标每周看一次持续优化。系统不是搭完就完事而是要像养一个团队成员一样持续调教。7.4 一个最小可行版本的搭建顺序如果你现在就想动手我建议按这个顺序来先接一个平台的 webhook能收到事件。写一个最简单的 PR 审查 Agent只做规范检查命名、提交信息。把结果以评论形式发回 PR。收集反馈逐步增加审查维度。稳定后再加 Issue 分析 Agent。最后加 CI 排障 Agent 和协调器。每一步都验证价值后再往下走不要贪多。我见过太多团队一上来就设计一个宏大的多 Agent 架构结果卡在第一个 Agent 的提示词调优上最后不了了之。这套系统我前后迭代了大半年从最初的一个脚本长到现在四个 Agent 协作。回头看最大的收获不是技术本身而是理解了AI 在研发流程里的正确位置——它不是替代人而是把人从重复劳动里解放出来去做真正需要判断力的事。这个认知比任何架构设计都重要。