Rig
用 Rust 构建模块化、可扩展的多模型 LLM 应用与智能体工作流。
可选功能、关闭若干依赖的默认特性、CI 最小化密钥暴露以及发布任务的显式权限体现了较好的最小权限意识；测试录音已脱敏，模型文件固定提交、大小和哈希。但示例从环境读取凭据而未说明运行时数据保留或密钥生命周期；框架未提供通用的用户确认门、外部工具副作用治理或事务回滚。临时下载可清理，AgentRun 可序列化，但都不等同于副作用恢复。仓库、版权和许可证归属清楚，不过发布者企业身份仍未知。
README、Cargo 功能映射、CI 注释与录音测试对架构、功能和测试策略高度一致，故自洽性满分。依赖版本、锁定构建、离线录音、重试及校验下载提高可用性，但大量云服务和第三方依赖仍受外部可用性影响。原生限定功能和下载脚本提供具体错误信息，不过所给材料未证明所有提供商及运行时路径都有同等完整的失败诊断。
材料覆盖基础 LLM、流式、多轮、工具调用、嵌入、媒体与向量存储等场景，但受众分层和部署决策指导仍有限。rig-core/rig-agent 分层、功能门、WASM/WASI 与 rmcp 边界十分明确，故能力边界满分。类型化工具模式和多步录音说明调用可精确组织，但具体触发策略最终由应用和模型决定。浏览器 WASM、原生限制、TLS 选项、Tokio 要求及逐包 CI 检查使环境适配证据充分。
README 目录、架构说明、集成表、文档入口和示例组织清晰；安装命令及 Tokio 要求足以入门，但凭据、生产部署和各提供商配置未在材料中完整展开。统一 facade 稳定了路径，同时明确警告未来会有破坏性变更，因此命名稳定性不是满分。示例、测试目录和录音覆盖丰富。已说明 WASI、rmcp、破坏性更新等限制，但没有综合限制清单。MIT 文本与清单元数据一致，许可证满分。存在明确版本及自动发布流程，却未提供实际 changelog 或迁移记录。版权主体、仓库和 issue 路径可识别维护渠道，但企业注册身份未经验证。
示例和录音展示了可直接消费的文本输出及多步工具结果，具有实际可用性，但未展示结构化输出质量、生产级结果验证或广泛场景的输出契约。统一 20 多个模型提供商、多个向量存储和可移植运行时带来明确的抽象与复用价值，边际价值证据强。功能门和最小样板代码有助于控制集成成本，但没有性能、费用、二进制体积或运维成本对比，因此成本收益不是满分。
主要架构和功能声明可在 Cargo 功能、工作流和录音中追踪；然而“使用者”名单及部分规模性、生产性表述仅由 README 陈述。README、清单、CI 与录音之间有多源相互印证，特别是功能边界、离线测试和多步工具调用，故交叉佐证满分。材料能区分警告、支持矩阵和测试策略，但营销性描述与第三方采用声明未始终附带仓库内证明。
- 该框架允许应用连接模型提供商、数据库和用户定义工具；部署者应自行增加逐项授权、外部写操作确认、审计和回滚机制。
- 环境变量凭据会被提供商客户端读取；应限制密钥权限，避免进入提示、日志、遥测或录音，并核查各提供商的数据保留政策。
- README 明确预告破坏性更新；升级前应固定版本并审查迁移说明、功能默认值和 facade 转发变化。
- 依赖面和可选集成较大；应在目标功能集合上运行依赖漏洞、许可证和供应链检查。
- 录音测试包含请求与响应正文；新增或重新录制录音时必须持续清除密钥、个人数据和服务端标识。
这个 Agent 能做什么，适合哪些场景？
Rig 是一个面向 Rust 开发者的库，用于构建模块化、可扩展的 LLM 应用，而不是可直接部署的独立聊天机器人。其架构将能力分为 rig-core 与 rig-agent：前者提供供应商无关的消息、模型、工具、记忆和向量存储契约，后者提供经典智能体构建器、提示与流式接口、类型化钩子、上下文工具、抽取能力及可序列化的 AgentRun 状态机。根 rig 包统一重新导出这两部分，并通过 Cargo feature 暴露数据库、向量存储、本地模型和云服务等配套 crate。应用可以调用模型完成与嵌入接口，执行多轮提示及流式工作流，并接入转录、音频生成和图像生成模型能力。可移植核心和经典运行时支持浏览器 wasm32-unknown-unknown，但 WASI 不受支持，rmcp 仅能在原生环境使用。采用者需要自行编写 Rust 应用、选择并配置模型供应商，并负责最终程序的构建和部署。
开发者通过 rig::providers 下的供应商客户端创建模型连接，再用 AgentBuilder 风格的 client.agent(...).preamble(...).build() 构造智能体，并通过 Agent::prompt(...).await 获取文本响应。rig-agent 负责多轮提示、流式处理、类型化钩子、上下文工具、结构化抽取以及可序列化的 AgentRun 执行状态；rig-core 则定义消息、完成模型、可移植工具、记忆和向量存储接口。模型侧统一覆盖完成与嵌入工作流，并可承载转录、音频生成和图像生成能力。数据侧可通过 feature 接入 LanceDB、Milvus、MongoDB、Neo4j、PostgreSQL、Qdrant、SQLite、SurrealDB 等后端，也可加入 FastEmbed、Candle、Vertex AI、Bedrock 等组件。最终产物是嵌入用户 Rust 程序中的响应、流式事件、抽取结果或 AgentRun 状态，而不是由 Rig 托管的成品服务。
- Rust 后端团队需要用同一套接口接入多个模型供应商，并减少各家完成与嵌入 API 的重复适配代码。
- 智能体应用开发者需要实现带多轮上下文、流式输出、上下文工具和可序列化运行状态的工作流。
- 检索增强应用团队需要把嵌入模型连接到 PostgreSQL、Qdrant、LanceDB、Milvus、MongoDB 或其他已列出的存储后端。
- 浏览器端 Rust/WASM 开发者需要在 wasm32-unknown-unknown 上使用可移植核心或经典智能体运行时，并能接受 WASI 和原生专属组件的限制。
- 需要多模态模型接口的 Rust 项目希望在同一框架内组织文本完成、转录、音频生成与图像生成调用。
- 希望观察模型调用的工程团队需要兼容 GenAI Semantic Convention 的遥测基础。
这个 Agent 有哪些优点和局限？
- 将 20 多个模型供应商置于统一接口后面，并统一支持完成与嵌入工作流，可降低 Rust 应用中的供应商适配重复。
- rig-core 与 rig-agent 分离，使只需要底层供应商契约的项目不必采用完整智能体编排层，同时根 rig 包仍提供统一入口。
- 提供 10 多种向量存储集成，并通过一项集成对应一个 Cargo feature 的方式控制依赖边界。
- 经典运行时包含多轮流式处理、类型化钩子、上下文工具、抽取及可序列化 AgentRun 状态机等具体编排能力。
- 可移植核心和经典运行时明确支持浏览器 wasm32-unknown-unknown，并兼容 GenAI Semantic Convention。
- 项目明确警告未来数月将快速增加功能并出现破坏性更新，采用者需要预留升级和迁移成本。
- 它是 Rust 库而非托管产品；团队必须自行实现应用入口、凭据管理、部署、错误处理和面向用户的界面。
- 浏览器支持存在边界：WASI 不受支持，rmcp 仅支持原生环境，部分组合不能跨目标直接复用。
- 示例依赖异步 Rust 环境和正确配置的 Tokio feature，新项目还需自行选择供应商并准备相应 API 凭据。
- 来源只演示了简单的 OpenAI 文本提示，没有给出成本控制、重试策略、生产部署拓扑或各供应商完整配置的统一示例。
如何安装或部署这个 Agent？
先准备 Rust 与 Cargo。在 Rust 项目中执行 cargo add rig；如果只需要供应商抽象，可执行 cargo add rig-core。需要配套集成时，在 Cargo.toml 中启用对应 feature，例如 rig = { version = "0.36.0", features = ["lancedb", "fastembed"] }。文档示例使用 Tokio，因此还需执行 cargo add tokio --features macros,rt-multi-thread，并加入示例返回类型所需的 anyhow。使用 OpenAI 示例前，需在运行环境中配置 openai::Client::from_env() 能读取的 OpenAI 凭据；来源未给出具体环境变量名称。
如何使用这个 Agent？
在异步 Rust 程序中导入 use rig::prelude::*; 和 use rig::providers::openai;，然后调用 openai::Client::from_env()? 创建客户端。通过 client.agent(openai::GPT_5_2).preamble("You are a comedian here to entertain the user using humour and jokes.").build() 创建智能体。接着执行 comedian_agent.prompt("Entertain me!").await? 并打印返回值。入口函数可使用 #[tokio::main] async fn main() -> Result<(), anyhow::Error>；Tokio 必须启用 macros 与 rt-multi-thread，或直接启用 full。若要使用存储或模型扩展，应启用对应的 rig feature，并从其根模块路径调用，例如 rig::lancedb 或 rig::fastembed。
这个 Agent 与同类方案有什么区别？
根 rig 包适合希望通过 feature 使用 rig-agent 及数据库、向量存储或模型配套 crate 的应用；rig-core 更适合只需要供应商无关消息、完成模型、工具、记忆和向量存储契约的项目。两者不是竞争产品：rig 是统一门面，而 rig-core 是更小的底层抽象层。
常见问题
Rig 会托管或部署我的智能体吗？
运行示例需要哪些凭据？
openai::Client::from_env() 读取环境凭据，因此需要有效的 OpenAI API 凭据；来源没有列出具体环境变量名称。其他供应商同样需要各自集成所要求的配置，但这里没有给出细节。可以在浏览器或 WASI 环境中运行吗？
wasm32-unknown-unknown。WASI 明确不受支持，rmcp 仅可在原生环境使用。是否必须使用完整的智能体运行时？
rig-core；需要经典构建器、流式提示、钩子、工具、抽取和 AgentRun 状态机时再使用默认启用的 rig-agent 或根 rig 门面。