并行后台 Agent 与上下文策略

并行后台 Agent 与上下文策略

学习目标

• 理解后台 Agent 的独立 session 与主 session 隔离
• 掌握结果消费模式和 tmux 可视化
• 识别并发 Agent 编辑冲突陷阱

前置知识

本章涉及上下文管理和流式传输的通用原理，建议先阅读：

• 上下文压缩与 Token 优化
• 流式传输架构

下文假设你已理解上下文管理和流式传输概念，直接聚焦 Oh-My-OpenAgent 的具体实现。

项目实践

后台 Agent 架构

Oh-My-OpenAgent 允许在后台运行多个 Agent，每个 Agent 有独立的 session：

主 Session (Sisyphus)
    ├── 后台 Agent 1 (Explore): 搜索认证模式
    ├── 后台 Agent 2 (Oracle): 架构咨询
    ├── 后台 Agent 3 (Librarian): 查找 OSS 示例
    └── 后台 Agent N (Hephaestus): 实现功能

关键设计：

• 每个后台 Agent 有独立的 session ID 和消息历史
• 主 session 不携带后台 Agent 的上下文，保持精简
• 结果通过通知机制返回主 session

调用模式

// 启动后台 Agent
task(
  subagent_type="explore",
  load_skills=[],
  prompt="查找项目中的所有认证实现",
  run_in_background=true
)

// 继续主流程工作...

// 结果通过系统通知返回
// [SYSTEM: background task bg_abc123 completed]

// 按需获取结果
background_output(task_id="bg_abc123")

tmux 可视化

启用 tmux 集成后，每个后台 Agent 在独立 pane 中运行：

{
  "tmux": {
    "enabled": true,
    "layout": "main-vertical"
  }
}

功能：

• 每个 Agent 一个 pane，实时输出流
• 主 pane + Agent pane 的网格布局
• Agent 完成后自动清理 pane
• 固定核心 Agent 排序：Sisyphus → Hephaestus → Prometheus → Atlas

后台通知管理

位于 src/features/background-notification/，负责：

• 后台任务完成时向主 session 发送通知
• 通知内容包括任务 ID、状态、简要结果
• 避免通知风暴：多个任务同时完成时合并通知

问题与规避

并发编辑冲突

问题：多个后台 Agent 同时编辑同一文件时产生冲突。

规避：

• 在 Team Mode 中使用 git worktree 隔离
• 非 Team Mode 下依赖 Agent 间的协调（较弱）
• 使用 Hashline 协议检测冲突（哈希不匹配即拒绝）

上下文泄漏

问题：后台 Agent 的上下文意外泄漏到主 session，导致 token 浪费。

规避：

• 严格 session 隔离：后台 Agent 的 session 与主 session 独立管理
• 结果聚合：只返回最终结果，不返回中间上下文

后台 Agent 挂起

问题：后台 Agent 因模型 API 错误或用户拒绝权限而挂起。

规避：

• 超时机制：后台任务超过设定时间自动终止
• 错误通知：挂起时向主 session 发送错误通知

设计取舍

独立 Session vs 共享上下文

方案	优势	代价
独立 Session	上下文隔离、不膨胀主 session	Agent 间共享信息需要通过消息传递
共享上下文	Agent 间信息传递直接	主 session 上下文膨胀、token 浪费

Oh-My-OpenAgent 的选择：独立 Session，通过 team_send_message 或通知机制传递结果。上下文膨胀的成本远高于消息传递的延迟。

参考来源

• Oh-My-OpenAgent Features 文档