TanStack AI 1.0 升级边界：核心转稳定，Agent harness 仍需独立评估
1. 发布范围：稳定承诺有明确例外
已报道事实： 2026年10月23日，TanStack 宣布 AI 1.0 发布，76个包进入稳定版，覆盖聊天、工具、媒体、MCP、持久化和沙箱等能力。官方将1.0定义为对 API 的正式承诺，并称这些稳定包已可用于生产；同一公告明确排除新增的 Agent harness，其 API 仍属实验性。
分析： 对构建 AI 应用的团队，这意味着应将核心升级和实验性运行框架接入拆成两个审批决定。官方的生产就绪声明可以作为维护承诺的信号，不能替代对具体应用的验收，也不能延伸为对 harness 的稳定性保证。
2. 可用能力：先核对需求是否落在稳定范围
已报道事实： 官方列出的1.0能力包括23个提供商适配器；自 RC 以来的新增项包括 chat() 和 useChat 中的子 Agent、用于类型化选择或评分的 decide()、按需加载的 Agent Skills，以及长对话压缩。新的 harness 被单独标注为实验性。
分析： 需要工具调用、子任务委派或长对话管理的团队，可以先评估这些已列入1.0的能力是否够用，不必仅因产品包含 Agent 就引入 harness。反过来，若需求的关键是长期任务生命周期，应单独评估运行框架；稳定核心的存在并不能回答任务恢复语义是否符合业务要求。
取舍： 先采用满足需求的稳定能力，可缩小实验性 API 的依赖面；引入 harness 则需要为接口变化和任务状态验证保留工程预算。
3. 升级风险：弃用接口清理与前后端协同
已报道事实： 1.0移除了所有在0.x中标记为弃用的 API；官方称其替代接口此前均已在0.x提供。公告同时要求一起升级所用的 @tanstack/ai* 包，并明确1.0客户端需要1.0服务端。
分析： 迁移成本取决于两个条件：代码是否已消除弃用调用，以及部署流程能否保持前后端版本匹配。前者主要影响代码修改，后者涉及发布和回滚安排。分别由不同团队发布前后端的应用，应先解决版本协调，再决定上线窗口。
未验证建议： 先盘点依赖与弃用调用，在预发布环境用同一组版本执行回归，并准备成对回滚。对于浏览器仍可能运行旧客户端的应用，需明确旧会话的处理方式；现有材料没有提供完整的混合版本兼容矩阵，不能自行假定兼容。
4. 谁适合采用：按依赖风险划定边界
编辑判断： 现有 TanStack AI 用户若已跟进弃用提示，且能协调前后端发布，可以优先安排稳定核心的升级验证。新项目若需要公告所覆盖的聊天、工具或沙箱能力，可以将1.0列入评估范围；材料不足以证明它优于其他方案。
依赖长期运行 Agent 的团队，应把 harness 放在隔离试点中，并明确可接受的接口变更成本。若业务不能容忍恢复行为尚未验证、又没有替代执行路径，建议暂缓让关键任务依赖它。
有边界的决定： 核心迁移通过验收即可独立推进，无需等待 harness 成熟；harness 的接入则应有自己的验收门槛与停用方案。这样会增加一次独立集成评估，但能避免把稳定版迁移和实验能力试用混在同一发布风险中。
5. 上线前验证清单
以下为未执行的验证建议，不代表已测结果：
- 依赖与构建： 检查所有已安装的相关包是否按官方要求同步升级；清除弃用接口引用，并运行类型检查和构建。
- 实际调用链： 针对应用使用的提供商、UI、工具和 MCP 路径，验证请求、流式响应、工具结果与错误处理；只测实际依赖的组合，不用包的稳定标签代替覆盖。
- 发布与回滚： 演练前后端协同切换、旧客户端会话处理及成对回滚；若无法保证版本匹配，先暂停上线。
- harness 独立验收： 若试用长期任务能力，验证中途补充指令后的状态，以及任务中断、进程重启后的恢复行为。对具有外部副作用的工具，检查恢复是否造成重复执行或遗漏；这里列出的是待验证风险，并非已发现缺陷。
通过条件建议： 稳定核心以现有应用回归通过、发布和回滚可控为门槛；harness 还需有任务状态与外部副作用的可检查记录。任何关键行为无法确认时，将试点限制在可丢弃任务中。
证据与适用范围
本文仅依据所提供的官方发布文章摘录、官方博客索引和事件摘要。未检查包仓库、完整迁移文档或运行代码，也未执行兼容性、性能及故障恢复测试。harness 的持久会话、中途补充指令、重启恢复及0.x状态来自事件摘要，所附正文摘录未展示实现细节；因此不对恢复保证作结论。稳定和生产就绪均为项目方声明，两份来源不构成独立验证。
本文使用 AI 辅助起草，并经过独立模型审稿；属于来源分析，未进行独立性能测试。