Coordinator 编排与架构

Worker 编排系统、远程 Daemon 架构、完整数据流、KAIROS vs OpenClaw 对比、未来展望。

7. Coordinator Mode——Worker 编排系统

Coordinator Mode 是 KAIROS 体系中最复杂的子系统之一。它将 Claude 从一个「独立执行者」转变为一个「项目经理」——不直接写代码，而是编排多个 Worker 并行完成任务，然后综合它们的成果。这是对 AI 编程助手「能力上限」的一次根本性提升。

与 Agent Teams/Swarms 的区别

激活方式

// coordinatorMode.ts
export function isCoordinatorMode(): boolean {
  if (feature('COORDINATOR_MODE')) {
    return isEnvTruthy(process.env.CLAUDE_CODE_COORDINATOR_MODE)
  }
  return false
}

Coordinator Mode 的激活需要两个条件同时满足：构建时 feature('COORDINATOR_MODE') 为 true，运行时 CLAUDE_CODE_COORDINATOR_MODE=1 环境变量被设置。

Session Mode 持久化

Coordinator Mode 的状态会被持久化到 session storage 中。当用户通过 --resume 恢复一个在 Coordinator Mode 下创建的会话时，系统会自动检测并重新激活 Coordinator Mode：

export function matchSessionMode(
  sessionMode: 'coordinator' | 'normal' | undefined,
): string | undefined {
  if (!sessionMode) return undefined;

  const currentIsCoordinator = isCoordinatorMode();
  const sessionIsCoordinator = sessionMode === 'coordinator';

  if (currentIsCoordinator === sessionIsCoordinator) return undefined;

  // 翻转环境变量，让 isCoordinatorMode() 返回正确的值
  if (sessionIsCoordinator) {
    process.env.CLAUDE_CODE_COORDINATOR_MODE = '1';
  } else {
    delete process.env.CLAUDE_CODE_COORDINATOR_MODE;
  }

  return sessionIsCoordinator
    ? 'Entered coordinator mode to match resumed session.'
    : 'Exited coordinator mode to match resumed session.';
}

超长系统提示的核心内容

Coordinator Mode 有一个极其详细的系统提示（从 getCoordinatorSystemPrompt() 生成），它定义了 Coordinator 的完整行为规范。以下是它的核心章节拆解。

You are a coordinator. Your job is to:
- Help the user achieve their goal
- Direct workers to research, implement and verify code changes
- Synthesize results and communicate with the user
- Answer questions directly when possible — don't delegate work
  that you can handle without tools

