从Vibe Coding到Agentic Engineering：如何让AI真正按软件工程流程工作

1. Vibe Coding爽过之后为什么大家都开始回头谈“流程”了1.1 Vibe Coding的甜与痛过去这一年多“Vibe Coding”几乎成了AI编程的代名词。它的核心体验其实很简单你不需要先想清楚再动手你把一个模糊的想法说给AI听AI给你生成一版能跑的代码你在旁边看着、改着、说“不是这个感觉”再让它继续改。整个过程中人类更像是“甲方”而不是“工程师”AI是那个被反复使唤的“全栈外包”。这套模式爽是真的爽尤其是做原型、做Demo、写一次性脚本的时候。我见过不少朋友用Vibe Coding的方式一个周末搓出一个带前端、后端、数据库的完整产品雏形放在Github上还能收到star。过去这种活儿至少得一周现在一个晚上就能搞定。但问题也出在这里当项目规模超过某个临界点之后Vibe Coding的体验会迅速恶化。最典型的几个信号代码库开始出现大量重复逻辑一个功能在三个文件里有三种写法AI生成的代码经常绕过已有的抽象层自己另起炉灶“改一处崩三处”的情况越来越频繁因为AI根本不知道代码库其他地方是怎么依赖这块逻辑的最要命的是你不敢让AI自己改大东西了——因为没有人能说清楚整个系统现在的真实状态。为什么因为Vibe Coding天然是一个“缺少工程约束”的对话过程。它不关心你的代码规范、不关心模块边界、不关心测试覆盖、不关心变更影响面。它只关心一件事你的这条指令它能不能尽量给出一个“看起来合理”的回答。这种模式在单文件、小范围、低压力的场景下是高效的但一旦进入多模块协作、多人共建、长期维护的软件工程语境它就开始失灵。1.2 从“让AI写代码”到“让AI按流程干活”于是行业里开始出现一个新词Agentic Engineering。这个词直译过来是“智能体工程”但我觉得更好理解的说法是——把AI Agent当作软件工程项目里的一名正式工程师来管理而不是一个随时喊一嘴的外包帮手。这两个定位的区别非常大。你让AI“写一个登录接口”这是Vibe Coding的用法。你让AI“阅读需求文档、拆解任务、设计接口方案、写测试、实现代码、跑完整回归、提交变更申请”这是Agentic Engineering的用法。前者是单点执行后者是流程参与。前者你只要结果后者你要求它对过程负责。为什么这个转变很重要因为软件工程这个行业花了几十年才沉淀下来的东西——需求管理、设计评审、代码规范、测试门禁、代码评审、灰度发布——它们不是官僚主义的摆设而是在大规模协作中用来“降低信息熵”的手段。AI Agent如果只是替代“写代码”这个动作那它本质上还是一个人的打字机不可能从根本上改变软件生产的效率结构。只有当Agent真的进入流程、被流程约束、也对流程负责的时候我们才谈得上把生产力放大一个量级。1.3 这里说的“软件工程流程”具体是什么说到“让Agent按照软件工程流程工作”先得把“流程”这个词落到实处否则容易变成空喊口号。我理解的、在Agentic Engineering语境下最有价值的流程至少包括这几个环节需求摄入与规格化把一句模糊的“我要一个订单管理后台”变成一份可以执行的需求规格说明包含功能点、边界条件、验收标准。架构与技术选型约束明确哪些模块可以动、哪些是核心领域不能碰、技术栈用什么、接口风格是什么。相当于给AI画了一个“可以自由发挥的边界”。任务拆解与依赖排序把一个中型需求拆成若干个可以独立验证、独立提交的工作单元并确定先后关系。测试先行与验收驱动在写实现代码之前先定义测试用例和验收条件实现代码以“让测试通过”为目标。变更集成与回归验证代码只是中间产物真正有价值的是它能安全并入主干、不破坏现有功能。评审与度量对Agent产出的变更做质量评审并持续统计缺陷率、返工率、交付周期等指标。这套流程对真人工程师来说已经写过太多“流水线文档”了不难理解。但难点在于怎么让一个LLM驱动的Agent也老老实实走这套流程这不是靠prompt里写一句“请遵循软件工程最佳实践”就能解决的。它需要我们在技术架构上设计一套约束和反馈机制让Agent只能在流程的轨道里工作而不是凭“感觉”自由发挥。2. Agentic Engineering的本质给Agent造一个“工程脚手架”2.1 为什么直接丢一个大任务给Agent必然翻车先做一个思想实验你把一个完整的“重构用户认证模块支持多因素认证”任务交给一个具备工具调用能力的Agent终端它能完成吗大概率不能至少不能可靠地完成。原因有三个第一上下文窗口是有限的。一个真实项目的代码库动辄几十万行Agent无法在一次对话里加载全部上下文。它看到的是它“认为”相关的代码片段而它“认为”相关的粒度是token级别的相似度不是工程语义上的依赖关系。结果就是它经常遗漏修改点。第二长流程中的状态一致性难以维持。一个复杂重构可能需要几十步操作。每一步操作都会产生新的文件内容、新的报错信息、新的测试结果。Agent如果要记住所有这些中间状态并保证每一步的决策都基于最新状态几乎是不可能的。它一旦忘记某个细节就会基于过时信息做出错误决策。第三任务太大会让Agent失去判断优先级的能力。当所有事情都“很重要”的时候它就开始平均发力。你说重构认证模块它会先花大量时间优化目录结构、把import顺序理顺而真正关键的多因素认证逻辑反而草草了事。这是Vibe Coding时代最常见的问题AI会在不重要的地方表现得很认真在关键的地方表现得很敷衍。所以让Agent按流程工作的第一步不是让它更聪明而是把一个巨大、模糊、无法验证的任务拆成一组小、清晰、可验证的子任务。这就是工程脚手架的第一个作用。2.2 核心思路Spec-Driven Harness现在行业里比较有共识的做法是Spec-Driven Development规格驱动开发简称SDD配合一套称为Harness的“约束框架”。Spec-Driven的含义是AI的每一次编码行为都必须从一份“规格说明”开始。这份规格说明不是让AI自己编的而是由一个更上层的过程生成、并且由人或更“较真”的Agent审查过的。规格里写清楚这个任务的目标是什么涉及的模块和文件范围是什么哪些是必须遵守的约束比如不得修改公共接口、不得引入新的依赖库验收标准是什么比如必须有测试覆盖、必须通过哪些静态检查。Harness则是一个更底层的概念。它定义的是Agent在一整个开发流程中的“活动区间”——它在哪台机器上运行、它能读写哪些目录、它能调用哪些工具、它被允许执行哪些命令、每一步完成之后需要产出什么中间物。Harness的作用很像游乐场的护栏不是限制Agent发挥而是确保它再怎么“自由发挥”也出不了危险的边界。我见过的一个比较典型的Harness设计包含这样几层层级示例配置目的运行环境容器化沙箱、临时分支、受限网络隔离对真实环境的影响工具权限允许运行测试、静态检查禁止操作生产环境、禁止修改依赖锁文件缩小风险面文件范围只允许读写本次任务涉及的白名单目录防止改动扩散流程约束必须先产出设计文档、必须先写测试、测试不通过不得提交保证过程质量出口门禁提交信息必须关联需求编号、必须通过全部CI检查保证合并安全这套东西的价值在于它把“软件工程流程”从一个抽象理念变成了Agent执行环境里的物理边界。AI不守流程的时候不是靠它自觉而是它压根就越不过那个边界。2.3 让Agent感知“当前阶段”与“全局目标”多步骤流程中另一个容易忽略的问题是Agent不知道自己“现在到哪一步了”。真人工程师从需求评审会回来会知道“当前处于设计阶段接下来要出技术方案”从设计文档的状态更新里会知道“评审已通过进入编码阶段”。这些元信息虽然细微但对工作质量影响巨大。Agent没有这种天然的时间感和阶段感。如果你没有显式告诉它“你现在处于第几个阶段”它就会把所有任务都当成同一个类型来处理。你说“把这段逻辑用策略模式重构一下”它不会意识到这是“编码阶段测试要同步更新”它可能改完实现逻辑就停在那里完全不碰测试。所以在Agentic工程实践中一个非常关键的设计是把流程阶段编码进Agent的上下文。常见做法是在Agent每次启动时注入一份“当前任务状态”{ task_id: AUTH-1142, current_stage: implementation, global_goal: 支持MFA登录流程, milestones: [ {stage: spec, status: done}, {stage: design, status: done}, {stage: tests, status: in_progress}, {stage: implementation, status: pending}, {stage: verification, status: pending} ] }这个状态文件让Agent在任何一个决策点上都能回答“我在哪里”“我要去哪里”“我已经完成了什么”。别小看这一步——很多Agent跑偏不是因为能力不够而是因为它真的“不知道自己在哪”。2.4 多Agent协作是自然选择不是炫技聊到让Agent按流程工作就很难不提多Agent架构。很多人以为“多Agent”就是一种潮流仿佛Agent多就等于效率高。但在我理解里多Agent协作之所以在Agentic Engineering里几乎不可避免根本原因是不同的流程阶段对“Agent人格”的要求是完全对立的。需求分析Agent需要发散——它要能从模糊的业务描述里想到各种边界情况、异常场景、未来扩展点。而编码Agent需要收敛——它要严格按照规格把代码写出来不能天马行空。你要是让同一个Agent既负责发散又负责收敛大概率两头都做不好。再比如测试Agent是“防御型人格”它的任务是找茬、挑错、验证假设而实现Agent是“进攻型人格”它的任务是快速产出可运行的代码。这两种人格放在同一个Agent身上要么就会自己先打起来要么就会用一个折中的、两头都不靠的状态工作。所以我把多Agent的理解是它是流程分权的自然延伸。既然流程分阶段而不同阶段的能力要求不同那就让不同的Agent各自负责自己最擅长的阶段用一个编排层把它们的产出串起来前后传递规格、代码、测试结果、评审意见。人负责的是流程设计者和最终审批者的角色而不是替Agent“代笔”。3. 真正让Agent“按流程工作”的落地做法一条完整链路3.1 第一步需求摄入与任务拆解先写Spec再动手任何Agentic Engineering的落地都要从“需求怎么进入系统”这一步开始。我见过很多团队上来就跳进“怎么调Agent写代码”的坑结果发现Agent在代码层面确实写得不错但做出来的东西根本不是需求方想要的。原因就是需求进入的方式不对——要么是一句话直接扔给编码Agent要么是给了一段含糊的聊天记录让它自己领会。正确做法是设置一个独立的需求分析/产品Agent或者人工流程输入是一段口语化的业务诉求输出是一份结构化Spec。我建议Spec至少包含几个部分目标描述一句话说清楚为什么要做这个功能解决什么业务问题用户故事/用例场景以“作为XX我希望XX以便XX”的格式列出核心场景功能清单小粒度地列出要支持的能力点每一条都必须可以独立验证业务规则与边界条件比如金额不能为负、状态流转必须经过中间态、并发下如何加锁非功能需求性能要求、兼容性要求、安全与合规要求验收标准每种场景下什么算“做对了”。Spec写完之后还有一个关键动作拆解任务。这一步可以由人来做也可以由一个专门的规划Agent基于Spec自动拆但我建议拆完之后由人再过一遍。拆解的逻辑是每一个任务单元必须满足“可独立提交、可独立验证、变更范围可控”三个条件。一个500行的重构不应该是一个任务而应该被拆成“模块A的接口签名更新”“模块A的实现替换”“调用方适配”“测试用例更新”“文档更新”五个任务。这里有一个非常实用的经验每个任务单元的实现量控制在200-400行代码量级或者等价的重构工作量是比较合适的。太大Agent容易失控太小流程开销占比过高反而不划算。3.2 第二步设计评审与架构约束代码不是第一产出物Spec敲定、任务拆完之后很多团队就会让编码Agent直接开工。这个跳跃是有问题的。编码Agent开工之前还需要一个“设计”的环节。这个环节的产出物不是代码而是一份足够细的技术设计方案至少要包括涉及的模块与文件清单新增/修改的接口定义方法签名、数据结构、错误码数据存储变更方案如果有的话依赖引入说明尽量不引新依赖兼容性与回滚方案。设计环节为什么不能省因为真实项目的架构约束往往是隐性的——某个模块不能引入数据库依赖、某个接口必须保持向后兼容、某个数据表变更需要迁移脚本。这些约束如果不在设计阶段显式写明编码Agent根本无从知晓。它很有可能会在一堆历史代码中“按自己的审美”做设计结果产出的代码跟整个项目的架构风格完全脱节。更现实的问题是设计阶段是人工介入成本最低的阶段。看一份设计方案可能只要10分钟而看Agent提交的2000行代码、然后要求返工可能要花2小时甚至更久。所以但凡复杂度超过“给单个函数加一个参数”级别的任务都应该让Agent先出设计再动手宁可设计阶段慢一点也不要等到代码阶段再来纠正。3.3 第三步测试先行编码Agent的“产出边界”设计评审通过后进入真正的编码阶段。但这里有一个顺序问题先写测试还是先写实现在传统的TDD流程里是先写测试再写实现让实现代码以“通过测试”为目标。在Agentic Engineering里这个顺序被赋予了更重要的意义测试是约束编码Agent行为的锚点。为什么不先写实现再补测试因为如果让Agent先写实现它对测试的态度通常就是“凑覆盖率”——它会写出大量断言非常脆弱、没有实际校验逻辑的“假测试”。反过来如果让Agent先基于Spec写测试那么测试本身就变成了一份“可执行的规格说明”实现代码必须解释清楚“为什么这组测试定义了正确的行为”。这个锚点会让Agent的编码过程收敛得多。具体操作上我会为每个任务单元设置两条Agent执行路径并确保它们跑在独立沙箱中# 测试Agent先产出测试用例 agent run test-writer \ --spec docs/specs/AUTH-1142.md \ --output tests/unit/auth_mfa_test.py \ --base-branch main # 实现Agent在测试就位后实现代码 agent run implementer \ --test-file tests/unit/auth_mfa_test.py \ --source-dir app/services/auth/ \ --output app/services/auth/mfa.py编码Agent的产出边界必须非常明确它写的是“让测试通过的实现代码”不是“它认为有价值的代码”。任何实现范围之外的改动比如顺手重构一个相邻函数、把README措辞改了都应该被视为违规并在评审阶段被拦截。3.4 第四步自动验证门禁防止“假成功”编码Agent提交实现之后流程并没有结束恰恰是后半程的开始。我们进入自动验证阶段。“假成功”是Agentic Engineering里最值得警惕的现象。什么叫假成功就是Agent告诉你“已经改好了测试都过了”但事实上它只跑了它自己写的那个测试文件没跑全量回归测试里用的是mock数据而且mock得过于理想根本没有覆盖真实环境下的数据形态代码能编译通过但类型检查器在严格模式下报了一堆错静态检查工具被它跳过了因为CI里没配它对接口的改动破坏了下游调用方的契约但下游的编译错误在另一个模块里它没检查到。针对这些情况必须在流程里设置多层验证门禁并且这些门禁不能由实现Agent自己执行和自述结果而要由独立的验证Agent运行并出具报告。我常用的一套门禁清单是这样的门禁项工具拦截条件单元测试pytest / jest测试失败或覆盖率不达标静态类型检查mypy / ts checker类型错误代码规范ruff / eslint违反规范项数超阈值全量回归CI pipeline任何既有用例失败依赖安全检查audit工具引入高危漏洞依赖变更范围检查git diff统计改动文件超出白名单注意最后一条变更范围检查。这是很多人会漏掉但极其重要的一条。因为Agent经常会在“顺手”中改坏东西而变更范围检查是成本最低、最客观的防线——它就是一条简单的git diff命令看看到底改了哪些文件。3.5 第五步合并前评审与回归验证人工关口怎么留所有自动门禁通过之后还需要一步评审与合并。这一步我认为目前还不能完全去掉人工。原因不是AI评审不够好——事实上AI评审在挑代码风格、找重复逻辑、发现遗漏的测试用例方面已经比很多真人reviewer更细致了。但AI评审有一个天然的盲区它不知道业务方的真实意图。一份Spec写得再详细也无法把客户开会时的语气、PPT里的一张架构图、运营负责人强调的那个数字背后的焦虑都表达出来。所以我的建议是自动评审全量跑AI评审逐个过最终的人工评审只看关键差异。具体做法是Agent提交的变更首先经过自动门禁和AI评审Agent产出一份“问题清单”所有阻塞性问题blocker必须被解决后变更才进入人工评审队列人工评审者不需要逐行看代码而是重点看Spec是否被正确理解、设计方案是否被完整执行、AI评审清单中非阻塞项是否有合理解释、以及变更带来的风险是否可控。这一步还有一个实践细节人工评审者的工作流也要被“工程化”不能让人靠感觉点按钮。我建议把合并门槛定义成一条严格的规则只有全部自动门禁通过、且至少一个真人评审者明确点了approve变更才能被合并。这条规则在Git分支保护里直接配置死不能因为时间紧就临时绕过。4. 过程中踩过的坑与解决办法4.1 Agent的“假成功”怎么识别和拦截前面提到了“假成功”这个概念这是我在实际改造中最先撞上的一堵墙。当时我让一个实现Agent去改一个支付模块的状态机逻辑。半小时后它回复“已完成测试全部通过”。我让验证Agent跑了一遍全量回归结果挂了13个用例。原因很典型实现Agent在自己的工作目录里运行了单测但它只跑了它修改过的那个测试文件而且那个文件的测试函数因为import路径错误实际上是静默跳过了——pytest把它当成“collection error”Agent没看输出细节只看到“0 failed”就以为通过了。这个坑给我的教训非常深刻绝对不能把“Agent自述的验证结果”当作有效结果。从那以后我把验证环节从实现Agent的执行环境中剥离出来用独立进程、独立沙箱执行并且要求输出中必须包含“实际运行的测试用例总数”“失败数量”“跳过数量”这些原始指标不允许只报一句“Test passed”。另一个有效手段是在Harness里配置“输出接管”实现Agent的终端输出不再直接返回给Agent自己判断而是先经过一个解析器提取出关键指标再决定是否继续下一步。如果解析器发现“测试报告里没有统计项”直接判定验证无效让Agent重新提交。这等于在流程里加了一个“质检员”而不是让写代码的人自己汇报质量。4.2 上下文漂移长任务中怎么保持一致性第二个大坑是上下文漂移。场景是这样的一个任务设计阶段挺好Agent也完整理解了Spec的全部内容。但执行到第40分钟、已经做了十几轮工具调用之后它“忘了”最开始的设计约束开始按自己当前的局部理解做决定。最典型的表现是Spec里明确写了“不得引入新的第三方依赖”Agent在实现第7个文件时觉得“其实用一下lru_cache更优雅”就顺手加了一个。不是它故意违反规则而是它的上下文窗口中那条约束已经因为早期太多工具输出被冲掉了。这个问题有治标和治本两层解法。治标在Agent的上下文中周期性地“重新注入”核心约束。我见过的最简单有效的做法是——在每次工具调用之后把那条最高优先级的约束重新写回系统提示词的最前面。成本不高但效果立竿见影。治本改进任务拆解。如果一个任务长到会出现明显的上下文漂移说明这个任务拆得还不够细。一个执行单元应该控制在Agent能“一口气完成”的范围内——通常来说10到20次工具调用以内是一个合理区间。超过这个区间就应该从流程层面把它拆开而不是指望Agent用更长远的“毅力”硬扛。4.3 工具调用失控给Agent配置最小权限第三个坑是关于工具权限的。Agent在编码过程中需要调用很多工具执行命令、读写文件、跑测试、查文档、调API。如果你给它的权限过于宽泛很容易出事。我曾经的配置失误是让编码Agent的沙箱直接挂载了整个项目仓库的写权限结果Agent在一次“顺手修复”中把另一个模块下的依赖文件也给改了。它可能觉得那个改动是合理的但它完全不知道那个文件是由另一个团队维护的、改动不能随意提交。从那之后我把权限控制的原则改成了“最小够用”每个任务单元只能读写自己的白名单目录能限制执行的命令范围就限制比如只允许跑测试和静态检查不允许执行任意shell命令Git提交权限由编排层统一控制Agent自身不接触git push。这些限制在Harness层用容器或权限系统固化下来。刚开始会觉得麻烦但出了一两次事故之后就会理解为什么“让Agent不能犯错”比“让Agent不犯错”重要得多。4.4 流程回环与死循环超时和重试策略第四个坑是流程层面的Agent在某个环节卡住或者反复重试但一直不成功整个流水线就堵死了。死者循环的常见形态有两种一是验证门禁持续失败Agent反复“修复再提交”但每次修的都是同一个问题的表象根因一直没变二是设计评审通过不了Agent反复改设计方案但改来改去都在一个思路上打转。针对第一种我设置了“失败重试上限”同一个任务单元最多重试3次3次全失败就把任务升级给人处理。升级的同时之前所有的失败日志、验证报告、Agent的每一次修复尝试都要打包提交给人。这样人不需要重新让Agent跑一遍就能看到“它为什么一直修不好”。针对第二种问题通常在于设计评审Agent和人之间缺乏有效的“否定原因”传递。后来我要求评审Agent的否定意见必须结构化输出——具体到违反哪一条约束、缺了哪个模块的设计、哪个风险没有应对方案。这样设计Agent才能基于具体原因去修改而不是拿一句“请重新设计”去猜。我也特别提一下不要让Agent长时间无人值守地运行。任何一个步骤的自主运行时间超过30分钟就应该触发一个检查点把中间产物固化下来、汇报当前状态。这既是审计需要也能避免Agent在一个错误方向上越走越远。5. 哪些工具能支撑这套流程落地5.1 先别急着选框架把流程定义想清楚聊完踩坑说说工具选型。现在市面上支持AI Agent开发的框架和工具越来越多但我不建议一上来就盲目选一个“看起来很强大”的框架。我的建议是先花时间把你想要的“流程”本身定义清楚。你可以先回答这几个问题你的流程里有哪几个明确的阶段每阶段的输入输出各是什么哪些环节需要人参与人的参与是审批型还是协创型哪些验证是自动跑、哪些需要人看各自的门槛是什么一个任务的失败重试策略是什么失败之后谁负责兜底这些定义清楚之后再去看工具你会发现很多工具的设计理念会帮你自动解决这些问题而另一些工具则可能跟你想要的流程冲突——直接把Agent暴露给一个无约束的对话式环境那种工具就不适合做Agentic Engineering。5.2 从“能跑”到“工程化”给团队的分步改造建议最后很多团队问我改造应该是怎么一个节奏大爆炸式还是渐进式我的建议是渐进式并且严格遵循“先外后内、先软后硬”的原则第一周只做一件事把需求摄入和Spec生成的环节流程化。让AI先产出结构化需求规格人评审然后作为后续所有环节的基础。这一步不改动代码生成方式但为后续所有改造打地基。第二周到第三周挑一个低风险模块做试点。选一个团队熟悉、改动量小、有充分测试覆盖的模块在上面试跑“Spec → 设计 → 测试 → 实现 → 验证”的完整链路人全程在场观察。一个月后跑通一条稳定的流水线再逐步扩大任务类型和模块范围。任何新模块要接入都要先满足前几个模块相同的测试覆盖率基线。不要一上来就追求“全程无人值守”。在Agentic Engineering成熟之前最高效的工作模式其实是一个高效的人管理一支AI“小团队”而不是把人完全撤走。每个阶段你是否保留人工关口、保留多少应该基于实际质量数据来调整而不是为了“All in AI”而强行自动化。5.3 有一条经验想特别分享在实践Agentic Engineering的过程中我最深的体会是最重要的不是Agent多聪明而是流程多坚韧。一个不那么聪明的Agent在一个约束良好的流程里也能稳定输出及格线以上的结果。反过来一个非常聪明的Agent在没有流程约束的环境里会以极高的效率犯下极其离谱的错误。这就像让一个资深工程师在完全没有测试、没有设计、没有代码评审的环境里工作——他也不是不能写但他写出来的东西大概率是失控的。Agent也是一样。Agentic Engineering的本质是把过去靠“人自觉”才能维持的工程纪律变成环境自动维护的强约束。所以如果你问我“如何让AI Agent真正按照软件工程流程工作”我的回答从来不是“提示词教得好”而是别把流程寄托在Agent的自觉上把流程做成Agent逃不出去的环境。Spec是它的宪法Harness是它的边界验证门禁是它的质检员人工评审是它的最终保险。把这套脚手架搭好你会发现AI Agent不是一个偶尔灵光一现的天才而是一个稳定可靠的执行者。这正是我从Vibe Coding走到Agentic Engineering之后最大的感受转变。前者让我相信AI什么都能干后者让我知道AI怎么干才靠谱。如果说Vibe Coding是给AI松绑那Agentic Engineering就是给AI画跑道——松绑让我们看到了它的上限画跑道才让它真正跑出成绩。