构建生产级AI API统一封装库：多模型路由、容错与成本管理实践

1. 项目概述：为什么我们要从零构建一个开源的LLM/AI API封装库

如果你在过去一年里深度参与过任何AI应用开发，下面这个场景你一定不陌生：项目启动，雄心勃勃，准备接入大模型能力。你打开文档，准备调用OpenAI的API，然后发现你需要处理API密钥管理、请求重试、流式响应解析、速率限制、错误处理、多模型切换……这还只是一个供应商。当你为了成本或性能考虑，想把部分请求分流到Anthropic的Claude，或者本地的Ollama服务，或者国内的一些大模型平台时，噩梦才真正开始。每个服务商的API设计、认证方式、参数命名、响应格式都像来自不同的星球。你的业务代码很快被各种if provider == “openai”、try...except和丑陋的适配器代码淹没，核心逻辑反而成了配角。

这就是我们启动这个开源项目最直接的动因。我们正在构建的，不是一个简单的、把HTTP调用包一层的“SDK”，而是一个面向生产环境的、统一且健壮的LLM/AI API封装库（Wrapper）。它的目标，是让开发者能够像使用一个本地函数库一样，以一种标准化、声明式的方式，去调用全球范围内数十种主流的大语言模型和AI服务，而无需关心底层错综复杂的网络细节和平台差异。这听起来像是一个基础设施性质的“轮子”，但在当前AI应用开发从探索走向规模化部署的关键节点，我们认为这个“轮子”不是可有可无的装饰品，而是决定开发效率和系统稳定性的关键轴承。

为什么非得自己造？市面上不是已经有LangChain、LlamaIndex这类成熟的框架了吗？这是一个非常好的问题。LangChain等框架功能强大，生态丰富，但它们的设计哲学是构建复杂的AI应用工作流（Workflow），提供了大量高级抽象，如链（Chains）、代理（Agents）、记忆（Memory）等。对于需要快速搭建原型或构建复杂AI逻辑的团队，它们是绝佳选择。然而，这种“重”框架也带来了较高的学习曲线、潜在的性能开销，以及在只需要进行简单、直接、高性能的模型调用时的那种“杀鸡用牛刀”的笨重感。我们的Wrapper定位更底层、更轻量、更专注：它只解决“如何以最好的方式调用AI API”这一个核心问题，追求极致的简洁性、灵活性和对生产环境的友好性。你可以把它看作是AI世界里的“Requests”库——一个你信赖的、处理所有HTTP通讯复杂性的基础工具。

更深层次的原因，源于我们对AI开发生态演进的观察。模型服务正在从集中走向分散，从单一走向多元。未来，一个成熟的AI应用后端，很可能需要根据查询类型、成本预算、响应延迟要求，动态地路由请求到不同的模型提供商，甚至是自托管模型。这种“模型路由”和“故障转移”能力，必须建立在坚实的、统一的底层通讯框架之上。我们的开源Wrapper，正是希望成为这个框架的一块基石，让开发者能更从容地应对多模型、多云、混合部署的复杂未来。

2. 核心设计哲学与架构选型

2.1 设计原则：从“能用”到“好用”与“敢用”

在项目启动之初，我们团队内部进行了多次激烈的讨论，最终确立了三个核心设计原则，它们将贯穿项目的整个生命周期。

原则一：统一抽象，差异透明化。这是Wrapper的立身之本。我们的目标是创建一个顶级的、统一的客户端接口。无论底层是GPT-4、Claude 3、Gemini还是通义千问，开发者都应该通过几乎相同的方法（如client.chat.completions.create()）来发起请求。模型特有的参数（如OpenAI的frequency_penalty或Claude的system提示词）将通过一个精心设计的、可扩展的参数体系来支持，确保在享受统一接口便利的同时，不丧失利用各模型独特优势的能力。差异处理被隐藏在SDK内部，通过适配器（Adapter）模式来实现。

原则二：生产环境就绪（Production-Ready）。个人项目或快速原型可以容忍偶尔的失败，但生产系统不行。因此，Wrapper必须内置企业级应用所需的韧性（Resiliency）功能。这包括但不限于：

