一、现状

当前开发主要依赖人工与claudecode、trae、codex这类ai 工具操作，通常人工说明清晰需求可以达到代码自动开发、单元测试，但是依然会觉得管控不足。例如使用claudecode 过多的关注代码设计与质量对于人力的消耗并不小；使用trae sole 多agent看似对代码开发全自动完成，但实际代码模块的设计是否符合原则足够高质量是存疑的。随着跨模块、复杂度升高代码质量会不断降低。另外想要突破人力上限，可并行复用。文档不是具体的落地方案，仅是指引性方案内容。

二、多智能体模式了解

多 Agent 协作，本质是“分工 + 流程”。常见有 4 大模式，可以覆盖大多数场景：

1）Coordinator（并行协调） 1 个协调者 → 多个专家并行执行 → 合并结果 同一任务上的多种独立视角/分析 代码审计：安全 / 性能 / 风格并行检查

2）Sequential（串行流水线） A → B → C → …，有严格先后顺序 必须按步骤来，后者依赖前者输出 写代码 → 跑测试 → 代码审查

3）Iterative（迭代改进） 生成者 ↔ 审阅者 多轮循环 质量敏感、需要反复打磨 代码重构：写实现 ↔ 自反/审查循环

4）Human-in-the-Loop（人机协同） Agent 干活 → 人审批 → 继续 高风险、不可逆操作 部署/发版、线上运维操作

三、多agent系统构思

1. 核心设计

本方案旨在解决多 Agent 无限并行的生成能力与有限人力审查之间的矛盾，同时防止 Agent 为完成功能而破坏系统架构，如单一职责、模块依赖规范。

1）代码即法律，拒绝自然语言约束：自然语言的规范提示词是“软约束”，Agent 遇到困难极易妥协。架构规范必须转化为可执行的测试代码或静态检查脚本，作为不可逾越的“硬约束”。 2）契约与测试先行：坚决执行“先立规矩，再写代码”。在开发 Agent 动手前，接口契约和架构守护测试必须就位且处于红灯状态。避免 LLM 间的哲学辩论：取消针对自然语言设计方案的 LLM 审核环节。方案的好坏不由 Agent 争论决定，而由编译器和测试运行器的客观结果决定，杜绝 Token 空耗。确定性工具 > LLM Agent：静态代码检查、CI/CD 触发、依赖规约扫描等确定性动作，必须由脚本工具执行，严禁封装为 Agent，避免浪费算力与增加不确定性。绿灯即合规，结果导向：只要代码通过了功能单测和架构守护测试，即视为符合开发与规范要求。人类从逐行代码审查中解放，转向契约审查和最终业务验收。 三、 标准工作流 整个流程分为三大阶段，形成从约束定义到代码落地的完整闭环。

流程详解：

阶段 1：前置契约与约束定义 架构师 Agent 接收需求，不输出长篇大论的设计文档，而是直接输出代码级契约和架构规则。 守卫 Agent 接收架构规则，生成对应的架构守护测试，提交后测试处于红灯状态。这一步将自然语言的担忧硬转化为代码级的问题。

阶段 2：测试驱动开发闭环 开发 Agent 拿到任务、契约和红灯测试，开始编写实现代码。 每次代码变更，自动触发 Lint 工具，拦截低级规范错误和测试运行器。 核心纠偏机制：如果开发 Agent 试图破坏架构如违规引入依赖，架构守护测试报红灯。开发 Agent 必须根据报错信息自我修正，直到全绿才能走出此闭环。这彻底杜绝了事后发现架构崩塌的问题。

文档与知识沉淀 Agent，这个 Agent 的核心定位不是“写代码注释”，而是“提炼上下文，反哺人类与系统”。它不会把代码贴给人类，而是用结构化的自然语言告诉人类：“这次开发实现了什么功能？为了不破坏架构，加了哪些硬性约束，做了哪些核心业务测试。只需看这份文档，就能对这块代码的边界和能力。 提取踩坑记录：这是它最核心的价值。去审查开发 Agent 在闭环中的迭代日志。如果开发 Agent 遇到了架构测试红灯，尝试了方法 X 失败，最后用方法 Y 成功了，史官 Agent 就会把这段挣扎过程提炼出来。 知识评估与沉淀，史官 Agent 会判断这个踩坑记录是否具有通用性，将其格式化为一条《最佳实践/避坑指南》，写入全局的向量知识库。以后其他 Agent 开发类似功能时，系统会自动检索这段知识注入到 Prompt 中。

阶段 3：语义审查与交付 代码全绿后，审查员 Agent 介入。它不再审查硬性架构规范，只审查测试无法覆盖的语义问题如变量命名、冗余逻辑、过度设计。 审查通过后，进入风险路由：系统根据变更文件如是否涉及核心支付、数据库变更判定风险。低风险自动合并，高风险拦截并通知人工终审。 合并后，Webhook 自动触发 CI/CD 流水线完成构建与部署。

