【唤醒实战笔记】2026-09-29 | 工作流重构：适配 LLM 的真实特性
date: 2026-09-29
tags: [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
