DevFlow/docs/05-代码审查/任务执行与推进能力分析-2026-06-16.md

任务执行能力与推进能力分析

日期: 2026-06-16 范围: 任务实体在 DevFlow 系统中的定位、执行链路、推进能力全景分析 关联文档: 任务推进构想-2026-06-14.md / 业务系统设计-2026-06-12.md / AI对话引擎-2026-06-14.md / DAG引擎详解-2026-06-14.md / 任务模块问题分析-2026-06-16.md

---

〇、核对结论速览（2026-06-16 · Explore 代理并行取证）

本报告系架构分析，含密集代码事实断言。经 2 个代理逐项取证，12 项断言中 10 真 / 1 部分真 / 1 假（重大）。核心论点（任务能存不能推进 / nodes 未接入 / 无回调）成立，但一处工具缺失论据错误（见下方纠正）。

真伪矩阵

#	断言	核实	证据
1	workflow.rs task_id 恒 None	✅真	workflow.rs:56，全局无写入点
2	workflow_def_id 从未写入	✅真	task.rs:73 None，crud 有 UPDATE 语句但无调用
3	AI 缺 update_task / run_command	❌假	update_task(tool_registry.rs:348) + run_command(:468) 均存在，仅缺 advance_task
4	df-task crate 已删除	✅真	ARCHITECTURE.md:89-90，crates/ 无 df-task
5	DAG 完成无任务回调	✅真	executor.rs:169-172 仅 emit WorkflowCompleted，无监听推进 task
6	任务无独立业务层	✅真	task.rs 直连 Repository，无状态机/推进逻辑
7	AiNode 未接入任务推进	✅真	ai_node.rs:331（~12.7KB）完整，无任务推进 DAG 模板
8	HumanNode 未接入任务推进	✅真	human_node.rs:640（~27.7KB）完整，无任务审批 DAG 模板
9	ProjectDetail 工作流入口下线	✅真	ProjectDetail.vue:289-292 注释 R-PD-2，script 节点不注册
10	前端无推进入口	✅真	Tasks.vue 纯展示 / TaskDetail.vue 纯只读
11	状态枚举三方不一致	⚠️部分真	后端7态 / 前端5态(merged) / 构想5态(done)；前端 vs 构想 merged≠done 微差
12	advance_task / can_transition_to / review_rounds 全未实现	✅真	Rust+TS 全局搜零定义，TaskRecord 无 review_rounds 字段

⚠️ 关键纠正（影响多处结论）

报告第二章 2.2「缺失关键工具」、第四章断裂点 2/3 称 「AI 缺 update_task / run_command 工具」——核实为假：

• update_task（tool_registry.rs:348）存在，AI 能改任务字段（含 status，经裸 update_field 非状态机收口）
• run_command（tool_registry.rs:468）存在且有完整 Shell 执行实现，AI 能写代码也能跑命令
• 真正缺失的仅 advance_task（推进链触发器）

修正后结论：AI 能更新任务状态、能运行命令，但仍不能：① 触发三闘门推进链（无 advance_task）② 联动工作流（task_id=None + 无完成回调）。报告核心论点「任务能存不能（自动）执行/推进」成立，但「AI 缺 update_task/run_command」的具体论据错误，断裂点 2/3 已在正文中纠正标注。

---

一、任务在 DevFlow 中的设计定位

1.1 产品旅程中的位置

想法池 ──晋升──▶ 项目 ──拆解──▶ 任务 ──执行──▶ 工作流(DAG)
(Idea)          (Project)      (Task)         (Workflow)
 第一公民        容器/上下文     执行单元        编排引擎

DevFlow 的核心价值链是 「想法 → 项目 → 任务 → 工作流」，任务是从「规划」到「执行」的转折点：

• 想法是「做什么」的候选池（评估/筛选/晋升）
• 项目是「在哪个上下文做」（目录绑定/技术栈/状态）
• 任务是「具体做什么」（标题/描述/状态/优先级/分支）
• 工作流是「怎么自动做」（DAG 编排 AI/Script/Human 节点）

