WorkBuddy任务间通讯与事件驱动协作编排

一、问题：单对话处理复杂任务会「坍塌」

把一条复杂的、多阶段的任务全塞进同一个对话窗口里让 WorkBuddy 一路往下做，是大多数人的直觉做法。但任务一旦变长变复杂，这种方式很快就会出问题——不是模型变笨，而是上下文被撑爆后系统性退化。

1. 上下文过长 → 失忆

对话越堆越长，早期的关键约束、用户给定的规格、已经定下的决策会被「挤」出有效注意力范围。越到后段，Agent 越容易「忘了」开头的要求，出现前后矛盾、重复劳动、漏做步骤。

2. 多种能力混在一个窗口 → 角色串台

选题调研、口播脚本、字幕排版、代码实现、发布部署——这些职责需要不同的「能力侧重点」。混在一个窗口里，模型会在不同角色间来回切换，导致能力混淆：该做调研的跑去写代码，该写文案的跑去调接口，质量全面下降。

3. 长链路推理衰减

一个 10 步的任务链，第 8 步往往会因为前面逐步累积的偏差而走偏。中间任何一步的「理解漂移」都会被后续步骤放大，最后产物离目标越来越远，且难以定位是哪一步出的错。

二、解法：任务窗口化 + 事件驱动编排

核心思路是把一个复杂任务按职责拆成多个独立任务窗口，每个窗口只专注一件事；再用事件驱动的方式让它们互相「唤醒」，而不是靠人工在窗口间来回复制粘贴。

1. 每个任务窗口 = 一个独立的 Agent 交互面

在 WorkBuddy 里，左边栏每一个任务，本质上是一个独立的 conversationId 会话。对用户而言，点开某个任务出现的对话窗口，就是「针对该任务的专属人机交互界面」。它拥有自己独立的上下文、文件工作目录（cwd）和记忆。

2. 拆解原则

• 按职责切：调研 / 创作 / 执行 / 发布，各占一个窗口。
• 按产物切：每个窗口的产出是一个明确文件（如 A_选题卡.md、B_脚本.md），产物路径作为下游的输入信号。
• 上下文隔离：每个窗口只装自己那点事，避免「失忆」和「串台」。

3. 编排内核：事件总线，不是定时器

关键认知：多窗口协作的「大脑」不是 automation 定时器。定时器是「硬串」——上游挂了下游照跑，时间一到就触发，和上游成没成功无关。真正的编排应该是事件驱动：上游完成 → 自然产生一条消息 → 下游被「唤醒」开始工作。消息，就是任务间通讯的载体。

三、关键技术发现：WorkBuddy 原生的「任务间通讯」能力

要让一个窗口的消息自动「跑进」另一个窗口，核心是找到把消息注入任务窗口的方法。我们实测确认：WorkBuddy 桌面端本身就是一个可被外部调用的 HTTP 服务。

1. 桌面端内置 codebuddy --serve

