DevFlow AI 深度教学 | 产品全生命周期自动化

Chapter 01

产品愿景与问题定义

让 AI Agent 成为研发流程中的"第一响应者"，开发者从"手动实现者"转型为"AI 编排指挥官"

💡 一句话定义 DevFlow AI

DevFlow AI = LLM + Multi-Agent + DAG 编排 + Harness Engineering + MCP 协议
它不是一个"代码生成器"，而是一个覆盖产品设计 → 研发 → 发布 → 运营全闭环的自动化平台。AI Agent 像一支虚拟研发团队——有产品经理、架构师、开发者、测试工程师、运维工程师和产品运营。

🔥 当前研发痛点 vs DevFlow 目标

痛点	现状	DevFlow 目标
需求到代码转化慢	需求文档→人工拆解→手动编码，周期 5-10 天	AI 自动解析需求→生成设计→产出代码，缩短至 1-2 天
质量保障依赖人工	手动编写测试用例、人工 Code Review	AI 自动生成测试、自动审查代码（用不同模型消除确认偏差）
部署流程碎片化	CI/CD 配置复杂、环境不一致	AI 编排部署流水线、自动化环境管理
生产监控被动响应	告警→人工排查→修复	AI 预测性监控→自动根因分析→自愈建议
输入输出端断裂	需求从哪来？发布后用户反馈呢？	产品域+运营域形成完整闭环

🔄 产品全生命周期闭环

🟦

产品域

产品设计
(PRD / 原型 / 竞品分析)

🟩

研发域

需求→设计→编码→审查
→迁移→安全→测试→文档

🟧

发布域

发布管理→部署发布
→事故响应 (常驻待命)

🟪

运营域

生产监控→产品运营
→知识沉淀 → 回到产品域

🔑 闭环的关键

产品运营 Agent 分析用户行为和反馈数据，自动提出新功能建议→回到产品设计；提出现有功能改进→直接回到需求分析。这让整个系统实现了数据驱动的自我进化。

Chapter 02

五层系统架构

从基础数据层到治理合规层，构建企业级的 Agent 运行基础设施

🛡️

Layer 5: 治理合规层 (Governance)

安全策略引擎 (OPA) | 审计日志 (ELK) | 沙箱管理 (Docker/gVisor) | 合规检查 (Trivy/SonarQube)

🤖

Layer 4: Agent 智能体层

15 个 Agent 角色 — 产品设计师、需求分析师、架构师、开发者、测试、部署、监控、运营...

🔄

Layer 3: 编排引擎层 (Orchestration)

DAG 工作流引擎 (Go+CEL) | Temporal 状态机 | 审批网关 (Human-in-the-Loop) | 质量门控

⚙️

Layer 2: 平台服务层 (Platform)

LLM Gateway (智能路由) | MCP Server 集群 | 上下文存储 (Redis+S3) | 可观测性 (Langfuse+Grafana)

💾

Layer 1: 基础数据层 (Foundation)

代码仓库 (Gitea) | 知识库 (PostgreSQL+pgvector) | 向量检索 (Milvus) | 制品仓库 (Harbor)

🎯 Harness Engineering 核心理念

Agent = LLM (大脑) + Harness (执行外壳)
LLM 只负责推理决策，Harness 负责一切执行、安全、状态管理和可观测性。
• 安全层：输入过滤、Prompt 注入防御、输出审查
• 编排层：状态机管理、任务分解、路由选择、重试策略
• 工具层：MCP 连接器、API 网关、沙箱执行环境
• 可观测层：OpenTelemetry 全链路追踪、Token 消耗监控

Chapter 03

15 个 SDLC 可组合阶段

分为产品域、研发域、发布域、运营域四大业务域，每个阶段由独立的 Agent 角色执行

Stage 1 · 需人工审批

产品设计 (Product Design)

将模糊的产品想法转化为可执行的产品方案。包括用户研究、竞品分析、交互设计、原型生成、PRD 撰写、功能优先级排序 (RICE/MoSCoW)。

Agent 角色：Product Designer 推荐模型：Claude Opus 4
核心输出：PRD 产品需求文档、用户画像、线框图原型、成功指标定义