1.2 设计意图：AI-First 推进链

任务推进构想-2026-06-14.md 定义了任务的终极形态：

todo ──AI执行──▶ in_progress ──AI自审──▶ review_ready ──人工核对──▶ done
       AiNode            AiNode              HumanNode
       AI 干活          AI 审 AI 的活        人最终把关 AI 产出

核心设计原则：

• 人从「操作者」转为「审批者」 — 任务由 AI 执行，人监督 AI
• advance_task 默认 AI 触发 — AI 执行/自审完成自动推进
• 三闸门必需 — AI 执行 / AI 自审 / 人工核对各有关卡
• 拒绝 → 退回 AI 重做 — 不是退回给人干

1.3 实际现状：设计 vs 实现的巨大鸿沟

维度	设计意图	实际实现
状态推进	advance_task 状态机 + 三闸门 DAG	❌ 不存在 advance_task，status 可被任意修改
AI 执行	AiNode/agent 读任务→写代码→跑测试→产出 diff	❌ AiNode 存在但未接入任务推进链
AI 自审	AiNode 结构化 verdict (pass/warn/block)	❌ 未实现
人工核对	HumanNode 审批闭环	⚠️ HumanNode 存在但未接入任务推进链
状态机收口	status 白名单移除，advance_task 唯一入口	❌ status 仍在白名单，任意可改
工作流联动	task → workflow 双向关联	❌ workflow 的 task_id 恒为 None
前端推进 UI	推进按钮 + 环节可视化 + diff 展示	❌ 纯只读，无任何推进入口

结论：任务模块目前是一个「数据容器」，不是「执行单元」。它能存、能查、能删，但不能推进、不能执行、不能联动工作流。

---

二、执行能力分析

2.1 任务「执行」的定义

在 DevFlow 的 AI-First 愿景中，「执行任务」意味着：

1. 读取任务描述 + 项目上下文
2. AI 写代码/改文件/跑测试（agent 多步）
3. 产出 diff / 文件变更 / 测试结果
4. AI 自审产出（code review，结构化结论）
5. 人工最终核对

2.2 当前执行能力盘点

❌ 任务 → 工作流：无连接

// commands/workflow.rs — run_workflow 中 task_id 恒为 None
task_id: None,  // 唯一引用点，硬编码 None

工作流执行完全不感知任务。WorkflowRecord 有 task_id 字段（V2 迁移加的），但没有任何代码写入它。工作流是独立运行的，不知道自己在为哪个任务工作。

❌ AI 对话 → 任务执行：无闭环

AI 对话引擎有 12 个工具，其中任务相关：

• list_tasks（Low 风险，自动执行）— 只读
• create_task（Medium 风险，需审批）— 只创建

缺失的关键工具：

• ❌ 无 update_task 工具 — AI 不能推进任务状态
• ❌ 无 advance_task 工具 — AI 不能触发推进链
• ❌ 无 run_command 工具 — AI 能写代码但不能跑（"能写不能跑"）
• ❌ run_workflow 工具是空壳 — AI 不能在对话中触发工作流

AI 可以 创建任务，但不能 执行任务、推进任务、关联工作流。

❌ 工作流节点 → 任务状态：无联动

DAG 执行完成
    │
    ▼
WorkflowRecord.status = "completed"
    │
    ▼
（结束 — 不回调任务状态，不触发 advance_task）

DAG 引擎有完善的执行能力（拓扑排序/并发/状态机/事件总线），但执行结果不回写任务。一个工作流跑完了，关联的任务状态纹丝不动。

⚠️ AiNode：有能力但没接入

// ai_node.rs — 12.7KB，完整实现
// 能力：调用 LLM（OpenAI/Anthropic），config 驱动，支持上游输入
// 但：只在 DAG 内可用，没有「为某个任务执行」的入口

AiNode 是通用的 LLM 调用节点，可以做分析/生成/审查。但当前没有任何 DAG 模板把 AiNode 接入任务推进链。

⚠️ HumanNode：有能力但没接入

