sanguo_moziplus_v2/docs/research/task_hierarchy_research.md

多层级任务组织最佳实践调研报告

调研日期：2026-05-17 调研目的：为 moziplus v2 三级任务层次（Project / Card(Epic) / Task）设计提供业界参考 调研范围：项目管理工具、AI Agent 编排系统、黑板架构、数据库模型

---

一、项目管理工具的层级组织

1.1 Jira 的层级模型

层级结构：

Project → Epic → Story/Bug/Task → Sub-task

Jira 支持自定义层级扩展（Premium/Enterprise），标准配置为 3-4 层。Jira 8+ 允许在 Epic 上方增加 Initiative、Theme 等层级。

数据库设计要点：

• 单表 + project_id 过滤：Jira 的核心表是 jiraissue，所有 issue 类型（Epic/Story/Task/Sub-task）存储在同一张表，通过 issuetype 字段区分
• 层级通过 parent_id + topmost_issue_id 实现：每个 issue 有 parent_id 指向上级，topmost_issue_id 指向层级树的根节点
• Project 是隔离边界：Project 持有独立的 workflow、permission scheme、notification scheme 配置，但数据物理上共享表
• 多租户隔离策略：小租户用共享 schema（加 tenant_id），大企业客户可提供独立 schema 或独立数据库实例

关键洞察：

Jira 选择"单表存所有 issue + 类型字段区分 + project_id 隔离"的模型。这说明在项目管理领域，灵活的类型系统比物理隔离更重要。Project 是逻辑隔离边界，不是物理隔离边界。

1.2 Linear 的层级模型

层级结构：

Workspace → Team → Project → Issue（可设 parent issue）

Linear 更扁平，没有原生的 Epic 概念，而是通过"Project"（时间框定的倡议）+ Issue 的 parent/child 关系来实现层级。

数据库设计要点：

• Workspace 级共享数据库：一个 Workspace 对应一个数据库实例（或共享实例+行级隔离）
• Team 是主要的分组单元：每个 Team 有自己的 Issue 列表视图
• Project 是跨 Team 的聚合：一个 Project 可以包含多个 Team 的 Issue
• UUID + organization_id 行级隔离：类似 SaaS 标准做法

1.3 Asana 的层级模型

层级结构：

Workspace/Organization → Project → Section → Task → Subtask

Asana 支持多项目（Portfolio/Program）聚合，Section 作为 Task 的分组。

数据库设计要点：

• 共享数据库 + 行级隔离：所有 workspace 共享同一个数据库，通过 workspace_id 过滤
• Task 是核心实体：Project、Section 都是 Task 的"容器标签"，而非独立实体
• 多对多关系：一个 Task 可以属于多个 Project（通过 project_membership 关联表）

1.4 小结：项目管理工具的共同模式

工具	层级数	DB 隔离边界	类型区分方式
Jira	3-7 层（可扩展）	Project（逻辑隔离）	单表 + issuetype 字段
Linear	3-4 层	Workspace	单表 + parent 关系
Asana	4-5 层	Workspace	单表 + 容器标签

核心结论：项目管理工具几乎都采用"单表存所有任务 + 类型/层级字段区分 + 逻辑隔离"的模型，而非物理隔离。

---

二、AI Agent 编排系统的多层级任务组织

2.1 LangGraph

层级组织方式：

• Graph → Subgraph → Node：LangGraph 通过嵌套的 StateGraph 实现层级
• State 是核心：每个 Graph 有自己的 State schema，Subgraph 可以有独立的 State
• State 传递机制：
  • 父 Graph 的 State 可以通过 state_schema 映射传递给 Subgraph
  • Subgraph 执行完毕后，State 可以回传给父 Graph
  • 使用 thread_id 实现持久化，同一 thread_id 下的 State 共享持久化存储

共享上下文 vs 隔离：

