多彩编程 多彩编程MZPH · CODE BLOG
ARTICLE DETAIL

文章详情

深耕前端与后端开发技术的一线实战笔记与踩坑复盘。

图解Spacebot五大进程模型:Channel、Branch、Worker、Compactor与Cortex如何协同工作

图解Spacebot五大进程模型:Channel、Branch、Worker、Compactor与Cortex如何协同工作 图解Spacebot五大进程模型Channel、Branch、Worker、Compactor与Cortex如何协同工作【免费下载链接】spacebotAn AI agent for teams, communities, and multi-user environments.项目地址: https://gitcode.com/gh_mirrors/spac/spacebotSpacebot 是一个面向团队、社区和多用户环境的AI Agent智能体框架。它最核心的设计思想是不再让一个大循环包办所有事而是把对话、思考、干活、压缩上下文、全局观察拆成五种各司其职的进程模型——Channel、Branch、Worker、Compactor 和 Cortex。这篇文章带你用最短的时间看懂它们各自是什么、为什么拆、以及它们如何协同工作。Spacebot 控制台界面左侧是频道Channel卡片流顶部标签页可切换到 Workers、Cortex 等视图为什么要把一个智能体拆成五个进程大多数 AI Agent 框架把所有工作塞进同一个会话循环里一边聊天、一边调工具、一边回忆记忆、一边压缩上下文。结果就是——它在干活的时候没空回你压缩上下文的时候直接掉线检索记忆还会把一堆原始结果塞满上下文。Spacebot 的做法在 README.md 中一句话概括Spacebot splits the monolith into specialized processes that only do one thing, and delegate everything else.把单体拆成只做一件事的专业化进程其余全部委托出去。这五种进程在代码中是一个统一的枚举定义位于 src/lib.rspub enum ProcessType { Channel, // 对话 Branch, // 思考 Worker, // 干活 Compactor, // 压缩 Cortex, // 观察 }一句话记忆法进程角色一句话定位Channel前台接待唯一直接面对用户的对话进程Branch脑内走神从频道复制上下文安静地思考Worker幕后干活的独立执行耗时任务完成后汇报Compactor上下文管家监控上下文水位触发自动压缩Cortex全局大脑观察所有事件维护记忆健康Channel 频道进程唯一与用户对话的前台Channel频道是唯一与用户直接交互的进程。用户来自 Discord、Slack、Telegram、Web 端的消息都由 Channel 接收并驱动 LLM 完成一轮回复。它的核心实现是 src/agent/channel.rs文件开头的注释就写得很直白Channel: User-facing conversation process.Channel 的特点是自己不做重活。它负责维护对话历史启动时最多恢复 200 条消息见 src/agent/channel.rs 中的HYDRATE_MESSAGE_LIMIT渲染系统提示词见提示模板 prompts/en/channel.md.j2在每一轮回复后调用 Compactor 检查上下文水位把重活委托出去派 Branch 去思考、派 Worker 去执行可以把它想象成前台接待你问什么它都接但需要翻档案记忆或者搬大件跑任务时它会去找专门的同事而不是自己蹲在柜台后面。Branch 分支进程把思考从对话中拆出去Branch分支是频道上下文的一份思维分身。当 Channel 需要深度推理、召回记忆、或者为后续任务做铺垫时它会分叉出一个 Branch。看 src/agent/branch.rs 的定义/// A branch is a fork of a channels context for thinking. pub struct Branch { pub id: BranchId, pub channel_id: ChannelId, ... /// Clone of the channels history at fork time pub history: Vecrig::message::Message,要点有三个Fork分叉Branch 在创建时会克隆一份频道当时的历史之后在独立副本里思考不污染主线对话。工具隔离Branch 拥有独立的工具集比如memory_save和memory_recall所以回忆记忆这种重操作不会挤占频道上下文。有终点max_turns限制最大回合数思考完必须给出结论conclusion交回给 Channel。一个经典组合拳是 branch_and_spawn 工具Channel 一次调用先派 Branch 召回相关记忆、把任务喂上充分的背景知识Branch 结束后系统用代码而非 LLM把结论直接交给新 Worker 执行。正如设计文档所说The branch thinks, the worker does, and the handoff is guaranteed.Worker 工作进程真正干活的多面手Worker工作进程是独立的任务执行进程实现位于 src/agent/worker.rs。它和 Channel 最大的区别不需要等用户可以长时间独立运行默认 30 分钟的墙钟预算见 src/agent/worker.rs 的DEFAULT_WORKER_WALL_CLOCK_TIMEOUT_SECS。Worker 承担了所有重活跑 shell 命令、读写文件、操作浏览器执行长链路的多轮工具调用每 15 回合检查一次上下文见 src/agent/worker.rs 的TURNS_PER_SEGMENT甚至 Compactor 触发的上下文压缩本身也是由一个专门的压缩 Worker 来完成的Worker 还内置了工程级的可靠性设计瞬时错误指数退避重试MAX_TRANSIENT_RETRIES 3、上下文溢出时自动去重 强制压缩 75% 消息再重试MAX_OVERFLOW_RETRIES 2、以及防止无限循环的分段上限MAX_SEGMENTS 10。干完活后Worker 把结果通过事件总线汇报回 Channel由 Channel 决定如何转述给用户。Compactor 压缩进程让对话永不爆内存Compactor压缩器是上下文水位的自动管家。它的实现注释写得很清楚src/agent/compactor.rsThe compactor is NOT an LLM process. It watches a channels context size and spawns compaction workers when thresholds are crossed.也就是说Compactor 本身不做 LLM 推理它只是个看水位的哨兵Channel 每完成一轮回复就调用一次check_and_compact()检查上下文占用比例src/agent/compactor.rs。根据水位它分三档处理默认阈值定义在 src/config/types.rs水位档位默认阈值动作后台压缩 Background≈80%派一个压缩 Worker用 LLM 总结并替换最旧的 30% 消息激进压缩 Aggressive中间档同上但压缩 50% 的消息紧急截断 Emergency95%同步执行不经过 LLM直接丢弃最旧消息并插入标记三档策略的取舍很聪明日常用 LLM 优雅总结信息保留最好危急时宁可丢内容也要保证对话不中断速度第一。压缩完成前后Compactor 还会发出CompactionTriggered/CompactionCompleted事件——而这些事件正好被下一位主角盯着呢。Cortex 皮层进程全局观察者与记忆管家Cortex皮层是整个智能体的全局大脑。它的定位写在 src/agent/cortex.rs 的注释里The cortex observes system-wide activity via signals, commits observation memories, elevates tasks, runs memory maintenance, and synthesizes the agent profile.Cortex 的运转方式与其他进程都不同——它不服务任何单个用户请求而是持续地订阅事件总线Channel、Branch、Worker、Compactor 产生的一切ProcessEvent比如 Worker 启动/失败、压缩触发、记忆保存都会被 Cortex 的observe()方法接收形成滚动信号缓冲区容量 100见 src/agent/cortex.rs。定期心跳 Tick按配置的tick_interval_secs周期性自检生成记忆简报memory bulletin。维护记忆健康在 Cortex 循环中定期执行记忆衰减decay、修剪低价值记忆prune、合并高相似度重复记忆merge默认相似度 0.95 以上触发详见 docs/design-docs/cortex-implementation.md。观察型熔断器Worker 连续失败会累计计数越过阈值即记录告警防止问题进程无限烧钱。可以这样理解Channel 是前台Worker 是后台工人而 Cortex 是店长——它不接待顾客但时刻盯着整个门店的运行状态负责打扫、盘点和复盘。五者如何协同一条消息的完整旅程把五个进程连起来Spacebot 处理一件复杂请求的典型链路是这样的用户消息 → Channel 接收 │ ├─ 需要回忆/深度思考──→ 分叉 Branch │ 克隆历史 记忆工具独立思考 │ └─ 结论返回 Channel │ ├─ 需要执行重活────→ 派出 Worker │ 独立运行可长达 30 分钟 │ └─ WorkerComplete 事件汇报结果 │ ├─ 每轮结束后 ──→ Compactor 检查上下文水位 │ └─ 超阈值时派压缩 Worker 总结旧消息 │ └─ 全程所有事件 ──→ Cortex 观察 记忆衰减 / 修剪 / 合并 / 健康告警几个关键协作点值得记住Channel 是总指挥只有 Channel 面对用户Branch 和 Worker 都是它按需派出的分身结果最终由它统一转述。Branch → Worker 的交接是代码保证的branch_and_spawn让思考的产出直接变成执行的输入不依赖 LLM 自觉调用工具docs/design-docs/branch-and-spawn.md。Compactor 与 Worker 是同源的压缩上下文本身就是一个无工具的 Worker复用同一套执行与重试机制。Cortex 通过事件总线旁观一切它不插足任何进程但所有进程的事件CompactionTriggered、WorkerStarted、MemorySaved等都会流入它的信号缓冲区让它成为唯一掌握全局视角的角色。快速上手与延伸阅读如果你想动手体验官方 README 提供了 Quick Start 指引也可以直接 clone 仓库git clone https://gitcode.com/gh_mirrors/spac/spacebot想深入源码时建议按这条路径阅读想理解从哪里开始看五种进程的统一抽象src/lib.rsProcessType枚举对话主循环src/agent/channel.rs分叉思考机制src/agent/branch.rs prompts/en/branch.md.j2任务执行与重试策略src/agent/worker.rs压缩阈值与三档策略src/agent/compactor.rs src/config/types.rs全局观察者设计src/agent/cortex.rs docs/design-docs/cortex-implementation.md总结Spacebot 的五大进程模型本质上是一套职责分离架构——Channel 管对话、Branch 管思考、Worker 管执行、Compactor 管上下文容量、Cortex 管全局健康。拆分开后Agent 才能做到边聊天边干活、压缩上下文时不掉线、越用越聪明。这也是它敢自称The agent harness that runs teams, communities, and companies的底气所在。【免费下载链接】spacebotAn AI agent for teams, communities, and multi-user environments.项目地址: https://gitcode.com/gh_mirrors/spac/spacebot创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表