从需求到 PR：Agent 端到端软件开发的架构设计

从需求到 PRAgent 端到端软件开发的架构设计一、端到端自动化的诱惑与难处让 Agent 接收一个需求直接吐出一个可合并的 PR。这是研发效能的圣杯。听起来一步到位做起来步步惊心。难点不在写代码在做对的事。需求有歧义边界没说清依赖没理清。Agent 闷头实现产出的 PR 往往跑偏。端到端架构的核心是把理解拆成显式环节。让需求先被结构化再驱动实现与验证。本文探讨从需求到 PR 的完整 Agent 架构。二、端到端流水线的机制整条链路分四段理解、规划、实现、验收。理解段把自然语言需求转成结构化规格。规划段拆任务并排依赖。实现段写代码验收段跑测试与审查。每段都是独立 Agent 或步骤靠结构化数据衔接。这样任一段失败能精准定位而非全盘重来。链路围绕结构化规格这个枢纽流转。它既是规划的输入也是验收的标尺。没有它实现与验收各说各话。三、生产级架构实现下面用代码描述规格与链路的衔接。from dataclasses import dataclass, field from typing import Optional from enum import Enum class SpecStatus(Enum): DRAFT draft PLANNED planned IMPLEMENTED implemented ACCEPTED accepted dataclass class RequirementSpec: 需求到 PR 之间的单一事实来源 id: str goal: str acceptance: list[str] tasks: list[str] field(default_factorylist) status: SpecStatus SpecStatus.DRAFT pr_url: Optional[str] None def plan(spec: RequirementSpec) - RequirementSpec: if not spec.acceptance: # 没有验收标准规划无从展开退回补全 raise ValueError(需求缺少验收标准无法规划) spec.tasks [f实现: {a} for a in spec.acceptance] spec.status SpecStatus.PLANNED return spec def accept(spec: RequirementSpec, passed: bool) - RequirementSpec: spec.status SpecStatus.ACCEPTED if passed else SpecStatus.IMPLEMENTED return spec if __name__ __main__: spec RequirementSpec(R1, 导出报表为 PDF, [含分页, 含页眉]) plan(spec) print(f已规划 {len(spec.tasks)} 个子任务)真实系统会把 spec 落库各 Agent 读写同一份。链路可断点续跑失败从断点恢复而非重头。四、边界分析与架构权衡端到端自动化强大但禁区明显。需求歧义不可逆。规格转错后面全错。理解段必须有人确认或置信度门槛。低置信需求应暂停而非硬猜。验收标准的完备性。验收写不全PR 质量无保障。应由人或强规则补全验收再放行实现。这是质量的第一道闸门。上下文跨段丢失。各段独立易失隐含意图。解决方式把为什么写进 spec 的 goal 与注释。而非依赖 Agent 之间的默契。权限与安全。自动开 PR 要限分支、限范围。不能让它改 CI、删分支、碰密钥。最小权限是底线。需求到 PR 的验收自动化是可复现的关键。验收标准若只写在文档里每次都要人判慢且不一致。建议把验收标准结构化、可机器校验如接口返回字段包含 X可用测试断言让验收能自动跑。另一个实践是小步合入不要等整个大需求做完才开 PR而是拆成可独立验收的小块逐步合入缩短反馈环、降低单次风险。最后PR 描述要自动带出关联的规格与验收清单 reviewer 一眼看清这次满足了什么减少来回确认的成本。五、总结从需求到 PR 的端到端 Agent本质是用结构化规格串起各段。机制上以 spec 为枢纽理解、规划、实现、验收各管一段。工程上靠人确认需求、最小权限兜底安全。落地路线先把需求转结构化规格并补验收再拆任务规划实现后接测试与审查设权限上限与断点续跑。自动化的是流程不放手的判断。