LyncoreLyncore
Lyncore

主会话 + 工作会话：
Agent 编排里"大脑与手"为什么要分开 ​

一句话结论：当你让一个 Agent 又当裁判又当运动员，它很快会把自己绕晕——长任务的细节糊满上下文，调度逻辑和干活逻辑互相踩。把"判断"和"执行"拆成两个会话，是多智能体编排里最值回票价的一刀。DeepSeek 的 dsh-superagent 这么干，Lyncore 也是这么干的，只是切法不同。

判断与执行拆成两个会话：请求 → 派活 → 执行 → 回报 → 续接

不分开会怎样 ​

设想一个最简单的"编码 Agent"：用户 @你 一句"修一下登录的 bug"，你在一个会话里读代码、改文件、跑测试、写提交。单次还行。一旦并发来三件事、其中一件要跑十分钟、另一件中途需要人确认——同一个会话就塌了：

  • 跑长命令时，新消息只能干等，或者把长命令砍了；
  • 一个任务的上下文（它读过哪些文件、改到哪了）会渗进另一个任务的判断；
  • 想让人介入某一件事，却得冻结整个会话。

根因是：调度（判断该接什么、派给谁、何时停）和执行（真去读代码改文件）是两种生命周期完全不同的活动，塞在一起必然互相污染。

dsh-superagent 的切法：Main + Executor ​

dsh-superagent 把会话分成两种角色（见 docs/007-architecture.md）：

  • Main Session（router / orchestrator）：负责评估 Trigger、accept/dispatch Ticket、回复人。它用的是 dsh-superagent-router 预设，工具集更小，只做"调度的事"。
  • Executor Session（worker）：每个 Ticket 一个，命名为 worker-<ticket id>，配一个以 Ticket 短名命名的独立目录。它用 dsh-superagent-worker 预设，带着干活要用的工具集。后台 job / 子 agent 跑完会自动唤醒它，不用卡在长命令上。

关键点是：一个负责"想"，多个负责"做"，彼此通过结构化的 Assignment 和 Input 通信，而不是共享一个上下文。主会话不会因为某个 worker 在跑十分钟编译就动弹不得；人也可以在某个 Executor Session 里直接写命令接着干，不影响别的 Ticket。

Lyncore 的切法：spawn_worker 顶层收口 ​

Lyncore 走的是同一思路，但更显式地做成了一个派发架构（见 AGENTS.md 与任务生命周期文档）：

  • spawn_worker 是顶层派发工具，在架构上收口了 lite / pro 两档执行器，外加并行的 expert（专家子智能体）。
  • 重的任务拆解 task_decompose 归属 Pro 那一档——它不是被"降级"成别的，而是明确放在能扛复杂规划的档位上。
  • lite 与 pro 的差异在权限与能力边界，不是"轻量版 vs 重型版"；对外改名也只是为了消除"Pro=heavy"的误解，分层本身保留。

换句话说，Lyncore 的"大脑"是那个做派发与拆解的主链路，"手"是 lite/pro worker 加并行 expert。和 dsh 的 Main/Executor 是同构的——只是 Lyncore 把这个分层写进了自有后端、桌面壳和双版（企业/个人）产品里，而 dsh 是吃 DeepSeek Harness 底座的 bundle。

对照阅读：《把"等人"做成一等公民状态》 讲分层之后人怎么插进来；《Lyncore 异步双工：边干边聊》 讲长任务为什么不阻塞主会话。

分离之后拿到三件事 ​

不管你用 dsh 的 Main/Executor，还是 Lyncore 的 spawn_worker，把大脑和手分开后，通常同时拿到：

  1. 上下文不被污染。 每个执行会话只装自己的活，调度会话保持"干净的判断面"。
  2. 并发各自独立。 dsh 用 WorkerSlots 控制并发上限，还特留一个额外槽给人或状态查询——新人消息永远能插进已有 Ticket，不会被新活挤掉。Lyncore 的 worker 并发也各自独立、互不跨会话影响。
  3. 可被独立恢复。 一个 worker 崩了，只需重启它那个 Assignment，主会话和别的 Ticket 不受影响。dsh 的重启会给新 Assignment 附一张 recovery note（先看目录/git/PR 再重复外部动作）；Lyncore 的任务生命周期对 waiting_approval 等状态也做了一致的重启域处理。

什么时候可以不分开 ​

不是所有 Agent 都需要这刀。单轮问答、一次性脚本、纯检索这类"判断即执行、执行即结束"的场景，硬拆反而增加复杂度。分离的必要性，随三件事上升：任务会变长、会并发、会需要人介入。只要命中其中两条，就该认真考虑主从会话了。

本系列 ​

本文以 DeepSeek 开源的 dsh-superagent（MIT）为例子。Lyncore 的派发与任务生命周期设计见官网 lyncore.top 与技术文档。