解决工程工作流碎片化问题
AI 编码智能体正在成为
软件开发的重要组成部分。它们最直观的用途，是帮助开发人员更快地编写代码。但如果希望真正提升研发效能，编码智能体就不能只停留在"生成代码"这一层，而要进一步融入软件开发生命周期、CI/CD、测试验证、依赖升级和工程工作流自动化之中。
在某海外大型科技公司的工程体系中，智能体还需要能够在庞大的单体代码库中工作，在完整工程环境中验证代码变更，并整合来自整个软件开发生命周期的上下文信息。
毕竟，开发人员的工作远不只是写代码。工程师还需要管理迁移、解决持续集成（CI）阻塞、调查故障，并处理大量重复性的运维任务。这些工作都很重要，但往往重复、琐碎且容易打断思路，会分散工程师对更深层产品和基础设施工作的注意力。
为了迎接编码智能体能够协助工程师完成更多工作的未来，我们构建了一个内部编码智能体平台：一项用于在云端运行编码智能体的内部服务。
这个平台允许工程师并行运行多个编码会话，也允许内部系统把 AI 智能体作为自动化工作流的一部分来调用。通过平台化方法，我们能够将智能体应用到各种内部工作流中，而不必为每一个用例单独构建一套实现，从而更容易快速试验 AI 如何支持工程工作。
在这篇文章中，我们将分享：为什么要构建这个 AI 编码智能体平台，为什么选择平台化方法而不是多个单一用途解决方案，以及我们在整个软件开发生命周期中使用它得到的经验。
为什么要解决工程工作流碎片化问题？
软件开发生命周期中有很多环节都需要工程师判断，但这些工作本身可能重复且耗时。例如，调试故障、更新依赖、提高测试覆盖率、修复不稳定测试用例等，都是软件开发中必不可少的工作。
与此同时，这些任务也会不断打断工程师，使他们无法专注于更有意义的工作。
许多这类工作流都很适合由编码智能体通过 AI 辅助完成。不过，并不是所有工作流都需要同一种交互方式。有些任务通过标准的交互式聊天方式效果最好；另一些任务则可以在异步工作流中自主运行，并且只在智能体发现有价值的信息时才展示结果。
要稳定支持这两种模式，仅靠单一用途工具远远不够。
在大型工程组织的规模下，开发环境对工具提出了现成方案难以满足的要求。我们的超大型单体仓库依赖内部构建和测试工具，也依赖缓存、远程执行以及本地基础设施，以确保构建和测试能够快速运行。
第三方编码智能体工具虽然适合本地迭代，但并不天然适配我们这种高度依赖仓库结构、基础设施和验证路径的工程环境。由于我们的开发工作流依赖公司特有的基础设施和验证方式，我们希望编码智能体能够在这些系统内部运行，而不是额外引入一套割裂的 AI 工作流。
这些需求促使我们构建一个平台，而不是为每个工作流开发单独的解决方案。
我们的目标，是创建一个共享系统，能够同时支持交互式开发、后台任务和内部服务，并让执行、验证和上下文处理保持一致。为了支持这些工作流，我们构建了这个内部编码智能体平台。
如何利用编码智能体平台改进开发流程？
这个平台最初源于一个明确问题：帮助工程师针对持续集成失败提出修复建议。
这一出发点对平台设计至关重要。每个编码会话都会在一个隔离环境中运行，这个环境基于代码库中某个特定提交的快照创建。调用方会提供任务，并且可以选择附带验证命令，在智能体完成操作后执行。
如果验证失败，例如测试未通过或构建失败，平台可以继续当前会话，将结果反馈给智能体，并要求它修复这个问题。这使得智能体始终在真实的构建和测试环境中运行，而不是生成一个看似合理的补丁后就停止。
整个工作流遵循一个简单模式：提出变更、执行验证，并且只有在验证结果成立时才继续推进。
随着时间推移，我们扩展了平台能力，使其能够通过同一个界面运行多个编码智能体。该平台可以与工程师已经在使用的工具和工作流无缝集成，也提供了类似云端编码智能体的交互式 Web 会话界面。
工程师还可以使用命令行界面和 API，从本地运行的智能体、脚本和内部服务中并行启动任务。为了支持长时间运行的工作流，我们维护了一些辅助工具，让用户可以更轻松地加入 AI 驱动的步骤，而不必重新构建周边基础设施。
平台还包含用于快速评估、可观测性和反馈收集的工具，帮助工程师更好地理解智能体的表现。
随着平台被应用到更多工程工作流中，我们发现，许多任务需要的不只是编辑文件。智能体通常还需要收集证据、读取日志、检查故障，并在多个步骤之间保留上下文。为了支持这些工作，平台集成了技能、插件和上下文协议，也包括对可观测性系统的访问能力。
除了交互式编码会话，我们还扩展了代码发布流程。我们选择把发布操作放在智能体之外，并将每次会话限制在单个分支上。这样可以清楚知道哪些分支处于活动状态，以及哪些变更正在发布。
如果允许智能体在一个会话中创建和管理多个分支，复杂度会显著增加。例如，系统需要判断后续工作应该基于哪个分支继续。保持工作流的确定性，也让围绕每个分支的自动化任务更容易实现，例如运行测试，或将代码变基到主分支。
{
"repo_commit": "<commit-sha>",
"task": "Investigate this CI failure and propose a fix",
"validation_commands": [
"build-tool test //path/to:test_target",
"build-tool test //path/to/related:all"
],
"continue_on_validation_failure": true,
"max_iterations": 5,
"push_branch": "ai/agent/ci-fix"
}以上是一个内部编码智能体平台请求示例，采用伪代码 JSON 表示。
AI 编码智能体平台可以用于哪些工程场景？
自平台发布以来，我们已经将它应用到多种工程工作流中，从开发人员主导的快速编码会话，到耗时更长的修复和迁移工作。下面这些用例展示了 AI 编码智能体如何融入日常交互式开发，以及更持久的运维工作流。
支持开发者主导的编码会话
平台支持开发者主导的会话，满足工程师对现代编码智能体的常见预期。
工程师可以使用平台的 Web 界面快速修复问题或构建原型，而不需要中断本地开发流程。对于代码变更，我们结合构建工具的选择能力和平台的验证命令，确保变更能够针对正确的编译和测试目标完成验证。
工程师也可以从团队沟通工具中的讨论串发起任务，并将该讨论串中的上下文带入编码会话。这样可以简化设置流程，并保留原本需要手动重写的讨论内容。
修复不稳定测试
平台最成功的运维工作流之一，是修复不稳定测试。
我们开发了一个内部工具，用于处理不稳定测试。它是一个持久化工作流，与不稳定测试检测系统集成。
该工具首先会找到测试通过和失败的示例。随后，它会把这些日志作为上下文发送给内部编码智能体平台，并要求智能体识别可能的根本原因并提出修复方案。
我们会根据测试失败率，在持续集成环境中运行测试 100 次或更多次，以验证提出的变更。如果测试再次出现不稳定，我们会获取新的日志，并保留上一次尝试的记录，然后启动下一轮修复尝试。
修复和验证的循环会持续进行，直到找到有效修复方案，或达到预设尝试次数上限。目前，这个上限是 5 次。
迁移和依赖升级
迁移和依赖升级，也很自然地成为平台的优势场景。
在这个平台出现之前，我们曾使用一个定制化 AI 迁移工具，并将它与内部迁移跟踪工具集成。这个系统使用提示词模板和验证命令，生成并行 AI 编码任务，然后将结果发布到代码托管平台的分支。
它曾被用于数千个迁移条目，包括将旧测试框架迁移到新的测试库，以及更新类型检查配置。
虽然这个迁移工具有效，但它也存在一些重要限制。它缺乏交互能力，无法查看或继续执行智能体输出。因此，一旦出现故障，团队往往很难有效恢复工作。
我们还发现，对于高度可重复的迁移工作，通常由迁移负责人直接处理效果更好。他们可以使用同一套运行手册启动和管理几十个智能体，而不必协调跨团队委派工作。
将迁移工作流迁移到统一平台后，我们获得了交互式编码会话、共享防护机制、可复用工作流工具，以及一致的操作模式。
随着时间推移，我们希望迁移负责人只需编写一次提示词，就能在代码库的多个部分并行运行，并作为协调部署的一部分审查最终变更。
现在，我们还将该平台与依赖更新机器人集成，使智能体能够初步修复由依赖升级引入的问题。
新兴工作流和实验
我们还使用这个平台响应生产环境中的崩溃警报：通过测试重现崩溃状态，生成候选修复方案，并将结果路由给相应服务团队。
一些最有前景的实验，建立在这些运维工作流之上，并扩展到代码编写之外。
我们正在探索，智能体是否能够根据团队的审查策略评估拉取请求，并针对是否需要其他团队参与审查提供指导，从而帮助判断代码变更何时需要额外审查。
除了拉取请求工作流，我们还在测试定时工作流是否能够减少重复性的值班工作，例如频繁出现的告警通知，或埋没在团队沟通频道里的后续跟进事项。
另一项实验，则是让多个智能体从不同角度审查同一项代码变更，然后汇总结果，去重并过滤掉低价值评论。
使用 AI 编码智能体平台后，我们学到了什么？
我们学到的第一点是，编码智能体的价值不仅来自代码生成本身，也来自它所处的平台。
将智能体作为服务运行，为我们提供了一种可复用方式，可以支持各种工程工作流。
我们还发现，上下文、验证和防护机制会相互增强。
本地化的智能体说明文件能够为智能体提供特定服务的上下文；验证命令、隔离执行、封闭测试、构建缓存和重试循环，则使智能体能够与工程师日常使用的相同系统进行交互。
每一层单独看都能提高可靠性，但当它们组合在一起时，会让后台工作流变得更加可信。
另一个重要经验是，并非所有步骤都适合放在智能体循环中执行。
随着平台在软件开发生命周期中的使用越来越广泛，我们必须决定哪些环节适合交给智能体，哪些环节应该由确定性系统控制。
例如，如果让智能体自行管理测试执行和迭代，可能导致会话等待 CI 数小时，或者导致代码变更所依据的验证测试与实际情况不一致。
我们发现，更好的做法是：由周边工作流确定性地触发 CI；当出现故障、需要检查或修复时，再让智能体重新介入。
随着编码智能体不断进步，我们预计它们将在软件开发生命周期中承担更多重复性工作。
未来的发展方向，不只在于更好的模型，也在于与塑造工程工作的系统进行更深层集成。
对于希望在自身组织中落地类似能力的研发团队来说，编码智能体平台不应该孤立存在，而要进入完整研发流程。
PingCode 这类智能化研发管理工具，可以帮助团队把目标、客户反馈、需求评审、开发测试、发布上线和 Wiki 知识沉淀串联起来，让 AI 辅助研发真正进入可追踪、可验证、可复用的管理闭环；而在跨团队协作、任务推进和沟通承接层面，Worktile
这类通用项目协作系统也能帮助团队统一管理任务、文档、即时沟通、日历和审批，让自动化工作流更容易落地到日常协作中。
这个内部编码智能体平台通过隔离环境、感知仓库的上下文、验证循环、工作流集成和可审查输出，为 AI 辅助工作流提供了一个共享执行层。
随着我们不断扩展上下文来源，包括与内部 AI 知识工具和标准上下文协议的集成，我们预计智能体将变得更加实用、可靠，并更好地契合大型工程组织的工作方式。