> ## Content Index
> Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt
> Use this file to discover other available public pages before exploring further.

# Aura：我用Rust重写的LLM网关
- URL: https://www.hubwiz.com/blog/aura-the-llm-gateway-i-rebuilt-in-rust/
- Published: 2026-05-31T02:25:46.000Z
- Updated: 2026-05-31T02:25:46.000Z
- Description: 我是一个Python开发者。我用Claude Code构建了一个Rust LLM网关。
- Author: admin
- Tags: LLM, AI GATEWAY, #Import 2026-10-14 14:41

我是一个Python开发者。我用Claude Code构建了一个Rust LLM网关。以下是我为什么要往LLM网关的货架上再加一个：是什么让Aura是agentic原生的而不仅仅是OpenAI兼容的，如何在你的现有框架中使用它，以及作为一个非Rust开发者使用vibe engineering构建生产基础设施学到了什么。

## 1、为什么我要构建另一个LLM网关

已经有**好的**LLM网关了。LiteLLM是大多数团队首先选择的。Portkey有护栏和一个精致的管理面板。Helicone在可观测性方面领先。OpenRouter给你290+个模型放在一个OpenAI兼容的URL后面，支持透传计费。Vercel AI Gateway为Next.js群体提供模型回退和Fluid-compute可观测性。Maxim AI的Bifrost声称在5k RPS下只有11微秒的开销——比LiteLLM快约50倍。Opper AI是欧盟主权管理的网关，内置300+模型和LLM-as-a-judge评分。货架已经**满了**。