// human_node.rs — 27.7KB，完整实现
// 能力：阻塞等待人工审批（subscribe→send→select!），支持单选/多选
// 但：只在 DAG 内可用，没有「为某个任务审批」的入口

2.3 执行能力总结

执行环节	需要的能力	现状	缺口
读取任务上下文	任务描述 + 项目目录 + 相关文件	✅ AI 工具可读	—
AI 写代码	write_file 工具	✅ 有（需审批）	—
AI 跑测试	run_command 工具	❌ 不存在	AI "能写不能跑"
AI 自审	AiNode verdict 结构化输出	❌ 未实现	需定义 prompt + 解析
触发工作流	run_workflow 工具	❌ 空壳	需实装
工作流回写任务	完成回调 advance_task	❌ 不存在	需实现回调链路
人工审批	HumanNode 审批	⚠️ 存在但未接入	需 DAG 模板 + 路由

核心断链：任务 ←✕→ 工作流 ←✕→ AI 执行。三个系统各自独立运行，没有形成闭环。

---

三、推进能力分析

3.1 当前推进机制：裸 status 字段 + 无保护

// commands/task.rs — update_task
// status 在白名单中，任意调用方可直接修改
state.tasks.update_field(&id, "status", &value)

任何人（AI/用户/脚本）可以一行代码把任务从 todo 直接改成 done，跳过所有闸门。这是 任务推进构想 文档中标注的 P0 致命漏洞。

3.2 设计中的推进机制：advance_task + 状态机

⚠️ 决策更新（2026-06-16）：本节原设想 advance_task 落 IPC 层 / df-task 复活。D-260616-03 已决策走 df-nodes Node（对齐 D3「业务逻辑在 df-nodes 实现」）：状态机落 df-nodes/src/task_state_machine.rs（F-01），advance_task 落 df-nodes/src/task_advance_node.rs 实现 Node trait（F-02），IPC 层 thin 入口调 df-nodes。又 D-260616-01 已定前端对齐 7 态，下文状态机示例的 5 态（ReviewReady/Abandoned）实施时按 7 态重设（激活 InReview/Testing/Blocked）。详见 任务推进链实施路径。

构想文档设计了完整的推进链，但全部未实现：

状态机（can_transition_to）

// 设计中 — 未实现
(Todo, InProgress | Abandoned) => true,
(InProgress, ReviewReady | Abandoned) => true,
(ReviewReady, Done | Abandoned | InProgress) => true,  // 可退回
_ => false,

状态机下沉 SQL（防 TOCTOU）

-- 设计中 — 未实现
UPDATE tasks SET status=:new, updated_at=:now
WHERE id=:id AND status=:expected   -- affected_rows==0 即状态已变,拒绝

advance_task 命令

设计中 — 未实现
1. 校验状态转换合法性（can_transition_to）
2. 原子写入（下沉 SQL WHERE 前置）
3. 触发对应闸门工作流（start/ready/merge）
4. 工作流完成回调再推进状态
5. 失败路径处理（退回/保持）

loop 管理

设计中 — 未实现
review_rounds: i32  -- 退回时 +1，任务卡显示「第 N 轮 review」

3.3 推进能力总结

推进环节	设计方案	实现状态
状态机定义	7 态 / 5 态（待统一）	❌ 无 can_transition_to
状态机收口	移除 status 白名单	❌ status 仍可任意改
advance_task 命令	唯一 status 写入路径	❌ 不存在
状态机下沉 SQL	WHERE 前置防 TOCTOU	❌ 不存在
AI 执行闸门	AiNode 最小形态	❌ 未接入
AI 自审闸门	AiNode verdict	❌ 未实现
人工核对闸门	HumanNode 审批	❌ 未接入
失败路径	退回/保持/重做	❌ 未实现
loop 管理	review_rounds	❌ 字段不存在
并发护栏	per-task 互斥锁	❌ 不存在
崩溃恢复	孤儿清理 + 审批持久化	⚠️ 部分存在（审批持久化有，孤儿清理无）
前端推进 UI	按钮 + 可视化	❌ 纯只读

