Agent 能做的动作越多，失效方式也越多。领域特定语言可以缩小执行空间，但它只适合语义稳定、任务重复、结果可独立验证的领域。很多系统用 JSON Schema 或 typed API 就能解决问题。真正的工程决策，是找到足以暴露关键错误的最小约束。
真正需要缩小的是验证空间
通用编程语言给了大模型很大的表达自由。两段代码都能编译，仍可能在事务顺序、权限范围、重试策略和业务语义上完全不同。模型需要从大量合法结构中选择，审核者也要在同样大的空间里找错。
DSL 主动放弃通用性。SQL 只表达关系查询，Kubernetes YAML 只描述部署配置，Mermaid 只描述图。面向 Agent 的 DSL 也可以把动词、参数、合法顺序和副作用固定下来。
它的核心价值是建立一个更小的可执行世界，让错误尽早变成明确的解析、类型或领域规则错误。
约束也会引入新的复杂度。团队需要维护词法、语法、AST、验证器、版本迁移和开发工具。领域语义一旦变化，语言本身也要升级。DSL 的收益来自验证成本下降，代价来自语言工程成本上升。
现有证据支持到什么程度
Unmesh Joshi 在 DSLs Enable Reliable Use of LLMs 中提出两个阶段。设计阶段由人主导，模型协助发现领域对象和共同词汇。语义稳定后，模型再成为 DSL 的自然语言入口。
这是一套有价值的工程方法，但 Tickloom 只是机制案例，没有跨模型 benchmark。它说明约束如何工作，没有证明 DSL 在所有任务上都能提高正确率。
Anka 预印本提供了一组受控实验。研究者为数据转换设计了 Anka DSL，在 100 个任务上比较 Anka 与 Python。Claude 3.5 Haiku 的总体任务准确率分别为 95.8% 和 91.2%。多步骤任务的差距更大，Anka 为 100%，Python 为 60%。GPT-4o-mini 的多步骤结果也呈相同方向，分别为 86.7% 和 60%。
边界同样重要。1 至 2 步的简单任务没有体现 DSL 优势；需要灵活条件逻辑的任务中，Python 有时表现更好。实验只覆盖两个模型、一个自建数据集和一个领域，也没有开发者研究。Anka 本身约有 6,400 行实现，可靠性收益背后存在明确的工具链成本。
因此可以得出一个克制结论：设计良好的 DSL 能减少重复多步骤任务中的顺序和状态管理错误。这项证据还无法支撑 DSL 普遍提升 Agent 可靠性的说法。
四层架构：从意图到可验证执行
很多团队把四类问题都塞进一个 prompt。更稳妥的结构是分层：
| 层 | 职责 | 主要错误 | 确定性检查 |
|---|---|---|---|
| 自然语言 | 收集人的意图 | 歧义和上下文缺失 | 澄清问题、显式假设 |
| 语义模型 | 定义领域对象、关系和不变量 | 意图解释错误 | 类型与不变量检查 |
| DSL | 保存可执行、可审核的计划 | 语法无效、顺序非法 | parser、compiler、schema、linter |
| 运行时 | 执行权限控制并产生外部效果 | 越权或执行结果错误 | dry-run、测试、日志、回滚 |
这套分层能避免一个常见误判：解析成功只说明 DSL 结构合法。TRANSFER account_a account_b 500 可以完全符合语法，同时仍然转错账户、违反授权或偏离用户意图。语义验证负责判断计划是否符合领域规则，运行时策略负责判断能否执行。
DSL、JSON Schema、typed API 怎么选
先用成本最低的约束关闭最重要的失效模式。
| 方案 | 适用情况 | 能约束什么 | 主要边界 |
|---|---|---|---|
| JSON Schema | 结构化输出、简单工具调用 | 字段、类型、必填值 | 难表达多步骤语义 |
| Typed API | 少量稳定动作 | 动词和参数 | 组合逻辑留在别处 |
| 规则引擎 | 明确政策和决策表 | 条件和允许结果 | 不适合复杂过程 |
| DSL | 重复的多步骤领域程序 | 词汇、顺序、不变量、组合 | 语言和工具链成本 |
| 通用代码 | 新颖、开放式实现 | 主要依赖语言规则 | 验证空间最大 |
如果工作流只有搜索、总结、提交审批三个动作，一个 JSON 对象已经够用。继续增加 parser 只会制造维护工作。Typed API 往往是下一步，它可以关闭动作词表，同时保留成熟编程工具。
当组合本身成为风险时，DSL 才更有价值。例如付款前必须审批，更新前必须读取，部分失败后必须回滚，提交前必须达到 quorum。这些规则约束的是领域步骤之间的关系，单个函数签名很难完整表达。
五个建造门槛
1. 领域词汇是否稳定
DSL 会把领域对象和关系固化成语言。发票、审批、部署、replica 等稳定概念适合编码。仍在探索核心对象的产品，会把每次认知更新都变成破坏性语法变更。
2. 错误成本是否足够高
金融变更、基础设施部署、访问控制和受监管流程，需要在执行前阻断非法动作。一次性数据探索通常用不上同等级约束。
3. 结构是否会重复使用
语言工程是一笔固定成本。相同结构被持续生成、修改和审核时，这笔成本可以摊薄。只运行一次的脚本很难摊薄它。
4. 能否建立独立验证器
DSL 至少需要一个独立于模型的确定性验证器。检查项可以包括语法、类型、权限、资源限制、领域不变量、golden test、property test 和 dry-run diff。若最终仍由另一个大模型判断对错，系统只更换了表示方式，还没有形成信任边界。
5. 审核成本能否显著下降
有效 DSL 应该产生小而有业务意义的 diff。审核者看到 REQUIRE two_approvers 就能理解规则变化，无需展开数百行生成代码。若每条 DSL 仍需还原到底层实现才能审核，抽象层没有减少验证工作。
最小可行 DSL
第一版可以非常小：
- 5 至 10 个领域原语。
- 一个版本化 schema 或 AST。
- 一个 parser，或受约束的结构化输入层。
- 一个独立于大模型的确定性 validator。
- 一个调用现有稳定 API 的 adapter。
- golden、negative 和 property tests。
- dry-run、可读 diff、来源记录和迁移规则。
执行逻辑继续放在成熟 API 后面。DSL 描述合法计划，adapter 负责调用现有服务。认证、重试、幂等和事务仍由确定性代码处理。
Agent loop 可以保持简单：
意图 -> 语义计划 -> DSL 候选 -> 验证 -> dry-run
-> 必要时审批 -> 执行 -> 核验结果 -> 保存证据
错误信息应使用领域语言。付款需要两名审批人的提示可以直接指导模型修复。生成式集成代码里的长堆栈很难提供同等清晰的修复目标。
哪些情况适合停在普通代码或 Schema
以下情况出现时，普通代码、typed API 或 schema 更经济：
- 任务只执行一次，或者只有 1 至 2 步。
- 领域规则变化速度高于语言版本迭代速度。
- 新颖条件逻辑本身就是核心价值。
- 团队无法定义独立的语义验证器。
- 现有 schema 和 API 已经能阻断高成本错误。
- 语言、IDE、文档、迁移和支持成本高于重复审核成本。
语法可能过期，validator 可能编码错误政策，优雅抽象也可能排斥合理的非标准需求。成熟 DSL 需要语义模型版本、compiler 测试、来源记录，以及处理语言外任务的明确出口。
从更大的系统看，DSL 是 AI 原生工作流设计 中可选的约束与验证组件。它仍需与上下文、权限、可观测性、人工升级和结果验收共同工作。
FAQ
面向 AI Agent 的 DSL 是什么
它是一种受限语言，让 Agent 只能用固定的领域词汇表达计划。parser 和 validator 可以在运行时执行前拒绝非法结构。
DSL 与 JSON Schema 有什么区别
JSON Schema 主要约束数据形状。DSL 还能表达组合、顺序、领域不变量和可复用过程。若主要需求是字段校验，先用 JSON Schema。
大模型能否在没有微调的情况下学会新 DSL
足够小的语言可以通过上下文学习。Anka 实验的 parse success 达到 99.9%，但结果只覆盖数据转换 benchmark 和两个模型。
DSL 能否保证 Agent 行为正确
它只能排除语法错误，以及 validator 已经编码的语义错误。用户意图错误、规则缺失、compiler 缺陷和外部数据错误都需要额外验证。
团队什么时候值得自建 DSL
领域稳定、任务重复、错误昂贵、组合关系重要，并且可以建立独立 validator 时，自建 DSL 才有合理回报。其他情况优先使用 schema 或 typed API。
参考资料
- Unmesh Joshi：DSLs Enable Reliable Use of LLMs，2026。
- Saif Khalfan Saif Al Mazrouei：Anka: A Domain-Specific Language for Reliable LLM Code Generation，2025。
- Unmesh Joshi：Tickloom。
- Jordi Cabot 等：Exploring the Use of Large Language Models in Domain-Specific Language Development，2025。
- Microsoft：AI Coding Agents and Domain-Specific Languages，2025。