Coding Agent 跑了 30 分钟，到底在忙什么？先看这四层
很多开发者直观感受到Coding Agent跑任务耗时久，却不知道它的工作时长基本都耗在质量保障和流程合规环节，远不是生成几行代码就能收工。
代码跑完不等于交付，自检循环占大半时长
大部分用户对Coding Agent的误解是“写完代码就完成任务”，但实际上它的工作流里，代码实现只是中间环节，后续的自检才是耗时大头：首先它会对自己生成的代码做批判性审视，判断可读性是否达标、注释是否充足、是否存在潜在性能问题或安全漏洞、是否遵循项目的代码风格和最佳实践，这个自我审查可以通过阅读代码、运行Linter工具或调用专门的代码审查子Agent实现，一旦发现问题就会回到修改阶段完善，不会把有缺陷的代码交付给用户。
完成代码审查后，它会立即进入测试驱动的质量保障环节：为新增或修改的功能编写测试用例，覆盖正常路径、边界条件和异常情况，执行测试套件，如果测试失败就分析原因、定位问题、修改代码，直到所有测试通过。这个“测试-修复”循环往往需要多次迭代，正是这种自我纠错能力将Coding Agent从简单的代码生成器升级为可靠的工程助手。反过来说，Coding Agent最常见的“偷懒”行为就是跳过这环节，写完代码不跑测试就报告“任务完成”，把“测试通过”而非“代码写完”定义为完成标准，正是工程体系里“由验证判定何时可以停”原则在编码场景的落地。
架构类修改必须同步更新文档，避免知识库失真
如果代码修改涉及架构层面的变化——例如引入新模块、改变模块间依赖关系、修改核心抽象语义，Coding Agent会相应更新架构文档，避免过时文档误导未来的开发者。通过在每次重要修改后自动更新文档，Agent帮助维护了项目知识库的完整性和时效性。
这套流程完全落地了软件工程的核心原则：计划先于行动，验证贯穿始终，文档与代码共同演化。不过需要注意的是，上述是推荐的工程化标准流程，现实中的Coding Agent（如Claude Code、Codex）会按需裁剪这套流程：简单bug修复任务会跳过生成设计文档的环节，只有任务复杂、影响面大时才会完整走完各阶段。
多层多模型Review把问题拦在交付前
行业数据显示，工程师用AI完成约60%的编程工作，但能“完全委派”的任务占比只有0-20%，这也让Review环节的重要性被进一步放大，而非缩小。不少团队已经跑通了Initializer+Coding Agent双Prompt架构，解决了此前Agent运行时常出现的三大问题：一是Agent尝试one-shot生成整个应用，context在实施中途耗尽，下一个session接手半成品烂摊子；二是后面的Agent看到前面已经有进度，直接宣布完成提前下班；三是Agent写完代码只跑单元测试就标记done，但E2E测试完全是坏的。
这套架构的工作逻辑很清晰：第一个Initializer session负责搭建环境，生成一份JSON格式的完整feature checklist（不用markdown是因为Agent会偷改markdown结构）、init.sh开机脚本、空的交班日志claude-progress.txt，以及初始git commit；后续每个Coding Agent session都按git flow流程运行：
- 读取交班日志+git log
- 读取feature list，挑选最高优先级的任务执行
- 完成任务后提交代码、更新交班日志
Review环节更是做了多层拆分：- /review：PR级审查，排查bugs、逻辑错误、边界case、安全问题
- /codex：调用OpenAI Codex CLI做跨模型交叉审查，两个不同AI看同一份代码，重叠发现的问题为高信心问题，各自独有的问题需要人工判断
- /qa：用真实浏览器跑E2E测试，不是跑单元测试就算完成
- /simplify：开3个平行agent分别检查代码复用率、代码质量、执行效率
这套逻辑完全对应了“人类监管从审查所有内容变成只审查需要判断力的部分”的理念，Agent先完成第一轮问题筛选，人类只需要Review真正需要决策的内容。
四象限任务边界明确Agent的“停机标准”
Harness工程体系会用「任务清晰度」和「验证自动化程度」两个