推进能力实现度：0%。全部停留在构想文档阶段。

---

四、任务与其他系统的断裂点

4.1 断裂全景图

┌──────────┐         ┌──────────┐         ┌──────────┐         ┌──────────┐
│  想法池   │──✅晋升──│   项目    │──✅拆解──│   任务    │──✕✕✕──│  工作流   │
│ (Idea)   │         │(Project) │         │  (Task)  │         │(Workflow)│
└──────────┘         └──────────┘         └────┬─────┘         └────┬─────┘
                                               │                     │
                                          ┌────┴─────┐          ┌────┴─────┐
                                          │  AI 对话  │          │ DAG 引擎 │
                                          │ (Agentic)│          │(Executor)│
                                          └──────────┘          └──────────┘
                                               │                     │
                                          ✕ 无 update_task      ✕ task_id=None
                                          ✕ 无 advance_task     ✕ 无完成回调
                                          ✕ 无 run_command      ✕ 无状态回写
                                          ✕ run_workflow=空壳   ✕ 无任务路由

4.2 六大断裂点详解

断裂点 1：任务 ↔ 工作流（task_id = None）

// commands/workflow.rs:56
task_id: None,  // 硬编码

工作流不知道为哪个任务执行，任务不知道被哪个工作流处理。TaskRecord.workflow_def_id 字段存在但从未被写入。

影响：工作流执行结果无法回写任务状态，无法实现「工作流完成 → 自动推进任务」。

断裂点 2：AI 对话 ↔ 任务推进（无 advance_task 工具）

⚠️ 核对纠正：原报告称「无 update_task 工具」——核实为假，update_task（tool_registry.rs:348）存在。AI 工具集实际仅缺 advance_task（推进链触发器）。AI 能经裸 update_task 改 status 字段（无状态机收口，B-260616-15/16 同源），但不能触发三闸门推进链。

AI 工具集有 create_task / update_task 但没有 advance_task。AI 能创建/改任务但不能触发推进链。

影响：AI 在对话中分析了任务、写了代码、跑了测试，但无法经「合法状态机路径」把任务从 todo 推进到 done，只能裸改 status（旁路闸门）。

断裂点 3：AI 对话 ↔ 命令执行（无 run_command） 【⚠️ 核对为假，本断裂点不成立】

⚠️ 核对纠正：run_command（tool_registry.rs:468）实际存在且有完整 Shell 执行实现。AI 有 write_file 也有 run_command，能写代码也能跑命令，「写→跑→改」闭环成立。（注：run_command 属高危需审批工具，见 AE-2025-04 会话级授权；其 stdout/stderr 恒空问题见 B-260616 系列另报。）

AI 有 write_file 但没有 run_command。AI 写了代码但无法运行验证。

影响：AI 执行链断裂在「写→跑→改」的「跑」环节 不成立。AI 执行链在命令执行环节闭合。

断裂点 4：AI 对话 ↔ 工作流（run_workflow 空壳）

// tool_registry.rs — run_workflow 工具是 no-op 桩
// 返回提示信息，不真正执行工作流

影响：AI 不能在对话中触发工作流来自动化任务执行。对应已有任务 R-PD-12。

断裂点 5：工作流完成 → 任务状态（无回调）

DAG 执行器有 WorkflowCompleted 事件，但没有回调机制把这个事件转化为任务状态推进。

影响：即使工作流成功执行了 AI 执行 + AI 自审，任务状态仍然是 todo。

断裂点 6：前端 ↔ 推进操作（无 UI 入口）

Tasks.vue 是纯展示，TaskDetail.vue 是纯只读。没有任何按钮/操作可以推进任务状态。

影响：用户只能通过 AI 对话（如果 AI 有工具的话）或直接 API 调用来推进任务，但前者缺工具、后者不暴露 UI。

---

五、核心矛盾分析

矛盾 1：状态枚举三方不一致

