从「跑通即正确」到「交付可验证」：Coding Agent 研发落地的反思与迭代

当团队第一次看到 Coding Agent 能从需求文档直接跑出代码时，很多人以为找到了研发提效的终南捷径。但真正把它接进真实迭代需求后，我们才意识到一个更根本的问题：流程能从头跑到尾，从来不等于跑出来的东西是对的。全自动最大的风险，不是它会犯错，而是它错了还在自信地往前跑。网盘团队正是基于这个认知，完成了一次从「一次性全自动流水线」到「人机多轮反馈循环」的关键转变。这不是简单的工具切换，而是对自动化与可控性如何平衡的工程反思。

流程跑通不代表结果正确

早期我们搭建了一套从需求分析到质量检查的自动化流程，期望实现「需求进、代码出」的愿景。然而一旦接上真实的迭代需求，问题立刻显现：有的任务走到一半被还没就绪的服务接口卡住；有的代码虽然走完了所有阶段，却是基于一份没人确认过的需求理解写出来的，等到验收才发现对不上，只能回头返工。更棘手的是，过程记录不完整时，连偏差最早在哪一步产生都说不清。问题根源在于：我们太指望每个阶段的输入都完整、都可靠，但现实里的需求描述、历史知识和外部依赖，往往带着大量未确认的空白。流程必须有本事把这些不确定性先识别出来，而不是假装它们不存在，一路把「不确定」当「确定」传下去。

七类典型问题的深层根源

把踩过的坑摊开来看，大致分为两类：执行过程中的信息堆叠与定位困难，以及任务输入层面的准备不足。在执行过程侧，上下文越堆越多，关键事实反而更难保持一致——字段引用错、接口判断失准、把早期推断当成确定事实继续用，这些问题单靠「把上下文喂得更丰富」并不能解决。更要命的是偏差一旦出现，往往缺少定位的抓手：运行记录只留了各阶段的结果，排查时很难还原当时的输入和判断依据。在任务输入侧，需求描述常有歧义、历史经验未显式化、知识图谱覆盖不全、外部依赖状态不稳定，这些因素共同导致 Agent 在不完整的上下文中做出自以为正确的决策，最终把错误固化在代码里。

重新定义人、工具与 Agent 的分工

经过反复实践，我们重新划定了三者的职责边界：路径选择、分支逻辑、编译校验、日志上报这类有明确规则的事，交给确定性脚本和质量门禁处理，避免每次任务都重复判断；而需求口径、方案取舍、历史兼容、体验评估这些需要结合业务背景做判断的事，必须由人来做最终决定。Agent 的角色是组织分析和执行——把证据理清楚、把候选方案摆出来，真正有分歧的地方交给对应责任人拍板。在这个基础上，我们把一次性执行改成多轮反馈循环：每一轮围绕明确目标做修改和验证，再决定下一步怎么走。这套机制我们称之为 Agentic Engineering Loop，它保留了规格驱动开发的核心思路：先把目标、约束和验收标准定清楚，再去组织实现和验证。执行前先做需求调研，把不确定项挂账；执行中分轮验证、过程全程可观测；人、Agent 与工程工具各司其职、各担其责。

让执行过程看得见、可回溯

新的工作方式已经在网盘日常研发中落地应用。需求进入循环前，先做一遍证据化的成熟度打磨，找到相关文件和调用关系，顺着提交历史理解当初的设计意图，划清改动范围和必须保持不变的行为边界，把需求、验收标准和改动计划各自编号，方便在实现和验证时一一对上。本地执行通过上报机制，把每一轮的事件、指标和迭代记录汇聚到远端平台，整理成运行、任务、事件、产物等结构化记录。研发同学可以及时判断该不该介入，团队复盘也有共同依据。更重要的是，这些记录沉淀下来形成趋势，慢慢成为团队的经验资产。目前需求相关的知识图谱覆盖还不全，Agent 自己检索上下文的能力被这个卡着；把存量经验沉淀成可复用的 Skills 还在探索中；自动化程度和可控性之间的平衡点，也仍在持续调试。

这次调整把关注点从「生成一次代码」拉到了整个交付过程：需求理解得准不准、改动有没有越界、验证能不能撑住结论、出了问题能不能回溯——这些才是自动化能不能真正发挥价值的前提。让生成的代码更容易被检查，让执行过程更容易被看懂，让每一次交付都留下一份清晰、可复查的依据，这条路我们会继续走下去。