• 智能重试：针对网络抖动、服务端限流（429错误）或临时过载（5xx错误）的指数退避重试策略。
• 故障转移（Fallback）：当主用模型服务不可用或返回不可接受的错误时，自动切换到备用的模型或服务提供商。
• 速率限制（Rate Limiting）：在客户端层面实施精细化的请求速率控制，防止意外超限导致API密钥被禁。
• 可观测性（Observability）：内置请求日志、耗时统计、Token用量计算，并易于与Prometheus、OpenTelemetry等监控系统集成。
• 连接池与超时管理：合理的HTTP连接复用和可配置的超时设置，防止资源泄漏和慢请求拖垮整个应用。

原则三：极致的开发者体验（DX）。API设计要符合直觉，文档要清晰完整，错误信息要具有可操作性。我们借鉴了现代Python/JavaScript库的最佳实践，提供完整的类型提示（Type Hints）、异步（Async）优先的支持、以及丰富的配置示例。让开发者花最少的时间在集成上，将更多精力投入到业务逻辑的创新中。

2.2 技术栈与架构决策

基于以上原则，我们做出了以下关键的技术选型：

语言选择：TypeScript/JavaScript & Python 双首发。这是当前AI应用开发最活跃的两个生态。TypeScript版本将提供顶级的类型安全和现代前端/Node.js开发体验，而Python版本则服务于数据科学、后端服务和快速脚本场景。两个版本将共享核心的设计理念和API形态，但会尊重各自语言社区的惯例。

核心通信层：基于成熟HTTP客户端封装。我们不会重新发明HTTP客户端。在Python端，我们会基于httpx（支持异步）或requests构建，利用其会话、代理等高级功能。在TypeScript端，则会基于fetch API或axios。Wrapper的核心价值在于在这些基础客户端之上，添加AI领域特定的逻辑层。

配置管理：面向环境的灵活设计。我们支持多种配置方式：环境变量、配置文件、代码直接传入。并且，配置支持分层覆盖，例如，一个基础配置定义默认模型和超时，而某个特定业务场景可以覆盖这些设置。我们还会设计“配置提供者（Provider）”模式，方便从远程配置中心（如Consul、AWS AppConfig）动态读取配置。

扩展性：插件化架构。核心库保持轻量，通过插件（Plugin）或中间件（Middleware）机制来扩展功能。例如，一个用于审计日志的插件、一个用于注入自定义请求头的插件、或者一个用于在请求前后进行数据转换的插件。这种设计保证了核心的稳定，同时满足了不同团队的定制化需求。

注意：在架构设计早期，我们曾考虑过是否要深度集成像pydantic这样的数据验证库。最终决定在核心层采用更轻量的方案，而在需要复杂验证的用户侧，让开发者自由选择他们喜欢的工具。这避免了不必要的依赖绑架，保持了库的纯粹性。

3. 核心功能模块深度解析

3.1 统一客户端接口与多模型路由

这是Wrapper最吸引人的功能。我们来看一个理想中的使用示例：

# Python 示例 from ai_wrapper import Client # 初始化客户端，配置多个模型端点 client = Client( endpoints=[ { “name”: “openai-gpt-4”, “type”: “openai”, “base_url”: “https://api.openai.com/v1”, “api_key”: os.getenv(“OPENAI_API_KEY”), “models”: [“gpt-4-turbo”, “gpt-4”] # 此端点支持的模型列表 }, { “name”: “claude-3”, “type”: “anthropic”, “base_url”: “https://api.anthropic.com/v1”, “api_key”: os.getenv(“ANTHROPIC_API_KEY”), “models”: [“claude-3-opus-20240229”, “claude-3-sonnet-20240229”] }, { “name”: “local-llama”, “type”: “openai_compatible”, # 兼容OpenAI API格式的本地服务 “base_url”: “http://localhost:11434/v1”, # 例如Ollama “api_key”: “not-needed”, “models”: [“llama3:8b”, “mistral:7b”] } ] ) # 使用方式1：直接指定模型名，Wrapper自动路由到正确的端点 response = client.chat.completions.create( model=“gpt-4-turbo”, # 自动使用 openai-gpt-4 端点 messages=[{“role”: “user”, “content”: “Hello”}] ) # 使用方式2：使用路由策略（如成本优先、延迟优先、轮询） response = client.with_strategy(“cost-optimized”).chat.completions.create( model=“claude-3-sonnet-20240229”, # 策略可能根据成本选择 sonnet 而非 opus messages=[...] )

