研发 Agent 如何落地：从工单诊断、缺陷修复到小需求开发

越来越多研发团队开始使用 Coding Agent。它们可以阅读代码仓、修改代码、运行测试，甚至创建 Pull Request。于是，一个很自然的问题出现了：既然 AI 已经能写代码，是否可以直接把完整需求交给它？

从企业实践看，答案没有这么简单。

一个复杂需求不仅包含代码实现，还涉及业务理解、方案取舍、跨团队依赖、测试验证和发布责任。AI 能执行其中一部分动作，并不意味着组织已经具备把完整研发任务交给它的条件。

GitHub 在 Coding Agent 的官方实践建议中，也推荐团队先从 Bug 修复、测试覆盖、文档更新等范围明确的任务开始。需求模糊、业务逻辑复杂、跨代码仓或涉及生产关键系统的任务，更适合由人主导。

因此，研发 Agent 的落地不应追求“一步到位”，而应遵循一条更现实的路线：

先让 AI 看懂问题，再让它修改代码；先处理明确的缺陷，再参与新需求开发。

一、为什么不能一开始就让 Agent 做复杂需求

研发任务是否适合交给 Agent，不能只看开发周期或代码量，还要看四个条件。

复杂需求的问题，在于这四类不确定性通常同时存在。

AI 可能正确完成了代码修改，却误解了业务目标；也可能通过了局部单元测试，却破坏了其他系统的兼容性。更常见的情况是，AI 在需求不清时仍然生成大量代码，团队直到测试或验收阶段才发现方向错误。

DORA 2025 年研究将 AI 描述为组织能力的“放大器”：工程基础扎实、反馈机制完善的团队，更容易获得正向收益；流程混乱、测试薄弱的团队，也可能因为 AI 加快局部产出而放大返工和稳定性问题。

因此，企业不应优先选择“价值最大”的任务试验 Agent，而应先选择“最容易判断对错”的任务。

二、研发 Agent 的三阶段落地路线

结合研发任务的风险和复杂度，可以把 Agent 的落地划分为三个阶段。

这三个阶段的差别，不只是任务越来越复杂，更在于 AI 需要承担的判断越来越多。工单诊断主要是在已有信息中寻找答案；缺陷修复是在明确的异常和预期行为之间完成修正；小需求开发则需要理解一个尚未存在的新功能。任务越往后，隐性业务规则越多，人工评审的重要性也越高。

三、第一阶段：从工单诊断开始

1. 为什么工单诊断适合作为起点

工单诊断的主要工作是读取、检索和分析，不需要一开始就给 Agent 较高的代码或生产系统权限。一个工单进入研发团队后，工程师通常要完成以下工作：

提取产品版本、运行环境和问题现象；

判断信息是否足以复现；

查询相似历史工单；

阅读相关产品文档和代码；

判断问题属于缺陷、配置还是使用问题；

给出下一步处理建议。

这些工作耗时，但判断结果相对容易被有经验的工程师复核。因此，工单诊断很适合用来验证 Agent 是否能够理解企业自己的产品和代码。

2. 工单诊断不能只做自动分类

许多 AI 工单工具能够自动总结描述、添加标签、判断优先级或推荐负责人。这些能力改善的是“工单应该交给谁”，但并没有真正回答“问题为什么发生”。一个有价值的诊断结果，至少应包括：

问题现象和影响范围；

已经查阅的版本、历史记录和代码；

可能的根因；

支持判断的证据；

仍然缺少的信息；

建议的验证或处理动作。

如果 Agent 只能生成一段没有证据的“可能原因”，工程师仍然需要重新调查，实际节省的时间非常有限。

3. 如何评价工单诊断效果

在 ONES 的内部研发实践中，AI 员工累计诊断了 241 条工单，其中 127 条形成明确结论，结论一次性接受率达到 88%，诊断时间由数小时缩短到分钟级。

这组数据不仅仅能证明“AI 诊断很快”。127 条明确结论约占全部工单的 52.7%，说明仍有相当一部分问题无法依靠现有信息完成判断。原因可能包括日志不完整、复现条件缺失、业务规则复杂，或者需要客户继续补充信息。

