Files

- 定义 AI Native vs 传统范式的差异(人从操作者→决策者)
- 优先级矩阵:P0人设+多Agent → P1模板+Git/CI → P2审批+算法
- 明确不做方向(全自动/MCP/跨端)及理由
- Agent架构说明添加前向引用
- 注册文档到架构 INDEX

2026-07-01 12:34:44 +08:00

6.6 KiB

Raw Blame History

AI Native 方向与路线图 — 2026-06-29

性质：方向定义 / 优先级矩阵 / 推进路线图关联: Agent架构说明-2026-06-14.md（当前 Agent 能力边界）关联: 三层模型-流程模板与人设体系-2026-06-28.md（模板/工作流/人设三层抽象）关联: 架构债迁移设计-2026-06-29.md（#8/#15/#18/#19 迁移路径）关联: 产品定位调整-2026-06-12.md（「想法到创作」产品定位）用途：作为后续所有功能/架构决策的优先级参考

一、AI Native 与传统范式的区别

DevFlow 的定位是 AI 原生——AI 不是辅助工具，而是系统的主要操作者。人的角色从「操作者」转变为「决策者 + 政策制定者」。

传统 DevOps 流程:
  需求 → 设计 → 编码 → PR → 审查 → CI → 部署
   ↑      ↑      ↑     ↑     ↑     ↑     ↑
  人      人     AI    人    人    自动   人
             辅助写   创建PR  审查

AI Native 流程:
  想法 → AI 分析 → AI 设计 → AI 编码并行 → AI 自审 → AI 测试 → AI 发布 ← 人类审批
    ↑       ↑         ↑          ↑           ↑        ↑        ↑
  人类   AI驱动    AI驱动   多Agent分工    AI审计   AI验证   自动编排
  输入

关键变化：

维度	传统	AI Native
人类角色	执行者（写代码、建 PR、跑测试）	决策者（立项、审批、定策略）
AI 角色	辅助（补全、建议、生成片段）	执行者（分析、设计、编码、测试、发布）
流程驱动	人类手工推进（点按钮、改状态）	AI 自动推进（工作流 + 事件驱动）
质量保障	人工审查 + CI 门禁	AI 自审 + 人工审批 + 质量门禁
产出物	代码 PR	可发布的全流程资产（代码 + 测试 + 文档 + 变更日志）

二、优先级矩阵

按「奠定 AI Native 基础」的依赖关系排序。P0 是 P1 的前提，P1 是 P2 的前提。

P0 ─── 人设系统 ─── 多 Agent 协作
        (角色划分)    (分工执行)
         │
P1 ─── 模板系统 ─── Git/CI 集成
        (流程预设)    (现实接轨)
         │
P2 ─── 审批政策 ─── 算法验证
        (规则配置)    (特定场景)

P0：智能体人设 + 多 Agent 协作

这两项构成 AI Native 的基础——没有角色划分就谈不上分工，没有分工就谈不上协作。

方向	内容	代码落点	前置依赖
人设系统	AgentPersona 结构体 + PersonaRegistry + 内置 5 人设（coder/reviewer/architect/tester/analyst）	`crates/df-ai/src/persona.rs`（新建）	`df-ai` crate 已有
人设注入	AINode 执行时从 NodeContext 读 persona_id，拼接 system_prompt + 过滤工具集	`crates/df-nodes/src/ai_node.rs` + `crates/df-workflow/src/node.rs`	人设系统就绪
Coordinator 填实	拆解任务 → 分配人设 → 并行 Agent → 汇总合并	`crates/df-ai/src/coordinator.rs`	人设系统 + SubflowNode
Planner 接入 Loop	`intent/plan_hint/planner` 三个纯函数模块接入主 loop	`src-tauri/src/commands/ai/agentic/mod.rs`	Coordinator 就绪

验证标准：单次 AI Chat 能调用多个子 Agent 并行工作（如同时生成三个模块的代码），最后合并为一个完整的 PR。

P1：模板系统 + Git/CI 集成

AI 产出的成果需要能推送到现实协作流程（Git PR、CI Pipeline）。

方向	内容	代码落点	前置依赖
模板加载器	YAML 模板 → DagDef 实例化	`crates/df-workflow` 新增	SubflowNode
SubflowNode	嵌套子工作流节点	`crates/df-nodes/src/subflow_node.rs`	模板系统
GitNode	分支创建/PR/合并操作	`crates/df-nodes/src/git_node.rs`	libgit2 就绪
DockerNode	容器内构建/测试	`crates/df-nodes/src/docker_node.rs`	workpod API
Config 统一	AppConfig struct + env override	`df-types/src/config.rs` + AppState	本迭代推进

验证标准：从 YAML 模板加载工作流 → 创建 Git 分支 → 生成代码 → 提交 PR → 跑 CI。

P2：审批政策 + 算法验证

当 AI 成为主要执行者后，「什么时候需要人批」「算法怎么验证」需要系统化的可配置机制。

方向	内容	代码落点	前置依赖
审批政策配置	按人设/节点/风险级别定制审批策略	`HumanNode` + 配置层	人设系统就绪
算法验证循环	基准测试 → 对比 → 迭代优化 → 早停	新建 `df-algo` crate	模板系统 + 人设

三、对既有工作的对齐

已有资产	与本路线图的关系
`intent.rs` / `planner.rs` / `plan_hint.rs`	P0 的预制件——三个纯函数模块算法已完备，只差接入主 loop
`coordinator.rs`	P0 的关键缺项——当前空壳，需要填实为真正的 Agent 调度器
三层模型设计文档	P1 的架构设计——模板/工作流/人设三层抽象已设计完成，待编码
走查报告	安全/架构债在 P0-P2 推进中同步修复
架构债迁移设计	#15 AI 状态机抽离在 P0+P1 完成后自然推进

四、不做的方向

以下方向经过评估后，当前阶段不投入：

方向	放弃理由	可能的时机
全自动无人值守	当前审批机制（HumanNode）是有意的设计取舍，AI 最终决策需人类把关	长效目标，非当前阶段
第三方系统集成（云效/禅道）	核心 Agent 能力未就绪前，集成的价值有限	P2 完成后评估
MCP 外部工具接入	工具集封闭是安全取舍，开放后将引入新的攻击面	Phase 5 或之后
Web/移动端	AI 执行逻辑焊死在桌面端（#15）解决之前，跨端无意义	#15 完成后

五、下一步行动

当前建议方向（按此顺序落地）：

本周 → 人设系统（Persona 数据结构 + 5 内置人设 + 注册表）
   ↓
下周 → Coordinator 填实 + Planner 接入（多 Agent 骨架）
   ↓
下月 → 节点补齐（Subflow/Docker/Git）+ 模板加载器 + YAML 模板

每步完成即可独立验证，不必等全部做齐再交付。

6.6 KiB Raw Blame History Unescape Escape