用户调研竞品分析 UX 设计 PRD 撰写优先级排序

Stage 2

需求分析

将 PRD 转化为结构化需求：用户故事、验收标准 (Given-When-Then)、技术可行性评估、Story Points 估算

Stage 3

架构设计

基于结构化需求设计 API 接口、数据模型变更、编码任务分解（含依赖关系DAG）

Stage 4 · Fan-Out 并行

编码实现

按设计方案实现代码。独立任务并行执行（Fan-Out），依赖任务串行。自动 build + lint 验证

Stage 5 · ⚠️ 不同模型

代码审查

用与编码 Agent 不同的 LLM 模型审查代码，避免自我确认偏差。独立从 Git Diff 开始分析

Stage 6

数据库迁移

独立处理 DB 结构变更。含安全检查（破坏性变更检测）、回滚脚本生成、大表迁移策略

Stage 7 · 可选

安全审查

OWASP Top 10 检查、依赖漏洞审计 (gosec, trivy)、安全编码规范检查

Stage 8 · 质量门控

测试验证

自动生成+执行测试用例。质量门控：覆盖率 ≥ 80%、Lint 错误 = 0、安全漏洞 = 0

Stage 9 · 与测试并行

文档更新

自动更新 API 文档 (OpenAPI)、CHANGELOG、README、ADR 架构决策记录

Stage 10

发布管理

管理版本号 (SemVer)、Release Notes 自动生成、Git Tag 创建。"决定发什么"

Stage 11 · 需审批

部署发布

Docker 构建、K8s 部署、金丝雀/蓝绿发布。"决定怎么发"。生产部署需审批

Stage 12 · 🔥 常驻待命

事故响应

监控触发时自动启动。负责紧急回滚、流量管理（熔断/限流/降级）、事故报告撰写

Stage 13 · 常驻

生产监控

Prometheus 技术指标 + 业务指标。异常检测、根因分析、智能告警（减少噪声）

Stage 14 · 🔑 闭环关键

产品运营

分析用户行为、A/B 测试、功能采用率、反馈洞察→输出新功能建议/改进项→触发产品设计或需求分析，形成闭环

Stage 15

知识沉淀

每次工作流结束后自动沉淀：ADR 记录、经验教训、Skill Prompt 优化建议。系统"自我进化"的基础

👥 15 个 Agent 角色总表

#	Agent 角色	域	类型	推荐模型
1	Product Designer	产品	任务型	Claude Opus 4
2	Requirement Analyst	研发	任务型	Claude Sonnet 4
3	Architect	研发	任务型	Claude Opus 4
4	Developer	研发	任务型	Claude Sonnet 4
5	Code Reviewer	研发	任务型	GPT-4o ⚠️ 与开发者不同模型
6	DB Engineer	研发	任务型	DeepSeek V4
7	Security Reviewer	研发	任务型	Claude Sonnet 4
8	Tester	研发	任务型	Claude Sonnet 4
9	Technical Writer	研发	任务型	DeepSeek V4
10	Release Manager	发布	任务型	DeepSeek V4
11	Deployer	发布	任务型	Claude Sonnet 4
12	Incident Responder	发布	守护型	Claude Sonnet 4
13	Monitor	运营	守护型	DeepSeek V4
14	Product Operator	运营	守护型	Claude Sonnet 4
15	Knowledge Engineer	运营	任务型	DeepSeek V4

⚡ 任务型 vs 守护型 Agent

任务型 (Task Agent)：执行完成即销毁，按次计费。如需求分析师、开发者、测试工程师。
守护型 (Daemon Agent)：常驻后台持续运行，按月计费。如监控工程师、事故响应、产品运营。

Chapter 04

自研 Agent 执行引擎

Go 原生性能 + ReAct 执行循环 + 多 LLM 后端 + 安全沙箱 — Agent 运行时的核心

🔄

ReAct 执行循环

Agent 引擎的"心跳" — 推理 (Reason) → 行动 (Act) → 观察 (Observe) 的持久化循环，带超时、Token 预算和检查点恢复

🔌

多 LLM 统一抽象

