WorkBuddy架构概述如何实现长任务与多任务

WorkBuddy架构概述如何实现长任务与多任务

一句话结论：WorkBuddy 是一个「Agent 运行时 + 任务编排层」，并非「聊天窗口」。对话只是外壳，核心是"一个能自主循环的执行器"，加上"一层管理这些执行器的调度与持久化"。

阅读说明：本文含两张内嵌 SVG 图，在支持 HTML 的 Markdown 预览器中可直接渲染；纯文本环境下可忽略图形，正文表格已完整表达相同信息。

---

SVG图在优快云还是展示有问题，只能用手动截图方式粘贴了

1. 总体架构：六层视图

读图要点：中间两层（任务编排 + Agent 运行时）才是真正的"系统"，其余各层都是外挂式可替换部件。上下两层的区别决定了能力上限——工具能否扩展，或者模型能否替换。

层	职责	可替换性
交互层	桌面客户端、命令行/IDE、IM 与移动端	高，只是入口
任务编排层	任务状态机、并发调度、上下文落盘、中断恢复	核心，不可省
Agent 运行时	上下文装配 → 模型调用 → 工具分发 → 观察 → 再循环；权限与沙箱拦截	核心，不可省
能力层	内置工具、Skills/专家（渐进加载的说明书）、子代理、MCP 连接器、自动化	高，插件式
记忆层	云端用户画像、用户级 MEMORY.md、工作区日志与长期笔记	中
模型层	多模型路由、Prompt 缓存、历史压缩	高，按环境切换

---

2. 长任务与多任务：两个正交的维度

一个解决"时间上跑很久"，一个解决"空间上同时跑很多"。

如下图，我开启了一个新项目的任务，从需求到代码生成，到测试，到部署，这个任务的执行时间很长可能要好几个小时，同时这个这个长任务在执行计划时拆分成了多个子任务同时执行；
流程如下：
先建立任务清单，并把三个相对独立的部分（文档解析/分块、Streamlit 前端、测试套件）委派给并行 agent，同时我自己编写后端核心（配置/DB/LLM/检索/记忆/MCP/编排/API/SQL/部署物）

3. 长任务：把"一次执行"改造成"可恢复的状态机"

能做到跑几个小时甚至跨天，靠的是下面六个机制，而不是把超时时间调大：

机制	做法	解决什么问题
任务对象化	任务是一个持久实体（ID + 状态 + 独立工作区目录），而不是一段内存中的对话	关窗、换设备或第二天再来时，都能继续处理
逐轮写入磁盘	每个回合结束就把消息和工具结果追加写入记录文件，相当于 WAL	崩溃后从最后一条重放，不用重跑前面几小时
上下文压缩	历史滚动摘要 + 工具结果截断 + prompt 缓存	长任务真正的瓶颈在于 token 的线性膨胀，而不在时间
产物写入磁盘	中间结果写进文件（结果区可见），不留在上下文里	上下文丢了工作还在，这是"长"的物理基础
后台通道	长命令转到后台执行，并拿到句柄，完成后回调通知	前台对话不被 20 分钟的构建阻塞
清单 + 确认点	计划外化成可勾选任务清单；状态机 规划中 → 进行中 → 待确认 → 完成/失败 → 归档	跑偏时既能自动纠正，也能由人纠正

最后一条最容易被低估。长任务失败的典型原因不是超时，而是目标漂移：上下文被无关结果挤满后，模型开始"编"，看起来还在干活。因此清单提供了可核对的中间状态，确认点则提供了让人介入的入口。

产品侧对应：任务状态（进行中 / 已完成 / 失败 / 待处理 / 规划中 / 已归档）、侧边栏"待确认"标记、以及"在已完成或失败的任务上继续补充消息"的续跑能力。

---

4. 多任务：三个不同粒度的并行

1. 回合内并行（micro）：一次模型响应里并发调用多个互不依赖的工具，比如同时读 5 个文件、同时搜 3 个来源。这种并行无需额外调度，靠一次 message 里发多个调用即可。
2. 任务级并行（macro）：一个任务对应一个 Agent 实例、一个工作区和一份对话记录，各自在后台跑，侧栏按"待确认 > 已完成未读 > 失败 > 进行中"聚合状态。
3. 上下文隔离式并行（sub-agent）：开子代理处理某个分支，它有独立的上下文窗口，只回传结论摘要。

第 3 条是核心机制，并非可有可无的优化。并行本身并不难，真正难的是并行时共享同一个 context：如果 A 分支的检索结果、B 分支的报错日志全都进入同一个窗口，模型就分不清哪条结论属于哪个任务。正确做法是每个并行分支获得独立上下文，汇总层只读摘要，这也是"上下文隔离"比"线程并行"更本质的地方。

此外还有两个补充维度：

• 依赖编排：任务清单支持声明"谁阻塞谁"，从而构造出串行与并行混合的执行图，而不是只能全部串行或全部并行。
• 时间维度：自动化任务（周期性或一次性）把"多任务"扩展到无人值守。此时并发量取决于调度器，而与你已经打开几个窗口无关。

---

5. 两个维度正交，组合起来才是真实场景

“三个任务同时跑，其中一个已经跑了 4 小时”，就需要同时具备：任务级并发（三份独立上下文）+ 长任务持久化（那份 4 小时的任务有检查点）。

只具备	结果
只有并行、没有持久化	一崩全崩
只有持久化、没有隔离	任务互相污染上下文
两者兼具	长时可恢复、并发不串味

---

6. 工程上真正难的地方（技术经理视角）

维度	常见误判	实际难点
长任务	以为难点是"跑得久 / 超时"	纠偏 > 续航：目标漂移、上下文膨胀、失败重试的幂等性
多任务	以为难点是"开多线程"	合并 > 并行：结果汇总、同一文件的写冲突、一致视图
成本	以为按调用次数计费即可	长任务 token 线性甚至超线性增长，缓存与压缩是省钱关键

实践建议：一个任务一个工作区目录，避免并发写冲突；汇总层只接收结构化摘要，不接收原始工具输出。

---

7. 如果你们要自建类似系统

最小骨架其实只有 5 张表和 3 个机制：

表

表	关键字段	用途
task	id, parent_id, status, workspace_path	任务实体与状态机
transcript_event	task_id, seq, role, content, tool_result	append-only 逐轮记录（WAL）
artifact	task_id, path, type, version	产物落盘索引
task_dep	task_id, blocked_by	依赖图
task_run	task_id, started_at, finished_at, stats	执行记录与观测

机制

1. 每轮 append 写入磁盘（不依赖内存状态）；
2. 达到阈值触发 compaction，把旧历史压成摘要；
3. 后台 worker + 完成回调，长命令不阻塞前台。

多任务不需要额外架构，只要在 task 表上添加 parent_id 和独立的 workspace_path，再把"子任务结果回传"定义成结构化摘要（而不是原始上下文）就够了。

---

8. 边界说明

上面对分层与机制的描述，是基于可观测的运行时行为（任务状态、后台句柄、子代理独立上下文、逐轮写入磁盘的效果）和通用 Agent 工程范式归纳出的架构视图，并非官方实现规格；内部的调度算法、沙箱技术和模型部署细节不对外，也不影响按这个结构做设计参考。

如需正式的产品能力说明，参见：

• WorkBuddy 简介
• 任务管理