新增: 上下文管理演进设计文档（发散思考 + 任务技术设计）
发散思考文档涵盖: - ContextManager 三维评估（效率/合理性/成本） - 业界方案对标（Claude Code/OpenAI SDK/Mem0/LangGraph 等） - 融合设计: 结构化分层上下文引擎（L1常驻/L2历史/L3摘要） - 9 种方法交叉论证（决策矩阵/ROI/帕累托/Kano/风险矩阵等） - 7 个发散方向与冲突分析，推荐派系 A 路线 任务技术设计文档涵盖: - T2 工具命名空间: 大工具结果不进主队列，NamespaceStore 详细设计 - T4 工作流 DAG 注入: 活跃路径裁剪，结构化 DAG 进 system prompt - T3 L3 结构化摘要: JSON+NL 双格式压缩摘要 - T1 动态压缩阈值: 精确到行的 3 处改动 - 4 种边界情况推演，AI coding 多 agent 并行策略
This commit is contained in:
@@ -0,0 +1,882 @@
|
||||
# 上下文管理：现状评估、业界对标与发散演进
|
||||
|
||||
> 创建: 2026-07-20 | 状态: 构想审查 | 关联: F-15 上下文管理增强设计
|
||||
|
||||
---
|
||||
|
||||
## 目录
|
||||
|
||||
- [一、当前 ContextManager 评估](#一当前-contextmanager-评估)
|
||||
- [二、业界方案对标](#二业界方案对标)
|
||||
- [三、融合设计：结构化分层上下文引擎](#三融合设计结构化分层上下文引擎)
|
||||
- [四、3 个近期改进的推演验证](#四3-个近期改进的推演验证)
|
||||
- [五、7 个发散方向](#五7-个发散方向)
|
||||
- [六、发散组合分析与冲突矩阵](#六发散组合分析与冲突矩阵)
|
||||
- [七、推荐路线](#七推荐路线)
|
||||
|
||||
---
|
||||
|
||||
## 一、当前 ContextManager 评估
|
||||
|
||||
### 核心架构
|
||||
|
||||
```
|
||||
build_for_request → 返回裁剪后视图（影响 LLM 上下文）
|
||||
all_messages_clone → 返回全量（影响 DB 存储, save_conversation）
|
||||
```
|
||||
|
||||
| 层级 | 组件 | 文件 |
|
||||
|------|------|------|
|
||||
| Token 估算 | `TokenEstimator` — chars×0.35 + 消息开销 | `context_helpers.rs:28` |
|
||||
| 窗口配置 | `ContextConfig` — max_tokens/output_reserve/safety_ratio | `context_helpers.rs:105` |
|
||||
| 消息管理 | `ContextManager` — 消息队列 + token 缓存 | `context/mod.rs:44` |
|
||||
| 自愈 | `sanitize模块` — 畸形配对过滤 + 序列合法性修复 | `context/sanitize.rs` |
|
||||
| 自动压缩 | `maybe_auto_compress` — F-15 自动触发 | `context_lifecycle.rs:64` |
|
||||
|
||||
### 三维评分
|
||||
|
||||
| 维度 | 评分 | 核心论据 |
|
||||
|------|------|---------|
|
||||
| **效率** | ⭐⭐⭐⭐ (8/10) | 核心路径零拷贝裁剪，O(n) 反向扫描查找，幂等压缩。瓶颈在 TokenEstimator 精度和压缩同步等待 |
|
||||
| **合理性** | ⭐⭐⭐⭐⭐ (9/10) | 三元组原子性、保护区、视图/持久化分离、畸形自愈——近乎工业级完整。略缺跨会话上下文 |
|
||||
| **成本** | ⭐⭐⭐⭐ (8/10) | 预算池 + 流式记录 + 关键词兜底形成三级防线。缺乏自动模型降级链和长时间会话自动分段 |
|
||||
|
||||
### 已知问题
|
||||
|
||||
1. **TokenEstimator 对所有字符一视同仁** — 中文（~1.8-2.5 tok/char）被低估，英文（~0.2-0.3）被高估。当前靠 `safety_ratio: 0.85` 和 `output_reserve: 8192` 补误差
|
||||
2. **压缩阈值硬编码 0.6** — 不考 system prompt 大小，大量工具结果时可能误判
|
||||
3. **无自动会话分段** — `archived_segment` 状态和 IPC 已就绪，但只能手动触发
|
||||
|
||||
---
|
||||
|
||||
## 二、业界方案对标
|
||||
|
||||
### 2.1 与 7 条行业公认合理标准对标
|
||||
|
||||
| # | 行业标准 | DevFlow 现状 | 差距 |
|
||||
|---|---------|-------------|------|
|
||||
| 1 | **运行时/LLM 上下文双层隔离** | 有部分隔离但不彻底。无类型层面的强制边界 | ⚠️ 概念上有但无强制 |
|
||||
| 2 | **分层记忆（瞬时→短期→长期）** | 只有「内存窗口 ↔ DB」两层，缺短期缓存层和向量检索层 | ⚠️ 有分层但缺中间层 |
|
||||
| 3 | **Token 预算管控** | `TokenEstimator` + `budget_limit` + 0.6 水位 + 降级关键词兜底 | ✅ 业界中上 |
|
||||
| 4 | **信息加权裁剪** | `PROTECT_COUNT=6` 保近期，但裁剪是纯位置滑动，不是按价值加权 | ⚠️ 机制粗糙 |
|
||||
| 5 | **命名空间隔离** | `conv_id` 做 Session 级隔离，无 User/Agent 维度 | ⚠️ 缺维度 |
|
||||
| 6 | **结构化沉淀** | 压缩摘要为纯文本，非结构化数据 | ❌ 文本摘要非结构化 |
|
||||
| 7 | **可持久快照** | DB 保留全量，但无版本概念，不可回滚 | ❌ 有持久无快照 |
|
||||
|
||||
### 2.2 具体方案比较
|
||||
|
||||
| 方案 | 核心优势 | 对 DevFlow 的参考价值 |
|
||||
|------|---------|---------------------|
|
||||
| **Claude Code 三层加载** | 常驻索引 + 按需主题 + 离线归档 | 当前 `pinned_goals` → 扩展为更丰富的 WorkingContext |
|
||||
| **OpenAI Agents SDK RunContext** | 运行时状态不进 prompt | 当前 AiSession 概念上有但无强制边界 |
|
||||
| **Mem0** | User/Session/Agent 三维命名空间 | 未来多租户/跨会话复用的架构参考 |
|
||||
| **Letta (MemGPT)** | 虚拟内存分页，模型自主调度 | 哲学不同：Letta 模型自主换页，DevFlow 系统强制压缩 |
|
||||
| **TencentDB Agent Memory** | 结构化任务画布替代文本历史 | **最有参考价值** — 与 df-workflow + df-nodes 天然契合 |
|
||||
| **LangGraph** | 可持久化 State + Checkpoint | 版本化快照模式参考 |
|
||||
| **AutoContextMemory** | 6 档阶梯式上下文管控 | 信息加权裁剪参考 |
|
||||
|
||||
### 2.3 核心启发
|
||||
|
||||
```
|
||||
TencentDB 任务画布思路 → 结构化卡片替代纯文本摘要
|
||||
↓
|
||||
WorkingContext 常驻 → 结构化目标/决策/步骤替代纯文本 pinned_goals
|
||||
↓
|
||||
MemoryAdapter trait → 插件化记忆层，不绑定 Vec<TrackedMessage>
|
||||
↓
|
||||
版本化快照 → 从覆盖写改为追加 checkpoint
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 三、融合设计：结构化分层上下文引擎
|
||||
|
||||
### 3.1 架构总览
|
||||
|
||||
```mermaid
|
||||
graph TB
|
||||
subgraph LLM 上下文窗口 (build_for_request 输出)
|
||||
L1["L1 常驻上下文<br>（永不裁剪，结构化 system 消息）"]
|
||||
L2["L2 活跃历史<br>（窗口滑动淘汰，user/assistant/tool）"]
|
||||
L3["L3 结构化摘要<br>（压缩/归档后锚点，JSON 卡片）"]
|
||||
end
|
||||
|
||||
subgraph 本地运行时状态 (不进 LLM)
|
||||
R1["原始消息全量 (SQLite DB)"]
|
||||
R2["工具执行日志 (分级缓存)"]
|
||||
R3["向量记忆索引 (df-knowledge)"]
|
||||
R4["工作流 DAG (df-workflow)"]
|
||||
end
|
||||
|
||||
L1 -->|注入 system| LLM["LLM 请求"]
|
||||
L2 -->|阈值超限| L3
|
||||
L3 -->|检索回溯| R1
|
||||
L3 -->|语义检索| R3
|
||||
|
||||
style L1 fill:#c8e6c9
|
||||
style L2 fill:#fff9c4
|
||||
style L3 fill:#bbdefb
|
||||
style R1 fill:#f5f5f5
|
||||
style R2 fill:#f5f5f5
|
||||
style R3 fill:#f5f5f5
|
||||
style R4 fill:#f5f5f5
|
||||
```
|
||||
|
||||
### 3.2 L1 常驻上下文：WorkingContext
|
||||
|
||||
融合 Claude Code 常驻索引 + DevFlow 现有 `pinned_goals` + Decision Journal：
|
||||
|
||||
```rust
|
||||
pub struct WorkingContext {
|
||||
pub goals: Vec<GoalItem>,
|
||||
pub decisions: Vec<DecisionItem>,
|
||||
pub unresolved: Vec<String>,
|
||||
pub current_step: Option<StepInfo>,
|
||||
pub key_artifacts: Vec<ArtifactRef>,
|
||||
}
|
||||
```
|
||||
|
||||
### 3.3 L1 注入策略：分层注入（非全量常驻）
|
||||
|
||||
`dirty_window_turns` 控制脏标记的可见窗口——只有最近 N 轮内有变更的字段才注入 system prompt。
|
||||
|
||||
```mermaid
|
||||
graph LR
|
||||
subgraph "L1a 高频常驻 (~200 tokens)"
|
||||
A1["当前步骤 current_step"]
|
||||
end
|
||||
subgraph "L1b 条件注入 (~200-800 tokens)"
|
||||
B1["活跃目标 — dirty_window 内变更才注入"]
|
||||
B2["未决项 — dirty_window 内变更才注入"]
|
||||
end
|
||||
subgraph "L1c 工具按需"
|
||||
C1["完整决策历史 → read_context 工具"]
|
||||
end
|
||||
|
||||
A1 -->|每轮必带| LLM
|
||||
B1 -->|变更在窗口内| LLM
|
||||
B2 -->|变更在窗口内| LLM
|
||||
C1 -->|模型主动调用| LLM
|
||||
```
|
||||
|
||||
### 3.4 压缩联动（关键补丁）
|
||||
|
||||
压缩事件发生后，`reset_all_with_summary` 将所有脏标记重置到当前轮次，保证压缩后下轮 L1b 全量注入，补偿被压缩丢失的历史信息：
|
||||
|
||||
```rust
|
||||
// context_lifecycle.rs: 压缩成功后
|
||||
conv.messages.compress_old_messages(protect_start);
|
||||
conv.messages.insert_at(0, ChatMessage::system(&summary));
|
||||
|
||||
// 压缩后重置脏窗口
|
||||
conv.working_context.version.reset_all_with_summary(&summary, current_turn);
|
||||
```
|
||||
|
||||
### 3.5 L3 结构化摘要卡片
|
||||
|
||||
将压缩输出的纯文本摘要改为 JSON + NL 双格式：
|
||||
|
||||
```
|
||||
当前: system: "用户讨论了审批流程，确认了超时参数改为 30 分钟"
|
||||
|
||||
改进后: system: <<<STRUCTURED_SUMMARY>>>
|
||||
{
|
||||
"type": "conversation_segment",
|
||||
"topics": ["审批超时设置"],
|
||||
"decisions": [
|
||||
{"what": "超时改为 30 分钟", "why": "用户反馈 15 分钟太短"}
|
||||
],
|
||||
"unresolved": ["推送方式待定"],
|
||||
"token_saved": 45200
|
||||
}
|
||||
<<<END_STRUCTURED_SUMMARY>>>
|
||||
自然语言摘要: 用户讨论了审批流程，确认了超时参数改为 30 分钟
|
||||
```
|
||||
|
||||
### 3.6 信息加权裁剪
|
||||
|
||||
当前 `build_eviction_units` 按消息位置淘汰，改为按消息类型赋予保留权重：
|
||||
|
||||
| 消息角色 | 保留权重 | 理由 |
|
||||
|---------|---------|------|
|
||||
| User（短指令） | 100 | 高价值，优先保留 |
|
||||
| User（长消息） | 70 | 中等 |
|
||||
| Assistant（含 tool_calls） | 50 | 工具调用链需要保留 |
|
||||
| Assistant（纯文本） | 40 | 一般 |
|
||||
| Tool（工具结果） | 20 | 低价值，优先淘汰 |
|
||||
|
||||
---
|
||||
|
||||
## 四、3 个近期改进的推演验证
|
||||
|
||||
### 4.1 改进 1：TokenEstimator 按字符类型加权
|
||||
|
||||
**初始提议**：中文×1.8、英文×0.25、数字×0.20 等混合加权。
|
||||
|
||||
**推演结论**：**不做。** 理由：
|
||||
|
||||
1. 当前 `safety_ratio: 0.85` + `output_reserve: 8192` 提供了约 27k tokens 的余量，中英混合对话要超界需要极端场景
|
||||
2. 真正该修的入口不在 TokenEstimator：tool_result 膨胀应由 `extract_key_info` 在工具执行阶段削减，不是靠 TokenEstimator 精度来兜底
|
||||
3. 改加权逻辑有回归风险（content / parts / tool_calls / tool_call_id 多处调用了 `chars_ratio`）
|
||||
|
||||
### 4.2 改进 2：动态压缩阈值
|
||||
|
||||
**初始提议**：将 `budget * 6 / 10` 改为 `available * 6 / 10`（available = budget - sys_tokens）。
|
||||
|
||||
**推演结论**：**做。** 3 行改动，效果明确：
|
||||
|
||||
```rust
|
||||
// 当前
|
||||
let should = (budget as u64) * 6 / 10 < history_tokens as u64;
|
||||
|
||||
// 改为
|
||||
let available = mgr.budget_limit().saturating_sub(sys_tokens);
|
||||
let should = (available as u64) * 6 / 10 < history_tokens as u64;
|
||||
```
|
||||
|
||||
`sys_tokens` 在 `maybe_auto_compress` 调用处已由调用方算好（loop 顶部传给 `build_for_request`），透传即可。
|
||||
|
||||
### 4.3 改进 3：长时间会话自动存档
|
||||
|
||||
**初始提议**：达到压缩次数或消息总量阈值后自动触发 `archived_segment`。
|
||||
|
||||
**推演结论**：**暂缓。** 基础设施已就绪（`archived_segment` 状态、IPC `ai_chat_clear_context`、前端 `AiContextCleared` 事件），但：
|
||||
|
||||
1. 极长对话（>300 条）才需要，日常场景用不着
|
||||
2. 归档后压缩摘要与归档摘要的关系需要先理清（归档时会把之前的压缩摘要也一并标记 archived_segment，确保不产生孤立 system 消息）
|
||||
3. 建议 Phase 4/5 再做
|
||||
|
||||
### 4.4 优先级
|
||||
|
||||
| 排序 | 项 | 改动量 | 收益 | 建议 |
|
||||
|------|----|--------|------|------|
|
||||
| 🥇 | **2a 动态阈值** | 3 行 | 减少误压缩和漏压缩 | **立即做** |
|
||||
| 🥈 | 1 TokenEstimator | 多文件 | 被 safety_ratio 兜住 | **不做** |
|
||||
| 🥉 | 3 自动存档 | ~50 行 | 场景不迫切 | **Phase 4/5** |
|
||||
|
||||
---
|
||||
|
||||
## 五、7 个发散方向
|
||||
|
||||
### 发散①：画布导航 — 模型自主控制视野
|
||||
|
||||
**核心思想**：不再把上下文拼成平铺消息队列丢给模型，而是组织成多维画布，模型通过 `look_at` 工具自主导航：
|
||||
|
||||
```json
|
||||
{
|
||||
"tool": "look_at",
|
||||
"args": { "zone": "L1/decisions", "expand": true }
|
||||
}
|
||||
```
|
||||
|
||||
**差异**：窗口永远不会满（不需要装全部），压缩不存在（没有"全量传输"的概念）。模型控制视野范围。
|
||||
|
||||
**代价**：需要模型主动使用 `look_at`，模型不用时需降级回传统模式。新协议，高实现成本。
|
||||
|
||||
### 发散②：上下文版本分支 — 决策回溯可导航
|
||||
|
||||
**核心思想**：支持分支与合并上下文。`ContextManager` 加 `parent: Option<String>` 和 `fork_point: usize`：
|
||||
|
||||
```mermaid
|
||||
graph LR
|
||||
A[方案 A] --> B[继续 A]
|
||||
A --> C[方案 B]
|
||||
C --> D[发现 B 不可行]
|
||||
D --> E[合并回到 A]
|
||||
B --> E
|
||||
```
|
||||
|
||||
**差异**：放弃的方案上下文不会被新会话污染，可随时回溯精确内容。
|
||||
|
||||
**代价**：存储复杂度——N 个分支 = N× 内存。
|
||||
|
||||
### 发散③：主动参与 — 系统在对话中插话
|
||||
|
||||
**核心思想**：上下文管理器在 agentic loop 中拥有系统消息通道，可以在检测到模式时主动"说话"：
|
||||
|
||||
```
|
||||
触发条件示例:
|
||||
连续 N 轮使用同一工具 → 建议创建快捷方式
|
||||
修改 A 后 5 轮内又修改 B → 建议关联工作流
|
||||
目标活跃但 N 轮无推进 → 提醒调整目标
|
||||
```
|
||||
|
||||
**差异**：从"你问它答"到"AI 主动观察并建议"——人机交互范式变化。
|
||||
|
||||
**代价**：冷却期管理和负面反馈机制是必需的，否则必然变成骚扰。
|
||||
|
||||
### 发散④：时间轴衰减 — 不裁不压，让信息连续"模糊"
|
||||
|
||||
**核心思想**：每条消息的精度随轮次连续衰减，而非在某一轮突然被压缩：
|
||||
|
||||
```rust
|
||||
pub struct TrackedMessage {
|
||||
pub message: ChatMessage,
|
||||
pub precision: f32, // 1.0=精确 → 0.0=完全模糊
|
||||
pub last_accessed: u32, // 最后被 LLM 读取的轮次
|
||||
}
|
||||
```
|
||||
|
||||
**差异**：压缩不是在某一轮突然发生的，而是每轮都在发生——精度衰减是连续的。
|
||||
|
||||
**代价**：需要新的衰减算法和精度阈值判断。与当前离散三态模型不兼容。
|
||||
|
||||
### 发散⑤：元控制器 — 上下文管理策略自感知
|
||||
|
||||
**核心思想**：把 `safety_ratio`、压缩阈值、`PROTECT_COUNT` 等硬编码常量变为动态自适应参数：
|
||||
|
||||
```rust
|
||||
pub struct MetaContextController {
|
||||
features: VecDeque<WindowFeature>, // 会话特征滑动窗口
|
||||
recommended: ContextConfig, // 当前推荐配置
|
||||
}
|
||||
```
|
||||
|
||||
**差异**：无需手调参数，系统在 5-10 轮后自动收敛到适合当前会话的策略。
|
||||
|
||||
**代价**：元控制器自己的参数（特征窗口大小、步长）也需要调——递归问题。
|
||||
|
||||
### 发散⑥：工作流即上下文 — DAG 作为上下文主干
|
||||
|
||||
**核心思想**：上下文就是当前工作流的 DAG 视图，消息按工作流节点组织，而非按时间排列：
|
||||
|
||||
```
|
||||
当前: [user][asst][tool][user][asst]... → 时间线
|
||||
改进: [节点1(完成)] [节点2(当前)] [节点3(待办)] → DAG
|
||||
```
|
||||
|
||||
**差异**：DevFlow 是唯一同时拥有工作流引擎和 AI 对话的产品，这种融合是**差异化最大的方向**。
|
||||
|
||||
**代价**：需要工作流与对话关联，自由对话不适用。
|
||||
|
||||
### 发散⑦：工具命名空间 — 工具结果不进主队列
|
||||
|
||||
**核心思想**：工具的执行结果不返回主消息队列，而是存入专属的 namespace：
|
||||
|
||||
```
|
||||
主队列:
|
||||
[asst] 正在读取 config.rs...
|
||||
[tool_result(namespace://read/config.rs)] ← 仅 20 tokens 的引用
|
||||
|
||||
工具工作区:
|
||||
namespace://read/config.rs → 342 行代码（按需读取，不占窗口）
|
||||
```
|
||||
|
||||
**差异**：大工具结果膨胀是当前压缩触发的主因，这直接消除膨胀源。
|
||||
|
||||
**代价**：需要 namespace 存储引擎 + 模型引用协议。工具执行路径不变，路由从 push messages 改为 push reference。
|
||||
|
||||
---
|
||||
|
||||
## 六、发散组合分析与冲突矩阵
|
||||
|
||||
### 6.1 内部不可调和冲突
|
||||
|
||||
#### 冲突 1：画布（①） vs 批传输（当前 Design + ②③④⑤⑥⑦）
|
||||
|
||||
```
|
||||
画布模式要求: 模型自主注视 → 增量读取 → 窗口永不装满
|
||||
批传输模式要求: 系统全量拼装 → 一次发给模型 → 压缩/裁剪管理窗口
|
||||
|
||||
当①启用时，压缩、裁剪、budget_limit 的假设前提不再成立——
|
||||
窗口装的不是全量消息，而是画布坐标系。
|
||||
```
|
||||
|
||||
#### 冲突 2：主动参与（③） vs 画布导航（①）
|
||||
|
||||
```
|
||||
①: 模型是自主的，系统是服务者
|
||||
③: 系统有更高优先级的信息需要模型注意
|
||||
|
||||
模型正在注视 L2，系统突然插话——注意力被打破。
|
||||
```
|
||||
|
||||
#### 冲突 3：时间轴衰减（④） vs 分支（②） vs 工作流（⑥）
|
||||
|
||||
三者对"什么是上下文的主要信息载体"的回答不同：
|
||||
|
||||
```
|
||||
④: 消息是主要载体 → 精度衰减作用于消息
|
||||
⑥: 工作流节点是主要载体 → 消息附着在节点上
|
||||
②: 分支是主要载体 → 消息在分支的线性时间线上
|
||||
|
||||
一条消息同时有精度值（④）+ 分支ID（②）+ 工作流节点ID（⑥）→
|
||||
三个矛盾的淘汰决策信号同时作用 → 需要额外仲裁逻辑
|
||||
```
|
||||
|
||||
### 6.2 组合爆炸
|
||||
|
||||
7 个发散引入至少 26 个新参数；状态空间约 3^7 ≈ 2187 种（无法穷举测试）。
|
||||
|
||||
### 6.3 三个互斥派系
|
||||
|
||||
```mermaid
|
||||
graph TB
|
||||
subgraph "派系 A: 工作流结构化 (推荐首做)"
|
||||
A6["⑥工作流即上下文"]
|
||||
A7["⑦工具命名空间"]
|
||||
A5["⑤元控制器 (精简版)"]
|
||||
A_RESULT["输出: 工作流DAG + 命名空间引用 替代平铺消息"]
|
||||
end
|
||||
|
||||
subgraph "派系 B: 记忆系统"
|
||||
B2["②上下文分支"]
|
||||
B4["④时间轴衰减"]
|
||||
B5["⑤元控制器"]
|
||||
B_RESULT["输出: 分支记忆 + 连续遗忘 替代离散压缩"]
|
||||
end
|
||||
|
||||
subgraph "派系 C: 交互范式"
|
||||
C1["①画布导航"]
|
||||
C3["③主动参与"]
|
||||
C5["⑤元控制器"]
|
||||
C_RESULT["输出: 自主模型 + 系统辅助 替代命令式对话"]
|
||||
end
|
||||
|
||||
A6 ---|不兼容| B2
|
||||
B4 ---|兼容| C1
|
||||
C3 ---|不兼容| C1
|
||||
```
|
||||
|
||||
| 派系 | 核心哲学 | 适合场景 | 与当前 Design 衔接成本 |
|
||||
|------|---------|---------|----------------------|
|
||||
| **A 工作流结构化** | 把上下文组织成 DAG | 有明确工作流的任务 | **低**（复用 df-workflow） |
|
||||
| **B 记忆系统** | 让上下文更像人脑记忆 | 超长对话、研究型任务 | 中（新算法 + 新状态） |
|
||||
| **C 交互范式** | 重新定义人机交互 | 高级用户、复杂决策 | 高（改变协议） |
|
||||
|
||||
### 6.4 双发散的乘数效应
|
||||
|
||||
| 组合 | 收益等级 | 价值 |
|
||||
|------|---------|------|
|
||||
| **⑥+⑦** | 🔥🔥🔥 | 工作流节点引用 namespace 路径，精确回溯无需重查 |
|
||||
| **①+②** | 🔥🔥 | 画布让 N 个分支的内存成本从 O(N) 降到 O(1) |
|
||||
| **③+⑤** | 🔥🔥🔥 | 没有⑤，③是骚扰；没有③，⑤的优化用户感觉不到 |
|
||||
| **④+⑦** | 🔥 | namespace 引用增加置信度信号 |
|
||||
| **①+②+⑥+⑦** | 🏆 | 最完整的中断恢复路径 |
|
||||
| **③+⑤+⑥** | 🔥🔥 | 工作流阻塞时智能主动提示 |
|
||||
|
||||
### 6.5 对「全组合」的结论
|
||||
|
||||
> **技术上可以，但架构上存在 3 对不可调和冲突、26+ 新参数、2187+ 状态空间。不可控。** 不推荐全组合。
|
||||
|
||||
| 维度 | 答案 |
|
||||
|------|------|
|
||||
| **技术上可行吗** | 可以，但需要全新架构，复杂度膨胀约 10 倍 |
|
||||
| **测试覆盖可行吗** | 不可行。2187 种组合状态 → 实际覆盖不到 5% |
|
||||
| **维护成本可接受吗** | 不可接受。团队需同时理解 7 个系统的交互 |
|
||||
| **价值可叠加吗** | 边际递减。②+④ 已覆盖 T-fork+T-resume 主要痛点 |
|
||||
| **更优路径** | **选派系 A 做深，接口预留 B 和 C** |
|
||||
|
||||
---
|
||||
|
||||
## 七、推荐路线
|
||||
|
||||
### 选派系 A（工作流结构化）为主干，预留接口
|
||||
|
||||
```mermaid
|
||||
graph TB
|
||||
subgraph "Phase 4-5"
|
||||
A6["⑥ 工作流即上下文"]
|
||||
A7["⑦ 工具命名空间"]
|
||||
A5["⑤ 元控制器 (精简版: 仅调 3-5 个参数)"]
|
||||
COMBINED["A 组构成新 ContextManager"]
|
||||
end
|
||||
|
||||
subgraph "预留接口 (不实现)"
|
||||
IF1["Trait: ContextNavigation<br>（供①画布）"]
|
||||
IF2["Trait: ContextFork<br>（供②分支）"]
|
||||
IF3["Trait: ProactiveHint<br>（供③主动参与）"]
|
||||
IF4["Trait: PrecisionDecay<br>（供④衰减）"]
|
||||
end
|
||||
|
||||
A6 --> COMBINED
|
||||
A7 --> COMBINED
|
||||
A5 --> COMBINED
|
||||
COMBINED --> IF1
|
||||
COMBINED --> IF2
|
||||
COMBINED --> IF3
|
||||
COMBINED --> IF4
|
||||
```
|
||||
|
||||
### 实施步骤
|
||||
|
||||
| 步 | 内容 | 改造成本 | 用户可见收益 | 阶段 |
|
||||
|----|------|---------|------------|------|
|
||||
| 0 | **动态压缩阈值** — 将 sys_tokens 纳入 | 3 行 | 减少误/漏压缩 | 立即 |
|
||||
| 1 | **L3 结构化摘要** — JSON 卡片替代纯文本 | ~100 行 | 压缩后上下文质量可测提升 | Phase 4 |
|
||||
| 2 | **⑦ 工具命名空间** — 大结果不进主队列 | ~300 行 | tool_result 膨胀消除 | Phase 4 |
|
||||
| 3 | **⑥ 工作流 DAG 注入** — 消息按节点组织 | ~500 行 | 工作流感知的精确回溯 | Phase 4 |
|
||||
| 4 | **L1 WorkingContext + 分层注入** — 结构化常驻 | ~400 行 | 长对话目标保持 | Phase 5 |
|
||||
| 5 | **MemoryAdapter trait 提取** — 重构 | ~200 行 | 零（纯重构） | Phase 5 |
|
||||
| 6 | **版本化快照** — checkpoint 追加写 | ~150 行 | 断点恢复 | Phase 5 |
|
||||
|
||||
**接口预留**（不实现，仅定义 trait）：
|
||||
|
||||
```rust
|
||||
#[async_trait]
|
||||
pub trait ContextNavigation { /* 供①画布实现 */ }
|
||||
#[async_trait]
|
||||
pub trait ContextFork { /* 供②分支实现 */ }
|
||||
#[async_trait]
|
||||
pub trait ProactiveHint { /* 供③主动参与实现 */ }
|
||||
#[async_trait]
|
||||
pub trait PrecisionDecay { /* 供④衰减实现 */ }
|
||||
```
|
||||
|
||||
### 一句话总结
|
||||
|
||||
> **做 ⑥+⑦ 结构化工作流上下文，留接口给记忆和交互范式，不做全组合。**
|
||||
|
||||
---
|
||||
|
||||
## 八、多方法交叉论证
|
||||
|
||||
> 本章用 7 种独立方法对同一组选项交叉验证。结论收敛到同一方向则信心高，出现分歧则标注并分析原因。
|
||||
|
||||
### 8.1 方法概览
|
||||
|
||||
| # | 方法 | 分析对象 | 输出 | 与已有分析的关系 |
|
||||
|---|------|---------|------|-----------------|
|
||||
| A | **决策矩阵** | 3 个派系 | 加权总分排序 | 把第 6 章定性结论量化 |
|
||||
| B | **成本收益分析** | 7 个发散 | 成本/收益散点图 | 补充第 5 章缺失的量化维度 |
|
||||
| C | **ROI 测算** | 派系 A 实施步 | 美元/月节省 vs 开发改动单元 | 把第 7 章路线图加上财务回报 |
|
||||
| D | **影响范围分析** | 7 个发散 | 波及文件 / 子系统热力图 | 补充实现成本的具体依据 |
|
||||
| E | **依赖图 & 拓扑排序** | 派系 A 实施步 | 前置条件图 | 验证第 7 章步骤顺序的合理性 |
|
||||
| F | **风险矩阵** | 7 个发散 | 概率×影响热力图 | 补充第 6 章冲突分析的失败模式 |
|
||||
| G | **根本原因回溯** | 7 个发散 → 原始痛点 | 覆盖度矩阵 | 从问题端验证发散是否对症 |
|
||||
| H | **帕累托分析** | 派系 A 实施步 | 累积收益曲线 | 找出 20% 努力得 80% 收益的关键步 |
|
||||
| I | **Kano 模型** | 7 个发散 | 用户满意度分类 | 从用户感知角度验证优先级 |
|
||||
|
||||
---
|
||||
|
||||
### 8.2 方法 A：决策矩阵
|
||||
|
||||
对 3 个派系在 6 个加权维度上打分（1-5）。权重表示该维度对 DevFlow 当前阶段的重要性。
|
||||
|
||||
| 维度 | 权重 | 派系 A（工作流结构化） | 派系 B（记忆系统） | 派系 C（交互范式） | 权重理由 |
|
||||
|------|------|---------------------|------------------|------------------|---------|
|
||||
| 贴合现有资产 | **5** | 5 — 复用 df-workflow + ToolRegistry | 2 — 全新记忆层 | 1 — 需改协议 | Phase 4 优先利用已有代码 |
|
||||
| 用户可见收益 | **4** | 5 — 压缩后仍可回溯精确行号 | 4 — 长对话不失忆 | 3 — 高级用户才感知 | 需要让用户感受到变化 |
|
||||
| 实现成本 | **4** | 4 — 增量改造（~900 行） | 2 — 新状态+新算法 | 1 — 新协议+新交互 | 资源有限，成本敏感 |
|
||||
| 测试覆盖度 | **3** | 4 — 可在现有单测基础上加 | 2 — 新算法需要全新测试 | 2 — 新协议需要集成测试 | 质量保障成本 |
|
||||
| 长期扩展性 | **3** | 5 — 为 B/C 预留接口 | 3 — 自成体系 | 3 — 自成体系 | 不堵死未来路径 |
|
||||
| 风险可控度 | **4** | 5 — 增量上线，可回退 | 3 — 新状态机，迁移风险 | 2 — 模型配合度不确定 | 线上稳定性 |
|
||||
|
||||
**加权总分**：
|
||||
|
||||
```
|
||||
派系 A = 5×5 + 4×5 + 4×4 + 3×4 + 3×5 + 4×5 = 25 + 20 + 16 + 12 + 15 + 20 = 108
|
||||
派系 B = 5×2 + 4×4 + 4×2 + 3×2 + 3×3 + 4×3 = 10 + 16 + 8 + 6 + 9 + 12 = 61
|
||||
派系 C = 5×1 + 4×3 + 4×1 + 3×2 + 3×3 + 4×2 = 5 + 12 + 4 + 6 + 9 + 8 = 44
|
||||
```
|
||||
|
||||
**结论**：派系 A 以 108 分大幅领先。差距主要在「贴合现有资产」（权重最高）和「实现成本」两个维度——这正是 Phase 4 阶段的核心约束。
|
||||
|
||||
---
|
||||
|
||||
### 8.3 方法 B：成本收益散点图
|
||||
|
||||
对 7 个发散方向估算实施成本（改动单元）和预期收益（用户可见改善度 1-10）：
|
||||
|
||||
| 发散 | 实施成本（改动单元） | 收益（1-10） | 性价比 | 说明 |
|
||||
|------|----------------|-------------|--------|------|
|
||||
| ①画布导航 | 25-35 | 6 | 低 | 新传输协议 + 模型配合训练 |
|
||||
| ②分支 | 15-20 | 7 | 中 | 新数据结构 + 状态机 |
|
||||
| ③主动参与 | 10-15 | 5 | 中 | 需要用户行为研究 |
|
||||
| ④时间轴衰减 | 12-18 | 4 | 低 | 与现有三态模型不兼容 |
|
||||
| ⑤元控制器 | 8-12 | 6 | **高** | 改配置参数即可，收益面广 |
|
||||
| ⑥工作流即上下文 | 10-15 | 9 | **最高** | 复用 df-workflow，DAG 注入 |
|
||||
| ⑦工具命名空间 | 5-8 | 8 | **最高** | 直接消除 tool_result 膨胀根因 |
|
||||
|
||||
```
|
||||
收益
|
||||
10│ 🚩⑥
|
||||
9│ 🚩⑦
|
||||
8│
|
||||
7│ ②
|
||||
6│ ① ⑤
|
||||
5│ ③
|
||||
4│ ④
|
||||
3│
|
||||
2│
|
||||
1│
|
||||
└──────────────────────────▶ 成本（改动单元）
|
||||
5 10 15 20 25 30
|
||||
```
|
||||
|
||||
**结论**：⑥+⑦ 落在「低成本、高收益」象限（左上），⑤ 居中，②③ 在中成本区，①④ 在右下象限（不推荐）。
|
||||
|
||||
---
|
||||
|
||||
### 8.4 方法 C：ROI 测算
|
||||
|
||||
以典型高频用户（日均 30 会话，每会话 20 轮，使用 Claude Sonnet $3/M input tokens）为基准，测算派系 A 实施后的成本节省：
|
||||
|
||||
| 实施步 | 节省机制 | 单会话节省 | 月节省（30 日） | 实施改动单元 | ROI（月节省/改动） |
|
||||
|--------|---------|-----------|---------------|---------|-------------------|
|
||||
| **步 0：动态压缩阈值** | 减少误压缩 ≈ 10% 不必要的压缩 LLM 调用 | ~$0.01 | **~$9** | 0.5 | **$18/改动单元** |
|
||||
| **步 1：L3 结构化摘要** | LLM 压缩时产出 JSON 摘要，后续检索少一轮 tool call | ~$0.02 | **~$18** | 2 | **$9/改动单元** |
|
||||
| **步 2：工具命名空间** | 大 tool_result 不进主队列，输入减少 30-50% | ~$0.08 | **~$72** | 5 | **$14.4/改动单元** |
|
||||
| **步 3：工作流 DAG 注入** | 结构化信息替代重复消息，压缩效率提升 | ~$0.03 | **~$27** | 8 | **$3.4/改动单元** |
|
||||
| **步 4：WorkingContext 分层注入** | 条件注入比全量常驻省 90% L1 开销 | ~$0.01 | **~$9** | 6 | **$1.5/改动单元** |
|
||||
|
||||
**累计 ROI 曲线**：
|
||||
|
||||
```
|
||||
月节省
|
||||
$140│ 🟢 步2后爆发
|
||||
$120│ 🟢
|
||||
$100│ 🟢
|
||||
$80│ 🟢
|
||||
$60│ 🟢
|
||||
$40│ 🟢
|
||||
$20│ 🟢
|
||||
0└──────────────────────────────▶ 累计改动单元
|
||||
0.5 2.5 7.5 15.5 21.5
|
||||
```
|
||||
|
||||
**关键发现**：步 2（工具命名空间）贡献了 ~50% 的总节省。如果资源只能做一件事，做步 2。
|
||||
|
||||
---
|
||||
|
||||
### 8.5 方法 D：影响范围分析
|
||||
|
||||
对 7 个发散方向统计影响的 Rust 文件数（含新增和修改）：
|
||||
|
||||
| 发散 | 新增文件 | 修改文件 | 涉及 crate | 核心改动点 |
|
||||
|------|---------|---------|-----------|----------|
|
||||
| ①画布 | 5-7 | 8-12 | df-ai, src-tauri, df-storage | `look_at` 工具注册、画布坐标系构建、导航状态机 |
|
||||
| ②分支 | 3-4 | 6-8 | df-ai, df-storage | `ContextFork` 分支存储、`parent_id`/`fork_point`、分支索引 |
|
||||
| ③主动参与 | 2-3 | 4-6 | df-ai, src-tauri | `ScheduledMessage` 队列、冷却期管理器、模式识别 |
|
||||
| ④衰减 | 3-4 | 5-7 | df-ai, df-ai-core | `precision` 字段、衰减函数、刷新策略 |
|
||||
| ⑤元控制器 | 2-3 | 3-5 | df-ai, src-tauri | `MetaContextController` 结构体、特征窗口、参数调节器 |
|
||||
| ⑥工作流 | 3-5 | 5-8 | df-ai, df-workflow, src-tauri | 工作流 DAG 序列化、节点↔消息关联、`workflow_id` |
|
||||
| ⑦命名空间 | 2-3 | 4-6 | df-ai, src-tauri, df-storage | `NamespaceStore`、引用路径编码、`extract_key_info` 接线 |
|
||||
|
||||
**子系统热力图**：
|
||||
|
||||
```
|
||||
①画布 ②分支 ③主动 ④衰减 ⑤元控 ⑥工作流 ⑦命名空间
|
||||
df-ai-core · · · ███ · · ·
|
||||
df-ai ███ ███ ██ ██ ██ ███ ███
|
||||
df-workflow · · · · · ███ ·
|
||||
df-storage ██ ██ · · · · ██
|
||||
src-tauri ███ ██ ███ · ███ ███ ██
|
||||
前端 ██ · ██ · · ██ ·
|
||||
|
||||
███=大量改动 ██=中等 █=少量 ·=无
|
||||
```
|
||||
|
||||
**结论**：
|
||||
- ⑤（元控）的影响面最小却收益面广——这是高性价比的信号
|
||||
- ⑥+⑦ 共同覆盖 df-ai + src-tauri 重叠区——可以合并实施，共享改造成本
|
||||
- ① 涉及前端 + df-storage + df-ai + src-tauri——全栈改动，风险最大
|
||||
|
||||
---
|
||||
|
||||
### 8.6 方法 E：依赖图 & 拓扑排序
|
||||
|
||||
对派系 A 的实施步进行前置依赖分析：
|
||||
|
||||
```mermaid
|
||||
graph LR
|
||||
S0[步0: 动态压缩阈值] --> S1[步1: L3结构化摘要]
|
||||
S1 --> S2[步2: 工具命名空间]
|
||||
S2 --> S3[步3: 工作流DAG注入]
|
||||
S3 --> S4[步4: WorkingContext分层注入]
|
||||
S4 --> S5[步5: MemoryAdapter trait]
|
||||
S5 --> S6[步6: 版本化快照]
|
||||
```
|
||||
|
||||
**拓扑排序分析**：
|
||||
|
||||
| 步 | 前置依赖 | 可并行？ | 关键路径？ |
|
||||
|----|---------|---------|-----------|
|
||||
| 步 0 | 无 | ✅ 可独立上线 | 否 |
|
||||
| 步 1 | 步 0（需要压缩触发确定） | ❌ 依赖 | 否（压缩已存在，只改输出格式） |
|
||||
| 步 2 | 无 | ✅ 可与任何步并行 | **是**（收益最高） |
|
||||
| 步 3 | 步 2（命名空间为 DAG 节点提供数据源） | ⚠️ 弱依赖 | **是**（差异化核心） |
|
||||
| 步 4 | 步 1（需要结构化摘要格式经验） | ⚠️ 推荐步 1 后 | 否 |
|
||||
| 步 5 | 步 0-4（重构现有逻辑） | ❌ 必须最后 | 否 |
|
||||
| 步 6 | 步 2（命名空间需要持久化） | ⚠️ 弱依赖 | 否 |
|
||||
|
||||
**关键路径**：步 2 → 步 3 → 步 5，这是派系 A 的核心价值链。步 0 和步 1 可以在任何时间插入。
|
||||
|
||||
**并行窗口**：步 2 与步 1 完全并行（互不依赖），可分配给两个独立 AI agent 同时编码。步 3 和步 4 可以部分重叠（共享 WorkingContext 的数据结构定义，但注入逻辑不同）。
|
||||
|
||||
---
|
||||
|
||||
### 8.7 方法 F：风险矩阵
|
||||
|
||||
对 7 个发散方向评估失败概率（1-5）和失败影响（1-5），风险值 = 概率 × 影响：
|
||||
|
||||
| 发散 | 失败模式 | 概率 | 影响 | 风险值 | 缓解措施 |
|
||||
|------|---------|------|------|--------|---------|
|
||||
| ①画布 | 模型不主动使用 `look_at`，降级回传统模式 | 4 | 3 | **12** 🔴 | 需 prompt 工程 + 用户教育，不可强制 |
|
||||
| ②分支 | 分支数量失控，内存爆炸 | 3 | 4 | **12** 🔴 | 设分支上限（如 5 个），超限自动合并 |
|
||||
| ③主动参与 | 用户觉得烦，关掉整个功能 | 4 | 3 | **12** 🔴 | 冷却期+负面反馈自愈（依赖⑤） |
|
||||
| ④衰减 | 衰减函数不匹配真实 tokenizer，精度信号无意义 | 3 | 3 | **9** 🟡 | 离线对比验证衰减曲线 vs 真实 token 分布 |
|
||||
| ⑤元控制器 | 参数震荡——元控自己的参数也需要调 | 3 | 2 | **6** 🟢 | 固定多数参数，只自适应 3 个核心参数 |
|
||||
| ⑥工作流 | 自由对话无工作流关联，收益为零 | 2 | 3 | **6** 🟢 | 检测 `workflow_id`，没有则跳过 DAG 注入 |
|
||||
| ⑦命名空间 | 模型不理解引用语法，从不读取 namespace | 2 | 2 | **4** 🟢 | 透明降级：模型读引用时自动补全内容 |
|
||||
|
||||
**风险热力图**：
|
||||
|
||||
```
|
||||
影响
|
||||
5│ ·
|
||||
4│ ② ①
|
||||
3│ ③ · ④
|
||||
2│ ⑦ ⑤ ⑥
|
||||
1│ ·
|
||||
└────────────────────────▶ 概率
|
||||
1 2 3 4 5
|
||||
|
||||
🟢 低风险（⑤⑥⑦）🟡 中风险（④）🔴 高风险（①②③）
|
||||
```
|
||||
|
||||
**重要发现**：
|
||||
- 派系 A 的 ⑥+⑦+⑤ 全部落在 🟢 低风险区域
|
||||
- 派系 B 的 ② 落在 🔴 高风险区域（分支爆炸）
|
||||
- 派系 C 的 ①③ 都落在 🔴 高风险区域（模型不配合 + 用户反感）
|
||||
- 风险分布与决策矩阵的得分分布高度一致——交叉验证通过 ✅
|
||||
|
||||
---
|
||||
|
||||
### 8.8 方法 G：根本原因回溯
|
||||
|
||||
从 DevFlow 中已确认的上下文管理痛点出发，看每个发散方向是否直接对症：
|
||||
|
||||
| 痛点 | 严重度 | 根因 | 对症的发散 | 不对症的发散 |
|
||||
|------|--------|------|-----------|-------------|
|
||||
| **P1: tool_result 膨胀撑爆窗口** | 🔴 P0 | `read_file` 等工具返回大量文本全部挤入主队列 | **⑦**命名空间（直接消除）| ①画布 ②分支 ③主动 ④衰减 ⑤元控 ⑥工作流 |
|
||||
| **P2: 压缩后目标丢失** | 🔴 P0 | `compressed` 消息不进 LLM，目标信息消失 | **⑥**工作流DAG保留结构化产出 | ①画布 ②分支 ③主动 ④衰减 ⑤元控 ⑦命名空间 |
|
||||
| **P3: 中断恢复模糊** | 🟡 P1 | `build_for_request` 只恢复窗口内消息，不恢复会话状态 | **⑥+⑦**（DAG+namespace 双重恢复） | ①画布 ②分支 ③主动 ④衰减 |
|
||||
| **P4: 触发时机不当** | 🟡 P1 | 压缩阈值硬编码，不考 system prompt 大小 | **⑤**元控制器（动态调参）| ①画布 ②分支 ③主动 ④衰减 ⑥ ⑦ |
|
||||
| **P5: 多方案对比困难** | 🟢 P2 | 线性历史无法表达多方案岔路，需切换分支 | **②**分支（直接解决） | ①画布 ③主动 ④衰减 ⑤元控 ⑥ ⑦ |
|
||||
|
||||
**覆盖度统计**：
|
||||
|
||||
| 发散方向 | 覆盖痛点数 | 覆盖的痛点 | 错过的痛点 |
|
||||
|---------|-----------|-----------|-----------|
|
||||
| ⑥工作流 | 2（P2, P3） | 目标丢失、中断恢复 | P1 tool膨胀、P4触发时机、P5多方案 |
|
||||
| ⑦命名空间 | 2（P1, P3） | tool膨胀、中断恢复 | P2目标丢失、P4触发时机、P5多方案 |
|
||||
| ⑤元控制器 | 1（P4） | 触发时机 | 其他 4 个 |
|
||||
| ②分支 | 1（P5） | 多方案对比 | 其他 4 个 |
|
||||
| ①画布 | 0 | — | 全部 5 个 |
|
||||
| ③主动参与 | 0 | — | 全部 5 个 |
|
||||
| ④时间轴衰减 | 0 | — | 全部 5 个 |
|
||||
|
||||
**结论**：⑥+⑦ 覆盖了 P0 和 P1 级的 3 个痛点（P1, P2, P3），合计覆盖 3/5 = 60% 的已知痛点。加上⑤覆盖 P4 后达到 4/5 = 80%。②覆盖 P5 后达到 100%。路径清晰：⑥+⑦ → +⑤ → +②。
|
||||
|
||||
---
|
||||
|
||||
### 8.9 方法 H：帕累托分析
|
||||
|
||||
对派系 A 的各实施步，计算累计收益占总收益的百分比：
|
||||
|
||||
| 实施步 | 累计改动单元 | 月节省 | 累计节省 | 累计节省占比 | 累计改动单元占比 |
|
||||
|--------|---------|--------|---------|------------|------------|
|
||||
| 步 0：动态阈值 | 0.5 | $9 | $9 | 6.7% | 2.3% |
|
||||
| 步 1：结构化摘要 | 2.5 | $18 | $27 | 20.0% | 11.6% |
|
||||
| **步 2：工具命名空间** | 7.5 | $72 | $99 | **73.3%** 🔥 | 34.9% |
|
||||
| 步 3：工作流 DAG | 15.5 | $27 | $126 | 93.3% | 72.1% |
|
||||
| 步 4：WorkingContext | 21.5 | $9 | $135 | 100% | 100% |
|
||||
|
||||
```
|
||||
累计节省占比
|
||||
100%│ ●
|
||||
75%│ ● ← 步2: 20%努力→73%收益
|
||||
50%│
|
||||
25│ ●
|
||||
0%│──●────●───────────────────────────▶ 累计改动单元占比
|
||||
0% 2.3% 11.6% 34.9% 72.1%
|
||||
```
|
||||
|
||||
**帕累托结论**：步 0-2（前 35% 努力）贡献 73% 收益。步 2（工具命名空间）是唯一的"低挂果实"——5 改动单元工作量，月节省 $72，占全部收益的 53%。**建议立即启动步 2，步 3-4 视资源情况决策。**
|
||||
|
||||
---
|
||||
|
||||
### 8.10 方法 I：Kano 模型
|
||||
|
||||
从用户感知角度将 7 个发散方向分类：
|
||||
|
||||
| 发散方向 | Kano 分类 | 判断依据 |
|
||||
|---------|----------|---------|
|
||||
| ⑤元控制器 | **基本型** | 用户不直接感知，但参数不当会导致对话中断（负面体验） |
|
||||
| ⑦工具命名空间 | **基本型 → 性能型** | 当前 tool 膨胀可接受但痛苦（Sprint 6 P1），改善后用户不说但感觉流畅 |
|
||||
| ⑥工作流即上下文 | **性能型** | 用户使用工作流时体验飞跃，自由对话时完全无感 |
|
||||
| ②上下文分支 | **性能型** | 多方案探索用户明显受益，单线用户不关心 |
|
||||
| ④时间轴衰减 | **无差异型** | 精度衰减在对话中无法被用户察觉（除非看日志） |
|
||||
| ①画布导航 | **魅力型** | 高级用户会惊叹"AI 自己知道要看哪里"，但普通用户不敏感 |
|
||||
| ③主动参与 | **魅力型 → 反向型** | 做得好是惊喜，做不好是骚扰。双刃剑 |
|
||||
|
||||
**Kano 对实施顺序的指导**：
|
||||
|
||||
```mermaid
|
||||
graph LR
|
||||
subgraph "先做（基本型→性能型）"
|
||||
A["⑤元控制器<br>（基本型，不做会出问题）"]
|
||||
B["⑦工具命名空间<br>（性能型，做了用户觉得流畅）"]
|
||||
end
|
||||
subgraph "再做（性能型）"
|
||||
C["⑥工作流即上下文<br>（差异化竞争力）"]
|
||||
D["②分支<br>（特定场景加分）"]
|
||||
end
|
||||
subgraph "可选"
|
||||
E["①画布<br>（魅力型，成本高）"]
|
||||
F["③主动参与<br>（双刃剑，需谨慎）"]
|
||||
G["④衰减<br>（无差异，不做）"]
|
||||
end
|
||||
|
||||
A --> B
|
||||
B --> C
|
||||
C --> D
|
||||
```
|
||||
|
||||
**结论**：Kano 模型给出的优先级顺序与决策矩阵、ROI、帕累托的分析高度一致——⑤→⑦→⑥→②→①③可选→④跳过。这是第 9 种独立方法得出同一结论，信心再度增强。
|
||||
|
||||
---
|
||||
|
||||
## 九、论证收敛总表
|
||||
|
||||
### 9.1 各方法结论汇合
|
||||
|
||||
| 方法 | 收敛结论 | 与主线是否一致 |
|
||||
|------|---------|--------------|
|
||||
| 推演法（第 4-6 章） | 派系 A > B > C，⑥+⑦ 为最优起点 | —（主线基准） |
|
||||
| **A 决策矩阵** | 派系 A 108 > B 61 > C 44 | ✅ 一致 |
|
||||
| **B 成本收益散点** | ⑥+⑦ 在低成本高收益象限 | ✅ 一致 |
|
||||
| **C ROI 测算** | 步 2 月节省 $72，5 改动单元回收 | ✅ 一致 |
|
||||
| **D 影响范围** | ⑥+⑦ 影响面可控，集中在 df-ai | ✅ 一致 |
|
||||
| **E 拓扑排序** | 步 2 和步 1 可并行，关键路径清晰 | ✅ 一致 |
|
||||
| **F 风险矩阵** | ⑥+⑦+⑤ 全 🟢，①②③ 全 🔴 | ✅ 一致 |
|
||||
| **G 根本原因回溯** | ⑥+⑦ 覆盖 3/5 痛点，② 补 1 个 | ✅ 一致 |
|
||||
| **H 帕累托分析** | 35% 努力得 73% 收益，步 2 为低挂果实 | ✅ 一致 |
|
||||
| **I Kano 模型** | ⑤基本→⑦性能→⑥性能→②性能 | ✅ 一致 |
|
||||
|
||||
**9 种独立方法结论全部收敛，无分歧。** 这是强信号。
|
||||
|
||||
### 9.2 最终建议
|
||||
|
||||
```
|
||||
立即启动（步 0 + 步 2）:
|
||||
动态压缩阈值（3 行） + 工具命名空间（5 改动单元）
|
||||
→ 消除 tool 膨胀主因，月省 $81
|
||||
|
||||
Phase 4 追加（步 1 + 步 3）:
|
||||
L3 结构化摘要（2 改动单元） + 工作流 DAG 注入（8 改动单元）
|
||||
→ 差异化竞争力，累计月省 $135
|
||||
|
||||
Phase 5 完善（步 4 + 步 5 + 步 6）:
|
||||
WorkingContext 分层注入 + MemoryAdapter trait + 版本化快照
|
||||
→ 架构完善，累计月省 $135+
|
||||
|
||||
不做:
|
||||
画布导航（①）、时间轴衰减（④）—— 收益成本比低
|
||||
主动参与（③）、分支（②）—— Kano 双刃剑，待用户需求信号出现后再评估
|
||||
|
||||
预留接口:
|
||||
ContextNavigation / ContextFork / ProactiveHint / PrecisionDecay
|
||||
→ 4 个 trait，仅定义不实现（实现零行）
|
||||
```
|
||||
Reference in New Issue
Block a user