• 默认行为：Subgraph 的 State 是隔离的，需要显式映射才能与父 Graph 共享
• 共享策略：通过 State 的 key 映射（state_key_mapping）实现有限共享
• 持久化：通过 Checkpointer（MemorySaver / SqliteSaver）实现 State 持久化，thread_id 是隔离边界

关键模式：

ParentGraph (全局 State)
  ├── Subgraph A (局部 State，映射父 State 的部分 key)
  ├── Subgraph B (独立的局部 State)
  └── Subgraph C (与 A 共享部分 State key)

2.2 CrewAI

层级组织方式：

• Crew → Agent → Task：Crew 是编排单元，包含多个 Agent 和 Task
• 共享内存：Crew 内的 Agent 共享一个 Memory 系统（支持 Short-term、Long-term、Entity Memory）
• 内置 SQLite 持久化：Crew 的执行状态和 Memory 可以持久化到 SQLite

共享上下文 vs 隔离：

• Crew 级别共享：同一 Crew 内的 Agent 默认共享上下文
• 跨 Crew 隔离：不同 Crew 的 Memory 默认隔离
• RAG 增强：支持向量检索来管理大规模上下文，避免全量加载

2.3 AutoGen

层级组织方式：

• Conversation → Agent Group → Agent：以对话为核心，Agent 组通过多轮对话协作
• 多对话模式：支持 two-agent chat、group chat、nested chat（层级嵌套）
• Context 传递：通过消息列表（chat history）传递上下文

共享上下文 vs 隔离：

• Group Chat 共享：同一 Group Chat 内的所有 Agent 共享完整的对话历史
• Nested Chat 隔离：嵌套对话有独立的消息历史，可通过闭包传递摘要结果
• 自定义 State：支持通过 ConversableAgent 的 context_variables 传递结构化状态

2.4 OpenAI Swarm / Agents SDK

层级组织方式：

• Agent → Handoff → Agent：极简模型，Agent 之间通过 Handoff 传递控制权
• Context Variables：通过共享的字典传递上下文
• 无显式层级：没有 Project/Task 概念，是扁平的 Agent 网络

关键洞察：

OpenAI Swarm 的哲学是"最小抽象"——不引入层级概念，让开发者在代码层面自行组织。这适合简单场景，但在复杂工作流中缺乏结构化管理。

2.5 小结：AI Agent 编排系统的模式对比

系统	层级机制	共享上下文方式	隔离边界	持久化
LangGraph	Graph/Subgraph 嵌套	State key 映射	thread_id	Checkpointer
CrewAI	Crew/Agent/Task	共享 Memory	Crew 边界	SQLite
AutoGen	Nested Chat	对话历史	Chat 边界	自定义
OpenAI Swarm	扁平	Context Variables	无显式边界	无

核心结论：AI Agent 编排系统的"共享 vs 隔离"权衡通常是"子任务隔离 + 结果摘要回传"。LangGraph 的 Subgraph 模式最接近我们的 Card/Epic 概念——每个 Subgraph 有自己的 State（类似黑板），执行完毕后通过 State 映射将关键结果传回父 Graph。

---

三、黑板系统（Blackboard Architecture）的上下文管理

3.1 经典黑板架构回顾

黑板架构的核心组成：

• Blackboard（黑板）：共享的数据空间，存储问题求解的中间状态
• Knowledge Sources（知识源）：独立的处理模块，观察黑板并响应变化
• Controller（控制器）：决定哪个知识源在何时执行

3.2 大规模场景下的挑战：上下文膨胀

黑板系统在大规模场景下面临的核心问题：

1. 数据增长：随着任务执行，黑板上的数据持续累积
2. 相关性衰减：早期数据对当前决策的相关性逐渐降低
3. 检索效率：大量数据导致查找变慢
4. 上下文窗口限制：LLM 的上下文窗口有限，不能无限加载

3.3 业界解决方案

方案一：分层黑板（Hierarchical Blackboard）

将黑板分为多个层级，每层有不同的数据保留策略：