层面	状态集	语义导向
后端 enum	todo/in_progress/in_review/testing/done/blocked/cancelled	通用软件工程
前端常量	todo/in_progress/review_ready/merged/abandoned	Git 工作流
推进构想	todo/in_progress/review_ready/done/abandoned	AI-First 推进链

三方各执一词，且推进构想的 5 态与前端常量一致但与后端 enum 不一致。在推进链实现前必须先统一状态集，否则状态机无法定义。

矛盾 2：df-task crate 已删除但任务无独立业务层

ARCHITECTURE.md: 5.3.1 ~~Task & Branch Manager (df-task)~~ — 已移除
> 2026-06-14 零引用清理：df-task crate 已删除

对比其他实体：

• Idea → 有 df-ideas crate（评估/晋升/对抗）
• Project → 有 df-project crate（扫描/管理）
• Task → ❌ 无独立 crate，IPC 层直连 CRUD

任务没有业务逻辑层，commands/task.rs 直接调 state.tasks.insert/query/update_field/delete。这意味着：

• 状态机逻辑无处安放（只能塞 IPC 层或重新建 crate）
• 推进链编排无处安放
• 与其他系统的联动逻辑无处安放

矛盾 3：工作流引擎完善但无业务消费

DAG 引擎功能完善（拓扑排序/并发执行/状态机/事件总线/审批闭环/取消机制），但没有任何业务场景在使用它：

• ProjectDetail.vue 的工作流演示入口已下线（R-PD-2：script 节点不再注册）
• run_workflow AI 工具是空壳
• 任务推进链未接入

引擎是「准备好了但没有乘客的列车」。

矛盾 4：AI 能力在增长但无法触达任务

AI 对话引擎是系统中最活跃的模块（Agentic Loop / 12 工具 / 审批门控 / 知识库集成 / 多 Provider），但它的能力无法触达任务执行：

• AI 能读项目代码、能写文件、能创建任务/项目/灵感
• 但不能推进任务、不能触发工作流、不能运行命令
• AI 的「手」伸到了文件系统，但伸不到任务状态机和工作流引擎

---

六、能力成熟度评估

按维度评分（满分 5 分）

维度	评分	说明
数据存储	⭐⭐⭐⭐	CRUD 完整，SQLite 持久化，字段丰富
数据查询	⭐⭐⭐	基本查询可用，缺分页/搜索/排序
状态管理	⭐	裸字段无保护，无状态机，无收口
执行能力	⭐	完全断裂，任务无法被执行
推进能力	⭐	0% 实现，全停留在构想文档
工作流联动	⭐	task_id=None，无回调，无路由
AI 集成	⭐⭐	AI 能创建任务，但不能执行/推进
前端体验	⭐⭐	列表展示可用，详情只读，无操作入口
数据安全	⭐⭐	硬删除无恢复，字段保护不足
架构设计	⭐⭐⭐⭐	构想文档非常完整（344 行），设计质量高

综合评分：2.1/5 — 数据层及格，执行/推进层空白。

与其他实体对比

实体	存储	业务逻辑	AI 集成	工作流联动	前端体验	综合
Idea	⭐⭐⭐⭐	⭐⭐⭐⭐ (df-ideas)	⭐⭐⭐ (评估/晋升)	⚪ N/A	⭐⭐⭐⭐	3.6
Project	⭐⭐⭐⭐	⭐⭐⭐ (df-project)	⭐⭐⭐ (创建/描述)	⚪ N/A	⭐⭐⭐⭐	3.5
Task	⭐⭐⭐⭐	⭐ (无 crate)	⭐ (仅创建)	⭐ (断裂)	⭐⭐ (只读)	2.1
Workflow	⭐⭐⭐	⭐⭐⭐⭐ (df-workflow)	⭐⭐ (AiNode 可用)	⭐ (无消费)	⭐⭐ (已下线)	2.4
Knowledge	⭐⭐⭐⭐	⭐⭐⭐	⭐⭐⭐⭐ (提炼/注入)	⚪ N/A	⭐⭐⭐	3.4

任务是系统中成熟度最低的实体。

---

七、根因分析

为什么任务模块「能存不能执行」？