背后的实现机制是一个注册中心（Registry）和路由引擎（Router）。客户端初始化时，将所有端点信息注册到内部中心。当发起请求时，路由引擎根据model参数和当前策略，查找匹配的端点，并通过对应的适配器发起请求。路由策略可以非常灵活，例如：

• 优先级路由：按配置顺序选择第一个可用的端点。
• 负载均衡：在多个提供相同模型的端点间轮询或按权重分配。
• 成本优化：根据各模型的每千Token定价，自动选择满足性能要求的最便宜模型。
• 地理位置路由：将请求发送到物理距离更近、延迟更低的服务区域。

3.2 健壮性增强：重试、熔断与回退

生产环境中，网络和服务是不可靠的。Wrapper必须能优雅地处理失败。

智能重试机制：并非所有错误都值得重试。我们将错误分类：

• 可重试错误：网络连接错误、HTTP 5xx服务器错误、HTTP 429（请求过多）等。对于429错误，我们会解析Retry-After头部，并遵守服务端要求的等待时间。
• 不可重试错误：HTTP 4xx客户端错误（如401认证失败、400错误请求）、模型内容过滤触发等。这些错误立即抛出，因为重试无法解决问题。

重试逻辑采用指数退避（Exponential Backoff）并增加抖动（Jitter），防止在服务恢复时所有客户端同时重试导致的新一轮雪崩。例如，首次重试等待1秒，第二次2秒，第三次4秒，并在每次等待时间上增加一个随机的小偏移。

熔断器模式（Circuit Breaker）：当某个端点在短时间内失败率超过阈值（如50%），熔断器会“跳闸”，短时间内直接拒绝发往该端点的所有请求，快速失败，给下游服务恢复的时间。经过一个冷却期后，熔断器进入“半开”状态，试探性放行一个请求，如果成功则关闭熔断，恢复流量。

分层回退（Fallback）策略：这是保证服务可用性的最后防线。可以配置多层回退，例如：

1. 主模型gpt-4-turbo失败。
2. 回退到同供应商的次优模型gpt-3.5-turbo。
3. 如果OpenAI服务完全不可用，回退到备用供应商的claude-3-sonnet。
4. 如果所有云端服务都失败，回退到本地部署的llama3模型。
5. 如果连本地模型都失败，则返回一个预设的友好错误消息或执行一个极其简化的本地逻辑。

# 配置示例：回退链 fallback_chain: - model: “gpt-4-turbo” endpoint: “openai-primary” - model: “gpt-3.5-turbo” # 第一层回退：降级模型 endpoint: “openai-primary” - model: “claude-3-sonnet” # 第二层回退：更换供应商 endpoint: “anthropic-backup” - model: “llama3:8b” # 第三层回退：本地模型 endpoint: “local-ollama” is_final: true # 最终回退，不再继续

3.3 可观测性与成本管理

没有度量，就无法优化。Wrapper内置了丰富的遥测数据。

请求日志与指标：每个请求都会生成结构化的日志，包含唯一请求ID、模型、端点、耗时、输入/输出Token数、状态码等。这些日志可以轻松接入ELK或Loki等系统。同时，关键指标（如请求延迟分布、错误率、Token消耗速率）以Prometheus格式暴露，方便监控告警。

Token计数与成本估算：虽然准确的Token计数依赖于模型本身的API返回，但Wrapper会尽力在客户端进行估算（对于兼容OpenAI格式的API，可直接获取；对于其他API，使用近似算法如tiktoken的等效实现）。结合预设的模型单价（可配置），Wrapper可以实时估算每次请求的成本，并汇总成报告，帮助团队进行预算控制和成本分析。

使用量统计与审计：提供简单的API，让开发者能按项目、按用户、按时间段查询模型使用情况。这对于SaaS平台向终端用户计费，或内部团队进行资源核算至关重要。

4. 实战：从零开始集成与配置

4.1 基础安装与环境配置

让我们以一个Python后端项目为例，演示如何集成这个Wrapper。

首先，通过pip安装（假设库名为ai-unified-client）：

pip install ai-unified-client

接下来是配置。我们强烈推荐使用环境变量或配置文件来管理敏感的API密钥，而不是硬编码在代码中。

方式一：环境变量（适合12-Factor应用）

export OPENAI_API_KEY=“sk-...” export ANTHROPIC_API_KEY=“sk-ant-...” export AI_WRAPPER_CONFIG_FILE=“./config/ai_endpoints.yaml”

