智能体产品一旦从“回答问题”走向“完成任务”，工具调用就会从偶发动作变成主干能力：查库、跑SQL、调外部API、做长链路检索、生成长篇报告、汇总多轮分析，任何一个环节都可能把用户晾在原地十几秒甚至几十秒。对工程团队来说，这类耗时并不罕见：模型推理在加长上下文后自然变慢，外部服务有排队与限流，数据查询要等索引与Join，生成长文还涉及结构规划与校对。问题是用户并不关心“为什么慢”，他们只感知到界面停住、没有反馈、像是卡死，于是中断请求、重复提交、投诉，甚至把系统判定为不可靠。
因此，“流式”工具调用并不是锦上添花，而是一种把可用性拉回到及格线的交互与架构能力。它的目标不是让任务真实更快，而是让等待变得可理解、可控、可介入，让用户看到系统在推进，并在推进过程中持续收到阶段性价值。最贴近的类比确实是视频缓冲：即便网络不稳定，播放器也会告诉你进度、先播一部分、必要时降码率，保证体验连续。把这种思想迁移到智能体系统，就需要从协议、编排、工具接口、内容生成方式和前端呈现五个层面重新设计。
一、先把“流式”说清楚：不是一边想一边吐字，而是可审计的阶段性交付
很多团队把“流式”理解为模型输出token的Streaming，这当然重要，但在工具调用场景里远远不够。用户真正需要的是“任务进展的可见性”和“结果价值的提前兑现”。前者意味着系统能持续输出状态事件，例如已启动检索、已命中数据源、正在汇总、正在生成报告第2节；后者意味着系统能分块输出可用结果，例如先给目录与关键结论，再逐段补充论据与引用，或者先返回Top-N查询结果，后续再补全细节字段与统计汇总。
更关键的是，这些分块输出必须可审计、可回滚、可重试。工具调用天然存在不确定性：网络失败、权限不足、查询超时、返回数据格式变化。若系统已经向用户“流式承诺”了某些内容，就必须能解释它来自哪个阶段、是否最终确认、是否仍在等待校验。否则流式输出会变成另一种“胡乱输出”，短期看像很快，长期会侵蚀信任。
因此，面向工具调用的流式体系，至少要区分三类事件流：
1. 状态流（progress events）：告诉用户现在在做什么、做到哪一步、预计还要多久或还差什么输入。
2. 结果流（partial results）：把阶段性
