AI Agent重构软件工程：研发瓶颈转向判断力

当AI编程工具从单纯辅助工程师写代码，进化到能够自主完成规划、实现、测试乃至问题排查的智能代理，软件工程领域正在发生的变革早已超出“提升编码速度”的范畴。

作为一家拥有成熟产品、工程体系和生产环境的SaaS公司，近期公开的内部Agentic Engineering实践显示：Agent会先审查需求文档、拆解任务，再并行写代码、跑测试、做质量验证，最终由人类完成评审和合并。在身份与访问管理团队，仅一周半时间，Agent就生成了64个拉取请求，完成了一个大型解耦项目约30%的工作。更值得关注的是，随着执行能力被进一步自动化，工程研发的瓶颈再次发生了转移——从写代码，到需求对齐，再到如今的判断力。

我们需要先明确，真正的Agentic Engineering并非简单的“AI写代码”，也不是不受限制的自主运行，更不是用AI替代工程责任。任何由Agent辅助完成的工作，最终署名的工程师依然要承担全部责任。我们的核心判断是：真正的变化不在于代码生成速度变快，而在于我们拥有了更自动化的工程闭环——这个闭环拥有持久状态，并且在关键节点内置了人工检查点。

最初的产品理念是消除用户协调会议的摩擦，而现在我们将这个思路应用到了内部研发流程中：从一个想法到最终可运行的软件，中间的协调成本有多少？其中又有多少可以被自动化消除？Agentic系统正在降低从明确需求到可验证实现方案之间的协调成本，我们的目标是消除想法、需求、实现、评审到最终可部署代码之间的所有不必要摩擦。

我们并不是为了自动化而自动化，我们的目标是自动化那些重复性高、严重依赖上下文、又容易造成等待和延迟的工作，让优秀的人才能够把更多时间投入到真正能够创造价值的地方：判断、权衡、架构、产品思考以及用户体验。这个出发点非常重要，因为它决定了后面所有安全护栏应该如何设计。

内部多个团队已经形成了相似的工程闭环流程：通常从一份需求文档或工单开始，其中明确了问题、约束、验收标准和已知风险。在编写任何代码前，Agent会先审查工单，排查其中的歧义、遗漏的边界情况或缺失的实现细节。随后，规划Agent会将已批准的工作拆解为适合单个拉取请求的任务。实现Agent会在隔离的工作环境中执行这些明确范围的任务，甚至可以并行处理。之后，QA或评审Agent会根据需求、测试套件和仓库级别的规则验证输出结果。直到这一步之后，人类才会进行最终的评审、批准和合并，确认哪些内容可以安全部署到生产环境。这套流程并非存在于临时的聊天会话中，而是依托现有系统保存所有信息，是一个拥有持久记忆的闭环系统，而非一个巧妙的提示词。

我们团队开发的内部工具CalTown就是典型案例。通过CalTown，团队成员可以用AI丰富工单，将任务分配给Agent，由Agent完成整个开发流程并最终创建拉取请求。在将分支提交给人类评审前，它还会自动运行代码检查、类型检查和完整的测试套件。更有意义的是，团队里两名从未真正交付过代码的成员——一位设计师和一位产品经理，现在已经可以通过CalTown创建并合并拉取请求。这证明只要安全护栏和评审流程足够可靠，这种模式可以扩大参与软件开发的人群范围。它的价值不仅在于提升速度，更在于为非开发人员提供了一条清晰安全的路径，将上下文转化为实际执行的成果，且每一步都有人类评审和CI系统的保障。

Agentic工作流也不仅限于功能开发。我们已经开始让Agent参与运维工作，比如让Agent对生产事故进行第一轮调查：将告警信息和最近的代码变更进行关联，追踪最有可能出现问题的代码路径，并给出根因假设。这样人类工程师就不必从零开始在仪表盘和日志中搜索线索。这种价值通常不是自动修复问题，而是更快地理解问题。有时Agent会给出诊断结果，有时会直接提出修复方案，有时也会坦诚调查不够深入，无法给出确定结论。但正是这种诚实，让我们愿意放心地让Agent承担第一轮调查工作。无论结果如何，它都能让后续接手的工程师从一个已形成的假设开始，而非从零摸索，大幅提升排查效率。

身份与访问管理团队的实践是目前内部量化效果最明显的案例。仅用一周半时间，Agent就生成了64个拉取请求，其中37个已经合并，另外27个仍在评审中，完成了“将数据模型从单体架构中解耦”项目约30%的工作量。所有工作都运行在专门的服务身份下，且必须经过两个人工评审关卡，因此无论Agent完成了多少工作，责任始终没有转移给工具。

还有团队构建了类似的规划-实现-QA闭环，并增加了工单优化和缺陷分类自动化。平台团队正在开发Agentic设计系统，让AI工具默认使用已批准的组件，避免重复造轮子，同时自动化共享UI库升级时所有依赖仓库的更新工作。另有团队尝试每日自动扫描生产缺陷积压清单，只有当Agent对修复方案的置信度超过极高阈值时，才会提出修复建议，否则将问题留给人类处理。可靠性团队则在构建可复用的技能，教Agent完成定义清晰的任务，比如搭建性能测试，部分技能已经成功生成测试套件并合并到生产服务中。

所有Agentic工作流都基于一套共享基础设施。我们维护了全公司共享的AI规则和技能仓库，任何工程师都可以贡献或调用其中的规则。同时我们还拥有评估框架，用于检查AI辅助代码评审是否能有效发现问题；以及编排模式，用于将需求或史诗级任务转化为范围明确、可评审的工作单元。尽管各团队使用的工具不尽相同，但共同的模式都是：在每个团队自己的工程闭环中，利用AI消除最重复、最依赖上下文、最容易造成延迟的工作。