然后在代码中，Wrapper会自动读取这些环境变量。

方式二：YAML配置文件（适合复杂配置）创建config/ai_endpoints.yaml：

version: “1.0” endpoints: - name: “openai-main” type: “openai” base_url: “https://api.openai.com/v1” api_key: ${OPENAI_API_KEY} # 支持从环境变量注入 default_model: “gpt-3.5-turbo” timeout: 30 retry: attempts: 3 backoff_factor: 1 rate_limit: requests_per_minute: 60 - name: “claude-backup” type: “anthropic” base_url: “https://api.anthropic.com” api_key: ${ANTHROPIC_API_KEY} default_model: “claude-3-haiku-20240307” timeout: 60

在代码中加载配置：

from ai_unified_client import Client, load_config_from_yaml config = load_config_from_yaml(“./config/ai_endpoints.yaml”) client = Client.from_config(config)

4.2 核心API调用模式详解

Wrapper提供了同步和异步两套API，以适应不同的应用场景。

同步调用：简单直接，适用于脚本、CLI工具或简单的同步Web服务器。

from ai_unified_client import Client client = Client() # 会自动从环境变量或默认路径加载配置 try: response = client.chat.completions.create( model=“gpt-4”, # 不指定则使用默认模型 messages=[ {“role”: “system”, “content”: “你是一个乐于助人的助手。”}, {“role”: “user”, “content”: “用Python写一个快速排序函数。”} ], temperature=0.7, max_tokens=500, stream=False # 非流式，一次性返回完整结果 ) print(response.choices[0].message.content) print(f“本次消耗Token: {response.usage.total_tokens}”) except Exception as e: # Wrapper抛出的异常会是定义良好的类型，如 RateLimitError, AuthenticationError print(f“请求失败: {e}”)

异步调用：现代Web框架（FastAPI, Quart）和高性能应用的推荐方式，可以更好地处理并发IO。

import asyncio from ai_unified_client import AsyncClient async def main(): async with AsyncClient() as client: # 使用异步上下文管理器 try: response = await client.chat.completions.create( model=“claude-3-sonnet”, messages=[...], stream=True # 启用流式响应 ) # 处理流式响应 full_content = “” async for chunk in response: if chunk.choices and chunk.choices[0].delta.content: content = chunk.choices[0].delta.content full_content += content # 可以在这里实现逐字输出的效果 print(content, end=“”, flush=True) print(f“\n完整回复: {full_content}”) except Exception as e: print(f“异步请求失败: {e}”) asyncio.run(main())

流式处理（Streaming）是大模型交互中的关键特性，它能极大提升用户体验，尤其是生成长文本时。Wrapper的流式响应处理经过了精心设计，确保事件循环的稳定性和内存的高效使用。对于不支持原生流式的API，Wrapper会在内部进行模拟，尽可能提供一致的开发者体验。

4.3 高级功能：自定义适配器与中间件

当需要接入一个全新的、Wrapper尚未官方支持的AI服务时，你可以通过实现适配器（Adapter）接口来轻松扩展。

from abc import ABC, abstractmethod from typing import Dict, Any from ai_unified_client.adapters import BaseAdapter class MyCustomAIAdapter(BaseAdapter): provider_type = “my_custom_ai” def __init__(self, config: Dict[str, Any]): self.base_url = config[“base_url”] self.api_key = config.get(“api_key”) # ... 其他初始化 async def create_chat_completion(self, params: Dict[str, Any]) -> Dict[str, Any]: """将标准参数转换为自定义AI服务的请求格式""" # 1. 转换参数 custom_payload = { “query”: self._format_messages(params[“messages”]), “config”: { “temperature”: params.get(“temperature”, 0.7), “max_length”: params.get(“max_tokens”, 1000), } } # 2. 发送HTTP请求 async with self._session.post( f“{self.base_url}/generate”, json=custom_payload, headers={“Authorization”: f”Bearer {self.api_key}”} ) as resp: result = await resp.json() # 3. 将响应转换回标准格式 return { “id”: result[“request_id”], “choices”: [{ “message”: { “role”: “assistant”, “content”: result[“generated_text”] } }], “usage”: { “prompt_tokens”: result.get(“input_tokens”, 0), “completion_tokens”: result.get(“output_tokens”, 0), “total_tokens”: result.get(“total_tokens”, 0), } } def _format_messages(self, messages): # 实现消息列表到自定义格式的转换 pass # 注册自定义适配器 from ai_unified_client import register_adapter register_adapter(MyCustomAIAdapter) # 现在可以在配置中使用 `type: my_custom_ai` 了

