fx适配器重构：宿主运行，沙箱执行

AI SDK 的 HarnessAgent 更新了 fx adapter：负责驱动 Agent 执行的 harness 和模型请求，现在与应用运行在同一个进程里；内置文件系统、Shell 操作仍留在沙箱。调整的重点是执行位置，而不是模型能力。

新版还加入内置工具筛选、运行中追加指令、结构化输出和图片工具结果，并支持保存会话后在新的宿主进程中恢复。对接入 HarnessAgent 的开发者来说，值得关注的是部署链路、凭证边界和交互方式发生了什么变化。

哪些回到宿主，哪些还留在沙箱

这里的 harness，可以理解为负责组织模型请求、工具调用和执行流程的运行层。新版 fx adapter 把它放回应用所在的宿主进程，模型请求也在这个进程中发起。

内置文件系统和 Shell 操作依然在沙箱里执行。也就是说，运行层搬了位置，执行命令和操作文件的隔离边界仍然保留。

新版最直接的变化，是模型凭证留在宿主，不再转发进沙箱。

原文没有进一步交代凭证存储、日志处理或宿主权限设计。因此，能确认的是凭证不再进入沙箱，不能据此推断整套应用已经具备完整的安全保障。

接入链路少了哪几环

新适配器使用 libfx，也就是 fx 的 TypeScript 库。相比此前的实现，它不再需要：

• 在沙箱内安装 fx。
• 运行连接宿主与沙箱的桥接服务。
• 暴露沙箱端口。

这几项删减有实际意义：接入方少了一些需要安装、启动和配置的环节，排查问题时也少了几个中间组件。

但原文没有提供启动耗时、请求延迟或资源占用的对照数据。可以判断它简化了运行结构，暂时不能把「更快」「更省资源」当成已经验证的收益。

新能力分别解决什么问题

这次重写还带来了四项能力。原文每项重复出现了两次，按内容看实际是四项更新。

内置工具筛选允许开发者选择 Agent 可以使用哪些内置工具。它适合用来明确一次任务的能力范围，但原文没有列出具体工具名称，也没有给出配置 API。

运行中引导（Mid-turn steering）允许在一轮执行尚未结束时发送新指令。它为用户中途补充要求提供了入口。不过，新指令何时生效、能否影响已经开始的工具操作，原文没说清。

结构化输出支持生成符合 schema 的响应。对于需要把 Agent 结果交给后续程序处理的应用，这比依赖自由文本更有接入价值；具体 schema 写法和异常处理方式仍需查看实际接口。

图片工具结果则可以通过 toModelOutput() 返回给模型。关键在于，工具返回的图片能够进入模型输入。原文没有给代码，也没有说明图片格式或模型兼容范围。

此外，会话可以保存，并在新的宿主进程中恢复。它说明恢复不必依赖原来的宿主进程持续存活，但没有承诺正在执行的工具操作也能从中断位置继续。

我的判断

我更看重这次更新对接入复杂度的削减。少安装一个沙箱内组件、少维护桥接服务和端口，再把模型凭证留在宿主，这些都是明确的结构变化。

与此前在沙箱内运行 harness 的方式相比，新方案把应用侧的执行组织和沙箱内的文件、命令操作分开了。这个边界容易理解，但宿主也承担了 harness 与模型请求的运行职责，接入方仍需评估宿主进程的资源和故障影响。

原文是一则更新公告，没有测试方法、对照数据或迁移案例。因此，它足以支持「部署结构更简洁」的判断，还不足以证明性能、稳定性或整体安全性全面提升。

升级指引也比较简略：将 @ai-sdk/harness-fx 更新到最新版。公告未给出具体版本号、最低兼容版本或迁移步骤，正式升级前需要核对这些信息。

能拿来做什么

• 如果你的应用已经使用 @ai-sdk/harness-fx，可以先在测试环境升级，检查原来安装 fx、启动桥接服务和暴露端口的配置是否还需要保留，并验证内置文件系统、Shell 操作仍在沙箱执行。
• 如果你在做带进度展示的 Agent 界面，可以评估运行中追加指令的交互，同时确认新指令何时生效，避免界面承诺超出实际能力。
• 如果 Agent 结果需要进入后续程序流程，可以评估结构化输出；如果已有工具产生图片，则可以检查 toModelOutput() 的图片返回方式。
• 如果服务重启后需要恢复会话，可以验证保存与恢复流程，重点检查恢复后的上下文和工具状态，不要直接假设它等同于正在执行任务的断点续跑。