在之前的研发变革中，我们看到瓶颈从编写代码转移到了对齐——也就是开会、写文档和反复沟通，确保所有人对“应该做什么”达成一致。而到了Agentic阶段，执行能力大幅提升，瓶颈再次发生转移，这次变成了判断力：真正值得做的事情是什么？哪些工作可以安全自动化？哪些问题需要升级给人类处理？哪些工作从一开始就应该完全由人类主导？当执行成本越来越低时，需求质量、范围定义质量和评审质量反而变得更加重要。将模糊的工单交给速度极快的Agent，并不会让你更快得到正确结果，反而会让你更快得到一个错误结果。

当思考工作已经被充分完成时，自动化才能发挥最佳效果。这并非全新的工程原则，但Agentic工作流将这个原则变得更加明确：过去手工开发中可以勉强容忍的模糊之处，在Agentic工作流中已经无法蒙混过关。一个强大的Agentic系统需要清晰的问题定义、良好的验收标准、可拆解为单个拉取请求的任务、明确的非目标和约束、审计轨迹、评审关卡，以及清晰的人类责任归属。我们不得不接受一个现实：现在的工单必须同时写给人类和AI阅读。一个能减少人类理解歧义的工单，同样能减少Agent的歧义，反之亦然。独立研究也验证了护栏的重要性：一项针对数百个拉取请求的分析显示，AI辅助生成的请求在评审中暴露的问题数量大约是纯人类编写请求的1.7倍，逻辑错误的概率高出75%。另有安全研究发现，相当一部分AI生成的代码样本会引入已知的安全漏洞，且使用更大参数、更强能力的模型也无法稳定解决这个问题。这些发现并非证明不应使用AI工具，反而证明了评审关卡、有限权限和人类对最终结果负责，并非可有可无的额外开销，而是让自主性真正可用的前提。简单来说，好的护栏才能让速度变得值得信任。系统的可靠性并非来自一个巧妙的提示词，而是来自一套强大的运行规则——这些规则不能依赖于“每一次提示词都足够聪明”。

工程师花在“将需求手动转化为样板代码”上的时间会越来越少，相应地，他们会将更多时间用于规划、评审、调试、定义意图、系统思考和发现风险。但这一切都需要深厚的技术能力作为支撑：在Agent输出进入生产环境前，必须有人拥有足够的知识来信任它、纠正它或推翻它。工程师的工作杠杆正在发生变化，正确定义问题、约束执行范围和严格验证结果的能力变得越来越重要。在覆盖十多个团队、数十名工程师的内部试验中，我们清晰地看到了这种模式：这些工具带来的变化，与其说是让工程师把原有工作做得更快，不如说是改变了工程师的工作方式。绝大多数工程师表示，他们仍然会像评审团队成员提交的请求一样，严格审查Agent生成的内容。这种本能是完全正确的：我们应该将Agent的输出视为任何协作者交出的第一版草稿来处理。随着Agentic工作流不断扩大，这正是我们希望继续强化的行为方式。

如今，我们的工程团队提出的问题已经发生了变化。过去更多是“我们能不能把它做出来？”或者“我们应该怎么做？”，现在越来越多的问题变成：“这真的是正确的东西吗？”“这个问题的定义方式正确吗？”“我们构建它所依赖的系统，是否拥有正确的约束？”“真正合适的人，是否在真正关键的时刻参与了评审？”随着整个软件行业的执行能力越来越充裕、执行成本越来越低，那些从来都难以伪装的东西——产品判断力、技术判断力以及组织清晰度——反而变得更加重要。执行从来都不是真正的稀缺资源，真正稀缺的是判断哪些事情值得被执行。

我们将继续优化覆盖规划、实现、QA和运维调查的Agentic工作流。这意味着我们会投入更多资源建设更强的任务定义能力、更清晰的验收标准和更完善的评审实践，让Agent能够在明确的边界内安全工作；同时进一步扩大已经证明具有明确价值的工作流，包括告警分类、事故调查、代码库研究和待办事项梳理。我们还在努力让现有协作工具和开发环境更好地协同工作，让Agent可以运行在人类已经信任的持久化系统中。与此同时，我们仍会谨慎判断哪些场景适合Agentic工作流，哪些场景使用轻量级AI辅助已经足够，以及哪些工作应该完全由人类主导。我们会继续构建必要的安全护栏，让团队能够安全使用更高程度的自主性，同时不失去责任归属。从公司创立的第一天开始，我们的核心主线从未改变：消除摩擦，让人们能够专注于真正重要的工作。

感谢整个工程组织中所有以好奇心、健康的怀疑态度和谨慎精神尝试AI辅助和Agentic工作流的同事，正是这种组合让本文中的案例都来自真正运行中的系统，而非猜想。特别感谢参与构建共享Agent配置、自托管工作器、规划工作流的同事，以及各个尝试相关实践的团队成员。也感谢所有在真实代码库中测试这些工作流的工程师，他们逐行评审Agent生成的计划和拉取请求，并坦诚分享哪些方法有效、哪些无效。同时感谢我们的产品、设计、基础设施、安全和平台合作伙伴，帮助我们建立了必要的清晰度和安全护栏，让这些实验真正有价值，而非鲁莽的冒险。和上一轮变革一样，这次转型同样是团队工作，建立在信任、共同学习和负责任的持续迭代之上。