cfdaily
346 lines
16 KiB
Markdown
346 lines
16 KiB
Markdown
# 多层级任务组织最佳实践调研报告
|
||
|
||
> 调研日期：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/
|