四、 关键问题应对策略

1. 如何约束单一职责原则 属于语义层面，难以用纯代码精确断言，采用“物理特征截断 + AI 兜底”策略： 物理截断：在 Lint 工具中配置硬性阈值，一旦 Agent 写出上帝类，直接阻断。 AI 兜底：交由审查员在语义审查阶段评判，若发现职责混杂，打回让重新拆分。

2. 多 Agent 并行修改同一项目如何防干扰 采用多分支物理隔离： 主控系统为每个并行任务创建独立 Git 分支如， feature/auth 和 feature/payment。Agent 只能在对应分支上提交代码，彻底杜绝文件级冲突。 3. 如何突破人力审查瓶颈 不审查过程，只审查结果与契约：人类不看并行分支的具体实现代码。 契约审查：在阶段 1，人类审查架构师 Agent 输出的接口设计是否符合业务预期。 异常拦截：系统仅将高风险变更，通过规则匹配推给人工，人类只做否决权表决。 业务验收：在所有分支合并、CI/CD 部署到预发环境后，人类进行最终的业务功能体验。

3. 建立四层防御：

防御层 1：前置约束 —— 架构师 Agent 预设骨架与契约 不要让功能 Agent 在一张白纸上画图。在并行开工前，必须有一个架构师 Agent或人工把边界定死。 定义接口契约：生成 interface 或 protocol 文件。并行 Agent 只能实现接口，不能改接口。 划定目录边界：明确规定 auth/ 目录下只能有认证逻辑，payment/ 下只能有支付逻辑。 提供基座代码：架构师 Agent 先把文件头、类定义、依赖注入的框架写好，功能 Agent 只需“填肉”。

防御层 2：硬约束 —— Linting 与静态分析作为工具 提示词是软的，报错是硬的。必须把架构规范转化为 Agent 无法绕过的机器检查。 架构级 Lint：使用静态检查工具。 依赖分析工具：硬性规定模块间的依赖方向

融入 Agent 循环：Agent 每次写完代码，系统自动运行这些 Lint，如果报错，直接将报错打回给 Agent 修改，不让它提交。

防御层 3：同行审查 —— 专职的代码审查 Agent 在多分支模型下，绝不能让功能 Agent 直接合并代码。必须引入不写代码、只做审查的 Agent。 流程设计： Agent 在 feature/auth 完成功能，运行单测通过，发起 PR。 审查 Agent 介入，它的提示词完全不同于功能 Agent： “你是一位严苛的高级架构师。请审查这个 PR。重点检查：1. 是否违反单一职责原则？2. 是否越界修改了非本模块的代码？3. 是否存在硬编码或魔法值？4. 公共接口是否被私自更改？” 审查 Agent 有权打回 PR，要求功能 Agent 修改。

防御层 4：终极守门员 —— 人工审核 AI 审查可以过滤掉 80% 的低级架构违规，但剩下 20% 的上下文妥协、过度设计或业务逻辑耦合，只有人类能判断。 最佳实践：让 AI 做前置审查和总结，只把经过 AI 筛选、标注了潜在架构风险的 PR 交给人看。这极大降低了人的审查负担，同时保住了人的最终决定权。

五、方案能否执行

这套多Agent工作流架构师->守卫->开发->审查->史官，且包含代码执行、测试闭环，在当前的技术生态中，纯“零代码、开箱即用”且能完全贴合你这套复杂规范的成型产品还很少。

1. LangGraph LangGraph 是 LangChain 团队推出的专门用于构建有状态、多角色、可循环应用的框架。 图结构原生支持循环：传统的链式框架只能 A→B→C，LangGraph 可以轻松画出 开发Agent → CI工具 → 如果失败→ 开发Agent 的闭环。 状态持久化：你的架构契约、红灯报错日志、重试次数，都可以存在全局 State 中，在不同 Agent 间流转。 人机协同内置：原生支持 interrupt，当风险路由判定高风险时，可以直接暂停图执行，等待人类审批后继续。 适合谁：想要最大灵活性、需要精细控制每一步流转逻辑的团队。

2. Temporal + AI SDK Temporal 本身不是 AI 框架，它是顶级的工作流编排引擎。用 Temporal 处理状态流转、重试、持久化，用 OpenAI SDK 处理 LLM 调用。 确定性执行与容错：Agent 调 LLM 会超时、会幻觉。Temporal 的工作流即使服务器宕机，重启后也会从断点继续执行，CI 等待、人工审批流程绝不会丢失。 长耗时支持：方案中的触发 CI/CD → 等待 10 分钟出结果 → 判断红灯。 适合谁：对系统鲁棒性要求极高、需要对接复杂内部基础设施、打算做成长期内部平台。