绝尘
80239500f1
- 项目知识图谱与任务队列系统-2026-06-26.md:AI Working 终局设计(任务网络queue/parent/links + 事件流 + 基础设施 + 注入 + Mission Control 五视图),父②Phase1 + 父⑥Phase2-3 已据此实施落地 - AI原生上下文地图与去AI化进化系统-2026-06-26.md:AI Working 定位体系设计
402 lines
17 KiB
Markdown
402 lines
17 KiB
Markdown
# AI 原生工作模式：上下文地图与去 AI 化进化系统
|
||
|
||
> **文档状态**：构想 → 架构设计
|
||
> **创建日期**：2026-06-26
|
||
> **关联灵感**：Idea `84797cb1-37f2-4599-ba5f-ae8d8555dc0f`
|
||
> **核心理念**：让 AI 做得越来越少——高频路径逐步结晶为确定性逻辑，AI 退守到真正需要推理的边界。
|
||
|
||
---
|
||
|
||
## 0. 问题诊断：当前 AI 工作流的资源浪费
|
||
|
||
### 0.1 现状痛点
|
||
|
||
| 症状 | 根因 | 代价 |
|
||
|------|------|------|
|
||
| 每次对话都从零检索项目结构 | 无持久化的工程地图 | 30-40% token 浪费在重复探索 |
|
||
| 简单文件操作也要 LLM 推理 | 无模式结晶机制 | 推理延迟 + API 成本 |
|
||
| AI 不知道上次改了什么 | 无上下文缓存层 | 重复扫描 + 上下文断裂 |
|
||
| 高频任务路径无法优化 | 无执行频度感知 | 永远全量推理，无法降级 |
|
||
|
||
### 0.2 核心洞察
|
||
|
||
> AI 原生不等于"什么都让 AI 做"。真正的 AI 原生是：**AI 构建认知基础设施，然后将高频路径交给确定性逻辑，自身退守到创造性边界。**
|
||
|
||
---
|
||
|
||
## 1. 架构总览：三层地图 + 缓存层 + 结晶器
|
||
|
||
```
|
||
┌─────────────────────────────────────────────────────────────────────┐
|
||
│ AI Agentic Loop │
|
||
│ │
|
||
│ ┌──────────┐ ┌──────────────┐ ┌───────────┐ ┌────────────┐ │
|
||
│ │ Working │ │ Coding │ │ Tool │ │ Context │ │
|
||
│ │ Map │──▶│ Map │──▶│ Map │──▶│ Cache │ │
|
||
│ │ (任务态) │ │ (代码态) │ │ (工具态) │ │ (会话态) │ │
|
||
│ └──────────┘ └──────────────┘ └───────────┘ └─────┬──────┘ │
|
||
│ │ │
|
||
│ ┌──────────▼───────┐ │
|
||
│ │ Pattern │ │
|
||
│ │ Crystallizer │ │
|
||
│ │ (模式结晶器) │ │
|
||
│ └──────────┬───────┘ │
|
||
└─────────────────────────────────────────────────┼─────────┼────────┘
|
||
│ │
|
||
┌─────────────▼─┐ ┌───▼──────────┐
|
||
│ Deterministic │ │ Frequency │
|
||
│ Scripts │ │ Tracker │
|
||
│ (确定性脚本) │ │ (频度追踪) │
|
||
└───────────────┘ └──────────────┘
|
||
```
|
||
|
||
### 1.1 设计原则
|
||
|
||
1. **地图先行**：AI 的每次操作都基于预构建的地图，而非实时盲搜
|
||
2. **缓存就近**：会话级上下文缓存，避免跨轮重复推理
|
||
3. **频度驱动结晶**：高频路径自动进入结晶候选队列
|
||
4. **渐进去 AI 化**：结晶后的路径从 LLM 推理降级为确定性脚本
|
||
|
||
---
|
||
|
||
## 2. 三层地图设计
|
||
|
||
### 2.1 Working Map（工作地图 — 任务态）
|
||
|
||
**职责**：描述"当前在做什么"——任务、项目、灵感、工作流的实时状态拓扑。
|
||
|
||
```
|
||
WorkingMap
|
||
├── active_projects[] // 活跃项目清单（含 stack/path/bind 状态）
|
||
├── active_tasks[] // 进行中任务（含 status/assignee/blocker）
|
||
├── task_dependencies[] // 任务间依赖（子任务/阻塞关系）
|
||
├── recent_decisions[] // 近期决策记录（灵感→任务转化轨迹）
|
||
├── workflow_state // 当前工作流执行状态
|
||
└── project_modules[] // 多工程结构（复用 modules 表）
|
||
```
|
||
|
||
**DevFlow 现状对接**：
|
||
- `projects` 表 → `active_projects`
|
||
- `tasks` 表 → `active_tasks`
|
||
- `ideas` 表 → `recent_decisions`（灵感→任务转化链）
|
||
- `modules` + `module_dependencies` 表 → `project_modules`（多工程功能，子1-5 任务在建）
|
||
|
||
**构建时机**：
|
||
- 冷启动：从 SQLite 全量加载活跃实体
|
||
- 热更新：CRUD 操作触发增量更新（事件驱动，复用全局事件总线）
|
||
|
||
### 2.2 Coding Map（代码地图 — 结构态）
|
||
|
||
**职责**：描述"代码长什么样"——文件树、符号索引、依赖图、技术栈。
|
||
|
||
```
|
||
CodingMap
|
||
├── module_index[] // 每个工程的文件树 + 技术栈
|
||
│ ├── file_tree // 目录结构（懒加载，按需展开）
|
||
│ ├── symbol_index // AST 符号索引（函数/结构体/类）
|
||
│ └── stack_signature // 技术栈指纹（Cargo.toml/package.json/...）
|
||
├── cross_module_deps[] // 跨工程依赖（API 调用/类库引入/消息通信）
|
||
├── recent_changes[] // 近期文件变更（git diff + 时间窗口）
|
||
└── hotspots[] // 热点文件（高频访问/修改的文件）
|
||
```
|
||
|
||
**DevFlow 现状对接**：
|
||
- `read_symbol` 工具 → `symbol_index` 的查询入口
|
||
- `detect_stack` 逻辑 → `stack_signature`
|
||
- `modules` + `module_dependencies` → `cross_module_deps`
|
||
- 知识库 Tier1 → `CodingMap` 的知识层补充
|
||
|
||
**构建策略**：
|
||
- 符号索引：按需解析（首次访问某文件时触发 AST 解析，结果缓存）
|
||
- 依赖图：module 绑定目录时构建，变更时增量更新
|
||
- 热点追踪：记录工具调用中的文件访问频度
|
||
|
||
### 2.3 Tool Map（工具地图 — 能力态）
|
||
|
||
**职责**：描述"AI 能做什么"——工具注册表、工具调用历史、工具审批策略。
|
||
|
||
```
|
||
ToolMap
|
||
├── registered_tools[] // 已注册工具清单（名称/参数schema/风险等级）
|
||
├── tool_call_history[] // 近期调用历史（参数/结果/耗时/是否审批）
|
||
├── approval_policies[] // 审批策略（自动批准/人工审批/拒绝）
|
||
├── tool_success_rate // 各工具成功率统计
|
||
└── parameter_patterns[] // 常见参数模式（用于结晶候选识别）
|
||
```
|
||
|
||
**DevFlow 现状对接**：
|
||
- 工具注册表（68 IPC commands）→ `registered_tools`
|
||
- 工具审批机制（Agentic Loop + 审批）→ `approval_policies`
|
||
- `tool_call_history` → 新增，记录到 SQLite 或内存环形缓冲
|
||
|
||
---
|
||
|
||
## 3. Context Cache（上下文缓存层）
|
||
|
||
**职责**：在 Agentic Loop 的多轮对话中，缓存已检索/已推理的上下文，避免重复劳动。
|
||
|
||
### 3.1 缓存结构
|
||
|
||
```rust
|
||
pub struct ContextCache {
|
||
/// 会话级：当前对话已探索的文件/符号
|
||
explored_files: HashMap<PathBuf, FileSnapshot>,
|
||
|
||
/// 任务级：当前任务关联的上下文窗口
|
||
task_context: HashMap<TaskId, TaskContext>,
|
||
|
||
/// 推理缓存：相同输入的推理结果（短 TTL）
|
||
inference_cache: LruCache<InferenceKey, InferenceResult>,
|
||
|
||
/// 工具结果缓存：相同参数的工具调用结果
|
||
tool_result_cache: LruCache<ToolCallSignature, ToolResult>,
|
||
}
|
||
```
|
||
|
||
### 3.2 缓存失效策略
|
||
|
||
| 缓存类型 | TTL | 失效条件 |
|
||
|----------|-----|----------|
|
||
| `explored_files` | 会话级 | 文件被修改（mtime 变化） |
|
||
| `task_context` | 任务级 | 任务状态变更 |
|
||
| `inference_cache` | 5 分钟 | 时间过期或上下文窗口滑动 |
|
||
| `tool_result_cache` | 10 分钟 | 时间过期或目标文件变更 |
|
||
|
||
### 3.3 预期收益
|
||
|
||
- 减少 **50-60%** 的重复推理量
|
||
- 工具调用延迟降低（缓存命中直接返回）
|
||
- 对话连续性增强（AI"记得"上次探索的结果）
|
||
|
||
---
|
||
|
||
## 4. Pattern Crystallizer（模式结晶器）
|
||
|
||
**职责**：识别高频任务路径，将其从 LLM 推理降级为确定性脚本/规则。
|
||
|
||
### 4.1 结晶流水线
|
||
|
||
```
|
||
Frequency Tracker Pattern Analyzer Crystallizer
|
||
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
|
||
│ 记录每次工具 │──▶ N 次 ─▶│ 分析参数模式 │──▶ 稳定 ─▶│ 生成确定性 │──▶ 注册为
|
||
│ 调用的签名 │ 以上 │ + 成功率 │ 模式 │ 脚本/规则 │ 新工具
|
||
└──────────────┘ └──────────────┘ └──────────────┘
|
||
```
|
||
|
||
### 4.2 数据结构
|
||
|
||
```rust
|
||
pub struct FrequencyTracker {
|
||
/// 工具调用签名 → 出现次数
|
||
call_signatures: HashMap<ToolCallSignature, u32>,
|
||
|
||
/// 参数模式聚类（相同工具 + 相似参数归为一类）
|
||
parameter_clusters: HashMap<ToolName, Vec<ParameterPattern>>,
|
||
}
|
||
|
||
pub struct CrystallizedPattern {
|
||
id: String,
|
||
/// 触发条件（何时使用此结晶路径）
|
||
trigger: PatternTrigger,
|
||
/// 确定性执行逻辑（脚本/规则/模板）
|
||
execution: DeterministicExecution,
|
||
/// 置信度（基于历史成功率）
|
||
confidence: f32,
|
||
/// 回退策略（结晶路径失败时回退到 LLM 推理）
|
||
fallback: FallbackStrategy,
|
||
}
|
||
|
||
pub enum DeterministicExecution {
|
||
/// 预定义脚本（Shell/Python）
|
||
Script(PathBuf),
|
||
/// 参数化模板（填充变量后直接执行）
|
||
Template(Template),
|
||
/// 规则引擎（条件→动作映射）
|
||
Rule(RuleSet),
|
||
}
|
||
```
|
||
|
||
### 4.3 结晶示例
|
||
|
||
| 高频模式 | 结晶前（LLM 推理） | 结晶后（确定性逻辑） |
|
||
|----------|-------------------|---------------------|
|
||
| 创建新 Rust crate | LLM 推理目录结构 + Cargo.toml | 脚本：`cargo new --lib` + 模板填充 |
|
||
| 添加 IPC command | LLM 生成 handler + 注册代码 | 模板：参数化生成 + 自动注册 |
|
||
| 运行测试套件 | LLM 推理测试命令 | 直接执行 `cargo test` |
|
||
| 代码审查 | LLM 全量分析 | 规则引擎：lint 规则 + diff 分析 |
|
||
|
||
### 4.4 回退机制
|
||
|
||
结晶路径不是"永久替代"——当确定性执行失败或结果异常时，自动回退到 LLM 推理：
|
||
|
||
```
|
||
执行结晶路径
|
||
├── 成功 → 直接返回结果（跳过 LLM）
|
||
├── 失败 → 记录失败 + 回退到 LLM 推理
|
||
└── 连续失败 N 次 → 标记结晶路径为"待审查"，暂停使用
|
||
```
|
||
|
||
---
|
||
|
||
## 5. 演进路线图
|
||
|
||
### Phase 1：地图构建（预计减少 30-40% 无效检索）
|
||
|
||
**目标**：三张地图的基础设施就位，AI 操作基于地图而非盲搜。
|
||
|
||
| 工作项 | 依托 | 状态 |
|
||
|--------|------|------|
|
||
| Working Map 数据层 | projects/tasks/ideas/modules 表 | ✅ 已有 |
|
||
| Coding Map 符号索引 | read_symbol 工具 | ✅ 已有 |
|
||
| Coding Map 跨工程依赖 | module_dependencies 表 | 🔨 子1-5 在建 |
|
||
| Tool Map 注册表 | 68 IPC commands | ✅ 已有 |
|
||
| Tool Map 调用历史 | 新增 tool_call_log 表 | ❌ 待建 |
|
||
| 地图查询 API | 新增 IPC commands | ❌ 待建 |
|
||
|
||
### Phase 2：上下文缓存（预计减少 50-60% 推理量）
|
||
|
||
**目标**：Agentic Loop 内置缓存层，跨轮复用已检索上下文。
|
||
|
||
| 工作项 | 说明 |
|
||
|--------|------|
|
||
| ContextCache Rust 结构 | 内存级缓存 + LRU 淘汰 |
|
||
| 文件快照机制 | mtime 监控 + 增量失效 |
|
||
| 工具结果缓存 | 签名匹配 + TTL 失效 |
|
||
| 缓存命中率指标 | 可观测性面板 |
|
||
|
||
### Phase 3：模式结晶器（高频任务去 AI 化）
|
||
|
||
**目标**：高频路径自动结晶为确定性逻辑，LLM 退守创造性边界。
|
||
|
||
| 工作项 | 说明 |
|
||
|--------|------|
|
||
| FrequencyTracker | 工具调用签名记录 + 聚类 |
|
||
| PatternAnalyzer | 参数模式分析 + 稳定性评估 |
|
||
| Crystallizer 引擎 | 确定性脚本/模板/规则生成 |
|
||
| 回退机制 | 结晶失败自动回退 LLM |
|
||
| 结晶管理 UI | 查看/审批/禁用结晶路径 |
|
||
|
||
### Phase 4：自治进化（长期愿景）
|
||
|
||
**目标**：系统自主识别优化机会，提出并验证新的结晶路径。
|
||
|
||
| 工作项 | 说明 |
|
||
|--------|------|
|
||
| 异常检测 | 识别低效路径（高 token / 低成功率） |
|
||
| 结晶提案 | 自动生成结晶候选方案 |
|
||
| A/B 验证 | 结晶路径 vs LLM 路径对比 |
|
||
| 自治注册 | 验证通过后自动注册新工具 |
|
||
|
||
---
|
||
|
||
## 6. 与 DevFlow 现有架构的融合点
|
||
|
||
```
|
||
DevFlow 现有架构 本方案融合点
|
||
┌────────────────────┐
|
||
│ Vue 3 前端 │ ← 结晶管理 UI / 缓存命中率面板 / 地图可视化
|
||
├────────────────────┤
|
||
│ Tauri IPC 层 │ ← 地图查询 API / 缓存管理 IPC / 结晶审批 IPC
|
||
├────────────────────┤
|
||
│ Rust 后端 │
|
||
│ ├─ df-storage │ ← tool_call_log 表 / crystallized_patterns 表
|
||
│ ├─ df-project │ ← Working Map + Coding Map 数据源
|
||
│ ├─ df-workflow │ ← 结晶路径作为工作流节点
|
||
│ ├─ df-agent │ ← ContextCache 注入 Agentic Loop
|
||
│ └─ df-tools │ ← Tool Map + FrequencyTracker + Crystallizer
|
||
├────────────────────┤
|
||
│ SQLite │ ← 新增迁移 V17+（patterns/tool_call_log）
|
||
└────────────────────┘
|
||
```
|
||
|
||
### 6.1 新增 Crate 规划
|
||
|
||
| Crate | 职责 | 依赖 |
|
||
|-------|------|------|
|
||
| `df-context` | ContextCache + 三张地图的内存结构 | df-storage, df-project |
|
||
| `df-crystallize` | FrequencyTracker + PatternAnalyzer + Crystallizer | df-tools, df-context |
|
||
|
||
### 6.2 新增数据表（V17+ 迁移）
|
||
|
||
```sql
|
||
-- 工具调用历史
|
||
CREATE TABLE tool_call_log (
|
||
id TEXT PRIMARY KEY,
|
||
task_id TEXT,
|
||
tool_name TEXT NOT NULL,
|
||
parameters TEXT, -- JSON
|
||
result_summary TEXT, -- 截断的结果摘要
|
||
success INTEGER NOT NULL,
|
||
duration_ms INTEGER,
|
||
approved INTEGER,
|
||
created_at INTEGER NOT NULL
|
||
);
|
||
|
||
-- 结晶模式
|
||
CREATE TABLE crystallized_patterns (
|
||
id TEXT PRIMARY KEY,
|
||
trigger_condition TEXT NOT NULL, -- JSON: 何时触发
|
||
execution_type TEXT NOT NULL, -- script / template / rule
|
||
execution_body TEXT NOT NULL, -- 脚本路径 / 模板内容 / 规则集
|
||
confidence REAL NOT NULL,
|
||
status TEXT NOT NULL, -- active / suspended / reviewing
|
||
success_count INTEGER DEFAULT 0,
|
||
failure_count INTEGER DEFAULT 0,
|
||
created_at INTEGER NOT NULL,
|
||
updated_at INTEGER NOT NULL
|
||
);
|
||
```
|
||
|
||
---
|
||
|
||
## 7. 关键设计决策
|
||
|
||
### 7.1 为什么是"三层地图"而非"一张大地图"？
|
||
|
||
- **职责分离**：任务态（Working）、结构态（Coding）、能力态（Tool）的生命周期和更新频率不同
|
||
- **按需加载**：AI 当前操作只需要相关地图层，避免全量加载
|
||
- **独立演进**：每层地图可以独立优化数据结构和索引策略
|
||
|
||
### 7.2 为什么结晶器需要回退机制？
|
||
|
||
- 结晶路径基于历史模式，无法覆盖所有边界情况
|
||
- 回退到 LLM 推理是安全网，确保系统鲁棒性
|
||
- 连续失败自动暂停，避免反复走死路
|
||
|
||
### 7.3 为什么缓存层放在 Rust 后端而非前端？
|
||
|
||
- Rust 后端是 Agentic Loop 的执行体，缓存就近放置延迟最低
|
||
- 避免前后端数据同步的复杂性
|
||
- Rust 的内存管理适合 LRU 缓存场景
|
||
|
||
---
|
||
|
||
## 8. 风险与缓解
|
||
|
||
| 风险 | 影响 | 缓解措施 |
|
||
|------|------|----------|
|
||
| 地图数据过期 | AI 基于过期信息做决策 | mtime 监控 + 事件驱动增量更新 |
|
||
| 结晶路径覆盖不全 | 部分场景回退频繁 | 回退机制 + 逐步扩大结晶覆盖 |
|
||
| 缓存内存膨胀 | 内存占用过高 | LRU 淘汰 + TTL 过期 + 容量上限 |
|
||
| 结晶脚本安全风险 | 恶意/错误脚本执行 | 审批机制 + 沙箱执行 + 权限限制 |
|
||
|
||
---
|
||
|
||
## 9. 总结
|
||
|
||
本方案的核心贡献是将 AI 工作流从"每次全量推理"进化为"地图导航 + 缓存加速 + 高频结晶"的三级加速体系：
|
||
|
||
1. **地图层**解决"去哪找"——减少 30-40% 无效检索
|
||
2. **缓存层**解决"别重复"——减少 50-60% 推理量
|
||
3. **结晶器**解决"别想了，直接做"——高频路径去 AI 化
|
||
|
||
最终愿景：**AI 构建认知基础设施，然后将确定性路径交给脚本/规则，自身专注于真正需要创造力的边界问题。这才是 AI 原生的终局——让 AI 做得越来越少，但每一步都精准。**
|
||
|
||
---
|
||
|
||
> **下一步行动**：
|
||
> 1. 将 Phase 1 中待建项（tool_call_log 表、地图查询 API）拆解为具体任务
|
||
> 2. 在 `df-context` crate 中实现 ContextCache 原型
|
||
> 3. 设计 FrequencyTracker 的数据采集埋点方案
|