基于 Rust 构建的人工智能应用正逐步从早期实验走向更加实用的形态，这是 JetBrains 与 Rust Foundation 联合举办的一场现场演示所介绍的内容。第一场会议重点介绍了开源 Rig 库，以及如何使用它构建依赖大语言模型的应用和能够调用工具、在应用内部执行任务的代理。
Developer Advocate Orhun Parmaksız 展示了一个使用 Rig 和 Ratatui 构建的小型编程代理，而 0xPlaygrounds 的 Rig 首席维护者 Stephen Korzeniewski 则讲解了项目的内部架构以及其 API 背后的设计选择。
面向模型提供商的统一接口
Rig 解决了大语言模型应用中的一个常见实际问题：OpenAI、Anthropic、Gemini 等服务各自拥有不同的 API，即使其中一些服务声称兼容 OpenAI API 也是如此。Rig 不让应用的各个部分直接绑定到某一家提供商的 API，而是提供统一的 Rust 接口，使开发者能够在不重写模型相关部分的情况下切换提供商。
该库围绕多个基本组件组织应用，包括提供商客户端、补全模型、代理以及代理可使用的工具。代理位于直接模型请求之上；它会添加执行超出输入文本到输出文本流程的任务所需的指令、令牌限制和能力。
代理指令在 Rig 中被称为 preamble，其作用类似于系统提示词，并会插入每个请求的开头。与模型提供商之间的网络通信通过异步接口管理，同时将许多异步工作的细节保留在库内部，让应用代码专注于所需的配置和行为。
工具让代理成为应用的一部分
Rig 通过 Rust 中的 Tool trait 定义工具。工具定义包括其名称、输入、输出和错误类型，以及调用工具时执行的函数。其定义还使用 JSON Schema 描述预期参数，使模型能够获得可供其提交的数据的结构化描述。
将工具注册到代理后，支持工具调用的模型便可以决定何时使用工具，并将工具结果整合到响应中。该函数可以执行计算、查询数据库、检索信息或连接到其他服务。工具还可以接收用于保存调用次数或缓存结果等状态的上下文。这一理念也适用于代理本身：可以将一个代理作为工具提供给另一个代理，从而在二者之间委派任务。
从演示到可测试的应用
Rat Code 项目使用 Rig 和 Ratatui，将这些组件组合成一个通过终端运行的小型编程代理。main.rs 文件初始化提供商客户端、模型和代理，而读取和写入文件、运行 shell 命令等能力则以独立方式定义，随后通过 Rig 的工具接口注册到代理中。
该应用还使用 Rig 的流式接口，分批处理响应，并在模型生成答案时更新终端界面。演示还介绍了钩子系统、工具调用的恢复机制，以及库所提供抽象背后的设计选择。完整代码演示从录制视频的 27:28 开始。
RAG、本地模型与测试
Rig 并不局限于托管模型提供商。它支持检索增强生成应用：将文档和用户查询转换为向量嵌入，然后搜索语义上最接近的文档，并将其加入模型上下文。该库提供与数据库的集成以及向量存储抽象；如果使用未被直接支持的数据库，也可以实现向量存储接口。
此外，还可以通过 Ollama 和 llama.cpp 运行本地模型，或使用 rig-candle 集成直接在 Rust 应用内部执行推理。该选项允许将模型权重嵌入应用，并通过 WebAssembly 运行受支持的模型，而不依赖托管模型接口或单独的本地推理服务器。
这些选项的重要性体现在模型和数据的运行位置上，但同时也带来了集成测试方面的挑战。Rig 主要依赖一种录制系统：测试会与真实提供商执行，并将 HTTP 流量保存到 YAML 文件中；随后，模拟服务器会在持续集成测试中重放请求和响应。该项目包含约 1,700 次已录制的交互，并会在每次合并请求中于几秒内重新运行这些交互。
这些测试可以验证软件集成是否持续正常运行，但无法衡量模型输出的质量，因为提供商更新模型后，输出可能会发生变化。因此，演示指出，针对在线模型进行定期测试是一种独立的方法，适用于依赖答案质量的应用。
编辑解读：开发者需要关注什么？
Rig 的实际价值并不只是增加一个新的提供商，而是将应用层与模型接口的具体细节分离，同时将工具、检索和本地推理保留在统一的 Rust 架构中。这可能降低更换提供商或运行方式的成本，但不会消除不同模型之间的行为差异，也无法单独解决输出质量评估问题。项目中的测试机制表明，确保连接正常工作是一回事，确认模型能够生成所需结果则是另一回事，后者需要在线测试和独立的评估标准。