下面是一个使用 Rig 构建的简单 Agent 示例。它定义了一个计算工具，并让 Agent 自主决定是否调用它。

为什么不用langChain？ 这个问题放到最后说

1 核心代码示例

在 Cargo.toml 中，只需要 rig-core 和 tokio。

use rig::{completion::Prompt, providers::openai};
use serde::{Deserialize, Serialize};

// 1. 定义工具的输入参数（强类型，类似 Java 的 DTO）
#[derive(Deserialize, Serialize, JsonSchema)]
struct AddArgs {
    x: i32,
    y: i32,
}

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::pub_error::Error>> {
    // 2. 初始化客户端 (这里以 OpenAI 为例，也支持 Gemini/Claude)
    let client = openai::Client::from_env();

    // 3. 定义一个工具 (Tool)
    // 在 Rust 里，工具就是一个带有元数据的函数
    let add_tool = rig::tool::Tool::new(
        "add",
        "Adds two numbers together",
        |args: AddArgs| async move {
            Ok(args.x + args.y)
        },
    );

    // 4. 构建 Agent (典型的 Builder 模式)
    let agent = client
        .agent("gpt-4o")
        .preamble("你是一个精通数学的助手。")
        .tool(add_tool) // 注册工具
        .build();

    // 5. 提示并运行
    let response = agent.prompt("请问 123 加上 456 等于多少？").await?;

    println!("Agent 回复: {}", response);

    Ok(())
}

简单不简单

• JsonSchema 派生宏： 在 Rust 里，通过 #[derive(JsonSchema)]，Rig 会自动生成 LLM 需要的 JSON 描述。这比 Python 里手动写描述字符串要安全得多，修改字段名时编译器会帮你检查。

• 异步原生 (Tokio)：由于 Agent 往往需要等待网络 IO（模型响应、API 调用），Rig 基于 tokio 构建，能完美集成到你的高性能后端服务中。

• 零碎抽象：Rig 不像 LangChain 那样强迫你学习 Chain、Memory、OutputParser 等几十个概念。它认为 Agent = Model + Prompt + Tools。这种扁平化设计让调试变得非常简单。

2 简易流程

既然第四步请求了gpt为什么第三步还要创建一个函数，难道gpt会使用这个函数吗？

当然!

这是非常关键的一个点，也是 Agent（智能体） 与普通 Chatbot（聊天机器人） 的本质区别。

答案是：GPT 可能会发出了一个“调用指令”。

这里把这个过程拆解为三个阶段（这在 Java 中类似于远程过程调用 RPC 或反射）：

1. 宣告能力

在第 4 步 build() 时，Rig 会把第 3 步定义的工具元数据（函数名：add，描述：Adds two numbers together，参数结构：x, y）转换成一个 JSON Schema，并随问题一起发给 GPT。

发送给 GPT 的隐藏信息：
“用户问了：123+456 等于多少？另外，我这有一个工具叫 add(x, y)，如果你觉得用得着，可以告诉我。”

2. 逻辑决策

GPT 接收到请求后，它不会直接回答“答案是 579”。它会分析语义，发现自己需要做数学运算，于是它不返回文本，而是返回一个 Function Call 请求。

GPT 返回给 Rig 的信号：
{ "call": "add", "arguments": { "x": 123, "y": 456 } }

3. 本地执行

这时候，Rig 框架（在你的 Rust 程序里）收到了这个信号。它会：

• 在本地查找到我们刚注册的那个 add_tool函数。
• 把 GPT 给出的 JSON 参数反序列化为 Rust 的 AddArgs 结构体。
• 真正运行我们的 Rust 代码（执行 x + y）。
• 把结果 579 再发回给 GPT。
• GPT 看到结果后，最后组织语言回答你：“123 加上 456 等于 579。”

这就是agent的过程。但是你应该会问：“为什么要这么麻烦？直接让 GPT 算不行吗？”
因为

• GPT 并不擅长计算： 对于 12345 * 67890 这种大数，GPT 经常会一本正经地胡说八道。

• GPT 无法触达外部世界： 它不能直接查询你的 MySQL 数据库，不能调用你的 Java 微服务接口，也不能读写本地文件。

通过这种模式，你可以把 llm 当成一个“大脑”，而把你的 Rust 函数当成它的“手”：

• 大脑（GPT） 负责拆解任务、理解意图、决定什么时候该用什么工具。

• 手（Rust 函数） 负责精准执行、访问私有数据、处理重型计算。

或者你把它想象成一个数据库查询 findUserById(Long id)， GPT 就能根据用户的聊天内容，自动调用我们本地的能力，好像是去数据库里查数据了。

3 为什么不用langChain?

LangChain 是目前生态最丰富、功能最完备的 Agent 框架，但它已经不再是唯一的选择。

现在不再把 LangChain 看作一个单一的库，而是一个全栈生态系统。
它之所以被认为“最完整”，是因为它覆盖了从原型开发、生产环境编排到后期监测的全生命周期。
有核心铁三角：LangChain + LangGraph + LangSmith。

Rig 呢

而Rig (rig-core) 代表了与 LangChain 完全不同的进化方向：极致的性能、类型安全以及底层掌控力。

• Rust 原生： 享受 Rust 的内存安全和零成本抽象。这意味着在处理数千个并发 Agent 请求时，它的资源占用远低于 Python。

• 类型安全（Type Safety）： 在 LangChain 里，你经常会遇到“运行时错误”（运行到一半才发现变量类型不对）。而在 Rig 中，依靠 Rust 强大的编译器，大部分逻辑错误在代码编译阶段就能被揪出来。

• 极简抽象： 相比于 LangChain 嵌套五六层的类继承，Rig 的设计非常扁平，代码读起来直观得多。

流程编排呢

Rig 并没有像 LangGraph 那样引入复杂的“图”概念。（现阶段）它倾向于让开发者通过 Traits 和 异步流 来处理逻辑。

• Rig 的解决方式： 它提供了一套清晰的 Agent 和 Tool 定义规范。虽然它没有内置像 LangGraph 那样的“可视化状态机”，但通过 Rust 的枚举（Enums）和模式匹配（Pattern Matching），能写出比 Python 更加严密的状态转换逻辑。

• RAG 支持： Rig 内置了非常轻量化的向量存储抽象，特别适合构建高性能的检索增强生成应用。

最后，最重要的一点，这毕竟只是一个demo，怎么简单怎么来 😄