【唤醒实战笔记】2026-09-29 | 工作流重构适配 LLM 的真实特性date: 2026-09-29tags: [HarmonyOS, 端云协作, 智能体, 架构重构, LLM, 工作流, 小艺开放平台]type: 实战笔记一、v8 改了三件事指向同一个根v8 是这套系统最大的一次重构但它改的不是功能而是工作流的底层机制。摊开看是三件事数据链路FC工具模型从执行者变成参数生成器端插件从模型内嵌改成工作流节点推进机制从计划步骤编号驱动改成从历史记录往下推理路由机制退出标记从放在前面改成放在最后。三件事看着不相干其实指向同一个根——LLM 有三个改不掉的真实特性而旧架构一直在逼 LLM 假装它没有这些特性LLM 真实特性旧架构的假装新架构的适配不能透传数据输出都是逐字生成的让模型把结果逐字抄回来插件节点化数据直接传值没有记忆记不住步骤让模型写计划1. 2. 3.每轮从历史记录重新读流式生成边想边答让模型先给标记再给内容标记放到最后这一篇按这三件事一件一件讲清楚。二、数据链路从模型内嵌工具到插件节点化旧方式慢在哪模型抄数据是一个字一个字抄最初把端插件挂在模型内部function calling——模型调用工具工具返回数据数据回到模型上下文模型再往下走。这套方式最大的问题是慢而且慢得莫名其妙。反复测下来根因在于一个很容易忽略的机制模型收到端插件返回的数据后即使你在提示词里明确要求原文返回、不要改动它也做不到透传——它必须一个字一个字地把结果重新生成一遍。这是 LLM 的底层机制决定的模型的一切输出都是逐 token 生成的不存在原样透传这回事。哪怕是让模型复述一段它刚收到的数据它也是在用解码速度每秒多少个 token重新打字而不是内存里直接传值。于是产生两个后果慢模型解码速度成了数据透传的瓶颈。本该几毫秒传完的一份数据被迫按模型的生成速度慢慢吐出来有损重抄可能走样转写保真风险返回内容一长还可能被输出长度上限截断。v1 提示词里 FC 的定位就是这套旧方式的写照FC模型你的手。它严格按你的指示调用工具把结果带回来给你。“把结果带回来”——就是让 FC 把工具返回再逐字抄一遍。数据在整条链路里被 LLM 转写了三遍FC 回带 → 分析模型交付摘要 → 聊天模型回复其中 FC 那遍是纯搬运慢且无益。新方式端插件设成节点数据直接传值v8 把端插件从模型内部挪到了工作流里作为一个节点工具模型FC翻译者。它把你的意图声明翻译成结构化调用参数JSON平台按参数直接调用端插件执行它不再转述结果——插件返回原文由系统直接拼回给你。新分工分析模型只声明意图“查询标题含’金力’的任务”不写调用语法FC把意图翻译成结构化参数 JSON只蹦几十个 token平台按参数直接调用端插件插件节点FC 不碰返回返回原文作为工作流变量直接拼回分析模型——是传值不是生成。数据从被模型抄三遍变成直接传值。FC 从一个数据会经过的环节变成了数据不经过的环节。新架构冒出的新问题改成节点化不是万事大吉因为 FC 从搬运工变成了翻译官冒出新风险翻译损耗FC 把自然语言意图翻译成参数时可能走样意图说查费用被翻译成别的关键词。配套对账机制——FC 的参数 JSON 拼进下轮输入分析模型做意图 ↔ 参数 ↔ 返回三方对照发现走样就重新声明意图。批量配对插件直连后批量调用同工具同动作多条调用怎么配对插件返回的 echo 不稳定参数回显时有时无不能靠返回内容自己报家门。解决工作流给每条返回拼归属标注“对应 calls[N]工具.动作” 顺序双保险。三、推进机制从计划步骤到历史推理旧架构靠模型记我做到第几步v1 让模型自己写计划、自己数步骤计划1. [步骤1] → 2. [步骤2] → 3. [步骤3]当前调 [工具名] [action][参数] 填 [值]循环继续时已完成1. → 2.下一步调 [工具]这套设计把走到哪一步了这个状态交给了模型在每轮重新生成的计划里维护。而模型没有真实记忆每轮都是从头开始想——它根本记不住自己做到了第几步。新架构每轮从历史记录重新读v8 把计划/步骤编号整个删了你不制定计划、不写步骤编号。自由思考走到需要数据的地方声明意图拿到返回继续想。判断你在循环的哪个位置首轮思考历史为空/ 续轮思考历史末尾已有 [调用]/[返回] 记录续轮三段式铁律——复述最新执行 → 对照目标评估 → 三选一决策推进方式彻底变了每轮看思考历史里的 [调用]/[返回] 记录判断自己走到哪再往下推一步。我在哪一步不再靠模型记而是靠外部历史记录现查。根既然模型记不住步骤就别让它记——改成每轮从历史里重新读。这是对无记忆这个特性的顺势而为而不是逆着它硬撑。四、路由机制标记放到最后模型是边想边答不是想好再答LLM 是流式生成的——一边推理一边输出不是先在脑子里想完、再一次性写出来。这个特性决定了一件反直觉的事退出标记不能放前面必须放最后。v8 里退出输出是交付摘要内容在前标记【信息足够可以回复...】在最后一行。为什么必须放最后可以在回答中推理模型的推理过程就是交付摘要的内容写在前面推理完了退出标记才在最后一行跟上。内容和判定在同一次输出里自然衔接。不用有结论了还要循环一轮如果标记放最前模型得先输出我退出了但内容还没写完——要么内容被路由截断要么已经有结论了还得再循环一轮才能把话说全。标记放最后内容说完了标记也到了一次退出。一句话标记是结论不是预告。五、辐射存储流程同构化这次重构还有顺带收益——存储流程与主循环同构。原来存储流程是另一套存储侧的 FC 也是执行者也有转述层。重构后存储分析模型走同一套声明意图 → FC 翻译 → 插件直连的工作流存储侧 FC 执行者退役转述层一并移除。一套机制两个流程通用维护成本直接砍半。六、教训分清改提示词还是改架构把这次重构放进整个迭代时间线看它是唯一一次改提示词解决不了的升级。循环、澄清、零工具宣称前一篇讲过都能靠改提示词压住但数据被模型抄三遍“逼模型记步骤”标记放错位置这些根子在架构提示词写得再好也绕不开。通用判断标准模型行为问题循环、假装调工具、误提取→ 改提示词架构适配问题数据多经过一个环节、状态逼模型记、机制违背流式→ 改工作流。判断错方向就会在提示词里越改越拧巴。而最深的一层是别跟 LLM 的特性较劲。它不能透传数据、它没记忆、它流式生成——这些都是改不掉的。聪明的做法不是逼它装成别的样子而是让架构顺着它的特性长。学习小结v8 的工作流重构改了三件事指向同一个根——LLM 有三个真实特性不能透传数据、没有记忆、流式生成旧架构一直在逼它假装没有。①数据链路端插件从模型内嵌改成工作流节点因为模型收到插件数据后即使原文返回也要逐 token 重新生成一遍——既慢又有损节点化后数据作为变量直接传值FC 从执行者变参数生成器数据从抄三遍降到一遍代价是新冒出的翻译损耗三方对账和批量配对归属标注顺序。②推进机制从计划步骤编号改成从历史记录往下推理因为模型记不住步骤就每轮从 [调用]/[返回] 现查。③路由机制退出标记放到最后因为模型边想边答——标记是结论不是预告放最后才能一次说完就退出。顺带让存储流程同构化。最核心的判断模型行为问题改提示词架构适配问题改工作流——别跟 LLM 的特性较劲让架构顺着它长。懿路向前 · AI辅助整理2026-09-29