• L0 热层（Working Memory）：当前活跃任务的数据，完整保留，常驻内存
• L1 温层（Context Buffer）：近期完成的任务结果，保留摘要+关键指标
• L2 冷层（Archive）：历史数据，仅保留元数据+索引，需要时通过向量检索召回

方案二：Context Folding（上下文折叠）

来自 ByteDance 2025 年的研究：

• Agent 执行子任务时进入独立的子轨迹（sub-trajectory）
• 子任务完成后，将中间步骤"折叠"为简洁的摘要
• 只保留最终结果和关键决策点，丢弃中间过程

这与我们的 Card 概念高度契合：Card 完成后，将整个黑板的详细数据折叠为摘要，只保留对上层有用的结论。

方案三：Hot/Cold Memory 分离

来自学术论文 "Codified Context"（2026）的实践：

• Hot Memory：始终加载的约定和规则（类似 system prompt），体积小但高频访问
• Cold Memory：按需加载的规范和文档，通过触发表（trigger table）自动路由
• 触发表：定义什么条件下加载什么冷数据，避免全量加载

方案四：摘要 + 向量检索

业界最常用的上下文管理策略：

• 历史对话嵌入向量存储
• 处理新查询时，通过语义检索召回相关历史
• 保留最近 5-7 轮完整上下文，更早的只保留摘要
• 合并相似度 > 0.95 的重复记忆

归档策略推荐

数据类型	热保留期	归档方式	召回方式
活跃任务数据	任务执行期间	完成后折叠	直接访问
任务结果摘要	Card 生命周期内	Card 完成后归档	向量检索
决策记录	Project 生命周期内	Project 结束后归档	元数据索引
执行日志	7 天	压缩存储	按需加载

---

四、Notion / Linear 的数据库模型

4.1 Notion 的数据模型

核心概念：

• Page：原子内容单元，可以是独立页面或数据库的一行
• Database（Data Source）：结构化的 Page 集合，有自己的 schema（属性定义）
• Relation：数据库之间的关联关系
• Linked Database View：一个数据库在另一个位置的过滤视图

一个项目一个 DB vs 一个大 DB？

Notion 社区的争论和实践表明：

方案	优点	缺点
一个大 DB + 过滤	统一 schema，跨项目视图，维护简单	属性膨胀（不同类型任务属性不同），过滤复杂
多个 DB（按类型分）	每个 DB 有专用 schema，更整洁	跨 DB 查询困难，rollup 受限（只支持一层）
混合方案	任务用一个大 DB，项目/目标用独立 DB	需要维护 Relation 关系

Notion 2025 的改进——Multiple Data Sources：

• 一个视图可以合并多个 Data Source
• 每个 Data Source 可以有独立的 schema
• 在视图层面进行统一展示和过滤

这启示我们：多类型实体可以用独立的 DB，通过关联关系连接，在视图层统一展示。

4.2 Linear 的数据模型

核心概念：

• Workspace → Team → Project → Issue
• 所有 Issue 存储在同一数据集中，通过 team_id 和 project_id 过滤
• Project 可以跨 Team，是"倡议"级别的聚合

Linear 的设计哲学：

• 一个巨大的表：所有 Issue 共享同一 schema
• 自定义字段：通过 Custom Fields 扩展属性，而非不同的表
• Cycle/Project 作为视图：不是数据隔离，而是数据视图

4.3 数据库模型选型建议

场景	推荐模型
实体类型统一，属性差异小	单表 + 类型字段 + 过滤
实体类型差异大，属性结构不同	多表 + 关联关系
需要跨类型聚合查询	视图/物化视图层统一

---

五、最佳实践总结

5.1 什么粒度最适合做 DB 隔离边界？

核心原则：隔离边界应该在"需要独立生命周期管理"的粒度上。

层级	是否适合做 DB 隔离	理由
Project	❌ 不适合	数量少，生命周期长，需要跨项目查询和聚合
Card/Epic	✅ 最适合	数量适中，有明确的开始/结束，需要独立的上下文空间
Task	❌ 不适合	数量大，生命周期短，频繁创建/完成，独立 DB 管理成本过高

