你觉得预制 workflow 按需暴露怎么样

回复 群友 8714： 思路很对，本质上是把固定套路固化成确定性SOP（像现在的 Skills 或复合工具），用工程确定性换掉模型自己瞎试的几十步推理。但在长程任务里，“按需暴露”如果设计不好，很容易反手把前面聊的 KV Cache 炸穿，核心有三个取舍要注意： 1. 按需暴露不能改前缀，只能走结果注入 如果“按需暴露”指的是根据任务阶段动态修改 System Prompt 里的工具列表（Tools Schema）或系统指令，那每切一次阶段，整条对话的 KV Cache 前缀就彻底失效，100 轮下来全在付昂贵的 Prefill 算力。 正确的做法是参考 Claude Code 的 Skill 机制：头部只放极简的目录描述且全程冻结不动；当模型判断需要某个预制 workflow 时，主动调一个 read_workflow 工具，把具体的 SOP 步骤或脚本作为普通的 tool_result 追加到上下文末尾。这样既做到了按需加载，又严格保证了 Append-Only。 2. 把“多步推理”压成“单步复合工具（Macro Tool）”最划算 为什么一个循环能跑 100 轮？往往是因为原子工具太碎（比如改完代码要自己调保存、调 linter、调单测、看报错、再过滤日志，光这一套固定动作就占了 6 轮 ReAct 和 6 段思考）。 如果把这套高频固定链路预制成一个确定性的 workflow 脚本（比如 verify_patch 工具），按需暴露给模型一键调用，内部在代码层跑完校验只返回最终报错摘要，就能直接把 10 轮机械的 ReAct 压缩成 1 轮，从根源上砍掉中间毫无价值的思考链累积。 3. 边界在于：只封装“确定性肌肉记忆”，别封装“探索性分支” 预制 workflow 最怕写成以前那种死板的节点编排图。在 ca 排障或复杂检索里，一旦遇到预期外的报错，写死的 workflow 就会卡死或者逼着你写无数个 if-else。 所以预制的粒度应该是“微流程”（比如环境初始化、标准的 PR 提交流程、特定框架的调试套路），让模型保有主循环的驾驶权，把 workflow 当作按需查阅的操作手册或组合技能来调，而不是用 workflow 把模型关进笼子里。