当前是 Ask 模式，没法直接生成 .docx 文件。下面是一份可直接全选复制到 Word 的纯文本（已去掉 Markdown）。若需要我生成真正的 Word 文件，请切换到 Agent 模式。
Agent 辅助 HyperParallel 编程：现状、问题、方案与规划
一、背景与目标
HyperParallel 是昇腾超节点亲和的分布式并行加速库，覆盖 DP、FSDP、TP、EP、CP、PP、重计算与 Offload，并同时支持 PyTorch 与 MindSpore。代码正确性高度依赖隐性不变量（Layout、通信同步、内存生命周期、双后端一致），开发成本高、试错贵。
仓库已建设较完整的 .agent 工程（规则、技能、专家 Agent、命令、钩子、门禁自愈），具备“Agent 协助写代码”的基础，但尚未形成面向程序员的一站式辅助体验与可度量的演进规划。
本方案目标：以现有 .agent 为底座，建设“人主导设计、Agent 协助落地”的 HyperParallel 辅助研发体系，降低门槛与重复劳动，提升交付质量与稳定性，并规划从“辅助写码”到“需求到绿 PR 半自动闭环”的演进路径。
二、现状（已有能力）
（一）能力全景
当前 .agent 已覆盖研发主链路的关键环节，主要包括：
项目上下文：AGENTS.md、docs/agent_workflow.md。作用是说明架构、高风险点与 Agent 用法。
硬约束规则：.agent/rules/（code-style、distributed、platform、testing、op-dev 等）。作用是按路径自动施加规范，减少“不懂行规”导致的错误。
写时代码守卫：hooks（enforce-code-style.sh、check-op-yaml.sh）。作用是编辑后自动修风格，并提醒 YAML 与双端耦合改动。
领域开发技能：dist-op-dev、dist-op-analysis、platform-dev。作用是按工作流协助算子与平台特性的实现和补测。
领域专家 Agent：dtensor、tensor、fsdp、ep、pipeline、activation 等。作用是按子系统提供专项实现与审查视角。
规划与验证：planner、code-verifier、code-reviewer。作用是改前规划、改后分层验证，以及分布式优先的代码审查。
交付自动化：autogit，以及 /commit、/test、/create-pr。作用是把测试、提交、开 PR 流程标准化。
门禁自愈：gate-doctor。作用是对 PR CI 红灯进行诊断、分类、修复与重跑，直至变绿。
其他能力：parallel-strategy-analyzer、LlamaFactory 相关 agent 等，用于并行策略分析与生态集成辅助。
（二）现有日常用法
当前团队已文档化的推荐路径大致为：
第一步，开发阶段加载规则，并选用 dist-op-dev、platform-dev 等技能写码；
第二步，检查阶段使用 pre-commit、/test、autogit check；
第三步，提交阶段使用 /commit、/create-pr；
第四步，审查阶段使用 /code-review；
第五步，门禁失败时再手动唤起 gate-doctor。
（三）现状结论
可以概括为“积木已齐，编排偏弱”：单点能力强（尤其是分布式规则、算子开发流、Git 与门禁自动化），但程序员仍需自行判断何时使用哪个 Agent 或 Skill。当前协助更像“工具箱模式”，还不是“跟着任务走的助手模式”。
三、当前遇到的问题
问题 1：分布式领域知识门槛高，Agent 若无约束则不可信。
DTensor 的 is_partial()、reduce_partial 后再 redistribute、异步通信必须 wait、resize_(0) 后不可再读、跨 stream 要用 event 同步等，属于“写错了也能跑、错了极难查”的问题。通用编程 Agent 缺少这些不变量时，容易产出“看起来完整、语义危险”的补丁。结果是程序员不敢把复杂改动交给 Agent，Agent 只能做改格式、写注释等打杂工作，整体提效有限。
问题 2：双后端与多模块耦合，漏改成本高。
同一能力常同时涉及 core、platform/torch、platform/mindspore、YAML 注册以及 UT/ST。只改一端、漏 YAML、漏对端实现是高频失误。hooks 已有提醒，但仍依赖程序员注意到提示并继续改完。结果是联调轮次多，经常出现“本地通过，对端或 CI 才暴露问题”。
问题 3：.agent 能力分散，使用成本转嫁给程序员。
规则、技能、专家、命令、门禁工具齐全，但缺少统一任务入口与自动路由。新人不知道加算子该走 dist-op-analysis 再 dist-op-dev，还是直接让通用对话写；修 PP 该找 pipeline-dev-expert 还是 code-reviewer。老人也需要记忆命令与触发词。结果是能力利用率低，出现“会用的人很顺、不会用的人等于没有”。
问题 4：质量门禁与开发过程脱节。
开发阶段偏重实现速度，严格的分布式 review、完整 verifier、CI 修绿往往发生在后期。code-reviewer、code-verifier、gate-doctor 能力很强，但默认不是每次改动必经流水线，而是“想起来才跑”。结果是问题后移到 PR 或 CI，返工成本高；Agent 协助写码与协助保质没有绑在同一流程中。
问题 5：协助停留在单次对话，缺少任务级闭环与度量。
一次对话能生成补丁，但“计划、实现、测试、提交、门禁、知识沉淀”很少作为同一任务被跟踪。失败经验留在聊天或个人笔记中，难以回流进 rules 与 skills。结果是 Agent 不会越用越懂本仓库，组织层面也难以证明 Agent 辅助到底节省了多少时间、降低了多少缺陷。
问题 6：人机分工不清晰，预期易摇摆。
一端期待 Agent 全自动写完，一端坚持每行必须手写，缺少中间态共识。没有明确哪些必须人审（并行语义、API 设计），哪些可大胆交给 Agent（样板实现、单测骨架、风格修复、门禁琐事）。结果是协作摩擦大，方案难落地、难推广。
四、方案描述
（一）方案定位
建设 Agent 辅助程序员编写 HyperParallel 代码的体系：人始终拥有需求、设计与合并决策权；Agent 在仓库约束下，系统化协助编码、测试、审查、提交与门禁修复，成为“懂 Hyper 行规的结对程序员”，而不是不受控的代码生成器。
（二）设计原则
第一，正确性优先于速度：分布式不变量与双端一致，高于“更快出 diff”。
第二，人机边界清晰：人做决策，Agent 做执行与检查。
第三，复用现有 .agent，先编排再造轮子：优先串联已有 skills 与 agents，而不是重写一套。
第四，流程内建，而不是靠自觉：高风险路径默认经过规划与验证，而不是可选插件。
第五，可度量：用任务时长、人工介入次数、CI 返工次数、漏检类缺陷证明价值。
（三）目标分工
程序员负责：提需求、定方案、确认计划、审关键语义、决定合并。不要求手写全部样板与重复流程。
Agent 负责：按规范生成或修改代码、补测、自检、协助提交、协助修 CI。不擅自决定公共 API 与并行语义的重大取舍。
仓库约束（rules 与 hooks）负责：写时拦截与提醒。
（四）方案架构
在现有积木上增加“辅助编排层”。程序员提出意图（需求、Bug 或 PR）后，由 HyperAssist Orchestrator 负责任务路由、检查点控制与报告输出；再分别调度 planner、领域 Skills、专家 Agent、Verifier/Reviewer，以及 autogit 与 gate-doctor；全程继续受现有 rules、hooks 与 AGENTS.md 约束。
本方案重点新增的是编排与体验层，而不是替换现有专家体系。
（五）端到端协助流程
阶段 A：开任务。程序员用自然语言描述目标，例如新增某分布式算子、修复某 stream 竞态、把某 PR 修绿。Orchestrator 识别任务类型，并拉起 planner 产出只读计划，包括影响面、双端范围、风险点与测试策略。
阶段 B：人确认计划。程序员确认或修改计划，对需要确认的事项拍板。未确认不进入大规模改码，避免 Agent 乱跑。
阶段 C：协助实现。系统自动路由：算子走 dist-op-analysis 与 dist-op-dev；平台走 platform-dev；子系统 bug 走对应领域 expert。写码过程持续受 rules 与 hooks 约束。程序员可随时插入局部重写、收窄范围或否定某方案。
阶段 D：协助保质。默认执行测试与 code-verifier；高风险改动默认再执行 code-reviewer，重点覆盖 stream、memory、layout 与双端一致性。输出阻塞项与建议项清单，程序员优先处理阻塞项。
阶段 E：协助交付。程序员确认后，Agent 使用 autogit 协助 commit 与开 PR，并保留现有安全策略，例如不静默强推。
阶段 F：协助门禁。PR 红灯时使用 gate-doctor 诊断与修复，区分“本 PR 引入”与“偶发 flake”。程序员仍负责最终是否接受修复策略，尤其是临时跳过类操作。
阶段 G：轻量回流。将高频失败与漏检沉淀为 rules 或 skill 的补丁候选，经人审后合入，使协助能力持续变强。该能力在后续规划阶段逐步落地。
（六）相对现状的关键变化
入口方面：从多个 skill 与命令靠人记忆，变为统一任务入口加自动路由。
写码方面：从可选使用 Agent，变为计划确认后的系统化协助实现。
质量方面：从后期才严格检查，变为实现后默认验证与 review 门槛。
门禁方面：从另起炉灶手动修，变为与开发任务衔接的修绿协助。
分工方面：从边界模糊，变为人决策、Agent 执行与检查。
演进方面：从手工改 skill，变为失败经验可回流。
（七）范围界定
一期就做：编排层、计划确认点、路由到现有 skill 与 expert、默认验证，以及交付与门禁衔接。
一期不宣称做到：完全无人值守写任意特性、自动合并、替代架构设计。
五、未来规划
阶段 P0：可用的统一协助，建议周期 1 至 2 个月。
增加统一入口，覆盖新特性、修 Bug、审 PR、修门禁四类意图。强制先 plan 后改，并自动路由到现有 dist-op-dev、platform-dev、experts、gate-doctor。产出标准任务报告，包括计划、改动文件、测试结果与残留风险。成功标准是：同学会用一个入口完成从需求到提 PR，不再需要背全套命令。
阶段 P1：质量内建，建议周期 2 至 3 个月。
对高风险路径默认绑定 code-verifier 与 code-reviewer。将 review checklist 中的高频项逐步可执行化：能自动检查的自动查，不能自动检查的明确列为人工必审。成功标准是：合并前分布式类低级问题回流率下降，人工 review 更聚焦语义。
阶段 P2：门禁闭环与任务档案，建议周期 3 至 4 个月。
打通开发任务与 PR、CI 状态，使同一任务可追踪到绿门禁。将 gate-doctor 结果写回任务档案，记录失败类型、修复方式与是否 flake。成功标准是：修 CI 的平均人工介入次数下降，常见红灯可半自动收敛。
阶段 P3：知识回流与团队级提效，持续推进。
从任务档案提炼 rules 与 skill 补丁，经人审后合入。建立度量看板，关注任务周期、Agent 改动占比、CI 返工与缺陷类型分布。拓展可插拔模板，支持新子系统 expert 与新技能工作流。成功标准是：同类问题重复踩坑减少，新人达到独立提交的时间缩短。
更远期可选愿景：在 P0 至 P3 稳定后，再评估低风险样板任务的更高自治，例如纯 YAML 注册类算子。但始终保留人在环，公共 API、并行语义、临时禁用测试等必须由人审批。
六、预期收益与风险
预期收益包括：样板实现、补测、提交、修门禁耗时下降；分布式低级错误更早暴露，双端漏改减少；新人借助统一入口与计划确认更快上手；.agent 从工具箱升级为可演进的团队研发基础设施。
主要风险与应对如下。
风险一：Agent 自信地写出错误并行语义。应对是计划确认、高风险强制 review，以及对关键 diff 进行人工审查。
风险二：编排层过于复杂难维护。应对是先做薄编排，多复用现有 skill，禁止一期重写专家体系。
风险三：程序员过度依赖、弱化理解。应对是报告强制列出风险点与必读 diff，关键模块保留人工必审清单。
风险四：度量缺失导致无法证明价值。应对是 P0 即记录任务时长与人工介入次数。
七、材料摘要
当前问题：HyperParallel 开发受分布式不变量与双后端约束，试错成本高；仓库虽已具备较完整的 .agent 规则、领域技能、审查与门禁能力，但能力分散、靠程序员自行编排，协助未形成稳定闭环，质量门禁也容易后移到 PR 或 CI 阶段。
方案描述：建设面向程序员的 Agent 辅助研发体系。以人主导需求、设计与合并，以编排层串联现有 planner、领域 skills 与 experts、verifier 与 reviewer、autogit 与 gate-doctor，提供“计划确认、协助实现、默认验证、协助提交、协助修门禁”的完整协助路径，并按 P0 至 P3 从统一入口、质量内建、门禁闭环到知识回流逐步演进，使 Agent 成为懂仓库行规的结对助手，而不是替代程序员的黑盒代码机。
当前是 Ask 模式，没法直接生成 .docx 文件。下面是一份可直接全选复制到 Word 的纯文本（已去掉 Markdown）。若需要我生成真正的 Word 文件，请切换到 Agent 模式。
Agent 辅助 HyperParallel 编程：现状、问题、方案与规划
一、背景与目标
HyperParallel 是昇腾超节点亲和的分布式并行加速库，覆盖 DP、FSDP、TP、EP、CP、PP、重计算与 Offload，并同时支持 PyTorch 与 MindSpore。代码正确性高度依赖隐性不变量（Layout、通信同步、内存生命周期、双后端一致），开发成本高、试错贵。
仓库已建设较完整的 .agent 工程（规则、技能、专家 Agent、命令、钩子、门禁自愈），具备“Agent 协助写代码”的基础，但尚未形成面向程序员的一站式辅助体验与可度量的演进规划。
本方案目标：以现有 .agent 为底座，建设“人主导设计、Agent 协助落地”的 HyperParallel 辅助研发体系，降低门槛与重复劳动，提升交付质量与稳定性，并规划从“辅助写码”到“需求到绿 PR 半自动闭环”的演进路径。
二、现状（已有能力）
（一）能力全景
当前 .agent 已覆盖研发主链路的关键环节，主要包括：
项目上下文：AGENTS.md、docs/agent_workflow.md。作用是说明架构、高风险点与 Agent 用法。
硬约束规则：.agent/rules/（code-style、distributed、platform、testing、op-dev 等）。作用是按路径自动施加规范，减少“不懂行规”导致的错误。
写时代码守卫：hooks（enforce-code-style.sh、check-op-yaml.sh）。作用是编辑后自动修风格，并提醒 YAML 与双端耦合改动。
领域开发技能：dist-op-dev、dist-op-analysis、platform-dev。作用是按工作流协助算子与平台特性的实现和补测。
领域专家 Agent：dtensor、tensor、fsdp、ep、pipeline、activation 等。作用是按子系统提供专项实现与审查视角。
规划与验证：planner、code-verifier、code-reviewer。作用是改前规划、改后分层验证，以及分布式优先的代码审查。
交付自动化：autogit，以及 /commit、/test、/create-pr。作用是把测试、提交、开 PR 流程标准化。
门禁自愈：gate-doctor。作用是对 PR CI 红灯进行诊断、分类、修复与重跑，直至变绿。
其他能力：parallel-strategy-analyzer、LlamaFactory 相关 agent 等，用于并行策略分析与生态集成辅助。
（二）现有日常用法
当前团队已文档化的推荐路径大致为：
第一步，开发阶段加载规则，并选用 dist-op-dev、platform-dev 等技能写码；
第二步，检查阶段使用 pre-commit、/test、autogit check；
第三步，提交阶段使用 /commit、/create-pr；
第四步，审查阶段使用 /code-review；
第五步，门禁失败时再手动唤起 gate-doctor。
（三）现状结论
可以概括为“积木已齐，编排偏弱”：单点能力强（尤其是分布式规则、算子开发流、Git 与门禁自动化），但程序员仍需自行判断何时使用哪个 Agent 或 Skill。当前协助更像“工具箱模式”，还不是“跟着任务走的助手模式”。
三、当前遇到的问题
问题 1：分布式领域知识门槛高，Agent 若无约束则不可信。
DTensor 的 is_partial()、reduce_partial 后再 redistribute、异步通信必须 wait、resize_(0) 后不可再读、跨 stream 要用 event 同步等，属于“写错了也能跑、错了极难查”的问题。通用编程 Agent 缺少这些不变量时，容易产出“看起来完整、语义危险”的补丁。结果是程序员不敢把复杂改动交给 Agent，Agent 只能做改格式、写注释等打杂工作，整体提效有限。
问题 2：双后端与多模块耦合，漏改成本高。
同一能力常同时涉及 core、platform/torch、platform/mindspore、YAML 注册以及 UT/ST。只改一端、漏 YAML、漏对端实现是高频失误。hooks 已有提醒，但仍依赖程序员注意到提示并继续改完。结果是联调轮次多，经常出现“本地通过，对端或 CI 才暴露问题”。
问题 3：.agent 能力分散，使用成本转嫁给程序员。
规则、技能、专家、命令、门禁工具齐全，但缺少统一任务入口与自动路由。新人不知道加算子该走 dist-op-analysis 再 dist-op-dev，还是直接让通用对话写；修 PP 该找 pipeline-dev-expert 还是 code-reviewer。老人也需要记忆命令与触发词。结果是能力利用率低，出现“会用的人很顺、不会用的人等于没有”。
问题 4：质量门禁与开发过程脱节。
开发阶段偏重实现速度，严格的分布式 review、完整 verifier、CI 修绿往往发生在后期。code-reviewer、code-verifier、gate-doctor 能力很强，但默认不是每次改动必经流水线，而是“想起来才跑”。结果是问题后移到 PR 或 CI，返工成本高；Agent 协助写码与协助保质没有绑在同一流程中。
问题 5：协助停留在单次对话，缺少任务级闭环与度量。
一次对话能生成补丁，但“计划、实现、测试、提交、门禁、知识沉淀”很少作为同一任务被跟踪。失败经验留在聊天或个人笔记中，难以回流进 rules 与 skills。结果是 Agent 不会越用越懂本仓库，组织层面也难以证明 Agent 辅助到底节省了多少时间、降低了多少缺陷。
问题 6：人机分工不清晰，预期易摇摆。
一端期待 Agent 全自动写完，一端坚持每行必须手写，缺少中间态共识。没有明确哪些必须人审（并行语义、API 设计），哪些可大胆交给 Agent（样板实现、单测骨架、风格修复、门禁琐事）。结果是协作摩擦大，方案难落地、难推广。
四、方案描述
（一）方案定位
建设 Agent 辅助程序员编写 HyperParallel 代码的体系：人始终拥有需求、设计与合并决策权；Agent 在仓库约束下，系统化协助编码、测试、审查、提交与门禁修复，成为“懂 Hyper 行规的结对程序员”，而不是不受控的代码生成器。
（二）设计原则
第一，正确性优先于速度：分布式不变量与双端一致，高于“更快出 diff”。
第二，人机边界清晰：人做决策，Agent 做执行与检查。
第三，复用现有 .agent，先编排再造轮子：优先串联已有 skills 与 agents，而不是重写一套。
第四，流程内建，而不是靠自觉：高风险路径默认经过规划与验证，而不是可选插件。
第五，可度量：用任务时长、人工介入次数、CI 返工次数、漏检类缺陷证明价值。
（三）目标分工
程序员负责：提需求、定方案、确认计划、审关键语义、决定合并。不要求手写全部样板与重复流程。
Agent 负责：按规范生成或修改代码、补测、自检、协助提交、协助修 CI。不擅自决定公共 API 与并行语义的重大取舍。
仓库约束（rules 与 hooks）负责：写时拦截与提醒。
（四）方案架构
在现有积木上增加“辅助编排层”。程序员提出意图（需求、Bug 或 PR）后，由 HyperAssist Orchestrator 负责任务路由、检查点控制与报告输出；再分别调度 planner、领域 Skills、专家 Agent、Verifier/Reviewer，以及 autogit 与 gate-doctor；全程继续受现有 rules、hooks 与 AGENTS.md 约束。
本方案重点新增的是编排与体验层，而不是替换现有专家体系。
（五）端到端协助流程
阶段 A：开任务。程序员用自然语言描述目标，例如新增某分布式算子、修复某 stream 竞态、把某 PR 修绿。Orchestrator 识别任务类型，并拉起 planner 产出只读计划，包括影响面、双端范围、风险点与测试策略。
阶段 B：人确认计划。程序员确认或修改计划，对需要确认的事项拍板。未确认不进入大规模改码，避免 Agent 乱跑。
阶段 C：协助实现。系统自动路由：算子走 dist-op-analysis 与 dist-op-dev；平台走 platform-dev；子系统 bug 走对应领域 expert。写码过程持续受 rules 与 hooks 约束。程序员可随时插入局部重写、收窄范围或否定某方案。
阶段 D：协助保质。默认执行测试与 code-verifier；高风险改动默认再执行 code-reviewer，重点覆盖 stream、memory、layout 与双端一致性。输出阻塞项与建议项清单，程序员优先处理阻塞项。
阶段 E：协助交付。程序员确认后，Agent 使用 autogit 协助 commit 与开 PR，并保留现有安全策略，例如不静默强推。
阶段 F：协助门禁。PR 红灯时使用 gate-doctor 诊断与修复，区分“本 PR 引入”与“偶发 flake”。程序员仍负责最终是否接受修复策略，尤其是临时跳过类操作。
阶段 G：轻量回流。将高频失败与漏检沉淀为 rules 或 skill 的补丁候选，经人审后合入，使协助能力持续变强。该能力在后续规划阶段逐步落地。
（六）相对现状的关键变化
入口方面：从多个 skill 与命令靠人记忆，变为统一任务入口加自动路由。
写码方面：从可选使用 Agent，变为计划确认后的系统化协助实现。
质量方面：从后期才严格检查，变为实现后默认验证与 review 门槛。
门禁方面：从另起炉灶手动修，变为与开发任务衔接的修绿协助。
分工方面：从边界模糊，变为人决策、Agent 执行与检查。
演进方面：从手工改 skill，变为失败经验可回流。
（七）范围界定
一期就做：编排层、计划确认点、路由到现有 skill 与 expert、默认验证，以及交付与门禁衔接。
一期不宣称做到：完全无人值守写任意特性、自动合并、替代架构设计。
五、未来规划
阶段 P0：可用的统一协助，建议周期 1 至 2 个月。
增加统一入口，覆盖新特性、修 Bug、审 PR、修门禁四类意图。强制先 plan 后改，并自动路由到现有 dist-op-dev、platform-dev、experts、gate-doctor。产出标准任务报告，包括计划、改动文件、测试结果与残留风险。成功标准是：同学会用一个入口完成从需求到提 PR，不再需要背全套命令。
阶段 P1：质量内建，建议周期 2 至 3 个月。
对高风险路径默认绑定 code-verifier 与 code-reviewer。将 review checklist 中的高频项逐步可执行化：能自动检查的自动查，不能自动检查的明确列为人工必审。成功标准是：合并前分布式类低级问题回流率下降，人工 review 更聚焦语义。
阶段 P2：门禁闭环与任务档案，建议周期 3 至 4 个月。
打通开发任务与 PR、CI 状态，使同一任务可追踪到绿门禁。将 gate-doctor 结果写回任务档案，记录失败类型、修复方式与是否 flake。成功标准是：修 CI 的平均人工介入次数下降，常见红灯可半自动收敛。
阶段 P3：知识回流与团队级提效，持续推进。
从任务档案提炼 rules 与 skill 补丁，经人审后合入。建立度量看板，关注任务周期、Agent 改动占比、CI 返工与缺陷类型分布。拓展可插拔模板，支持新子系统 expert 与新技能工作流。成功标准是：同类问题重复踩坑减少，新人达到独立提交的时间缩短。
更远期可选愿景：在 P0 至 P3 稳定后，再评估低风险样板任务的更高自治，例如纯 YAML 注册类算子。但始终保留人在环，公共 API、并行语义、临时禁用测试等必须由人审批。
六、预期收益与风险
预期收益包括：样板实现、补测、提交、修门禁耗时下降；分布式低级错误更早暴露，双端漏改减少；新人借助统一入口与计划确认更快上手；.agent 从工具箱升级为可演进的团队研发基础设施。
主要风险与应对如下。
风险一：Agent 自信地写出错误并行语义。应对是计划确认、高风险强制 review，以及对关键 diff 进行人工审查。
风险二：编排层过于复杂难维护。应对是先做薄编排，多复用现有 skill，禁止一期重写专家体系。
风险三：程序员过度依赖、弱化理解。应对是报告强制列出风险点与必读 diff，关键模块保留人工必审清单。
风险四：度量缺失导致无法证明价值。应对是 P0 即记录任务时长与人工介入次数。
七、材料摘要
当前问题：HyperParallel 开发受分布式不变量与双后端约束，试错成本高；仓库虽已具备较完整的 .agent 规则、领域技能、审查与门禁能力，但能力分散、靠程序员自行编排，协助未形成稳定闭环，质量门禁也容易后移到 PR 或 CI 阶段。
方案描述：建设面向程序员的 Agent 辅助研发体系。以人主导需求、设计与合并，以编排层串联现有 planner、领域 skills 与 experts、verifier 与 reviewer、autogit 与 gate-doctor，提供“计划确认、协助实现、默认验证、协助提交、协助修门禁”的完整协助路径，并按 P0 至 P3 从统一入口、质量内建、门禁闭环到知识回流逐步演进，使 Agent 成为懂仓库行规的结对助手，而不是替代程序员的黑盒代码机。