AI 代理端到端开发工作流

现有AI编码代理能较好完成单个开发任务，但处理包含多个关联任务的完整功能需求时，会遇到任务编排、依赖管理和风险控制等问题。近期有文章提出一套从Epic到合并的端到端AI代理开发工作流，可在减少人工干预的同时，保留变更风险所需的控制措施。

这套工作流的核心思路是将大型功能需求（Epic）拆解为粒度合适的独立任务，构建依赖关系图，让不同AI代理分工协作，再逐步集成验证。Epic作为需求意图的来源，应包含目标、背景、范围、验收标准等信息，实践中可将其作为GitHub父Issue，任务作为子Issue存放，贴近代码管理。

任务分解要关注内聚性而非代码量：一个足够粒度的任务，需要能独立交付、验证和回滚，可作为一个逻辑单元评审。如果一个任务同时包含调研和实现，应当拆分，先做调研减少不确定性，再执行实现，便于控制AI代理行为。

每个任务执行前需做就绪检查，确认结果清晰、范围明确、依赖已声明、架构决策已定等。任务运行采用隔离环境，每个任务有独立的Git分支、工作树或容器，避免文件冲突。任务依赖需要显式建模，编排器可并发执行无依赖任务，比让代理自行发现顺序更安全。

工作流设置三类核心角色：
- Planner：负责调研代码库，识别风险，制定执行计划，不修改生产代码。
- Builder：按批准的计划实现变更，更新测试，运行验证，提交变更，发起PR。
- Reviewer：独立评估变更结果，基于验收标准给出结构化的明确问题，而非模糊评价。

编排方式分为内部编排和外部编排，该工作流倾向于使用外部编排，支持确定性流程、显式并发和持久化状态。每次仅给任务提供完成工作所需的最小上下文，避免过多无关信息干扰决策，同时基于风险定义AI代理的自主权限：哪些操作可自动执行，哪些需要人工审批。

完整的实现流程从创建Epic开始，经过任务分解、构建依赖图、创建集成分支、生成任务上下文、运行Planner、创建隔离环境、执行Builder、发起任务PR、运行Reviewer、修正循环、合并到集成分支、Epic级验证、最终人工批准合并到主分支。可根据不同角色选择不同能力的模型，对工作流指标做量化测量，持续优化流程。

文章认为，AI辅助开发目前最值得关注的问题不是代码生成，而是编排。更强大的模型能提升单任务执行能力，但不能解决任务编排问题，合理的工作流可以把开发者从日常实现中解放出来，专注于需求、架构和风险等需要判断力的决策环节。