推荐方案：Card/Epic 级别的逻辑隔离（共享数据库实例 + Card 级别的数据分区/命名空间）

具体实现：

• 所有 Card 共享一个数据库实例
• 每个 Card 有独立的黑板命名空间（如 blackboard:{card_id}:*）
• Card 完成后，其黑板数据归档（折叠为摘要），释放存储空间
• Project 级别维护一个聚合黑板，存储所有 Card 的摘要结果

5.2 黑板（共享上下文）的隔离策略

Project（全局聚合黑板）
  ├── Card A（独立黑板空间）
  │     ├── Task A1 的产出
  │     ├── Task A2 的产出
  │     └── Card A 摘要（完成后回传给 Project）
  ├── Card B（独立黑板空间）
  │     ├── Task B1 的产出
  │     └── Card B 摘要
  └── Project 聚合结果

关键规则：

1. Card 间默认隔离：不同 Card 的黑板空间不互相访问
2. 结果向上流动：Card 完成后，摘要结果写入 Project 级黑板
3. 依赖显式声明：Card B 需要 Card A 的结果时，在定义中声明依赖，系统自动注入摘要
4. 禁止向下传递全部数据：Task 只能看到自己 Card 的黑板，不会加载整个 Project 的数据

5.3 归档策略设计

阶段一：任务执行中
  → 黑板数据全量保留在热层
  → 每个 Task 完成后产出写入黑板

阶段二：Card 完成
  → 黑板数据"折叠"：中间步骤摘要化
  → 保留：最终结果、关键决策、错误记录
  → 归档：原始日志、中间计算过程
  → 摘要写入 Project 级黑板

阶段三：Project 完成
  → 所有 Card 摘要聚合为 Project 报告
  → 全部黑板数据归档到冷存储
  → 保留可搜索的元数据索引

5.4 对 moziplus v2 的具体建议

1. 数据库模型：采用"单实例 + Card 级命名空间"方案

   • 所有任务共享一个数据库实例（SQLite 或 PostgreSQL）
   • 每张表通过 card_id 字段区分归属
   • 黑板数据使用 blackboard_entries 表，key 为 {card_id}:{entry_key}

2. Task 类型：使用"单表 + 类型字段"方案

   • tasks 表存储所有 Task，type 字段区分类型
   • 不按 Task 类型分表，保持查询灵活性

3. Card 级隔离：

   • 每个 Card 的黑板空间独立
   • Card 间通过"依赖声明 + 摘要注入"传递上下文
   • Card 完成时触发归档流程

4. 上下文管理：

   • 热层：活跃 Card 的完整黑板数据
   • 温层：已完成 Card 的摘要数据（保留 7-30 天）
   • 冷层：归档数据，通过向量检索按需召回

---

六、参考资料

1. Jira Issue Hierarchy - Atlassian Community: https://community.atlassian.com/forums/Jira-questions/
2. Jira Database Schema - Atlassian Developer: https://developer.atlassian.com/server/jira/platform/database-schema/
3. Multi-Tenant Database Architecture Patterns - Bytebase: https://www.bytebase.com/blog/multi-tenant-database-architecture-patterns-explained/
4. LangGraph Subgraphs Documentation: https://docs.langchain.com/oss/python/langgraph/use-subgraphs
5. CrewAI Memory Documentation: https://docs.crewai.com/en/concepts/memory
6. Context Folding (ByteDance, Oct 2025): https://medium.com/@najeebkan/context-management-for-ai-agents-d68716a37965
7. Codified Context - Hot/Cold Memory Separation (2026): https://arxiv.org/html/2602.20478v1
8. Azure AI Agent Design Patterns: https://learn.microsoft.com/en-us/azure/architecture/ai-ml/guide/ai-agent-design-patterns
9. Notion Data Sources (2025): https://www.notionapps.com/blog/notion-data-sources-update-2025
10. Agent Memory & State Management: https://www.techaheadcorp.com/blog/agent-memory-state/