24 KiB
任务执行能力与推进能力分析
日期: 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-ideascrate（评估/晋升/对抗） - Project → 有
df-projectcrate（扫描/管理） - 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：
- 统一状态枚举（前后端对齐）
- 注册
/tasks/:id路由 - 补 updateTask store 错误处理
- 不可变字段保护
阶段 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% 推进能力到「手动推进闭环」）