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

1. 问题现象和影响范围；
2. 已经查阅的版本、历史记录和代码；
3. 可能的根因；
4. 支持判断的证据；
5. 仍然缺少的信息；
6. 建议的验证或处理动作。

如果 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 一次承担越来越大的任务，而是让它在真实研发流程中稳定地产出可验证、可审核的结果，并持续减少工程师在信息查找、重复执行和流程流转上的投入。