因此，工单诊断阶段应重点观察：

明确结论率：有多少工单能够形成可执行判断；

一次接受率：工程师是否认可首次结论；

人工审核时间：工程师还需要投入多少时间；

信息不足识别率：AI 能否在证据不足时主动停止，而不是强行猜测。

可靠的 Agent 不必回答所有问题，但必须知道什么时候不能回答。

四、第二阶段：让 Agent 处理边界清晰的缺陷

1. 缺陷为什么比新需求更容易交给 Agent

缺陷通常已经存在明确的预期行为和异常行为。

例如，某项功能原本应该返回正确结果，但在特定版本或条件下出现错误。修复后的结果是否正确，可以通过复现步骤、单元测试或回归测试判断。

这种任务天然具备反馈闭环：

分析问题 修改代码 运行测试 观察结果 继续修正。

相比之下，新需求往往没有唯一实现路径，AI 不仅要判断代码怎么写，还要判断产品究竟要什么。

2. 不要把缺陷修复简化为“一键修 Bug”

完整的 Agent 缺陷修复流程，通常包括五个环节。

1.根因分析：Agent 阅读缺陷、历史工单、相关代码和近期变更，判断问题发生的位置及影响范围。

2.修复方案评审：Agent 先说明准备修改哪些模块、为什么这样修改、可能有哪些风险。研发人员确认后，再进入编码。

3.测试方案评审：Agent 根据触发条件设计测试范围，不仅验证缺陷本身，还要检查相邻功能是否可能回归。

4.代码修改与自动检查：Agent 修改代码，并运行编译、单元测试、Lint、类型检查等工具，根据结果继续修正。

5.人工代码评审与测试验收：工程师审核代码，测试人员完成验证，最终结果再写回缺陷任务。

这里的人机关系不是“AI 做完，人点确认”，而是：AI 承担调查和执行，人负责关键判断与最终责任。

3. 缺陷修复应关注哪些指标

ONES 的研发实践中，AI 已经完成 235 条逃逸缺陷修复：

修复方案一次通过率为 77%；

测试方案一次通过率为 94%；

代码一次通过率为 87%；

测试有效率为 50%；

人工占用时长由数小时降低到 20 分钟以内。

其中最值得关注的并不是 87% 的代码一次通过率，而是测试有效率只有 50%。

这意味着，Agent 生成的测试方案可能形式完整，也能通过人工评审，但其中并非所有测试都真正覆盖了关键风险。由此可以看出，评价 Agent 不能只看代码是否能运行，还应同时考察：

根因判断是否准确；

修复方案是否控制了影响范围；

测试是否能发现真实问题；

是否引入新的回归缺陷；

人工修改与审核成本是否下降。

只有诊断、修改和验证形成闭环，才算真正完成缺陷修复。

4. 为什么需要连接研发管理与代码环境

如果 Agent 只能看到代码仓，它可能知道“代码如何修改”，却不知道这次修改对应哪条缺陷、影响哪个版本，以及结果应该记录在哪里。

ONES MCP Server 支持 Cursor、Claude Code、VS Code 等兼容 MCP 的 AI 工具，以用户授权身份读取或更新 ONES 中的项目和知识数据。Agent 可以查询需求与缺陷、处理 Bug、记录修复过程，并将代码执行与项目任务连接起来。

这种连接的价值不在于增加一个 AI 入口，而是让 Agent 获得任务的完整上下文：为什么修改、修改什么、如何验证、结果如何回到正式流程。

五、第三阶段：让 Agent 参与小需求开发

1. 什么样的小需求适合 Agent

从缺陷修复进入需求开发后，任务的不确定性会明显增加。适合作为早期试点的小需求，一般具有以下特点：

业务目标和验收标准清楚；

影响模块相对集中；

不涉及重大架构调整；

跨团队依赖较少；

可以通过测试快速验证；

出现错误后容易回退。