// Anti-pattern — lazy delegation (bad whether continuing or spawning)
Agent({ prompt: "Based on your findings, fix the auth bug", ... })
Agent({ prompt: "The worker found an issue in the auth module.
                  Please fix it.", ... })

// Good — synthesized spec (works with either continue or spawn)
Agent({ prompt: "Fix the null pointer in src/auth/validate.ts:42.
  The user field on Session (src/auth/types.ts:15) is undefined
  when sessions expire but the token remains cached. Add a null
  check before user.id access — if null, return 401 with
  'Session expired'. Commit and report the hash.", ... })

Worker 的工具访问权限

Worker 的工具集由 ASYNC_AGENT_ALLOWED_TOOLS 常量定义：

// src/constants/tools.ts
export const ASYNC_AGENT_ALLOWED_TOOLS = new Set([
  FILE_READ_TOOL_NAME,      // Read — 读取文件
  WEB_SEARCH_TOOL_NAME,     // WebSearch — 搜索网页
  TODO_WRITE_TOOL_NAME,     // TodoWrite — 写入待办
  GREP_TOOL_NAME,           // Grep — 内容搜索
  WEB_FETCH_TOOL_NAME,      // WebFetch — 抓取网页
  GLOB_TOOL_NAME,           // Glob — 文件模式匹配
  ...SHELL_TOOL_NAMES,      // Bash, PowerShell — Shell 执行
  FILE_EDIT_TOOL_NAME,      // Edit — 编辑文件
  FILE_WRITE_TOOL_NAME,     // Write — 写入文件
  NOTEBOOK_EDIT_TOOL_NAME,  // NotebookEdit — Jupyter 编辑
  SKILL_TOOL_NAME,          // Skill — 调用技能
  SYNTHETIC_OUTPUT_TOOL_NAME, // SyntheticOutput — 合成输出
  TOOL_SEARCH_TOOL_NAME,    // ToolSearch — 搜索工具
  ENTER_WORKTREE_TOOL_NAME, // EnterWorktree — 进入 Git worktree
  EXIT_WORKTREE_TOOL_NAME,  // ExitWorktree — 退出 Git worktree
])

Worker 被禁止的工具及原因

但 in-process teammates（非通过 Coordinator Mode 创建的，而是通过 KAIROS Team 初始化的）有额外的工具权限：

export const IN_PROCESS_TEAMMATE_ALLOWED_TOOLS = new Set([
  TASK_CREATE_TOOL_NAME,    // TaskCreate
  TASK_GET_TOOL_NAME,       // TaskGet
  TASK_LIST_TOOL_NAME,      // TaskList
  TASK_UPDATE_TOOL_NAME,    // TaskUpdate
  SEND_MESSAGE_TOOL_NAME,   // SendMessage
  // + Cron 工具（如果 AGENT_TRIGGERS flag 启用）
  CRON_CREATE_TOOL_NAME,
  CRON_DELETE_TOOL_NAME,
  CRON_LIST_TOOL_NAME,
])

Scratchpad 跨 Worker 知识共享

Worker 之间不能直接通信，但它们需要某种方式共享信息。Scratchpad 是解决方案——一个所有 Worker 都可以读写的共享目录，不需要权限提示。它的启用受 tengu_scratch GrowthBook gate 控制。

if (scratchpadDir && isScratchpadGateEnabled()) {
  content += `\n\nScratchpad directory: ${scratchpadDir}
Workers can read and write here without permission prompts.
Use this for durable cross-worker knowledge — structure files
however fits the work.`
}

task-notification XML 格式

Worker 完成时的通知以 XML 格式注入到 Coordinator 的对话上下文中：

<task-notification>
  <task-id>{agentId}</task-id>
  <status>completed|failed|killed</status>
  <summary>{human-readable status summary}</summary>
  <result>{agent's final text response}</result>        <!-- 可选 -->
  <usage>                                                 <!-- 可选 -->
    <total_tokens>N</total_tokens>
    <tool_uses>N</tool_uses>
    <duration_ms>N</duration_ms>
  </usage>
</task-notification>

关键设计：task-notification 作为 user-role 消息注入——它看起来像用户消息，但不是。Coordinator 通过 <task-notification> 开头标签来区分它和真正的用户输入。

Worker 权限决策链

Worker 的权限模型遵循与普通模式相同的三层决策链：先检查 Hooks（如果有自定义规则），再检查 Classifier（自动分类器），最后在需要时请求用户交互式审批。在 KAIROS Daemon 模式下，交互式审批通过 Bridge 远程桥接到用户的 viewer 客户端。

8. Auto Dream——让 AI 做梦

Auto Dream 是 KAIROS 体系中最诗意的设计。它的灵感来自人类的睡眠记忆整合——在白天积累了大量零散信息后，大脑在夜间通过 REM 睡眠将这些信息整合、归类、存储为长期记忆。Auto Dream 让 Claude 做同样的事。

为什么需要「做梦」

KAIROS 模式下的 Claude 会在长时间运行中积累大量会话上下文。每个会话的 transcript 都包含了工具调用、文件读写、用户对话等海量信息。随着时间推移，这些信息呈指数级膨胀——但 Claude 的上下文窗口是有限的。

传统的解决方案是 Context Compact（上下文压缩）——在上下文接近窗口上限时，通过摘要压缩来释放空间。但 Context Compact 是被动的、即时的——它在压力下丢弃信息。

Auto Dream 是主动的、定期的——它在没有紧迫压力时，从容地审视所有近期会话，将有价值的信息提炼并存入持久记忆。

触发门控（成本优先排序）

Auto Dream 的触发经过三层门控，按成本从低到高排序（cheapest first）：

// Gate order (cheapest first):
//   1. Time: hours since lastConsolidatedAt >= minHours (one stat read)
//   2. Sessions: transcript count with mtime > lastConsolidatedAt >= minSessions
//   3. Lock: no other process mid-consolidation

还有一个扫描节流机制：当时间门控通过但会话门控未通过时，锁的 mtime 不会更新，导致时间门控在每个 turn 都通过。为了避免频繁扫描，有一个 10 分钟的 SESSION_SCAN_INTERVAL_MS 节流。

整合流程（四阶段）

Auto Dream 的整合工作由一个 forked subagent 执行，遵循以下四阶段流程（定义于 consolidationPrompt.ts）：

- ls 记忆目录，查看现有内容
- 读取入口文件（entrypoint），理解当前索引
- 浏览现有主题文件，避免创建重复
- 如果存在 logs/ 或 sessions/ 子目录（assistant 模式布局），
  审查近期条目

按优先级排序的信息来源：
1. Daily logs（logs/YYYY/MM/YYYY-MM-DD.md）— 追加流
2. 已漂移的现有记忆 — 与代码库现状矛盾的旧事实
3. Transcript 搜索 — 用 grep 窄范围搜索 JSONL 文件

关键原则：不要穷举读取 transcripts。只搜索你已经怀疑重要的东西。

对每个值得记住的事项，写入或更新记忆目录顶层的记忆文件。
聚焦于：
- 将新信号合并到现有主题文件，而非创建近似重复
- 将相对日期（"昨天"、"上周"）转换为绝对日期
- 删除被推翻的事实 — 如果今天的调查推翻了旧记忆，
  在源头修正它

更新入口文件，保持在行数上限和 ~25KB 之内。
它是索引，不是数据库 — 每个条目一行 ~150 字符：
- [Title](file.md) — 一行钩子

操作：
- 移除指向过时/错误/被取代的记忆的指针
- 缩减冗长条目：如果索引行超过 ~200 字符，
  它承载了属于主题文件的内容 — 缩短行，移动细节
- 添加指向新重要记忆的指针
- 解决矛盾 — 如果两个文件不一致，修正错误的那个

启用配置

// config.ts — 轻量配置模块
export function isAutoDreamEnabled(): boolean {
  // 用户设置优先级最高
  const setting = getInitialSettings().autoDreamEnabled;
  if (setting !== undefined) return setting;

  // 否则回退到 GrowthBook gate
  const gb = getFeatureValue_CACHED_MAY_BE_STALE(
    'tengu_onyx_plover', null
  );
  return gb?.enabled === true;
}

9. Channel Notifications——MCP 推送

Channel Notifications 是 KAIROS 的外部集成接口——它允许 MCP 服务器向 Claude 推送「频道消息」，就像 Slack channel 中的消息一样。这为 Claude 打开了一个全新的输入通道：不只是用户在终端里打字，还可以是外部系统的事件通知。

claude/channel capability

Channel Notifications 通过 MCP 协议的 capability 机制实现。MCP 服务器在初始化时声明 claude/channel capability，然后通过 notifications/claude/channel 方法推送消息。

// 构建时门控
feature('KAIROS') || feature('KAIROS_CHANNELS')

// 运行时门控（GrowthBook）
tengu_harbor gate

消息格式与注入

MCP Channel 消息以 <channel-message> XML 标签包裹，作为 user-role 消息注入到 Claude 的对话上下文中：

<channel-message>
  <channel>plugin:name@marketplace</channel>
  {消息内容}
</channel-message>

Channel 的标识格式是 plugin:name@marketplace——这标识了消息来源于哪个 MCP 插件。Claude 可以根据 channel 标识决定如何处理消息（是否立即响应、是否需要用户确认等）。

企业配置

Channel Notifications 的启用可以在企业级别进行配置。channelsEnabled 配置项允许组织管理员控制哪些 MCP 服务器可以推送 channel 消息、消息的审批流程等。

权限模型

10. 远程会话架构——Daemon 的底层

KAIROS 的所有高级功能（主动心跳、后台工作、断线恢复）都建立在一个核心基础设施之上：远程会话架构。这是 Claude Code 从「本地终端应用」到「可远程连接的 Daemon 服务」的架构跃迁。

Bridge 在 KAIROS 中的角色

Bridge 是连接 Daemon 进程和 Viewer 客户端的通信层。在 KAIROS 模式下：

  +-------------------+         WebSocket        +-------------------+
  |                   |<------------------------->|                   |
  |  Daemon 进程      |    Bridge 通信层          |  Viewer 客户端    |
  |  (agentic loop)   |                          |  (REPL UI)        |
  |                   |  - 消息流转发             |                   |
  |  - API 调用       |  - 权限请求桥接           |  - 显示输出       |
  |  - 工具执行       |  - 状态同步               |  - 接收用户输入   |
  |  - 上下文管理     |  - 会话历史分页           |  - 权限审批       |
  |                   |                          |                   |
  +-------------------+                          +-------------------+
         |                                              |
         | JWT Token                               关闭/重连
         | 刷新调度器                               不影响 Daemon
         |
  +-------------------+
  |  Anthropic API    |
  +-------------------+

WebSocket 订阅机制

Viewer 客户端通过 WebSocket 与 Daemon 建立持久连接。连接建立后，Viewer 订阅 Daemon 的消息流，实时接收以下事件：

• Claude 的文本输出（通过 SendUserMessage）
• 工具调用的进度和结果
• 权限请求（需要用户审批）
• Worker 的状态变化
• 系统通知

Session History 分页 API

当 Viewer 断线重连时，它需要追赶 Daemon 在断线期间产生的输出。Session History API 提供了分页查询机制，允许 Viewer 按时间范围获取历史消息。这确保了即使网络中断后重新连接，用户也能看到完整的执行历史。

viewer-only 模式

在 KAIROS 模式下，REPL 的角色发生了根本变化——它从「驱动者」变为「观察者 + 信使」：

权限请求的远程桥接

当 Daemon 中的 Claude 需要执行一个需要用户审批的操作（如写入敏感文件、执行 destructive 命令）时，权限请求通过 Bridge 发送到 Viewer 客户端。Viewer 在终端中显示审批提示，用户做出决定后，结果通过 Bridge 返回给 Daemon。这个机制确保了即使在远程 Daemon 模式下，用户仍然保持对敏感操作的控制权。

JWT Token 刷新调度器

Daemon 进程是长时间运行的——可能运行数小时甚至数天。它使用的 JWT token 有有效期限制，需要定期刷新。Token 刷新调度器负责在 token 接近过期时自动获取新 token，确保 Daemon 的 API 调用不会因为 token 过期而中断。

11. KAIROS 的完整数据流

以下是从用户启动 KAIROS 到 AI 自主工作的完整数据流图。这是本文最重要的图示之一——它将前面所有章节的内容串联成一个完整的画面。

  用户启动: claude --assistant
  |
  +-- [1] CLI 解析
  |     options.assistant = true
  |
  +-- [2] 构建时检查
  |     feature('KAIROS') == true?
  |     |-- false --> 普通 REPL 模式
  |     |-- true  --> 条件 require assistantModule, kairosGate
  |
  +-- [3] 运行时门控
  |     markAssistantForced() (--assistant 跳过 GB gate)
  |     OR isKairosEnabled() (GB gate: tengu_kairos)
  |     |-- false --> 普通 REPL 模式
  |     |-- true  --> kairosEnabled = true
  |
  +-- [4] Trust Dialog
  |     checkHasTrustDialogAccepted()
  |     |-- false --> 打印警告, 禁用 KAIROS
  |     |-- true  --> 继续
  |
  +-- [5] 初始化链
  |     setKairosActive(true)
  |     options.brief = true (强制 Brief)
  |     initializeAssistantTeam() (预置 in-process team)
  |
  +-- [6] REPL 模式切换
  |     fullRemoteControl = true
  |     Bridge 启动 (WebSocket)
  |     REPL --> Viewer/Messenger 客户端
  |
  +-- [7] Daemon Agentic Loop 启动
        |
        +-- [7a] Proactive Mode 激活
        |     maybeActivateProactive()
        |     TICK_TAG 心跳注入
        |
        +-- [7b] Brief Mode 激活
        |     maybeActivateBrief()
        |     setUserMsgOptIn(true)
        |     系统提示注入 BRIEF_PROACTIVE_SECTION
        |
        +-- [7c] Channel 初始化 (如果启用)
        |     MCP 服务器 channel capability 注册
        |
        +-- [7d] 主循环
              |
              +--[收到用户输入]--+--[处理]--+--[Brief 输出]
              |                              |
              +--[收到 <tick>]---+--[检查环境]--+--[有工作]--> 执行
              |                              |--[无工作]--> Sleep
              |
              +--[收到 task-notification]---+--[综合]--+--[Brief 汇报]
              |
              +--[收到 channel-message]----+--[处理]--+--[Brief 或忽略]
              |
              +--[Auto Dream 门控通过]-----+--[Fork]--> Dream 子进程
              |                                         |
              |                                   [Phase 1-4]
              |                                         |
              |                                   [记忆文件更新]
              |
              +--[PR 事件 (如已订阅)]------+--[处理]--> 自动响应
                                                    |
                                              [Push Notification]
                                              (如果 proactive && 用户离线)

12. KAIROS vs OpenClaw 对比

KAIROS 和 OpenClaw 是同一愿景的两种实现路径。前者是 Anthropic 官方的、深度集成的方案；后者是社区驱动的、基于逆向工程的开源方案。以下是全面的对比分析。

总体对比

核心取舍

13. 未来展望与思考

后提示词时代的含义

KAIROS 标志着我们正在从「提示词时代」过渡到「后提示词时代」。在提示词时代，人与 AI 的关系是：人说一句话，AI 做一件事。每次交互都是原子性的，AI 没有「记忆」、没有「计划」、没有「主动性」。

在后提示词时代，这个关系变为：人表达一个意图，AI 自主规划和执行。AI 拥有持久记忆（Auto Dream + memdir）、主动行为能力（Proactive Mode + Tick）、多任务编排能力（Coordinator Mode + Workers），以及持续运行的底层架构（Daemon + Bridge）。用户不再需要一步一步地指导 AI——而是表达目标，然后让 AI 自己去实现。

AI 自主权的渐进式释放

KAIROS 的 Feature Flag 体系不仅仅是技术实现的需要——它反映了 Anthropic 对 AI 自主权的渐进式释放策略。每个 flag 控制一个自主权维度：

这种渐进式释放是安全导向的设计——每打开一个 flag，AI 获得一个新的自主权维度，同时也引入新的风险面。Anthropic 通过 GrowthBook 灰度发布来逐步观察每个维度的安全性，在确认安全后才向更多用户开放。

Token 消耗问题的可能解法

KAIROS 的最大技术挑战是 token 消耗。一个持续运行的 Daemon 进程，每 5 分钟一次心跳，每次心跳需要读取完整上下文——这意味着巨大的 API 调用成本。当前的缓解措施包括：

• Prompt Cache（5 分钟 TTL）：在 cache 有效期内唤醒可以复用缓存，大幅减少计算成本
• SleepTool 的智能间隔：没有工作时 AI 会睡眠，减少无效心跳
• Auto Dream 的异步整合：将记忆整合推迟到空闲时间，避免在活跃会话中消耗额外 token
• 构建时 DCE：减少系统提示和工具描述的体积，降低每次调用的 token 数

未来可能的进一步优化方向：

• 增量上下文：不发送完整上下文，只发送自上次心跳以来的增量变化
• 分层唤醒：轻量级心跳（只检查有无新事件）和重量级心跳（完整环境评估）分离
• 边缘推理：在客户端侧运行轻量级模型来处理简单的心跳判断，只在需要时调用完整模型
• 事件驱动替代轮询：用 webhook 和文件监听替代定期心跳，只在真正有事件时才唤醒

从工具到员工的跨越

KAIROS 代表的不仅是一次技术升级，更是一次范式转换。当 AI 拥有了持续存在、主动行动、长期记忆的能力后，它就不再是一个「工具」——它更像是一个「员工」。

这个转变带来了深刻的问题：当 AI 从工具变为员工，我们需要什么样的新管理范式？如何设定 AI 员工的「工作边界」？如何审计它在你不在时做了什么？如何平衡自主性和可控性？

KAIROS 的多层 Feature Flag 体系和渐进式释放策略，正是 Anthropic 对这些问题的初步回答：不要一次性给 AI 全部自主权——而是一个维度一个维度地释放，在每一步都确认安全后再前进。