统一 Provider 接口：Claude / GPT-4o / DeepSeek / Qwen / Ollama (本地)。智能路由器按任务类型自动选择最佳模型

🛡️

安全沙箱 (Docker)

每个 Agent 实例在独立 Docker 容器中隔离执行。CPU/内存/网络严格限制，仅允许内网访问

            // ReAct 主循环伪代码 (Go)

            for iteration := 0; iteration < maxIterations; iteration++ {

              // Step 1: REASON — 调用 LLM 获取决策

              response := llmClient.ChatCompletion(ctx, messages, tools)

              // Step 2: 判断是否完成

              if !response.HasToolCalls() { break } // 最终答案

              // Step 3: ACT — 策略检查 → 人工审批 → 沙箱执行工具

              for _, toolCall := range response.ToolCalls {

                policy.Check(toolCall)     // OPA 策略引擎校验权限

                sandbox.ExecuteTool(toolCall) // Docker 容器内执行

              }

              // Step 4: OBSERVE — 追加结果到消息历史 + 上下文压缩

              messages = ctxManager.CompactIfNeeded(messages)

              state.Checkpoint(iteration) // 故障恢复检查点

            }

🧠 智能模型路由策略

任务类型	首选模型	降级模型	Temperature	理由
架构设计	Claude Opus 4	DeepSeek R1	0.3	需要深度推理
代码生成	Claude Sonnet 4	DeepSeek V3	0.2	准确性与性能平衡
测试生成	Claude Sonnet 4	DeepSeek V3	0.1	精确性优先
日志分析	GPT-4o	Claude Sonnet 4	0.1	多模态分析
简单分类	Qwen 2.5	DeepSeek V3	0.0	低成本
完全离线	Ollama (本地)	Ollama	0.2	无外网场景

Chapter 05

DAG 动态工作流引擎

不再是固定流水线 — 有向无环图 (DAG) + CEL 条件表达式 + 可组合的工作流模板

🔸 固定流水线的问题

紧急 Hotfix 不需要走需求→设计 ❌
测试失败需要回退到编码重做 ❌
安全审查是可选阶段 ❌
文档和测试应该并行 ❌
监控触发的自动修复闭环 ❌

🔹 DAG 工作流引擎的能力

跳过阶段 — skip_condition (CEL 表达式)
条件分支 — 质量门控不通过→回退编码
并行执行 — 同一节点多条出边
循环重试 — 失败边指回上游
自定义阶段 — 团队定义私有 Stage

📋 预定义工作流模板

1. 标准全流程

产品设计→需求→设计→编码→审查→迁移→测试→文档→发布→部署→监控→运营→知识沉淀。完整 15 阶段

2. 紧急 Hotfix

编码→测试→部署。跳过产品域和运营域。最短路径快速修复

3. 安全审计开发

增加安全审查阶段：编码→安全审查→测试。涉及敏感数据时使用

4. 运营数据驱动改进

起点是运营分析：运营→需求→编码→审查→测试→部署。数据驱动闭环

Chapter 06

Agent Skills 模块化能力系统

Agent 角色 = 基础 System Prompt + Skills[] (按需加载) + Tools[] — 让同一个角色适应不同技术栈

💡 为什么需要 Skills？

同一个"编码 Agent"面对 Go 项目需要 Go 规范、golangci-lint；面对 TypeScript 需要 ESLint、Jest。如果全塞进一个 System Prompt：过长（超出上下文窗口）、不相关知识干扰推理、难以维护。

Skill = 可组合的模块化能力单元。Agent 的 System Prompt 由基础角色 + N 个 Skill 片段动态组装，工具集也从 Skill 声明中自动聚合。

📦 内置 Skills 分类

💻

编程语言 Skills

go_development、go_testing、ts_development、python_development — 包含语法规范、测试框架、Lint 工具等

🔧

工作流 Skills

git_workflow (分支策略/Commit规范)、gitea_integration (PR/Issue)、hotfix_workflow

🔒

安全 Skills

secure_coding (OWASP)、dependency_audit、owasp_check — SQL注入防护、XSS、密码加密规范

🚀

DevOps Skills

