BISHENG 灵思任务模式会话模型收敛跨模式会话上下文共享的统一设计v2.6.0 / F035【免费下载链接】bishengBISHENG is an open LLM devops platform for next generation Enterprise AI applications. Powerful and comprehensive features include: GenAI workflow, RAG, Agent, Unified model management, Evaluation, SFT, Dataset Management, Enterprise-level System Management, Observability and more.项目地址: https://gitcode.com/GitHub_Trending/bi/bisheng本文基于 features/v2.6.0/035-linsight-task-mode/跨模式会话上下文共享设计.md 展开结合 BISHENG 开源仓库src/backend与src/frontend的源码实现深入讲解日常对话与任务模式如何收敛为同一会话的完整设计方案、关键决策与落地路径。读者读完可掌握统一会话模型的动机与数据建模、POST /chat/completions单入口 task_mode逐轮标记的后端分流与前端渲染方案、历史注入从 session 维度向 chat_id 维度的迁移以及任务模式端到端接口流程与刷新重建逻辑。1. 背景为什么日常与任务必须共享会话BISHENG 的灵思Linsight工作台承担两种交互形态日常对话Workstation 工作台问答与任务模式deepagents 驱动的多步任务执行。在 v2.6 之前两者看起来是两套系统日常对话走工作台链路任务模式则新建一条独立会话并跳到独立路由/linsight导致用户在同一主题下切换模式时上下文被割裂——任务模式看不到前面聊过的内容回到日常对话也丢失了任务执行的结果。但仔细审视底层分裂其实比想象的近底层已经共享了一半linsight 的session_id本来就是一个MessageSession.chat_id见 workbench_impl.pychat_id submit_obj.session_id or uuid4()续聊时session_id message_session.chat_id。也就是说任务模式早已挂在MessageSession这张统一会话表上只是打了flow_type20LINSIGHT的标签。ChatMessage字段足够承载任务轮message最终答案、extra/intermediate_stepsLargeText可存执行详情指针、category消息分类、files、is_bot一应俱全见 message.py。真正造成分裂的只有两点也正是本设计要消除的#现状目标①任务模式新建flow_type20的独立MessageSession→ 独立侧边栏项 独立/linsight路由任务轮不再新建会话跑在当前会话的chat_id上无独立路由②任务轮只写linsight_session_version不写ChatMessage任务轮也写ChatMessageuser bot 各一行extra指向linsight_session_version_id执行详情仍存 linsight 表一句话概括目标把任务模式 一种会话类型flow_type20降级为任务模式 某一轮的处理路由标记。linsight_session_version/LinsightExecuteTask从会话退位为某条 bot 消息的执行详情附属。目标模型产品定调会话层不存在任务模式这个概念。前端只有一个对话入口是否开启任务模式只是逐轮附带的一个标记只影响后端如何处理这一轮用户问题。一轮普通问答、一轮任务执行产生的所有内容都属于同一条会话同一个chat_id构成一条线性消息流。2. 统一数据模型会话一条MessageSession消息一条ChatMessage流2.1 会话 一条MessageSession一个chat_id一条会话只有一个MessageSession行flow_type是会话级稳定属性与某轮是否走任务模式正交——不再因为开了任务模式就变成 20。会话flow_type固定为WORKSTATION(15)决策 D1日常工作台对话本就是FlowType.WORKSTATION15。可在 flow.py 中看到完整的FlowType枚举定义WORKSTATION 15、LINSIGHT 20等。由 chat_service.py 写库——新建会话时MessageSession(chat_id..., nameNew Chat, flow_typeFlowType.WORKSTATION.value, ...)。开不开任务模式都不改变它任务模式不再产生flow_type20任务轮直接挂在这条 15 会话上。侧边栏图标、筛选、历史归类全部沿用日常会话既有逻辑零新增。2.2 消息 统一ChatMessage线性流按chat_id每一轮无论何种模式都落ChatMessage字段普通轮任务轮is_botuser / botuser / botmessage文本用户问题 / 最终答案output_result.answercategory既有分类新增标记task前端据此渲染富面板extra既有{ linsight_session_version_id }—— 指向执行详情intermediate_steps既有可选执行步骤摘要ChatMessage的字段定义在 message.pyextra与intermediate_steps均为可存大文本的列category为max_length32的分类列天然支持本设计。要点执行详情仍存 linsight 表tasks / sop / steps / 产物文件继续落linsight_session_versionLinsightExecuteTask键仍是chat_id无需迁移键。变化只是它们从独立会话内容变成被某条ChatMessage.extra引用的附属详情。前端富面板按需懒加载消息流里任务轮先渲染答案气泡 折叠的任务面板入口展开时按linsight_session_version_id拉详情ExecutionFlow / TaskPanel 复用既有组件。2.3 上下文共享变成免费因为所有轮次都是同一chat_id下的ChatMessage展示前情 加载该chat_id的消息流即可天然含两种轮次无需跨表归并、无需 group 锚点。喂给模型 两条处理链都从同一份ChatMessage历史取上下文。3. 后端设计单入口 逐轮分流3.1 单入口提交端点按task_mode分流已定决策2026-06-15后端统一端点 handoff统一入口 扩展既有日常端点POST /chat/completionsstream_chat_completion请求体APIChatCompletion加task_mode。后端按task_mode分流各路径沿用既有流式基建不重做传输层task_modefalse→ 既有日常 SSE_agent_stream_chat_completion不变。task_modetrue→_task_mode_stream_completion复用submit_user_question在当前chat_id建/复用会话SSE 回传session_version_id的 handoff 事件linsight_task_handoff前端据此 start-execute 连既有task-message-streamWS。选择 handoff 而非把 linsight 事件重桥接到 chat-completions SSE的原因最大复用 linsight 既有 WS 流零重写传输层。前端只调一个提交入口POST /chat/completionstask_mode逐轮标记的伪代码POST /api/v1/.../chat body: { chat_id, question, task_mode: bool, tools?, model?, files?, ... } handle(question): persist ChatMessage(user, chat_id) # 用户轮先落库两模式统一 if task_mode: → 进 linsight deepagents 链复用现有 submit/start 内核但 chat_id 当前会话 → 产出 linsight_session_version完成后回写 ChatMessage(bot, messageanswer, categorytask, extra{linsight_session_version_id}) else: → 进既有 工作台(workstation, flow_type15)日常链 → 回写 ChatMessage(bot, ...) # 既有逻辑复用而非重写 linsight 内核deepagents 执行、HITL、Worker、事件流见 design.md §2–§5全部不变改的是入口装配——不再自建flow_type20会话而是接收外部chat_id并把结果回写进统一消息流。submit改造点submit_user_questionworkbench_impl.py当前逻辑是无session_id就新建flow_type20会话chat_id submit_obj.session_id or uuid4()续聊时校验message_session.user_id ! login_user.user_id则回退新建。新模型下chat_id必由调用方统一入口传入且会话已存在linsight 侧不再创建/决定 flow_type。3.2 历史注入从「session 维度」改为「chat_id 维度」任务链原_get_history_summary按session_version_id收 task answers改为按chat_id读ChatMessage历史含普通轮 任务轮答案归一成文本前情注入既有history_summary通道。日常链本就按chat_id读ChatMessage历史 → 自动看见任务轮答案任务轮已落 ChatMessage。token 预算复用 design.md §3.8 的历史压缩裁剪长会话防爆窗。3.3 兼容存量flow_type20会话决策 D3不迁移存量不迁移历史flow_type20的 linsight 会话保持原样按既有只读形态展示旧路由/旧渲染路径保留到存量自然消亡或仅作历史查看。新会话走统一模型自上线起新产生的任务轮一律挂在日常会话的chat_id下、双写ChatMessage。不写迁移脚本、不补ChatMessage行避免触碰存量数据一致性风险。4. 前端设计client4.1 单入口 逐轮标记删除切到/linsight路由的跳转模型。AiChatInput中onEnterTaskMode{() navigate(/linsight/new)}AiChatInput.tsx改为仅切换输入框的taskMode本地态不导航。当前组件已具备taskModeEntry/taskMode特性开关并通过taskModeSkillsState维护技能 chip 选择见 AiChatInput.tsx。提交时把task_mode随这一轮请求发出统一入口。开/关任务模式不丢任何上下文——因为根本不换页、不换会话。4.2 单一消息流渲染一个会话 一条线性消息列表。渲染分支按message.category普通轮 → 既有气泡components/Chat/Messages。任务轮 → 答案气泡 可展开的任务执行面板复用components/Linsight/Execution/*ExecutionFlow / TaskPanel / ConversationRound 的只读形态数据按extra.linsight_session_version_id懒加载。状态收敛linsightMapState按 versionId退化为当前/展开中任务轮的执行态缓存不再承担会话职责会话流真相回归日常的消息 store。4.3 侧边栏 / 会话列表同一会话只有一条列表项不再有flow_type20单独项。useNavigateToConvo的flowType20 → /linsight分支随路由统一而移除。5. 端到端时序同一会话内开关任务模式会话 C(单条 MessageSession, chat_idC) — 用户先普通聊两轮 ChatMessage×4 (u/b/u/b) 落在 chat_idC │ 用户在输入框开启任务模式发问 Q3 ▼ POST /chat { chat_idC, questionQ3, task_modetrue } 持久化 ChatMessage(user, C) → linsight deepagents 链(chat_idC, 注入 C 的历史前情) ← 喂模型(看得见前两轮) ✅ → 产出 linsight_session_version SV; 回写 ChatMessage(bot, C, categorytask, extra{SV}) ▼ 前端消息流: 第5/6条 Q3 任务答案(可展开富面板) ← 同一会话内展示 ✅ │ 用户关掉任务模式发问 Q4(普通) ▼ POST /chat { chat_idC, questionQ4, task_modefalse } → 工作台日常链(flow_type15, 读 chat_idC 历史, 含任务轮答案) ← 普通链也看得见任务前情 ✅全程同一个chat_idC无新建会话、无跨页、无 group 锚点。6. 边界与异常场景处置任务轮执行失败 / 进行中bot 的ChatMessage落失败/进行中占位extra仍指向 SV 供查看详情不污染后续历史注入失败轮不计入 answer 前情任务轮 HITL 中断等待沿用 design.md §4 的 park-and-release消息流该轮显示等待输入恢复后原地更新同一ChatMessage行富面板详情拉取失败答案气泡正常显示面板区降级提示详情加载失败不影响文本前情长会话历史爆窗design §3.8 裁剪存量 flow_type20 会话不迁移按旧形态只读展示§3.3任务轮产物文件仍存 linsight 工作区design §9.3通过 SV 关联展示文件持久化记忆沿用 §9.3.87. 与 design §9.3.8 的关系正交不冲突两者管的是不同的东西互不推翻| | §9.3.8 | 本文 | |--|--------|------| | 管什么 |选择态文件 / 知识库 / 工具的chip 选择在任务模式进出之间是否保留 |内容用户问题 模型最终答案的问答上下文是否共享 | | §9.3.8 原意 | 退出任务模式后用户在任务模式上传的文件等持久化存在下次再开任务模式仍然有效不是清空也不是问答不共享 | —— |设计文档 design.md 中 §9.3.8 明确退出任务模式后文件 / 知识库 / 工具的选择态chip在会话内保留但不在日常对话链路真正生效仅在再次进入任务模式时回填并随任务提交生效。统一模型下两者都自然成立§9.3.8选择态持久开/关任务模式只是同一会话同一输入框的逐轮标记文件/知识库/工具的选择态本就随输入框延续下次开启自然仍在 —— §9.3.8 的诉求不需要专门记忆回填机制即满足。本文问答共享普通轮与任务轮共享同一chat_id的ChatMessage历史两条处理链都读得到对方的问答用户输入 模型最终答案即两者都要。这与 §9.3.8 不冲突——§9.3.8 的日常对话不接管指的是文件/知识库/工具这些 chip 能力不在日常链生效不涉及问答文本。8. 关键决策已定D1 会话flow_typeWORKSTATION(15)日常对话类型任务模式不再产生flow_type20任务轮直接挂在 15 会话上。D2 问答上下文双向共享均喂模型统一ChatMessage后普通链与任务链都读取同一份chat_id历史含对方轮次的用户问题 最终答案。与 §9.3.8 正交无需过滤、无需撤销 §9.3.8见 §7。D3 存量 flow_type20 会话不迁移旧会话只读保留新会话走统一模型不写迁移脚本§3.3。D4 纳入 F035 当前迭代作为 F035 的会话模型收敛项推进非独立 feature。需在 tasks.md 增设对应 Track/Wave并在 依赖与契约约定 登记统一提交入口与ChatMessage双写契约。9. 分阶段落地阶段内容触及P0统一提交入口 task_mode逐轮标记linsightsubmit改为接收外部chat_id、不自建会话后端入口 前端输入P1任务轮双写ChatMessagecategorytaskextraSV前端单消息流渲染任务轮富面板懒加载后端写入 前端渲染P2历史注入改chat_id维度两链共享ChatMessage历史 token 裁剪后端P3路由/侧边栏收敛新会话不再走/linsight独立路由存量旧会话的只读路径保留前端存量flow_type20会话不迁移D3无 P4 迁移阶段。10. 实现锚点速查关注点锚点任务模式入口裸跳转→改本地态AiChatInput.tsx任务 submit改为接收外部 chat_id、不自建会话workbench_impl.py任务历史注入改 chat_id 维度同文件_get_history_summary、历史注入点日常对话写库链flow_type15chat_service.pyFlowType.WORKSTATIONFlowType 枚举WORKSTATION15 / LINSIGHT20flow.py会话元数据表单 flow_typesession.py统一消息表承载两类轮次message.pyextra/intermediate_steps/category前端任务执行渲染组件复用为消息流内富面板src/frontend/client/src/components/Linsight/Execution/*、ConversationRound.tsx路由 flowType20 分支新会话不再走存量保留只读src/frontend/client/src/hooks/Conversations/useNavigateToConvo.tsx、routes/index.tsxlinsight 会话态 store降级为执行态缓存src/frontend/client/src/store/linsight.ts、hooks/useLinsightManager.tsx文件/知识库/工具持久化记忆正交沿用design.md §9.3.811. 会话历史查询与前端渲染流程11.1 数据形态一条线性流 两类消息会话历史 同一chat_id下按时间排序的ChatMessage列表。每条消息靠is_botcategory区分类型任务轮的重内容不在列表里、只放一个指针ChatMessage(chat_idC) 列表时间序: ├─ {is_bot:0, message:..., category:question} ← 用户·普通 ├─ {is_bot:1, message:..., category:answer} ← 模型·普通答案 ├─ {is_bot:0, message:..., category:question} ← 用户·任务开了 task_mode └─ {is_bot:1, message:最终答案, category:task, ← 模型·任务答案 extra:{linsight_session_version_id:SV-…}} tasks/sop/产物详情按需懒加载11.2 查询流程两段式列表轻量 详情懒加载要点列表查询只走一处ChatMessageDao.get_messages_by_chat_id(C)普通轮与任务轮天然同流、同序无需跨表 join、无需 group 归并。任务详情懒加载列表只携带extra.linsight_session_version_idtasks/sop/中间步骤/产物文件等重内容仅在用户展开该轮时按 SV 拉取避免首屏拉爆。进行中/HITL 等待的任务轮列表里该 bot 消息为占位态富面板的实时事件仍走既有 WS 流design.md §3落库后回填同一条ChatMessage。11.3 前端渲染决策树统一列表组件只做按category分发普通轮复用components/Chat/Messages任务轮复用components/Linsight/Execution/*不新造消息容器。渲染真相回归日常消息 storelinsightMapState仅缓存当前/展开中任务轮的执行态含 WS 实时事件不再承担会话职责。滚动/分页任务轮在列表里只占一条答案 折叠入口不因任务步骤多而撑爆列表高度分页逻辑与普通会话一致。12. 任务模式端到端接口流程前端调用 判断条件覆盖准备 → 提交首轮 → 排队 → 执行 → HITL → 结束 → 再发起一轮 → 刷新重载。现状实时前端走 linsight 原生端点目标TJ-6 落地后首轮提交统一为POST /chat/completions {task_mode:true}→ SSElinsight_task_handoff {svid, chat_id}其余执行/HITL/产物仍复用 linsight 端点与 WS。12.1 主流程图12.2 刷新/重载任意阶段纯 REST 重建刷新能看到在途/等待输入的任务轮依赖 TJ-3 的占位行执行开始即写 bot 任务轮、完成回填同行见 §2.2 / §6。12.3 判断条件速查表阶段触发/判断条件调用接口提交首轮用户发送(task_mode on)/chat/completions(目标) 或/workbench/submit/start-execute(现状)是否排队后端返回排队 / queueCount0轮询GET /workbench/queue-status执行流WStask_generate/task_start/task_execute_stepWStask-message-stream需要 HITLWSevent_type user_inputClarifyCard →POST /workbench/user-inputHITL 已答WSevent_type user_input_completed收起 ClarifyCard无新请求完成WSfinal_result产物下载类接口失败WSerror_message—用户终止用户点停止POST /workbench/terminate-execute→ WStask_terminated再发起一轮任务结束后再次发送POST /workbench/continue同 SV/ 新 submit统一模型新 SV刷新感知状态重载session-version-list(整体) execute-task-detail(per-task)completed/waiting_for_user_input/in_progress三态分支关键点执行中/HITL 全靠WSevent_type驱动前端不轮询、不自判刷新靠REST 读持久化状态session.statustask.statuswaiting_for_user_input重建。13. 总结跨模式会话上下文共享设计的本质是一次会话模型的收敛把任务模式从一种独立的会话类型降级为会话内某一轮的处理路由标记用既有的MessageSessionChatMessage承载全部两种轮次。收益是结构性的数据层一条会话、一份ChatMessage线性流历史查询天然统一无需跨表归并上下文层普通链与任务链共享同一份chat_id历史问答上下文双向可见D2且与选择态持久§9.3.8正交互不冲突体验层前端单入口、单消息流、单侧边栏项模式切换不换页不丢上下文成本层linsight 的 deepagents 执行内核、WS 事件流、HITL、Worker 全部复用仅改造入口装配与历史注入维度存量flow_type20会话不迁移D3规避数据一致性风险。这一设计连同 spec.md、tasks.md 与 依赖与契约约定 一起构成 F035 灵思任务模式迭代中会话模型收敛这一关键支柱的完整落地蓝图。【免费下载链接】bishengBISHENG is an open LLM devops platform for next generation Enterprise AI applications. Powerful and comprehensive features include: GenAI workflow, RAG, Agent, Unified model management, Evaluation, SFT, Dataset Management, Enterprise-level System Management, Observability and more.项目地址: https://gitcode.com/GitHub_Trending/bi/bisheng创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考