# 给大模型建一个更小的可执行世界：DSL、FastAPI 与上下文基础设施

> 原标题：LLM 需要一个更小的可执行世界：DSL、FastAPI 与 Context Infrastructure

- 来源：Computing Life · Share · 鸭哥调研
- 发布时间：2026-07-18T00:00:00.000Z
- AX AI 日报：https://ai-daily.ax0x.ai/items/45201
- 原文：https://yage.ai/share/llm-smaller-executable-world-20260718.html

## 摘要

作者从自己放弃 DSL 的经历说起，指出 AI 大幅降低了设计语言、写解析器和准备示例的成本，让团队可以先建领域边界，再根据实际使用决定它的寿命。核心思路是把 FastAPI 当作原子操作层，DSL 负责描述完整计划，上下文基础设施保存过去的判断和纠正。文章引用了 Unmesh Joshi 的 DSL 文章和 Tickloom 演示，但指出 Tickl...

## 推荐理由

标题角度新鲜，架构思路具体，直击 agent 工程的核心痛点，三条 HKR 都踩中了。分数定在 72 是因为它来自个人博客的观点文章，没有可复现的实验或生产环境案例，思考质量高但不是硬实证，所以不往上调。

## 锐评

这篇文章把 DSL 重新定位成“给 LLM 建一个更小的可执行世界”，而不是发明新语法。核心逻辑是：AI 降低了设计语言、写解析器和准备示例的成本，团队可以先为眼前几个相似任务建立领域边界，跑起来再决定它的寿命。这个判断是成立的，但文章引用的 Tickloom 项目只是一个工程案例，没有比较同一批任务在自然语言、JSON、普通 Java 和 DSL 下的生成成功率，也没有跨模型 benchmark。它能说明机制怎么工作，不能证明 DSL 已经普遍提高 LLM 的任务正确率。

文章提出的三层架构值得关注：FastAPI 负责原子操作，DSL 描述完整计划，Context Infrastructure 保存过去的判断和纠正。这比单纯堆 prompt 更接近工程系统。但作者也诚实指出缩小世界的代价——边界太窄可能把正确答案一起删掉。判断重点不在 DSL 是否图灵完备，而在模型能触发哪些外部效果，以及系统允许这些动作怎样组合。

还缺什么？文章没给出 DSL 设计的具体方法论，比如怎么判断领域动作是否足够稳定、怎么避免过度约束。也没有讨论 DSL 的维护成本在团队规模变大后如何分摊。如果后续能补充跨模型的对比实验和实际项目的长期维护数据，这套思路会更有说服力。