例如，在现有页面增加一个筛选条件、补充一个配置项，通常比重新设计计费、权限或数据模型更适合作为 Agent 试点。

2. 小需求开发为什么需要更多人工节点

小需求开发不能直接从需求描述跳到代码生成，中间至少需要两次关键评审。

第一次：需求理解评审

Agent 应先说明：目标用户是谁；需要解决什么问题；包含和不包含哪些范围；涉及哪些业务规则；如何判断需求已经完成。产品和研发人员确认理解正确后，才能继续。

第二次：技术方案评审

Agent 再说明：需要修改哪些模块；接口和数据结构是否变化；如何兼容现有行为；存在哪些技术风险；准备如何测试。完整流程应是：需求理解 人工确认 技术方案 人工评审 编码测试 代码评审 产品与测试验收。

这些评审不是对自动化的阻碍，而是在错误成本较低时及时纠偏。

3. 小需求开发的数据说明了什么

ONES 的实践中，AI 已经完成并上线 9 条小需求，另有 5 条研发完成、等待验收：

需求理解一次通过率为 70%；

技术方案一次通过率为 56%；

代码一次通过率为 44%；

测试有效率为 40%；

研发投入周期由周级缩短到天以内。

与缺陷修复相比，小需求阶段的各项通过率明显下降。这不意味着 Agent 完全不适合需求开发，而是说明：随着业务判断和技术取舍增加，首次产出需要更多人工修正。

企业不能只统计“AI 完成了多少需求”，还要比较：

Agent 参与前后的总交付周期；

产品、研发和测试的人工投入；

需求理解偏差导致的返工；

代码修改和评审次数；

上线后的缺陷与回滚情况。

如果 Agent 的代码一次通过率只有 44%，但已经完成了大量代码阅读、方案草拟和初始实现，工程师的总投入仍有可能下降。反之，如果人工需要反复重写方案和代码，那么周期缩短就不一定代表真正提效。

六、研发 Agent 稳定落地，需要补齐三项基础

1. 让 Agent 知道如何理解企业代码

历史系统不可能为了使用 AI 而重新补齐所有文档。更现实的方法，是建立代码理解指引，告诉 Agent：

代码仓之间是什么关系；

应从哪些入口查找功能；

如何构建和运行项目；

测试在哪里、怎样执行；

哪些目录可以修改；

哪些模块必须经过专项评审。

ONES 内部使用了名为 understand-ones-code 的 Skill，引导 AI 阅读 34 个代码仓、超过 300 万行代码。这类 Skill 的目的不是把全部知识提前写成文档，而是为 Agent 提供正确的调查路径。

2. 把专家判断沉淀为组织资产

提示词和 Skills 的价值，不在于堆积操作步骤，而在于固化专家判断，例如：

什么证据足以确认根因；

哪类修改必须升级给架构师；

哪些目录禁止自动修改；

什么情况下必须补充回归测试；

哪些高风险任务需要立即交还给人。

这些内容应像代码一样经过评审、版本管理和持续改进，而不是分散在个人提示词里。

3. 建立反馈、权限和人工接管机制

Agent 必须能够从编译、单元测试、运行日志和人工评审中获得反馈，否则只能不断生成“看起来合理”的结果。同时，企业需要明确：

Agent 可以读取哪些项目和代码仓；

能否创建或修改工作项；

哪些动作必须经过人工确认；

如何区分 AI 与人工产出；

出错后如何回退；

完整过程能否查询和审计。

ONES AI 的公开原则也强调结果可追踪、权限可控，并要求 AI 输出经过人工评审后再进入正式协作流程。

结语

研发 Agent 的落地，不应从最复杂的需求开始，而应从结果容易判断、错误容易回退的任务开始。工单诊断验证 Agent 能否理解真实问题；缺陷修复验证它能否完成“分析—修改—测试”的闭环；小需求开发则进一步检验其业务理解和方案能力。

真正值得追求的，不是让 Agent 一次承担越来越大的任务，而是让它在真实研发流程中稳定地产出可验证、可审核的结果，并持续减少工程师在信息查找、重复执行和流程流转上的投入。