
在过去的一年里,我花了很多时间与 RubyLLM 合作,我开始欣赏其 API 的深思熟虑设计。语法简单而富有表现力,它不会向你的应用程序泄露提供商细节。
当我试图在 Node.js 中实现相同的体验时,我意识到缺少了什么。
NodeLLM 是我试图为 Node 生态系统带来同样水平的清晰性和沉着的尝试------使 AI 集成可预测、明确,并对供应商变化具有弹性。
NodeLLM 深受 RubyLLM 优雅的启发,为 Node.js 生态系统带来了同样的对开发体验和架构清晰度的重视。
1、为什么这很重要
AI 集成应该是一个架构决策,而不仅仅是 API 调用。
大多数团队开始时将业务逻辑直接连接到提供商 SDK。当模型改变、定价变化或 API 被弃用时,这种耦合就变成了痛苦的重构。
LLM 应该被视为基础设施。
NodeLLM 的存在是为了在你的应用程序和快速发展的 AI 生态系统之间提供一个稳定、有主见的边界。
2、NodeLLM 哲学
2.1 架构优于 API
NodeLLM 不是一个薄包装器。它定义了跨提供商的一致交互模型,因此当模型或供应商改变时,你的系统逻辑不会改变。
import { NodeLLM } from "@node-llm/core";
// 1. 配置一次
NodeLLM.configure({ provider: "openai" });
// 2. 高级聊天界面
const chat = NodeLLM.chat("gpt-4o");
const response = await chat.ask("解释事件驱动架构");
console.log(response.content);
你思考的是能力,而不是 SDK 差异。
2.2 免编排地狱的工具
定义工具不应该需要脆弱的 JSON 模式或手动执行循环。
NodeLLM 提供了一个基于类的 DSL,工具只定义一次并由运行时自动执行。
import { Tool, z } from "@node-llm/core";
class WeatherTool extends Tool {
name = "get_weather";
description = "获取当前天气";
schema = z.object({ location: z.string() });
async handler({ location }) {
return `${location} 晴天`;
}
}
await chat.withTool(WeatherTool).ask("东京天气怎么样?");
执行循环为你管理------安全且可预测。
2.3 类型安全的结构化输出
结构化响应是一等公民。
NodeLLM 集成 Zod ,因此输出是经过验证和完全类型化的,而不是手动解析的。
const Product = z.object({
name: z.string(),
price: z.number(),
});
const res = await chat.withSchema(Product).ask("生成一个小工具");
console.log(res.parsed.name); // 完全类型化
2.4 作用域并行
真实系统通常需要并行评估多个提供商。
NodeLLM 允许隔离的执行上下文,而没有全局副作用。
const [gpt, claude] = await Promise.all([
NodeLLM.withProvider("openai").chat("gpt-4o").ask(prompt),
NodeLLM.withProvider("anthropic").chat("claude-3-5-sonnet").ask(prompt),
]);
2.5 为真实应用程序而构建
NodeLLM 支持你在生产中实际需要的功能:
- 视觉和文件 ------ 图像、PDF 和音频,自动编码
- 标准化流 ------ 单一的
AsyncIterator接口 - 确定性调试 ------
NODELLM_DEBUG=true显示确切的有效载荷 - 最小依赖 ------ 不强制重量级 SDK 安装
3、在生产中使用
NodeLLM 经过实战测试,在生产系统中用作核心 AI 集成层。
如果你正在构建长期运行的 Node.js 应用程序,NodeLLM 旨在与你一起成长------而不会锁定你。
npm install @node-llm/core