baml
将 AI Prompt 从字符串拼接升级为类型安全的函数,用 Rust 编译器和多语言 SDK 生成器实现企业级 Prompt 工程
加载项目详情…
本应用为开源项目,仅供学习研究,请遵守其开源协议。
将 AI Prompt 从字符串拼接升级为类型安全的函数,用 Rust 编译器和多语言 SDK 生成器实现企业级 Prompt 工程
加载项目详情…
本应用为开源项目,仅供学习研究,请遵守其开源协议。
你有没有过这样的经历:花了两天调试一个 AI Agent 的提示词,终于让它在测试集上表现完美,结果换了个模型——整个流程彻底崩溃?或者,好不容易在 Python 里写好的 Prompt,复制到 TypeScript 项目里就报错了?这种「提示词脆弱症」,几乎是所有 AI 开发者的共同痛点。
BAML(Basically A Made-up Language) 正是为解决这一痛点而生。它是 BoundaryML 公司开源的专用于 AI 工作流与 Agent 构建的领域特定语言(DSL),用类 Rust 的语法来编写 AI Prompt,让提示词从「字符串拼接」升级为「类型安全的函数」。项目目前已收获超过 8000 颗 GitHub 星标,被认为是 Prompt Engineering 领域最具工程化思维的解决方案之一。
在大模型应用开发的早期,Prompt 通常以字符串形式散落在代码各处——Python 的 f-string、TypeScript 的模板字符串、甚至直接写在 API 调用参数里。这种做法有几个致命缺陷:
第一,无法类型检查。 Prompt 里引用了一个变量 user_name,但如果代码里写错了变量名,只有运行到那一行才会报错。第二,跨语言复用困难。 一个 Prompt 如果需要在 Python 后端和 TypeScript 前端共用,几乎无法优雅地实现。第三,Prompt 的输出格式不稳定。 模型返回的 JSON 可能缺字段、多余了注释、或者嵌套层级不符合预期,传统字符串解析极易崩溃。
BAML 的核心洞察是:把 Prompt 当函数,而不是字符串。 每个 BAML 函数定义了一个输入输出的「契约」——输入什么参数,模型应该返回什么结构化数据。这个「契约」由 BAML 编译器在编译期校验,从根本上杜绝了类型不匹配的问题。
在 BAML 中,一个 AI Prompt 就是一个函数。BAML 文件(.baml)里可以定义多个函数,每个函数声明输入参数和输出类型:
function ChatAgent(message: Message[], tone: "happy" | "sad") -> string
这个语法借鉴了 Rust 的类型系统和函数式编程风格,开发者可以清晰地定义枚举类型(如 "happy" | "sad")、嵌套类结构、多态输出(一个函数可以返回多种类型)。编译器会检查所有引用的变量是否存在、类型是否匹配,并在构建时自动生成各语言的调用代码(Python/TypeScript/Ruby/Java/C#/Rust/Go)。
即使模型本身不支持 tool-calling、function calling,BAML 也能通过自研的 SAP(Schema-Aligned Parsing)算法 实现可靠的结构化输出。SAP 能处理模型常见的「不稳定输出」:JSON 嵌套在 Markdown 代码块里、模型在 JSON 前后加了思考过程、字段顺序与 schema 不一致……这些在传统解析方式下都会失败,但 SAP 都能容错处理。
这意味着:模型发布 Day 1,BAML 就能用。 无需等待模型更新 API 或第三方适配,切换新模型几乎零成本。
BAML 为 VS Code 和 JetBrains 全系列 IDE 提供了深度集成的插件,支持:
根据项目文档的描述:如果原来跑一轮测试需要 2 分钟,现在缩短到 5 秒,20 分钟内的测试迭代次数可以从 10 次提升到 240 次——快了 24 倍。
BAML 最大的差异化优势之一是对多语言生态的完整支持。声明一个 BAML 函数后,BAML 编译器会为以下语言自动生成类型安全的客户端代码:
| 语言 | 包管理 | 说明 |
|---|---|---|
| Python | pip / uv | baml-py,提供同步/异步双接口 |
| TypeScript | pnpm / npm | baml-js,兼容 Node.js 和浏览器 |
| Ruby | gem | baml gem |
| Java | Maven | baml-java |
| C# | NuGet | baml-csharp |
| Rust | crates.io | baml( crates.io 直接发布) |
| Go | go mod | baml-cli 目录独立维护 |
这意味着团队里用不同语言的前后端开发者,都能调用同一个 BAML 函数定义的 Prompt,无需各自维护一套 Prompt 副本。
BAML 的技术架构分为两层:
bamlc 编译。Rust 保证了编译速度极快(BAML 官方称「快到你感受不到它的存在」)。编译器输出各语言的调用代码(生成器模式)。项目采用 monorepo 结构,使用 Turborepo 管理多语言子包,通过 pnpm workspace 协调 TypeScript/JavaScript 包,用 Cargo 管理 Rust 核心引擎。
BAML 内置了几乎所有主流大模型的连接器:OpenAI 全系列、Anthropic Claude/Gemini 系列、AWS Bedrock(Claude/Llama/Mistral)、Azure OpenAI、Google Vertex AI,以及任何兼容 OpenAI API 格式的自托管模型(Ollama、vLLM、LM Studio、OpenRouter 等)。
在 BAML 中切换模型只需要改一行代码:
function Extract() -> Resume {
+ client openai/o3-mini
prompt #"
...
"#
}
还支持重试策略(Retry Policy)、降级策略(Fallback)和模型轮询(Model Rotation),这些都可以静态声明在 BAML 文件中,由编译器生成对应代码。
BAML 遵循 Apache 2.0 开源协议,核心编译器完全开源。关键隐私承诺:
BAML 也有明显的局限性:
首先,学习曲线不可忽视。 虽然官方说「大一学生都能理解」,但 BAML 的类型系统、函数语法对没有 Rust/TypeScript 背景的开发者来说仍有门槛。特别是在定义复杂嵌套类型时,语法容易出错。
其次,没有官方 Docker 部署支持。 对于习惯「一行 docker-compose up」的开发者来说,需要自己准备 Python/Node/Rust 环境,上手成本稍高。
第三,对模型输出质量的依赖没有降低。 BAML 解决的是「输出格式可靠」的问题,但 Prompt 本身的逻辑质量、模型推理质量,仍需要大量人工调优。
BAML 的出现代表了一个趋势:Prompt Engineering 正在从艺术走向工程。 传统的字符串拼接方式终将被类型安全、可测试、可版本控制的 DSL 所取代。目前 8000+ GitHub 星标和大量生产环境使用案例,已经证明了这一方向的市场认可度。
对于 AI 开发者而言,BAML 提供了一套完整的「工程化 Prompt」的完整工具链——类型定义、编译检查、IDE 工具、测试框架、多语言生成、模型管理——这是 Prompt Engineering 领域目前最接近「工业化生产」的解决方案之一。

图1:每当出现新技术,就会有人发明「标准化」方案——xkcd 的经典调侃恰恰是 BAML 试图解决的问题:让 Prompt 不再是散落各处的字符串,而是有结构、可维护的工程代码。
本报告由 PIFS 平台自动生成,分析时间:2026-05-30。数据来源:GitHub API、官方文档、仓库源码。