AI 任务还没结束，Mastra 已能把每一步进度发到界面

用户上传资料后，页面只转圈一分钟，最后突然出现一份答案。这类等待很难判断任务是在读取文件、调用工具，还是已经失败。Mastra 的 streaming 能力，值得从“让产品显示真正发生的进度”来看。

它没有要求把所有过程都包装成一句“正在努力思考”。官方文档把文字生成与工作流事件分成两种输出，应用可以分别接住，再决定给用户展示什么。

文字在增长，与步骤已完成，是两种信息

Agent.stream 的 textStream 持续返回文本片段，适合让答案边生成边出现。最终完整文字、步骤和用量等结果，则有各自的返回属性。

工作流的 Run.stream 走的是另一条路：它返回结构化事件。workflow-start、workflow-step-start、workflow-step-result、workflow-finish 等，分别说明一次运行及其步骤发生了什么，还可以区分暂停、挂起和取消。

这些事件带有 runId 和来源，便于前端对应到正确任务。页面不必把收到任意一条文本都当作“成功”，也不必因为连接还开着就一直显示同一种转圈状态。

教学情境中，一个资料处理任务可以显示“开始提取”“提取步骤完成”“正在组织答案”。这些状态应来自真实步骤，而不是根据等待秒数推算一个百分比。哪一步是应用定义的，也应该能在工作流里找到对应位置。

工具内部，也能交出中间材料

官方还展示 writer：工具可以通过 context.writer，工作流步骤可以通过 writer 参数发送自定义事件。示例在网络请求前发出 pending，请求完成后发出 success，最后再返回正式结果。

这让工具不必等全部工作结束才能反馈。比如，一次处理多份文件，可以在合适的处理边界发出已完成项的信息；用户看到的是工具提供的中间材料，而不是另一次模型凭空生成的进度描述。

开发者仍应谨慎命名状态。请求发出、收到响应和任务内容合格不是同一个阶段；工具返回成功，也不保证模型最后使用了正确材料。事件清楚，产品才更容易表达这些差别。

哪些进度值得留在历史

writer.custom 发出的 data-* 块默认可以进入消息历史。对于只在运行当时有用的高频日志，文档提供 transient: true，使它继续实时发送，但不保存到数据库。

这个开关会影响用户刷新之后看到什么：临时块不会重新出现，正式工具结果和非临时内容才从存储加载。如果一项进度也是用户以后需要的处理记录，就不应该随手标成临时。

Mastra README介绍了 TypeScript 的代理、工作流和应用集成。其核心采用 Apache-2.0，ee/目录为企业受限许可，托管平台与模型服务也各有条件。对于正在做长任务界面的团队，这套流式接口最有用的成果，是把“任务怎样推进”变成应用真正能读取的数据，再让用户看见有依据的进展。