WorkBuddy 桌面端进程（WorkBuddy.exe）内部就运行着 codebuddy --serve，在本地暴露一套 /api/v1/* 接口（实测监听于 127.0.0.1:51049/59637）。内置二进制位于：

D:/Users/pc/AppData/Local/Programs/WorkBuddy/resources/app.asar.unpacked/cli/bin/codebuddy

2. 注入消息的核心端点

向某个 conversationId 注入一条消息、并立即触发它开始执行，只需一个 POST：

POST /api/v1/runs
Headers: X-CodeBuddy-Request: 1
         Authorization: Bearer <token>   # 本地可设 CODEBUDDY_GATEWAY_AUTH=none 关闭
Body:
{
  "id": "run-唯一id",
  "type": "message",
  "source": {
    "platform": "generic",
    "sender": { "id": "ext", "name": "外部事件" },
    "conversation": { "id": "目标窗口的conversationId", "type": "direct" }
  },
  "payload": { "text": "请执行：……（带产物路径等信号）" }
}

3. 自带 Webhook 入口

该 API 还提供 POST /api/v1/webhooks/:platform（platform 含 generic）。上游系统（或另一条自动化流水线）完成后直接 POST 进来，即可触发目标窗口——比自建消息队列更规范，无需自己造轮子。

4. 任务窗口清单从哪来

所有工作空间与子任务都登记在 ~/.workbuddy/workbuddy.db 的 workspaces 与 sessions 表；sessions.id 即 conversationId，sessions.cwd 是该窗口的工作目录。这让我们能程序化地「找到要注入哪个窗口」。

四、已验证的闭环（实测证据）

我们做了一次端到端实测，证明「注入消息 → 窗口自动执行」完全可行，且不需要升级标准版。

步骤与结果

步骤	操作	结果
1	起一个自己掌控的本地 serve（关闭认证）	/api/v1/health → status: ok
2	列出会话，确认能看到真实任务窗口	返回含当前对话的会话列表
3	向 inject-test 窗口注入一条消息	POST /api/v1/runs → status: accepted
4	Agent 收到消息并自动执行	生成文件 inject_test_result.txt
5	校验产出	内容 INJECT_OK_测试成功，run active: false（完成）

# 后台起一个关闭认证的 serve（路径必须用 Windows 风格 D:/）
CODEBUDDY_GATEWAY_AUTH=none \
D:/Users/pc/AppData/Local/Programs/WorkBuddy/WorkBuddy.exe \
D:/Users/pc/AppData/Local/Programs/WorkBuddy/resources/app.asar.unpacked/cli/bin/codebuddy \
  --serve --port 8090 --session-id 目标会话ID --setting-sources user --no-session-persistence

# 注入消息触发执行
curl -X POST http://127.0.0.1:8090/api/v1/runs \
  -H "X-CodeBuddy-Request: 1" -H "Content-Type: application/json" \
  -d '{"id":"r1","type":"message","source":{"platform":"generic","sender":{"id":"ext","name":"外部"},"conversation":{"id":"目标会话ID","type":"direct"}},"payload":{"text":"做某件事"}}'

五、三条落地路径对比

路径	原理	是否升级	状态	适配度
A. 本地 serve + API 注入	桌面端自带的 /api/v1/runs 直接注入	否	✅ 已实测	高（直接推、直接注入）
B. 标准版云端 API	/v1/tasks/create + webhook 回调	需标准版 ¥70/月	待接入	高（最规整的云端解）
C. A2A broker	自建收件箱 + 轮询（register/send/inbox）	否	✅ 已跑通	中（走外部 broker，非窗口直连）

六、设计不可省的三件事

多窗口编排一旦上规模，下面三点是底线，否则会乱：

1. 信号必须带产物路径：上游完成事件里写明「我产出了 xxx.md 在哪」，下游才知道读什么。
2. 幂等 run_id：每条注入消息带唯一 id，重试不会重复执行（用 ?since= 游标或 run_id 去重）。
3. 状态落盘 state.json：每条任务推进到哪、产出在哪，写进文件，崩溃可恢复。

七、应用示例：抖音 A/B/C 事件驱动流水线

1. Orchestrator 窗口拆解任务，生成路由表（触发事件 + 下游窗口）。
2. 窗口 A（选题调研）完成 → 注入消息到窗口 B：「选题卡已生成在 A_选题卡.md，请据此写口播脚本」。
3. 窗口 B 完成 → 注入消息到窗口 C：「脚本已生成，请生成字幕与预览 HTML」。
4. 全程事件触发，无需人工在窗口间搬运，也无需定时器硬串。

八、结论与下一步

复杂任务在单一对话里执行，会因上下文膨胀而「失忆、串台、推理衰减」；正确做法是拆成多个任务窗口，并用事件驱动把它们编排成一支团队。WorkBuddy 原生的 /api/v1/runs 注入机制，已经提供了「向指定窗口发消息并触发执行」的官方能力——我们实测跑通了完整闭环。

下一步：① 把 A 路封装成可复用 skill（自动查 DB 取 conversationId、起 serve、注入、回查状态）；② 用抖音 A/B/C 跑通第一个真实事件驱动流水线；③ 评估是否上标准版 B 路做云端规整编排。