那么我为什么要花过去几个月构建[Aura](https://aura-llm.dev/?ref=hubwiz.com)——一个我即将开源的Rust LLM网关（github.com/UmaiTech/aura-llm-gateway）——而我可以直接使用其中一个？

三个原因，而且它们都相关：

1. 大多数网关将代理视为事后补充。它们说`chat/completions`。它们将所有东西标准化为OpenAI的旧schema。工具调用、推理项和`requires_action`标志被扁平化或丢弃。我实际需要构建的东西——在模型和我的应用之间来回让出控制权的agentic工作流——勉强放在上面。
2. 我想要Rust的延迟预算，而不是"够快"的Python代理。当网关位于你产品发起的每一个LLM调用的请求路径上时，它增加的开销就是用户感受到的开销。
3. 我是一个Python人。我想知道用Claude Code进行vibe engineering能否带我进入一个我从未发布过生产代码的语言——以及什么东西会出错。

这篇文章讲述了Aura是什么，它做了现有网关没做的事情，如何在你现有框架中使用它，以及构建它学到的东西。这是我在**Agentic Dev Days Stockholm 2026**演讲的配套文章——"Vibe engineering教会了我Rust"。

> **核心论点：**Aura是一个围绕Open Responses API构建的Rust网关——agentic LLM工作流的新兴开放标准——不是一个将代理扁平化为chat completions的翻译层。模型是一个提供商。网关是使agentic循环跨提供商可读的运行时。

## 2、现有网关格局

在我为新网关的需要辩护之前，让我们诚实地看看已经有什么。我在写一行Rust之前自己做了这个研究，它塑造了Aura最终的样子。

![None](https://www.hubwiz.com/blog/content/images/2026/05/1-brYaANsXrQutX0dAAbOrSA.png)

LiteLLM是我的基准线。它是我在之前工作中实际使用过的网关，而且它能胜任。但当我开始认真构建代理原型时——工具将控制权交回给我的代码、多步推理、带有`requires_action:true`的部分响应——我发现自己总是要写两次同一个翻译层：一次用来跟LiteLLM通信，一次用来解释返回的内容。

那个翻译层就是Open Responses API。所以我省掉了中间环节。

## 3、Open Responses API到底改变了什么

Open Responses API是由openresponses.org工作组发布的规范，已被Hugging Face、OpenRouter、Vercel、LM Studio、Ollama和vLLM采用。它基于OpenAI的Responses API，但被重新定义为开放标准，使agentic原语——items、工具调用、推理、状态生命周期——在所有提供商之间以相同方式工作。

核心原语：

- **Items**——对话的原子单位。不仅是消息，还包括`function_call`、`function_call_output`、`reasoning`、`web_search`等。代理的"回合"是一个item列表，而不是一个字符串。
- **Response**——一个具有`status`生命周期的容器：`in_progress → completed | failed | incomplete`。
- **流式传输作为语义事件**——不是原始token增量。你得到`response.output_item.added`、`response.output_text.delta`、`response.completed`。你的UI知道每个事件的含义。
- `previous_response_id`用于对话线程化，无需重新发送历史。
- **外部托管vs内部托管的工具**——函数调用vs提供商托管的工具（文件搜索、网络搜索）是一等公民概念，而不是附加的。

如果你在构建代理，这是你想要的形状。Chat Completions形状是为一次性问答设计的；Responses形状是为循环设计的。

Aura原生支持这个。一个端点——`POST /v1/responses`——每个提供商都通过相同的基于item的契约。

## 4、认识Aura

Aura是一个4个crate的Rust工作空间。它小到可以在一个下午读完，结构清晰，每个部分只有一个职责——底层堆栈是刻意平淡的。

![None](https://www.hubwiz.com/blog/content/images/2026/05/1-udxnAE_rHdP3Hi-o2mrovw.png)

#### `aura-types`——Open Responses API类型

Open Responses规范的共享类型系统——请求、响应、items、events。仅类型就有60+个测试，以便在编译时捕获提供商漂移。

**模块：**`item.rs`、`response.rs`、`stream.rs`、`compression.rs`、`consistency.rs`、`validation.rs`

**依赖：**`serde`、`thiserror`

**暴露：**

- CreateResponseRequest / Response容器
- Item枚举（message、function\_call、reasoning等）
- StreamEvent语义事件
- 压缩、一致性、验证配置

#### `aura-db`——数据库模型和迁移

Postgres的SQLx模型、查询层和迁移集。Org → team → project → end-user层级结构在这里。可选——Aura可以无状态运行。

**模块：**`models.rs`、`repo.rs`、`pool.rs`、`error.rs`

**依赖：**`sqlx (Postgres)`、`aura-types`

#### `aura-core`——提供商适配器、路由、成本、压缩

业务逻辑：Provider trait + 每个供应商的适配器、成本计算器、速率限制器、响应缓存、提示压缩、加密。

**模块：**`provider/`、`router/`、`cost.rs`、`cache.rs`、`rate_limit.rs`、`compression/`、`crypto.rs`、`metrics.rs`

**依赖：**`aura-types`、`aura-db`、`reqwest`、`redis`、`tokio`

**暴露：**

- Provider trait + 7个适配器
- ProviderRegistry（model → provider解析）
- 具有2026年模型定价的成本计算器
- 令牌桶速率限制器、TTL缓存、AES-256-GCM加密

#### `aura-proxy`——Axum二进制文件、中间件、路由

实际的服务器。路由处理器、中间件栈、应用状态、/metrics端点。唯一产生二进制文件的crate。

**模块：**`main.rs`、`routes/`

**依赖：**`aura-types`、`aura-core`、`aura-db`、`axum`、`tower-http`

网关上有什么

- **Open Responses API**——agentic原生规范，不是"OpenAI兼容的附属品"。
- **7个提供商**——OpenAI、Anthropic、Google Gemini、Mistral、Ollama、AWS Bedrock、HuggingFace。
- **每个响应上的Agentic元数据**——`provider`、`latency_ms`、`has_tool_calls`、`tools_used`、`requires_action`、`request_id`。相同的形状，每个提供商。
- **成本跟踪**——每个响应上的每请求USD，包含input/output/cached/reasoning的细分。向用户展示，不仅记录。
- **多租户模型**——`org → team → project → end-user`层级。每用户成本分配在数据模型中，而不是在你的计费服务中。
- **AES-256-GCM信封加密**用于静态存储的提供商凭证。自带密钥的网关不应该泄漏密钥。
- **速率限制+响应缓存**——基于Redis的令牌桶+SHA256键的TTL缓存。可选，但如果你在路由真实流量，你两者都需要。
- **提示压缩**——TOON、AISP、YAML-min、JSON-min。通过TOON在统一数组上获得40-60%的token节省，这比人们预期的累积得更快。

## 5、架构概览

图中的两件事比看起来更重要：

从模型名称进行提供商解析，无需路由配置。你发送`"model": "claude-sonnet-4-5"`，Aura知道这是Anthropic。你发送`"gpt-5"`，它去OpenAI。`provider:`字段在响应中 enriched返回。你不需要维护YAML映射；注册表拥有这些知识。

**响**应增强是不可谈判的。每个响应——每个提供商——都会在离开网关之前被加上`cost_usd`、`latency_ms`和`agentic{}`块。这是Aura在提供商原生响应之上添加的契约。它也是让网关有用而不仅仅是一个路由器的原因。

## 6、支持的模型

Aura截至v0.9随附七个提供商。Anthropic和Gemini具有完整的流式传输和工具调用支持；其他通过相同的`Provider` trait接入，可以在单个文件中添加。

![None](https://www.hubwiz.com/blog/content/images/2026/05/1-xlvVZbibTwkkyWFFVjNKEQ.png)

## 7、从现有框架使用Aura

Aura只是一个说Open Responses API的HTTP服务器。本地运行在`localhost:8080`；生产环境是`https://api.aura-llm.dev`。你可以用任何能说HTTP的东西来调用它。

### 7.1 Python：官方SDK

第一方SDK在PyPI上作为`aura-llm`发布。

然后相同的代码形状可以用于七个提供商中的任何一个——同步、流式或异步：

### 7.2 OpenAI SDK：指向即用

如果你已经在使用OpenAI Python或TypeScript SDK，将`base_url`指向Aura，大多数调用就能正常工作。

### 7.3 代理框架

同样的技巧适用于主要的代理框架，因为它们基于OpenAI/Responses形状构建：

- **LangChain / LangGraph**——将`ChatOpenAI`的`openai_api_base`设置为`https://api.aura-llm.dev/v1`，可以像使用OpenAI模型一样使用Aura的七个提供商中的任何一个。
- **LlamaIndex**——将`api_base="https://api.aura-llm.dev/v1"`传递给`llama_index.llms.openai`中的`OpenAI(...)`。
- **Mastra / LangGraph.js**——TypeScript方面相同的形状。设置base URL然后发布。
- **DSPy**——`dspy.OpenAI(api_base="https://api.aura-llm.dev/v1", model="claude-sonnet-4-5")`，你就拥有了一个Anthropic支持的`Module`，无需更改一行DSPy代码。

TypeScript SDK（`@umaitech/aura`）正在开发中；在它完成之前，OpenAI SDK是Node方面阻力最小的路径。

## 8、部署Aura

有几种部署方式：`cargo run`、`docker compose`、`docker build`、`systemd`、`helm`。

几个注意事项：

- `cargo run`的愉快路径不需要Postgres或Redis——两者都是可选的。跳过它们，Aura以无状态模式运行（无请求日志、无API-key认证、无速率限制——适合本地代理实验）。
- `docker compose`是你想要的本地完整中间件方式——认证、速率限制、响应缓存、请求日志全部接好。
- `docker build`是生产形态。`Dockerfile`使用cargo-chef进行层缓存的多阶段构建，产生一个通常小于80MB的最小Debian-slim镜像。

## 9、Aura有什么新东西

**1\. Open Responses API作为前门，而不是翻译层。**

我评估的其他每个网关都将OpenAI Chat Completions schema视为规范形状，并将所有东西向上翻译为更agentic的东西。Aura反转了这一点。Open Responses规范是线格式；提供商适配器向下翻译成每个供应商原生API想要的。工具调用、推理项和`requires_action`不是增强——它们是承重的。

**2\. Agentic元数据作为响应契约的一部分。**

`has_tool_calls`、`tools_used`、`requires_action`、`latency_ms`、`cost_usd`、`request_id`——每个提供商、每个响应、相同的形状。这听起来很无聊，直到你在应用代码中写了第三个版本的"这个响应实际上调用了工具吗？"

**3\. 成本作为产品特性，而不是计费关注点。**

`cost_usd`在每个响应上出现。它不是你在月底查看的管理面板报告。你可以向终端用户展示它，基于每用户预算限制功能，让产品经理在不使用单独遥测管道的情况下推理单位经济学。

**4\. 数据模型层的多租户层级。**

`org → team → project → end-user`被嵌入到schema中，而不是用API key前缀附加。

**5\. Rust级别的延迟开销——诚实比较。**

演讲幻灯片说"10ms以下的开销"。这个数字是网关本身——中间件、路由、增强——不包括你无论如何都要支付的提供商往返。Python代理在热路径上会有30-80ms的纯开销；建立在Axum + Tokio上的Rust网关在个位数。在每回合触发5-20个请求的agentic循环中，这会复合。

**6\. 中间件栈中的提示压缩。**

TOON、AISP、YAML-min和JSON-min压缩是一等公民中间件。

## 10、Aura还没有做的事

我宁愿诚实而不是过度推销。Aura处于**v0.9**——1.0之前的版本，公共API和schema仍然可能在次要版本之间发生变化。

护栏和PII脱敏——Portkey的核心竞争力——还没有。EU主权作为一等公民概念还没有。

你今天能得到的是：一个小的、快速的、agentic原生的网关，具有干净的类型和一个作为一人开源项目我实际上能跟上的路线图。

## 11、作为一个Python人构建Rust

这个故事的另一半不是关于网关的。它是关于**它是如何被构建的**。

我主要是一个Python和TypeScript开发者。我之前接触过Rust——读过书，写了一个CLI，然后放弃了。我在Rust中发布Aura的原因是我用**Claude Code作为编码伙伴**来构建它，并应用了我开始称为vibe engineering的方法：vibe coding背后的纪律。相同的工具——相同的Claude——不同的严谨度。

大致的区分：

- **Vibe coding**是提示和希望。一个巨大的PR。没有计划。跳过测试。信任AI。适合一次性演示。
- **Vibe engineering**是PRD优先，提示其次。小批量的commit。架构图。验证，不信任。测试作为契约。相同的工具，不同的纪律。

### 11.1 作为非Rust开发者的Rust经验

**有效的部分：**

- 编译器错误是老师，不是墙壁。
- 类型能在早期捕获提供商schema漂移。
- 单个静态二进制文件，无运行时依赖。
- Tokio干净地处理SSE流式传输。
- Claude Code精通地道的Rust。
- 重构感觉很安全。

**痛苦的部分：**

- 借用检查器+async=痛苦峰值。
- 生命周期需要数周才能内化。
- AI领域的crate生态系统较薄。
- 编译时间会打断心流状态。
- 调试async trait是一段旅程。

> **诚实的收获**那才是真正的解锁——不是"AI为你写代码"，而是"AI让你在适合工作的工具中发布，即使它不是你已经知道的那个工具"。一个Python人发布了一个生产级Rust网关。纪律可以扩展；语言壁垒不能。

### 11.2 如果能告诉过去的自己六件事

1. **按延迟预算选择语言，而不是按炒作**——如果你的开销预算在10ms以下，Rust有它的位置。其他地方，用你的团队已经知道的来发布。
2. **可观测性优先，功能其次**——从第一天开始OpenTelemetry。你无法修复你看不到的东西。
3. **类型化的提供商schema在凌晨3点拯救你**——LLM API会漂移。强类型在用户之前捕获漂移。
4. **在你需要回退链之前构建它们**——每个提供商都会宕机。重试、切换、降级。
5. **成本跟踪是产品特性**——从一开始就向用户和PM展示。
6. **Vibe code原型。Vibe engineer生产。**——不同的模式。不同的严谨度。不要混淆它们——也不要为使用AI做其中任何一个而道歉。

## 12、Aura的下一步

路线图，按我预期落地的顺序：

- **多节点负载均衡器**——跨Aura实例分布，而不仅仅是在一个实例内跨提供商。
- **自动化定价爬虫（cron）**——提供商价格变更不应该需要PR。
- **Webhook和异步回调**——用于响应不在原始HTTP连接上返回的长时间运行的agentic任务。
- **管理面板（React UI）**——密钥管理、组织/团队设置、成本报告。
- **TypeScript SDK**——SDK故事缺失的一半。
- **通过trait系统接入更多提供商**——`Provider`是一个trait。新提供商应该是单文件添加。

## 13、结束语

有好的LLM网关。Aura不试图取代它们。它试图成为我实际想用来构建代理的那个：agentic原生API、每个响应的成本、捕获提供商漂移的类型，以及小到可以消失的延迟预算。由一个Python人用Rust构建，Claude Code作为编码伙伴——证明vibe engineering的触达范围超出了你已经知道的语言。

---

原文链接: [Building Aura: An Agentic LLM Gateway in Rust](https://medium.com/ai-advances/building-aura-an-agentic-llm-gateway-in-rust-9f5f788bb712?ref=hubwiz.com)

汇智网翻译整理，转载请标明出处