企业官网建设流程全解析

上一篇聊了“为什么大多数 AI 助手是任务孤岛”。这篇把镜头拉近，看一次具体的长任务，从你点下“整理这份资料”到结果回来，中间到底发生了什么。

你以为的 vs 实际发生的

你以为：你发指令 → 它转圈 → 出结果。中间你什么都干不了。

实际要支持“边干边聊”，中间至少有四个环节在并行运转：

阶段一：接单（不阻塞）

你发“整理这份 50 页 PDF 出摘要”，服务端收到后立刻返回“已收到，后台跑着”——这个返回不走任务执行，只走一个轻量的“接单”动作。

关键：这次请求的响应和任务执行解耦。你不会因为任务要跑十分钟而被挂住。

阶段二：异步 worker 执行

真正的整理工作，被丢给一个独立的 worker（进程 / 协程 / 线程池），和你的对话通道分开跑。

这就是为什么你能“继续发消息”——你的对话请求走 A 通道，任务跑在 B 通道，互不阻塞。

阶段三：状态挂起

这是最容易被忽略的一步。

你派完活，突然想到“顺便帮我把第 3 章单独摘出来”。这条新消息进来时，worker 还在跑。系统要做的是：把你的新指令接进同一个任务上下文，而不是开一个全新任务，也不是把 worker 杀掉重来。

换句话说，会话状态被“挂起”保存了——不是断开，是记住“你刚才在等这份摘要，现在又加了个要求”。

阶段四：结果回流

十分钟后 worker 干完了。结果要通过事件总线（消息队列 / 本地事件）推回正确的会话。

“正确”二字是关键：系统得知道这个摘要该回到你刚才那个对话、那个任务，而不是随便弹个通知。这一步做不好，异步结果就会“找不到家”。

一个具体实现

我们做的 Lyncore 个人版，异步挂起机制做在内核里（fc_async.go）：长任务 worker 不阻塞主会话，你随时插话、改需求、问进度都接得住。

目前是异步双工：长任务不打断对话。下一步要启用 interrupt/resume（fc_interrupt.go，现在预留未启用），走到“干活中途能先停、先回答你一个问题、再接着干”的真·全双工。这部分在路线图上，如实说。

为什么这比“加功能”难

很多产品想做“边干边聊”，但请求-响应模型是同步、阻塞、无状态的。要支持上面四个环节，得把状态管理、上下文保持、结果回流整套做进内核——不是叠一个功能按钮。

这也是为什么“任务孤岛”型产品，加再多功能也长不出双工。

我们做的 Lyncore 个人版 就是把这套机制落在了本地：异步挂起做进内核，长任务不阻塞主会话，数据留在你本机。安装包即将开放，官网可留邮箱获取更新。