传统 agent 在执行工具调用时，由于依赖“调用工具 -> 打断模型思考 -> 完成工具 -> 带着工具结果重新调用大模型”这一条路线，每次执行工具调用都会导致系统重新进入一轮模型调用。
即使在缓存命中率较高的情况下，这条路线仍然会造成大量重复性浪费：重复提交上下文，重复恢复任务状态，重复处理工具结果消息，重复让模型从被打断的位置继续生成。对于用户端来说，制造了大量因为缓存命中输入导致的成本，对于推理端（我没有接触过真实的推理端成本，因此只能根据公开信息查找），缓存也会占用大量内存并且寻找缓存的过程中也会造成大量算力浪费。
我有一个判断：
可预测式工具调用不需要打断大模型的推理与思考。
我将这条技术路线称为“续想（ThinkFlow）”。接下来本技术路线将简称为续想。
问题不在反馈，而在信息差
讨论可预测式工具调用时，最容易产生的误解是：既然不打断模型，是不是意味着工具反馈没有价值？
并不是。
工具反馈当然有价值。工具可能失败，可能被权限策略拒绝，可能遇到路径冲突，可能触发安全规则，可能出现文件系统异常。任何真实执行系统都不能假设工具一定成功。
真正关键的问题不是“反馈有没有价值”，而是“反馈是否携带了模型当前不知道的新信息”。
对于读取文件、搜索代码、联网查询、运行测试这类工具，反馈显然包含新信息。模型不知道文件内容，不知道搜索结果，不知道测试错误，不知道网页返回了什么。因此这些工具必须打断模型，把结果交还给模型，然后模型才能继续推理。
但对于一部分可预测式工具调用，情况不同。
例如模型准备写入一个文件。文件路径、文件内容、写入意图都由模型自己生成。模型天然知道自己要写什么，也知道自己为什么要写。工具成功返回“已写入”时，传统工具调用和可预测式工具调用之间并没有实质信息差。
这并不是说“写入成功”的反馈无用，而是说在成功路径上，这个反馈没有提供足以改变模型当前推理路线的新信息。
换句话说，传统工具调用把“执行确认”当成了“推理输入”。
续想要拆开的正是这件事。
什么是可预测式工具调用
可预测式工具调用指的是这样一类工具：
工具要执行的核心内容由模型自己生成。
工具成功后的状态可以由模型在调用前预测。
工具成功反馈不会改变模型当前计划。
工具失败反馈才会改变模型后续行为。
典型例子包括：
写入文件。
追加文本。
创建目录。
创建空文件。
复制已知内容。
在受控规则下做局部替换。
这些工具的共同点是：成功路径上的反馈主要是确认，不是信息获取。
这类工具当然仍然需要执行，仍然需要审计，仍然需要失败处理。但它们不一定需要在成功路径上打断模型推理。
与信息型工具的区别
信息型工具必须阻塞，因为模型不知道工具会返回什么。
例如：
read file
grep keyword
web search
run tests
run build这些工具的结果会改变模型的判断。模型必须看到结果，才能决定下一步。
可预测式工具调用不同。
例如：
write file A with content X
append content Y to file B
mkdir path C在这些动作里，模型已经知道 A、X、B、Y、C。如果工具成功，模型获得的新信息只是“执行环境完成了这个动作”。这当然是系统状态的一部分，但它通常不需要立刻反哺给模型，除非后续推理显式依赖这个状态。
所以，工具调用是否应该打断模型，不应该由“它是不是工具调用”决定，而应该由“它的返回结果是否携带模型当前缺失的信息”决定。
成功路径与失败路径应该分开
传统 agent loop 往往把成功路径和失败路径放在同一个同步机制里处理：
模型发起工具调用
模型停止
工具执行
返回结果
模型继续这种机制很统一，但也很粗糙。
续想更合理的抽象是：
模型生成可预测工具调用
执行系统接收并排队
工具成功 -> 记录状态，不打断模型
工具失败 -> 打断模型，反馈错误也就是说，不是没有反馈，而是反馈分流：
成功反馈进入执行系统和审计记录。
失败反馈进入模型上下文并触发修复。
这才是问题的核心。
成功路径不需要制造新的模型回合；失败路径必须能够及时中断并恢复。
可预测不等于盲目执行
可预测式工具调用并不意味着客户端可以盲目执行模型输出的任意文本。
相反，它对执行系统提出了更高要求：
工具调用必须结构化。
工具调用内容必须完整。
工具调用必须经过权限和路径检查。
多个工具调用的执行顺序必须与模型生成顺序一致。
工具执行结果必须被记录。
工具失败必须能中断模型并反馈错误。
续想只是说：当一个工具的成功反馈和模型已有意图之间没有信息差时，成功反馈不必成为模型推理的强制中断点。
安全边界仍然存在，审计仍然存在，错误处理仍然存在。
为什么必须保持顺序一致
可预测式工具调用还有一个重要前提：执行顺序必须稳定。
模型连续生成多个可预测工具调用时，后一个调用可能默认依赖前一个调用已经完成。例如先创建目录，再写入目录下的文件；先写组件，再写样式；先写配置，再写 README。
如果执行系统随意并发执行，就可能产生乱序副作用。
因此，可预测式工具调用不能简单理解成“并行执行工具”。模型的推理可以不中断，但工具副作用仍然必须保持与模型生成顺序一致。
不中断推理和无序并发不是一回事。
与传统工具调用的本质差异
传统工具调用的默认假设是：
工具结果一定是模型继续推理所需的信息。
续想的判断是：
一部分工具结果只是模型意图的执行确认，而不是新的推理输入。
这个区别很重要。
如果工具结果是新的推理输入，那就必须打断模型。
如果工具结果只是执行确认，那么可以让模型继续推理，把执行确认交给运行时系统记录。只有确认失败时，才需要把失败信息反馈给模型。
这不是取消工具反馈，而是把反馈放回它真正应该去的位置。
为什么这能减少浪费
设一次任务中有：
P 个可预测式工具调用。
B 个必须阻塞的信息型工具调用。
F 个失败修复回合。
传统工具调用的模型回合数量近似为：
1 + P + B可预测式工具调用的模型回合数量近似为：
1 + B + F当 P 很小，收益不明显。
但在大量写文件、生成文档、创建项目结构、多文件重构这类任务里，P 往往很大。此时，每一个不必要的同步回合都会放大上下文重复、调度延迟和状态恢复成本。
例如：当上下文在100k左右的时候，进行小说写作任务，写十章，传统tool-call行为会导致多吃十次上下文至少消耗1.1m的token，而续想技术路线则不需要打断，可以流式执行十次write文件命令，只需要消耗100k的token。
续想减少的不是工具执行本身，而是不必要的模型中断。工具调用的质量和数量并不会随着成本降低而降低。
边界
可预测式工具调用不适用于所有工具。
以下情况仍然应该阻塞：
模型需要读取外部信息后才能继续。
工具结果不可预测。
工具失败概率高且失败信息本身是主要推理依据。
工具有高风险副作用。
操作需要用户确认。
后续推理显式依赖工具完成后的状态。
可预测式工具调用不是万能加速器。它只适用于“成功路径与模型已有意图之间没有信息差”的工具。
结论
传统 agent 把所有工具调用都当成模型回合边界，是一种通用但粗粒度的设计。
对于信息型工具，这个设计是合理的；对于可预测式工具调用，它会制造大量不必要的中断。
可预测式工具调用的核心不是“工具反馈无用”，而是：
在成功路径上，模型已经知道自己调用可预测工具时写了什么，工具成功反馈与模型当前推理之间没有足以改变路线的信息差。
因此，这类工具可以在模型持续推理的过程中被执行和记录。成功时不中断，失败时再中断。
这就是“可预测式工具调用不需要打断模型的推理与思考”的原因。
在下一篇技术报告中，我会阐述我个人简单制作的续想agent及其技术路线报告，目前的agent受限于作者只是大二学生能力和资源都极其有限，仅是实现了证明技术路线可行性的半成品agent。目前已经同步发布至知乎。
续想agent以及技术路线已经开源网页链接，欢迎有能力有想法的团队完善这个路线，如果有交流意愿还请详聊，感谢参与讨论 作者：沐雪清泽（网名）