根因链（从表层到深层）：

表层：前端无推进入口，后端无 advance_task
  ↑
中层：任务 ↔ 工作流断裂（task_id=None），AI 工具缺 update_task/run_command
  ↑
深层：df-task crate 被删除后，任务没有业务逻辑层
  ↑
根因：任务推进链涉及跨系统编排（Task + Workflow + AI + Human），
      但系统设计是「引擎不绑定业务」（D3 决策），
      导致引擎和业务之间的「胶水层」始终没有建立

架构决策 D3 的双刃剑

### D3: 引擎不绑定业务
- DAG 引擎纯粹做编排，不感知具体业务语义
- 业务逻辑在 df-nodes 实现（Node trait 是纯接口）

这个决策本身是好的（关注点分离），但它留下了一个架构空洞：

DAG 引擎（通用编排）  ←——空洞——→  任务业务（具体语义）
    df-workflow                       ???
    df-nodes

谁来把「任务推进」这个业务语义映射到「DAG 工作流执行」？答案应该是 advance_task 编排层（构想文档中设计了但未实现），或者一个新 crate（df-task 的复活）。

---

八、建议：从「数据容器」到「执行单元」的路径

阶段 0：修复基础问题（前置条件）

参照 任务模块问题分析-2026-06-16.md：

1. 统一状态枚举（前后端对齐）
2. 注册 /tasks/:id 路由
3. 补 updateTask store 错误处理
4. 不可变字段保护

阶段 1：建立推进骨架（最小闭环）

目标：任务状态能通过「合法路径」推进，而非裸字段修改

1. 实现 TaskStatus::can_transition_to（状态机定义）
2. 实现 advance_task 推进逻辑（**df-nodes Node**，D-260616-03 已决策；IPC 层 thin 入口）：校验+原子写入+状态机下沉 SQL
3. 从 update_task 白名单移除 status（收口）
4. 前端 TaskDetail 加推进按钮（手动推进，不接 AI）
5. 补 review_rounds 字段

此阶段不接 AI/工作流，纯人工推进，但状态机保护和收口到位。

阶段 2：接入工作流（单向联动）

目标：工作流执行能回写任务状态

1. run_workflow 支持 task_id 参数（不再硬编码 None）
2. 工作流完成回调 → 检查 task_id → 推进任务状态
3. 定义任务推进 DAG 模板（AiNode 执行 + AiNode 自审 + HumanNode 核对）
4. advance_task 触发对应闸门工作流
5. 前端展示工作流执行进度

阶段 3：AI 执行能力（闭环）

目标：AI 能真正执行任务内容

1. 补 run_command AI 工具（或等 patch_file + run_command 完善）
2. 补 update_task / advance_task AI 工具
3. 实装 run_workflow AI 工具（不再是空壳）
4. AiNode 接入任务上下文（读任务描述 + 项目目录）
5. AI 自审 verdict 结构化输出 + 解析
6. 失败路径完整处理（退回/重做/保持）

阶段 4：Git 集成（增强）

目标：代码类任务支持 Git 工作流

1. 加 kind 字段（code/doc/design/generic）
2. code kind 闸门接 git 命令（worktree/commit/merge）
3. BranchRecord 联动（加 worktree_path）
4. on_task_advanced 钩子填充（分支联动 + 项目 completed）

---

九、总结

一句话诊断

任务是 DevFlow 系统中设计最完善（344 行构想文档）但实现最空白（0% 推进能力）的模块。它目前是一个「能存能查不能做」的数据容器，距离设计中的「AI-First 执行单元」还有阶段 1-3 的完整路径要走。

最紧迫的事

不是写 AI 执行、不是接工作流，而是 先建立 advance_task 状态机骨架 + 收口 status 字段。因为：

• 状态机是所有后续工作的基础（没有合法转换定义，AI 推进无从谈起）
• status 旁路是 P0 安全漏洞（AI 能直接改 status = done，所有闸门形同虚设）
• 这是投入最小（~200 行代码）但收益最大的改动（从 0% 推进能力到「手动推进闭环」）