中间件（Middleware）则用于横切关注点，如日志、审计、注入、修改请求/响应等。例如，一个用于给所有请求添加请求ID的中间件：

import uuid from ai_unified_client.middleware import BaseMiddleware class RequestIDMiddleware(BaseMiddleware): async def on_request(self, request): request.headers[“X-Request-ID”] = str(uuid.uuid4()) return request # 使用客户端时加载中间件 client = Client(middlewares=[RequestIDMiddleware()])

5. 部署实践与性能调优

5.1 客户端配置的黄金法则

将Wrapper投入生产环境，合理的配置是稳定的第一步。以下是一些经过验证的配置建议：

连接池大小：对于高并发应用，务必调整HTTP客户端的连接池。过小会导致请求排队，过大则浪费资源。一个经验公式是pool_size = max_concurrent_requests * 1.2。在Python的httpx中，可以这样配置：

import httpx from ai_unified_client import Client transport = httpx.AsyncHTTPTransport( limits=httpx.Limits( max_connections=100, # 连接池最大连接数 max_keepalive_connections=50, # 保持活跃的连接数 ), retries=0 # 禁用httpx自带的重试，使用Wrapper的更智能重试 ) client = AsyncClient(transport=transport)

超时设置：必须设置连接超时、读超时和总超时。对于大模型生成，读超时应设置得足够长（如60-120秒），但总超时可以稍短，以便在模型“卡住”时及时中断。

endpoint: timeout: connect: 5.0 # 连接超时5秒 read: 120.0 # 读取超时120秒 write: 10.0 # 写入超时10秒 pool: 5.0 # 从连接池获取连接的超时

重试策略：默认的指数退避重试对于大多数场景是好的，但在面对持续的服务端过载时，可能造成“重试风暴”。可以结合熔断器和更激进的退避策略（如backoff_factor: 2），并严格限制最大重试次数（如3次）。

5.2 监控、告警与日志聚合

部署后，需要建立监控体系来观察Wrapper的运行状态。

关键监控指标：

1. 请求率（Request Rate）：按端点、按模型统计的QPS。
2. 延迟（Latency）：P50， P95， P99分位的请求耗时。特别注意P99延迟，它反映了长尾请求的体验。
3. 错误率（Error Rate）：HTTP状态码4xx/5xx的比例，以及熔断器触发次数。
4. Token消耗速率：输入/输出Token的消耗速度，是成本控制的核心。
5. 饱和度（Saturation）：如连接池使用率、线程池队列长度等。

可以在应用启动时，将Wrapper内置的指标收集器（如一个Prometheus客户端）挂载到你的监控端点。同时，确保所有结构化的请求日志被收集到集中式日志系统（如ELK Stack），便于故障排查和审计。

告警规则示例（以Prometheus为例）：

# 过去5分钟内，某个端点的错误率超过5% - alert: AIEndpointHighErrorRate expr: rate(ai_client_request_failed_total{endpoint=“openai-main”}[5m]) / rate(ai_client_request_total{endpoint=“openai-main”}[5m]) > 0.05 for: 2m labels: severity: warning annotations: summary: “{{ $labels.endpoint }} API错误率过高” # P99延迟超过10秒 - alert: AIEndpointHighLatency expr: histogram_quantile(0.99, rate(ai_client_request_duration_seconds_bucket{endpoint=“openai-main”}[5m])) > 10 for: 2m labels: severity: warning

5.3 性能压测与瓶颈分析

在流量增长前，进行压力测试至关重要。使用locust或k6等工具模拟并发用户请求。

压测关注点：

• 极限QPS：在可接受的延迟（如P95<5s）下，单个应用实例能支撑多少请求。
• 内存与CPU消耗：长时间运行和高并发下，Wrapper客户端本身以及其依赖（如HTTP连接池）的资源占用。
• 长连接稳定性：在流式响应场景下，大量并发的长连接是否会拖垮客户端或服务器。
• 故障注入下的行为：模拟网络延迟、丢包、下游服务故障，观察重试、熔断、回退机制是否按预期工作。

我们曾在内部测试中发现，在极端高并发（>1000 QPS）下，如果每个请求都创建新的客户端实例，会导致端口耗尽和内存飙升。最佳实践是，在整个应用生命周期内，复用同一个全局客户端实例（或有限数量的实例池）。对于多线程/多进程环境（如Gunicorn worker），需要谨慎处理客户端的共享和线程安全性。

6. 常见陷阱、问题排查与社区生态构建

6.1 实战中踩过的“坑”与解决方案

坑1：流式响应中的连接超时与内存泄漏在异步处理流式响应时，如果消费者处理速度过慢，或者网络中间件（如Nginx）有较短的代理超时设置，可能导致连接被意外关闭。更危险的是，如果异步生成器没有被正确关闭或消费完，可能会引起底层连接无法释放，导致内存泄漏。

解决方案：始终使用async with上下文管理器来确保客户端和响应流的资源被正确清理。在消费流时，使用try...finally块或在任务取消时主动关闭响应。在服务端（Nginx）适当调大proxy_read_timeout。

坑2：默认配置的“重试风暴”我们曾遇到一个案例：一个下游AI服务区域临时故障，导致所有请求失败。由于默认重试策略和大量并发请求，应用在短时间内向该服务发送了数倍于平时的重试请求，几乎打垮了正在恢复的服务。

解决方案：引入“熔断器”和“全局重试预算”概念。除了对单个请求的重试控制外，在客户端层面设置一个全局的并发重试上限。同时，确保重试逻辑与监控告警联动，一旦发现某个端点错误率飙升，能快速人工或自动介入。

坑3：Token计数不准与成本失控对于非OpenAI官方API，Token计数通常需要估算。早期我们依赖简单的空格分词，结果与模型服务端的实际计数相差甚远，导致成本估算完全失真。

解决方案：为每个主要的模型系列（如Llama系列、ChatGLM系列）实现或集成对应的Tokenizer。虽然增加了复杂度，但这是成本管控的基石。同时，提供配置项让用户可以手动校准或覆盖单价，并设置预算告警阈值。

坑4：配置复杂性与“配置漂移”当有数十个端点、不同的路由策略和回退链时，YAML配置文件会变得非常庞大和复杂。不同环境（开发、测试、生产）的配置容易发生不一致，即“配置漂移”。

解决方案：推行“配置即代码”和版本控制。将配置文件纳入Git管理。同时，设计配置的继承和覆盖机制。例如，一个base.yaml定义所有公共配置，production.yaml只覆盖生产环境的API密钥和端点URL。使用配置管理工具或Kubernetes ConfigMap来管理不同环境的配置注入。

6.2 问题排查清单

当遇到AI API调用问题时，可以按以下清单快速定位：

6.3 开源协作与生态展望

我们坚信，一个基础设施类的项目，其生命力在于社区。因此，从第一天起，我们就将项目托管在GitHub上，采用宽松的开源协议（如MIT或Apache 2.0），并致力于构建开放的协作流程。

如何参与贡献：

1. 报告问题与需求：在GitHub Issues中清晰描述你遇到的问题或新功能想法。
2. 贡献适配器：为你常用的、但尚未支持的AI服务编写适配器。我们有详细的适配器开发指南和模板。
3. 完善文档：好的文档和示例代码的价值不亚于核心代码。帮助我们将使用场景、最佳实践写成教程。
4. 代码审查与测试：参与Pull Request的审查，帮助提升代码质量；为更多边缘案例编写测试。

生态构建的愿景：我们希望这个Wrapper能成为一个中立的、社区驱动的“连接器”。未来，围绕它可以生长出丰富的生态工具：

• 管理面板：一个可视化界面，用于监控所有端点的健康状态、流量和成本。
• 配置生成器：通过图形化界面，拖拽配置复杂的路由和回退策略。
• 模型性能基准测试套件：基于Wrapper，可以轻松地对不同模型在特定任务（如代码生成、文本总结）上的性能、成本、速度进行标准化测试和对比。
• 与其他框架的集成：提供LangChain的LLM封装器，或为Semantic Kernel提供原生插件，让这些高层框架的用户也能享受到统一、健壮的底层调用能力。

构建这样一个开源项目，远不止是写代码。它关乎于建立标准、分享最佳实践、以及凝聚一群相信“更好的开发者体验能让AI创新更快发生”的同行者。我们期待你的加入，一起让调用AI大模型变得像调用本地函数一样简单、可靠。