docker_build (多阶段构建)、k8s_deploy (Deployment/Probe)、canary_deploy

🏢

领域 Skills (自定义)

团队自定义业务规范，如 payment_system (金额用int64/分、幂等、审批)

🔍

自动检测加载

检测到 go.mod → 自动加载 Go Skills。检测到 gin 依赖 → 加载 Gin 框架 Skill

Chapter 07

安全隔离与多租户

支撑 100 开发者、20+ 团队、1 万项目的隔离需求 — Docker 沙箱 + 多租户配额 + OPA 策略引擎

🐳 沙箱隔离

每个 Agent 实例在独立 Docker 容器中运行：
• CPU: 2 cores / Memory: 4GB / Disk: 10GB
• 网络: 仅内网 (Gitea/Registry/GoProxy)
• 安全: no-new-privileges, 非 root 用户
• 沙箱镜像预装: Go 1.22+, git, ripgrep, golangci-lint

👥 多租户隔离

Organization → Team → Project → Workflow → Agent：
• 数据库: Schema-per-team (PostgreSQL)
• 文件: 目录前缀隔离 /{org}/{team}/{project}/
• 沙箱: Docker Network 命名空间隔离
• 配额: 并行 Agent 数 / 每日 Token / 存储 / 允许模型

📊 三层可观测追踪模型

Workflow Trace (工作流级) → Agent Trace (Agent 级) → Iteration Trace (循环迭代级)
每层包含：LLM Call Span (模型/tokens/延迟)、Tool Call Span (工具名/参数/执行时间)、Policy Check Span (允许/拒绝/原因)。
故障发生时可以精确定位到"Agent 在第几步、调了什么工具、因为什么出错"。

Chapter 08

阿里云部署架构与实施路线

阿里云 VPC 全内网部署 — ACK (K8s) + RDS + Redis + OSS + Milvus

~¥8,550

月基础设施成本

~$1.94

单次全流程成本

~$55

月守护Agent成本

~¥13,200

月总运营成本

🗺️ 三阶段实施路线图

PHASE 1 · M1-M3

🏗️ Agent 引擎 MVP

Go 项目初始化 + LLM Provider 统一接口 + ReAct 执行循环 + 基础工具集 + Docker 沙箱 + Gitea 集成 + 多租户 + OpenTelemetry + Web 控制台 MVP

ReAct LoopDocker 沙箱5 核心角色DAG 引擎

PHASE 2 · M4-M6

🔧 全流程 + 阿里云部署

补全所有 Agent 角色 + 质量门控 + HITL 审批界面 + Terraform IaC + Helm Charts + Fan-Out 并行 + LLM 语义缓存 + 配额管理

Code Review Agent工作流编排 UISkill 管理 UI阿里云 ACK

PHASE 3 · M7-M9

🚀 监控闭环 + 企业级

产品设计 + 产品运营 + 事故响应 + 知识沉淀 + Skill 市场 + RBAC + SSO + API 平台 + 万级项目压测

产品域运营闭环Skill 市场万级项目

Chapter 09

面试宝典 & 高频考点

DevFlow AI 涉及的核心架构决策与技术深水区

❓ 为什么自研 Agent 执行引擎，而不用 LangChain？+

三个核心原因：
1. 内网部署：完全运行在阿里云 VPC 内，代码和数据不出网，LangChain 等框架依赖外网 PyPI
2. Go 原生性能：Goroutine 并发模型轻松支撑数百并行 Agent 实例，Python GIL 是瓶颈
3. 深度可控：自研可以精确控制 ReAct 循环、策略引擎、Token 预算、检查点恢复等

关键词：Harness Engineering——LLM 只是引擎里的一个可插拔组件

❓ 代码审查 Agent 为什么必须用不同模型？+

防止自我确认偏差 (Self-Confirmation Bias)。如果编码和审查都用 Claude Sonnet 4，同一个模型倾向于认为自己的输出是正确的。

解决方案：
• 编码 Agent 使用 Claude Sonnet 4
• 审查 Agent 使用 GPT-4o 或 Claude Opus 4（不同模型）
• 审查 Agent 不继承编码 Agent 的上下文历史，独立从 Git Diff 开始分析

