灵思任务模式执行流段流重构从 todo 归属到 write_todos 切分的增量优化实践【免费下载链接】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导读本文基于 BISHENG 开源仓库中《灵思任务模式执行流增量优化方案活动摘要·子代理拆平·自然语言旁白》PRD完整讲解灵思Linsight任务模式执行流的第二轮增量优化如何将「按 todo 归属的嵌套进度树」降维为「以 write_todos 调用为界的单条段流」并落地 R1 活动摘要、R2 自然语言旁白、R3 子代理拆平三项体验优化。读完本文你将理解 deepagents 框架下执行流归属机制的固有缺陷、后端单桶B2改造的动机与实现以及前端如何把 write_todos 从「丢弃噪声」改造成「段边界锚点」并掌握对应的测试落点与回归清单。该方案对应的上游文档为《灵思任务模式后端执行与前端渲染映射技术报告》根因 114 实测与《灵思任务模式执行流渲染优化方案》22→3 与聚合层已落地本文所述方案是聚合层上线后的第二轮增量优化。1. 背景执行流为何要从「归属」降维到「切分」1.1 北极星对齐 Claude 的执行流交互范式Claude 的执行流交互范式做对了三件事这正是本轮要对齐的目标每个折叠块的标题就是「干了什么」的摘要——例如Used 6 tools, ran 5 commands, read 3 files而不是「已深度思考」这种与动作无关的元信息。折叠块之间穿插一句自然语言——把机器在干活翻译成同事在汇报例如Materials read — I have the full picture now. Moving to writing.。层级克制——过程是一条可扫读的浅栈而不是需要逐层下钻的深树。1.2 现状与差距MECE对照北极星灵思任务模式执行流存在四条差距前三条是 UI 表层对应 R1/R2/R3第四条是底层机制——它是前三者的共同地基本轮才认清差距一 · 一级标题是元信息而非动作一级组统一显示「已深度思考用时 382.0 秒」。用时有了但这 382 秒里搜了几次、读了几个文件、写了什么全无。→需求 R1一级标题改为活动摘要。差距二 · 摘要之间没有自然语言纯摘要行堆叠缺少把过程翻译成人话的旁白。→需求 R2段之间穿插一句自然语言旁白。差距三 · 运行过程层级过多子代理被包了三层已派出 N 个子智能体调研→子智能体 N→已深度思考→工具调用。→需求 R3去外壳、每个子代理升一级、内部铺平。差距四 · 归属机制本身不可靠本轮新认知执行流当前把每个步骤按task_id归属到某个 todo靠「隐式游标」再按 todo 分桶渲染成多条时间线。但框架不提供 todo 关联信号、且模型并行标记多个in_progress时步骤会错位。R1/R3 若继续建在这个会错的归属之上等于在歪地基上盖楼。→底座决策归属机制换底座为write_todos 段流。1.3 本轮的根本决策deepagents 的流里根本不携带「这一步属于哪个 todo」的信号——归属做不到、只能近似且会错而 write_todos 是流里的确定性事件——切分永远准。把问题从「步骤属于谁attribution」降维成「段的边界在哪segmentation」模型并行标记 todo、不守 todo 纪律等一切 adherence 问题随之蒸发。三项目标R1/R3/R2都建立在这个新底座之上按依赖与价值排序编号目标形态改动面风险底座归属机制不可靠隐式游标归属 →write_todos 段流后端单桶 B2后端 mapper 前端渲染中multi-turn 需先验证R1一级标题信息量不足「已深度思考用时 N 秒」→活动摘要 用时 N 秒纯前端低R3运行过程层级过多子代理「团队外壳→子代理→已深度思考→工具」四层→每段一级 → 工具二级纯前端中R2摘要之间缺自然语言段间穿插一句模型自然语言旁白后端 mapper prompt 前端中可行性先验证1.4 已与产品对齐的决策基线项已拍板决策底座段流·甩开 todo 归属执行流降为单条「段流」以 write_todos 调用为段边界前端靠name write_todos切段复用现有丢弃判断点零后端新增契约不再按 task_id 把步骤分到各 todo 容器。落地走B2后端单桶后端把主图步骤统一落id svid会话伪任务桶、删隐式游标。底部 TaskPanel 保留作独立进度展示、与执行流脱钩。prompt删去「同一时刻只允许一个 in_progress」一句——段流后已不依赖单 in_progress删它使 system prompt 与 write_todos 工具说明书不再矛盾、顺应 deepagents 原生并行语义保留「只翻转 status 不改文案」TaskPanel todo 标识稳定与「子代理并行委派 ≤2~3」。R1活动摘要为主 「用时 N 秒」后缀新建/编辑文件合并为一档「编辑 N 个文件」不拆 created/edited纯推理、段内无可计动作时回退「已深度思考用时 N 秒」。段头纯活动摘要、不带 todo 名。R3完全拆平每个子代理namespace 硬边界独立成一段、升为一级内部去「已深度思考」二级、工具升二级。接受代价弱化并行分组信号。R2本轮一起做不推后但实现前置一个可行性 Spike抓真实 DeepSeek 流确认工具批次间content产出率后端 mapper 接通被丢弃的AIMessage.content通道 prompt 引导。产出稀疏则降级prompt 强制 / thinking 末句派生。1.5 非目标不重做后端 thinking 切段碎片化逻辑——渲染层已吸收作为技术债保留。不追求「步骤 ↔ todo」的精确绑定——已确认框架无此信号本轮正是放弃这个目标。不动日常/c深度思考组北极星本体。2. 现状逻辑与三个根本缺陷2.1 现状两层切分 隐式游标归属第一层 · 按归属切成多条时间线sessionSteps规划伪任务一条时间线每个 todo 各一条在各自TaskStepRow内。归属怎么算隐式游标deepagents 的write_todos推全量 todo 快照后端_diff_todos做 3 级对齐、给每个 todo 算稳定task_id_stable_task_idmd5(svid : content)[:8]见 stream_event_mapper.py 中的_stable_task_id。随后_refresh_in_progress扫快照把当前in_progress的 todo记为游标current_in_progress_task_id。此后每个步骤thinking/工具/interrupt一律按task_id current_in_progress_task_id or svid盖戳——有in_progress的 todo 就归它没有规划/收尾就归会话伪任务svid。第二层 · 每条时间线内buildTimelineGroups聚合把连续顶层步骤包进一个deep_step_group 一个「已深度思考」唯一切断点是子代理组。本质归属是时间游标式的——某步属于哪个 todo纯看它发生那一刻哪个 todo 恰好in_progress与这步的内容无关。2.2 三个根本缺陷为什么必须换底座而非修游标框架无 todo 关联信号deepagents 的 streammessages 模式 metadata只有langgraph_node/namespace没有任何字段能把一条 message/工具关联到 todo。隐式游标是在硬凑一个不存在的信息——怎么修都是近似。multi-in_progress → 空壳 todolangchainTodoListMiddleware的工具说明书鼓励模型并行标多个in_progressmark your first task(or tasks)as in_progress与灵思 system prompt「只允许一个」自相矛盾。一旦模型并行标记_status_transition对每个都发TaskStart前端 N 个 todo 亮 running但_refresh_in_progress的break只认列表第一个做游标 → 所有步骤堆到第一个、其余是亮着 running 却没有任何过程的空壳 todo。这不是 bug 可补是「时间游标」在并行下的本质局限主图是单 agent 顺序流todo 是备忘录、不是执行隔离边界真正的硬隔离只有子代理 namespace。无可靠全局序BaseEvent.timestamp只有秒级 int无全局自增序。这堵死了前端把多个 todo 桶合并重排成单条流的退路同秒必乱、且子代理步骤时间戳早于主图委派帧——倒逼 B2后端单桶天然有序。三者叠加的结论归属做不到、修不好唯一稳健的出路是不再归属改以 write_todos 切段。2.3 现成基础设施活动摘要 旁白通道活动摘要R1 几乎零新建summarizeActivityclassifyActivity已实现 8 类计数已排除 thinking/ls/write_todos/ask_user见 stepUtils.tsACTIVITY_I18N三语文案已就绪见 execTokens.ts。8 类联网搜索 / 检索知识库 / 读取文件 /编辑文件新建覆盖追加合并一档/ 导出文档 / 运行代码 / 查找文件 / 执行操作。R1 本质只是把它接到段标题上 无动作回退。旁白通道现在是断的R2 关键stream_event_mapper._handle_messages对模型纯自然语言正文AIMessage.content一律丢弃最终答案另走 values →ResultSection。Claude 那种工具批次间一句旁白 这条被丢弃的 content。R2 必须先在后端接通它——这是 R2 风险高于 R1/R3 的根因。3. 方案write_todos 段流重构3.1 核心从「归属」降维到「切分」隐式游标现状write_todos 段流本方案在回答什么问题这步属于哪个 todoattribution段的边界在哪segmentation依赖什么当前 in_progress 是谁模型纪律write_todos 出现在哪确定性事件multi-in_progress错位 → 空壳 todo不读 in_progress 集合问题蒸发框架支持❌ 无 todo 关联信号✅ write_todos 是流里的实锚点段流定义执行流 单条按 write_todos 边界切出的「段」序列。两次 write_todos 之间的步骤聚成一个一级段子代理namespace 硬边界天然独立成段首个 write_todos 前为规划段、末个 completed 后为收尾段。段标题 活动摘要 用时R1段间穿插旁白R2子代理段内部铺平R3。利好write_todos 调用在后端本来就产出一个可见 ExecStepmessages 模式经_handle_tool_starts无过滤前端目前在mergeStepFrames把它当噪声丢弃。本方案只需把丢弃改成留作不可见的段边界 marker——锚点是现成的。这一点在 stepUtils.ts 的mergeStepFrames与buildTimelineGroups中已落地write_todos 帧被保留、打标为段边界但永不渲染为行。3.2 落地决策B2后端单桶B1 否决B1前端重组多桶已否决要把sessionSteps N×tasks[].history合并成单条流唯一排序键是秒级 timestamp缺陷三→ 同秒乱序、子代理步骤错排。mergeStepFrames又只信数组序、从不重排。退路堵死。B2后端单桶采纳后端把所有主图 ExecStep 的task_id统一改成svid它们全部 append 进id svid的会话桶 historyappend 顺序 真实执行顺序是可靠全局单调序、无需 timestamp 排序。前端直接渲染这一条流。支撑 B2 的已核验事实子代理识别纯靠extra_info.namespace与 task_id 无关→ 改 task_id 不影响子代理段R3 不回归。这一点在 stream_event_mapper.py 的_handle_tool_starts/_build_end_step中可确认namespace 始终写入extra_info。TaskPanel只读tasks[].status→_diff_todos/TaskStart/TaskEnd/GenerateSubTask全保留即可驱动勾选与段流脱钩、零回归。id svid会话桶行已由_ensure_session_pseudo_task建好、add_execution_task_step已支持 upsert能承载整条流。3.3 后端改动stream_event_mapper.pyagent_factory.py原计划的task_exec.pyper-round 会话桶已砍掉勘察证明 reload 不分轮、B2 落svid桶即零回归。后端只剩 mapper prompt 两处改动改动位置内容task_id 统一 svid_handle_tool_starts、_build_thinking_step、_handle_interruptcurrent_in_progress_task_id or svid→self.ctx.svid落现有id svid会话伪任务桶tool-end 继承 open_call自动跟随删隐式游标_refresh_in_progress、其在_diff_todos的调用、StreamContext.current_in_progress_task_id字段整段删除三处盖戳改 svid 后无消费者prompt 收口agent_factory删「同一时刻只允许一个 in_progress」一句顺应框架并行、消矛盾保留「只翻转 status 不改文案」「子代理并行 ≤2~3」保留_diff_todos3 级对齐 /_stable_task_id、_status_transition、GenerateSubTaskTaskPanel 唯一数据源绝不动write_todos 帧_handle_tool_starts现状即产可见 ExecStep保持产出——落当轮桶后顺序即真实 write_todos 时刻作前端段边界锚点从当前仓库源码看B2 已经落地stream_event_mapper.py 中_handle_tool_startstask_id self.ctx.svid、_build_thinking_steptask_id self.ctx.svid、_handle_interrupttask_id self.ctx.svid三处均已统一为 svidStreamContext中已不存在current_in_progress_task_id字段_diff_todos的注释也明确说明projection still drives TaskPanel signals … it no longer needs an in_progress cursor。prompt 侧agent_factory.py 的_LINSIGHT_SYSTEM_PROMPT_TEMPLATE_ZH中保留的是「同一时刻并行委派不超过 2~3 个」与「更新待办时只翻转 status不改写已有文案」已无单 in_progress 要求与 write_todos 工具说明书不再矛盾。3.4 前端段流stepUtils.ts为主含 R1/R3/R2 接线改动位置内容write_todos 转段 markermergeStepFrames从丢弃集移除 write_todosask_user/ls 仍丢弃改为打标保留extraInfo.segmentBoundary仅作切段信号、不 inline 渲染。classifyActivity已对它返 null不污染 R1 摘要计数段边界切断点buildTimelineGroupsnode.kind step分支判isSegmentBoundary(step)→ flush 当前 episode 且不 push marker子代理组仍 flushpassthrough。改动局限单函数R1 段标题DeepStepGroup的label接summarizeActivity(group.steps)ACTIVITY_I18N拼活动摘要 用时 N 秒摘要空纯 thinking回退「深度思考」compact子代理内仍去时间子句R2 段间旁白DeepStepGroup段头下方接已实现的narrationFromSteps取段内 thinking 末句其上游依赖后端接通 contentSpike 先行R3 子代理拆平完全拆平渲染层ExecutionTimeline 新增explodeSubagentGroupstepUtils每子代理升为独立一级段explodeSubagentGroup把subagent_group爆成「每子代理一段」复用DeepStepGroup新增subagent头goal·活动摘要 子代理图标。buildTimelineGroups与其测试不变爆破在渲染层。删SubagentTeamGroup/SubagentTrack。代价丢「N 个并行」分组信号渲染塌缩零改 carrier—无需改ExecutionFlow/ConversationRound/TaskTurnPanelB2 后新数据task.history皆空 →TaskStepRow命中!hasSteps自返 null既有ExecutionTimeline history{sessionSteps}/自动成段流。比删 TaskStepRow 更安全老 reload 数据仍经 TaskStepRow 渲染免费向后兼容退役TaskStepRow保留不删——它对空 history 自失效且承载老 reload 数据的向后兼容从当前仓库源码看前端改动同样已经落地stepUtils.ts 中isSegmentBoundary定义step.name write_todosmergeStepFrames不再丢弃 write_todosbuildTimelineGroups在段边界 flush episode、call_user_input作为另一类段边界内联 IntentRowexplodeSubagentGroup将每个子代理按 namespace 拆为独立SubagentSegment。DeepStepGroup.tsx 中 R1 通过summarizeActivityACTIVITY_I18N生成活动摘要标题纯推理段回退R2 通过narrationFromSteps取段内 thinking 末句作为旁白降级路径仅折叠态渲染、空则不渲染。渲染示例目标态执行流单条 · 按 write_todos 切段 ✦ 检索知识库 3 次 · 读 2 文件18 秒 ← 规划/首段 「先摸清已有材料。」 ← R2 旁白 ✦ 联网搜索 5 次 · 读 3 文件42 秒 ← 段2 ✦ 调研框架A · 执行 5 工具38 秒 ← 子代理段namespace 硬边界 ✦ 撰写交付物 · 写 1 文件26 秒 ← 收尾段 ──────────────────────────────── 底部 TaskPanel☑任务1 ☑任务2 ☐任务3 ← 计划清单独立、与段流脱钩4. R1 活动摘要把「已深度思考」换成「干了什么」R1 的核心是把一级段标题从「已深度思考用时 382.0 秒」改为「活动摘要 用时 N 秒」。实现要点源码确认计数分类classifyActivity按工具名小写分类顺序敏感——knowledge/search 在通用 search 之前判断保证search_knowledge_base落入knowledge而非web_searchwrite/edit 家族在 read 之前判断保证add_text_to_file等不被read吞掉thinking/ls/write_todos/ask_user永不计数见 stepUtils.tsclassifyActivity。统计与排序summarizeActivity遍历段内 steps排除 thinking 与 call_user_input分类计数后按 count 降序返回空输入或纯推理段返回[]。三语文案ACTIVITY_I18N将 8 个类别映射到 i18n keycom_linsight_act_web_search/com_linsight_act_knowledge/com_linsight_act_read_file/com_linsight_act_write_file/com_linsight_act_export/com_linsight_act_code/com_linsight_act_browse/com_linsight_act_other每个短语带一个{{0}}计数占位符见 execTokens.ts。标题组装DeepStepGroup中activityText用·连接各分类短语标题图标按主导活动切换write_file主导时用 Write 图标子代理段用 PeopleRound 图标其余用 Bulb 灯泡图标无活动纯推理时回退「深度思考」标签。文件编辑合并一档新建/覆盖/追加不拆 created/edited统一归为「编辑 N 个文件」。渲染层级段默认折叠含 live 尾段折叠头仍通过NarrationTicker流式更新最新思考用户手动展开读完整推理。5. R2 自然语言旁白把机器在干活翻译成同事在汇报R2 的目标是在段与段之间穿插一句模型的自然语言旁白。原方案的正路是后端 mapper 接通被丢弃的AIMessage.content通道 prompt 引导——stream_event_mapper._handle_messages此前对纯自然语言正文一律return []丢弃这正是 R2 风险高于 R1/R3 的根因。当前仓库已落地的是一条降级旁白路径不依赖后端 content 通道extractNarration从段内 thinking 文本中抽取一句自然的旁白先清理 markdown 噪声标记、按句子边界CJK 句号与换行恒切分ASCII 句点仅在跟空白/结尾时切分避免小数/股票代码误切切成单元再做三遍扫描挑选——优先「带终止符的严格散文句」其次「任意严格散文单元换行边界也算」最后放宽为「带终止符的基础散文句」结构性垃圾括号枚举、冒号列表、编号大纲、泄漏的工具名、scratch 路径每轮都拒掉抽不出自然句则返回空串绝不把垃圾上屏见 stepUtils.tsextractNarration。narrationFromSteps取段内最后一个 thinking 步骤的输出做抽取运行中取最新思考段末句live 旁白结束后取最后思考段末句总结句。DeepStepGroup在折叠态、段头下方渲染NarrationTicker逐句推进、带垂直淡入淡出空则不渲染不占用视觉噪音。文档明确保留的待办「好」路径后端接通AIMessage.content prompt 引导仍欠需对真实 DeepSeek 流做 Spike本地↔116 隧道不稳环境就绪后再做并需确保最终答案不被同时渲成 narration ResultSection仅在 tool-call 前 flush、流末丢弃。6. R3 子代理拆平去外壳每个子代理独立成段R3 的目标是去掉「团队外壳 → 子代理 → 已深度思考 → 工具」四层嵌套改为每段一级、工具二级。实现要点源码确认子代理识别纯靠 namespace主图task委派帧step_type subagent、nsNone只记录委派 goal/name不产生节点子代理内部步骤按extra_info.namespacetools:uuid桶分每个 distinct namespace 成为一个子代理3 个 distinct ns 得 3 个 agent而不是 22 个步骤。agentByNamespace在整个任务期间持久即使中间插入顶层步骤后续同 ns 步骤仍归回原 agent见 stepUtils.tsbuildFlowNodes。爆破在渲染层explodeSubagentGroup把subagent_group按agents顺序爆破成「每子代理一段」的SubagentSegmentgoal 按顺序对齐仅当 goal 数与 agent 数相等时才对齐否则回退「子智能体 N」复用DeepStepGroup的subagent头goal·活动摘要 子代理图标。buildTimelineGroups及其测试不变。接受的代价弱化「N 个并行」的分组信号——团队组两件套SubagentTeamGroup/SubagentTrack删除。时间跨度修复对零跨度deep_step_group单帧 thinking 只带一个秒级时间戳导致startedAt endedAt做时长修复——以「下一个节点开始时间」估算本段结束时间且带next start保护避免子代理乱序时间戳造成负跨度运行中组交给 live ticker。7. 实施次序与当前进度7.1 三波实施次序Wave内容特征Wave 0per-round 会话桶已砍勘察证明 reload 不分轮、B2 落svid桶即零回归per-round 桶是独立新功能而非前置。后端直接从 Wave A 起。Wave A后端单桶svid 删游标 prompt 收口3 处 task_id →self.ctx.svid、删隐式游标_refresh_in_progress 其调用 字段、删单 in_progress 要求单 PR。Wave B前端段流 R1 R3纯前端紧随 A与 A 有契约耦合write_todosname作段锚点建议同分支、分 commit。Wave CR2 旁白本轮内、最后做Spike → 后端 content prompt 前端风险最高、放最后但仍在本轮。先抓真实 DeepSeek 流验证工具批次间 content 产出率产出稀疏则降级prompt 强制 / thinking 末句派生。原则先落底座A/B最小可见收益尽早R2 的不确定性靠其内部 Spike 闸门隔离、不阻塞 R1/R3。7.2 实现进度截至文档修订Wave A 后端✅ mapper 三处 task_id →self.ctx.svid 删隐式游标方法/调用/字段✅ prompt 收口已落删单 in_progress 要求。test/linsight/全绿327 passed。Wave B 前端✅ 段流mergeStepFrames保留 write_todos 作边界 buildTimelineGroupsflushR1 段标题活动摘要 用时纯推理回退「深度思考」新增 i18ncom_linsight_act_summary×3 语R3完全拆平explodeSubagentGroupDeepStepGroup.subagent头删团队组两件套。Execution/*.test39 passed、touched 文件 tsc 零新增错误。Wave C R2✅ 降级旁白已落DeepStepGroup接narrationFromSteps取段内 thinking 末句仅折叠态渲染、空则不渲染。⏸「好」路径仍欠后端接通AIMessage.content prompt 引导需对真实 DeepSeek 流做 Spike。待办① 对抗式 review② E2E 目检段切分 / R1 标题 / R3 扁平 / R2 旁白 / TaskPanel 勾选live≈reload需真机③ R2「好」路径 Spike。从当前仓库源码看上述 Wave A/B 的改动均已存在见 §3.3、§3.4 的源码证据与文档「实现进度」小节一致R2 的降级路径也已在DeepStepGroup中落地。8. 风险与回归清单multi-turn已澄清无需后端改动reload 今天即单条合并history[]仅 live 客户端快照填充、reload 入口不重建B2 落svid桶后 live 仍靠现有客户端快照分轮、reload 仍单条合并今天行为。回归只需确认「B2 后 live 多轮分轮不变 reload 不更糟」不引入per-round 桶/迁移。「reload 按轮分开展示」是另一条独立增强、不在本轮。R3 单文件 ≤600 行stepUtils.ts复核必要时拆出clarifyUtils.ts。R2 可行性DeepSeek 中途 content 产出率是 Spike 唯一判据adherence 风险须正视留降级路径。需确保最终答案不被同时渲成 narration ResultSection仅在 tool-call 前 flush、流末丢弃。prompt 矛盾本轮删除单 in_progress 要求解决删 system prompt「单 in_progress」一句、顺应框架并行后矛盾消失模型并行标记时 TaskPanel 如实亮多个 running反映并行意图、自洽非 bug。全路径回归liveWS 落svid→ sessionSteps/ reloadsvid伪任务 history →splitSessionPseudoTask/ 多轮 ConversationRoundlive 快照分轮reload 单条合并今天/ 分享只读 / clarify HITLask_user 仍走 ClarifyCard不进段流/ 规划段 / 收尾段 / TaskPanel 勾选status 驱动与段流脱钩。验证环境本地起前后端 连测试中间件mock 流补 write_todos×2 子代理真实 DeepSeek E2E 目检——无空壳 todo、段标题摘要、子代理铺平、reload≈live、多轮 reload 分轮正确。9. 测试落点后端test_stream_event_mapper.py删除current_in_progress_task_id相关断言新增 ① 全步骤task_id svid② write_todos 仍产可见 ExecStep段边界③_diff_todos仍驱动 TaskPanel ④ 子代理步骤task_id svid且 namespace 保留。从当前源码看该文件已包含「all main-graph steps land in the single session bucket (id svid)」「The implicit in_progress cursor is gone; steps are NEVER attributed to a todo」等断言注释与 Wave A 的验收一致。前端stepUtils.test.ts现有 write_todos「丢弃」用例语义反转为「切段」——[tool, write_todos, tool]→ 2 段、[tool, write_todos, subagent, write_todos, tool]→ 3 段write_todos 仍不作可见 stepsummarizeActivity排除 write_todos 用例保留。10. 总结本轮优化把灵思任务模式执行流的底层机制从「按 todo 归属的嵌套进度树」换成了「以 write_todos 调用为界的单条段流」本质是把问题从「步骤属于谁attribution」降维成「段的边界在哪segmentation」。后端 B2 单桶让所有主图步骤以真实执行顺序汇聚到id svid会话桶前端则把 write_todos 帧从丢弃噪声改造成段边界锚点在此之上接上 R1 活动摘要、R2 自然语言旁白、R3 子代理拆平三项体验优化。这一方案的关键可复用结论是当框架不提供某个关联信号时与其反复修补近似机制不如寻找流中真实存在的确定性事件来重新定义问题——这既是本轮执行流优化的核心决策也是 deepagents 类流式框架下执行流呈现设计的通用思路。【免费下载链接】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），仅供参考