跳转至

Rust 与智能体平台

Rust 现在已经值得被认真看作智能体系统基础设施层的一门语言，但它还不是围绕 LLM 智能体开发的通用答案。

到 2026 年，更有用的区分是两件事：

  • Rust 作为智能体基础设施语言；
  • Rust 作为厂商原生智能体构建语言。

前者已经相当有说服力，后者仍然明显不够均衡。

规范 Rust 平台案例（Canonical Rust platform cases）

Rust 基础设施（Rust infrastructure）应该通过三个规范案例（canonical cases）证明价值。支持分流（Support triage） 检查工具网关（tool gateway）、策略执行服务（policy enforcement service）、审批队列服务（approval queue service）、幂等语义（idempotency semantics）和审计管线（audit pipeline）。内部知识助手（Internal knowledge assistant） 检查记忆/索引层（memory/index layers）、检索服务边界（retrieval service boundaries）、来源证明（source provenance）、租户隔离（tenant isolation）和追踪处理器（trace processors）。事件协调（Incident coordination） 检查长期运行时（long-lived runtime）、MCP 兼容集成层（MCP-compatible integration layer）、出口控制服务（egress control services）、通知安全（notification safety）和控制平面可靠性（control-plane reliability）。

Rust 已经很适合哪些地方

Rust 特别适合这些要求明显的组件：

  • 需要可预测的性能；
  • 需要严格的契约类型；
  • 运行时开销要低；
  • 并发安全非常重要；
  • 服务会长期在线并承担网关职责。

这使 Rust 很适合以下层：

  • 工具网关；
  • 策略引擎与审批网关；
  • MCP 服务器与适配器；
  • 记忆与索引层；
  • 遥测采集器与追踪处理器；
  • 网络代理与出口控制服务。

这些地方真正受益的是严格契约、稳定性能和更少隐藏的运行时问题。

Rust 暂时不那么有优势的地方

如果你的首要目标是围绕模型行为、提示行为和厂商新特性进行最快速的实验，Rust 还不总是最优起点。

通常原因包括：

  • 官方 SDK 支持往往在 Python 和 TypeScript 上更强；
  • 新智能体特性的示例更多出现在这些语言里；
  • 托管智能体服务和评测工具往往先支持这些语言；
  • 动态语言在快速实验方面的生态更丰富。

所以 Rust 已经很适合平台基础设施，但并不总是最快的应用层迭代语言。

一手来源给出的信号

OpenAI 与 Anthropic

在 OpenAI 和 Anthropic 的官方智能体相关层里，重心仍然更偏向 Python、TypeScript 以及其他支持更完整 SDK 路径的语言。这并不意味着 Rust 不可用，但说明它还不是这些生态里的默认一等路径。

AWS

AWS 在这方面更强一些。它有成熟的 AWS SDK for Rust、官方 Bedrock Runtime Rust 示例，以及 Agents for Amazon Bedrock Runtime 的 crate 包。对于 Bedrock 周边的生产集成和较低层的平台服务，这已经是比较现实的选择。

Microsoft

Microsoft 的 Rust 路线在发展，但现有总览文档里 Azure SDK for Rust 仍然标为 beta 版。对某些基础设施工作来说这未必是问题，但它还不是一种和主要语言路径同等成熟的信号。

Rig

在 Rust 原生的开源生态里，Rig 是目前较明显的智能体相关项目。它适合做实验，也适合用来理解 Rust 优先框架的形态。但整体生态还没有稳定到足以成为本书里的跨厂商标准路径。

Rust 特别适合哪些智能体平台工作

Rust 最值得优先考虑的场景包括：

  • 为多个智能体共享的工具网关；
  • 策略执行服务；
  • 审批队列服务；
  • 与 MCP 兼容的集成层；
  • 追踪采集与审计流水线；
  • 对吞吐与可靠性要求很高的网络层。

在这些地方，Rust 的价值不在于让智能体“更聪明”，而在于让平台更稳定、更可控、更容易维护。

什么时候 Python 或 TypeScript 仍然更实际

如果你需要的是：

  • 以最快速度迭代智能体行为；
  • 第一时间使用厂商新 API；
  • 把评测与实验紧贴数据工具；
  • 快速做出演示和工作流密集型集成；