这是 2026 年 Multi-Agent 系统的核心设计原则之一。

❓ DAG 工作流引擎如何处理条件分支和循环重试？+

使用 CEL (Common Expression Language) 表达式作为边的条件：

• 条件分支：stages.testing.quality_gate.passed == true → deploy，false → coding
• 循环重试：失败边指回上游阶段，如测试失败→编码→测试，最多重试 N 次
• 跳过阶段：skip_condition: "stages.design.output.migration_plan == null" 无迁移计划时跳过 DB 迁移
• 并行执行：DAG 拓扑排序后，入度相同且无相互依赖的阶段可以并行

❓ Skills 系统解决了什么核心问题？如何动态组装？+

核心问题：同一个 Agent 角色面对不同技术栈需要不同知识。如编码 Agent 对 Go 项目需要 Go 规范，对 TS 项目需要 TS 规范。

组装流程：
1. 显式指定：工作流模板中声明 skills: [go_development, git_workflow]
2. 自动检测：ProjectDetector 扫描项目（go.mod → Go, package.json → TS）
3. 依赖解析：go_testing 依赖 go_development，拓扑排序
4. 互斥检查：go_development 与 ts_development 互斥
5. Prompt 组装：最终 System Prompt = Base + Skill1.prompt + Skill2.prompt + Examples
6. 工具聚合：从所有 Skill 的 tools 字段自动去重聚合

❓ 多 Agent Fan-Out 并行编码时，如何处理代码冲突？+

关键设计决策：只有无依赖的任务才能 Fan-Out，依赖链串行执行。

• 架构设计 Agent 输出的 coding_tasks 带有 dependencies: ["TASK-1"] 依赖声明
• Orchestrator 的 DAG 引擎解析依赖图，将任务分组：独立组并行，依赖链串行
• Git 策略：一个工作流使用一个 feature 分支，所有 Task 串行提交到同一分支
• 同一 Feature 分支共享一个沙箱容器，串行任务复用工作目录

原则：能用串行就别用并行——复杂度是有代价的

❓ 产品运营 Agent 如何实现"自动闭环"？+

产品运营 Agent 是闭环的关键节点。它持续分析：

• 功能采用率：追踪每个功能的 DAU、留存影响
• A/B 测试：分析实验结果，推荐全量/回滚
• 用户反馈：从 Gitea Issues / 客服系统提取痛点和需求
• 增长指标：DAU/MAU/留存/转化率/流失率

输出自动路由：
• 新功能建议 → 触发 product_design 阶段
• 改进项 → 直接触发 requirement_analysis 阶段
• A/B 测试结论 → 触发 coding（全量切换）
• 下线建议 → 触发 coding + deployment（功能移除）

❓ 如何保证数据库迁移不会导致线上事故？+

DB 迁移是独立阶段 (Stage 6)，有严格的安全机制：

1. 安全检查：自动检测破坏性变更（DROP COLUMN/TABLE）
2. 影响评估：查询影响行数、预估锁表时间
3. 回滚脚本：自动生成对应的回滚 SQL
4. Staging 验证：先在 Staging 环境验证迁移
5. 人工审批：approval: true — 数据库变更必须人工审批
6. 部署顺序：部署 Agent 内置"迁移优先"策略 — 先执行迁移再部署代码

输出中包含 recommendation: "safe|caution|dangerous" 等级判定

❓ 单次全流程的成本是多少？如何控制 Token 消耗？+

单次全流程预估：~420K 输入 Token + ~200K 输出 Token ≈ $1.94（含 3 个并行编码任务）

成本控制机制：
1. 智能路由：简单任务用低成本模型（Qwen/DeepSeek），复杂推理才用 Opus
2. Token 预算：每个 Agent 有 MaxTokenBudget，超出自动终止
3. 上下文压缩：对话过长时自动 Compact，移除冗余信息
4. 语义缓存：重复的 LLM 调用命中缓存，减少 API 请求
5. 团队配额：按团队规模设置每日 Token 上限

守护型 Agent 月成本约 $55（监控+运营+事故响应）

产品全生命周期自动化平台深度教学