那么 Python 或 TypeScript 往往仍然更实用。

这在产品早期尤其明显：那时最大的风险通常不是网关性能，而是产品行为回路本身还没有稳定下来。

更现实的工程建议

对大多数团队来说，更成熟的路径通常是：

  1. 智能体行为与快速应用层迭代继续放在 Python 或 TypeScript。
  2. 基础设施关注点逐步抽到更严格的服务中。
  3. 当平台开始形成长期运行的运行时、网关或控制平面组件时，再引入 Rust。

这通常比为了语言纯度而强行把整个智能体栈都迁到 Rust 更稳妥。

如果你仍然想走 Rust 优先路线

那就最好保持现实感：

  • 先从一个基础设施服务开始，而不是整个平台；
  • 不要过早绑死在一个还年轻的框架上；
  • 把契约设计得尽量明确；
  • 在架构承诺之前先验证厂商 SDK 成熟度；
  • 不要在真正的平台约束还不清楚时先决定语言。

GitHub Copilot 案例：作为可嵌入库的共享运行时

GitHub：使用 Copilot 将其运行时迁移到 Rust（2026 年 9 月 16 日）讨论的不仅是语言选择，也是封装方式。原 SDK 以 Node.js 子进程启动无界面的 CLI，通过 stdin/stdout 上的 JSON-RPC 通信。即使应用使用其他语言，每个使用方仍需承担额外进程、V8、启动成本以及跨进程事件和文件系统操作传输。

目标是没有终端界面的共享运行时：通过 C ABI 暴露接口的原生库，供各语言 SDK 使用 FFI 嵌入。需要进程边界时，仍可使用基于 stdin/stdout 或套接字的独立服务器。这不代表整个 CLI 都变成了 Rust：文章发布时，将界面完全迁至公开 SDK 接口的工作仍在进行，部分调用仍直接访问运行时内部。

架构启示是分离用户界面、公开 SDK 和执行核心，再按核心的约束选择语言。C ABI 有助于跨语言集成，但不会自动规定内存所有权、回调顺序、取消或安全的会话释放。作者描述了不透明句柄比原生对象存活更久，以及已记录的取消未能停止活动模型循环等回归问题。编译成功不能证明行为兼容。

保留独立验证的渐进替换

GitHub 选择原地逐组件替换：将有限的 TypeScript 部分替换为带薄兼容适配层的 Rust 实现，并在同一次变更中移除旧实现。先迁移不涉及 I/O 或共享状态的纯辅助函数，再处理高耦合的会话编排。每个阶段运行现有 CLI 和 SDK 端到端测试，并逐步发布。这是作者对一次具体迁移的报告，不是要求立即删除旧实现的通用规则。

本书建议的可迁移步骤是：

  1. 固定可观察行为和独立端到端检查，包括持久化会话格式、回调、取消和完成。不得为了让新实现通过而削弱测试；契约变更应单独审查。
  2. 通过明确接口替换有界组件，先保持语义，再把优化和重新设计作为独立阶段。
  3. 小批量发布，配合可观测性和已验证的恢复路径；单独检查持久化状态兼容性，因为回退二进制文件不保证状态可恢复。

对纯函数而言，“两版同时运行并比较”较简单；但编排器拥有可变状态、调用工具并接收回调。两个活动实现可能因事件而分歧，或重复产生外部效果。比较前需要隔离状态、控制输入，并抑制或模拟副作用；这是本书建议，不代表 GitHub 使用了此类影子运行模式。

文中加速结果来自 C# SDK 和本地确定性响应服务器的系统测量：排除了模型推理与网络延迟，迁移期间也有其他系统变化。因此不能据此预测真实 LLM 任务耗时，也不能将其视为纯粹的 Rust 与 TypeScript 对照实验。部署位置的实用标准见语言与执行模式比较。

结论

Rust 已经值得进入这本书，但位置应该是 智能体平台层：

  • 网关；
  • 策略与审批服务；
  • MCP 与集成服务；
  • 可观测性与控制平面组件。

它还不应该成为本书里“如何构建智能体”的主线。更诚实的表述是：Rust 已经很适合智能体基础设施，但未必适合最快的智能体迭代循环。

下一步做什么