最近在帮团队梳理一套RAG Agent的调用链时我盯着满屏的Python代码突然问身边的同事如果让一个不懂代码的产品经理来描述这个系统的行为他会怎么讲大概率是“用户问一个问题我们从知识库里找到相关片段让模型生成回答再附上引用出处”。这种自然语言描述和真实代码之间的鸿沟已经大到让人有点不安了。当AI系统越做越复杂我们是不是需要一种专门用来“描述AI程序”的语言这不是拍脑袋想出来的概念而是我在同时接触Python Agent框架、Rust Agent生态和提示词工程之后越来越强烈的直觉——我们缺的不是更强的模型而是一层能把“意图”和“实现”重新分开的描述语言。这篇文章就把我脑内的“AI语言”构想完整写出来它不打算替代Python或Rust而是想成为人和AI系统之间的一张可执行的蓝图。1. AI时代编程范式正在发生什么变化从“实现逻辑”到“描述意图”老一代程序员写代码本质是在给机器写剧本先做这个再做那个如果条件成立就跳到另一条路。这种“实现逻辑”的范式统治了计算机行业七十年编译器、操作系统、数据库、Web服务统统建立在这套“告诉机器每一步怎么做”的根基上。但到了大模型时代事情开始变得微妙。当我们调用一个聊天模型时我们不再逐行指示模型如何处理token而是用自然语言描述“你是一个客服助手请根据以下文档回答用户问题”。模型自己完成剩余的大量推理工作——理解语义、组织知识、生成语气合适的回复。代码写的东西悄悄从“如何做”变成了“做什么”。这个转变不是渐进式的它正在动摇编程范式的底层假设。传统编程里我们有一整套精确的工具来表达逻辑类型系统、条件分支、循环、函数调用、异常处理。但AI系统里最核心的东西——意图、上下文、置信度、不确定性、安全边界——这些概念在传统语言里几乎找不到直接对应的语法结构。你可以用Python写一个Agent循环用Rust写一个推理管线但你会发现代码里大部分时间在处理“胶水逻辑”把prompt拼好、处理重试、解析JSON输出、检查是否符合格式。真正属于AI的那部分反而被埋在了一层又一层工具代码下面。我印象最深的一个项目是给某业务线做一个多Agent协作系统。系统里有意图识别Agent、知识检索Agent、写作Agent、质检Agent。跑起来之后最困难的不是让模型输出正确答案而是让这几个Agent之间的协作顺序、容错策略、上下文传递变得可理解、可测试、可解释。每次改需求产品经理说“某个问题没有引用来源需要回退”我就得在agent框架配置里翻半天。那一刻我意识到问题不在于哪个模型不够强而在于我们描述这整套系统的方式太原始了。于是我开始琢磨一种“程序描述语言”Program Description Language简称PDL式的构想。它不描述算法本身而是描述AI系统应该具备的行为、约束、资源和验收标准。传统的编译器吃掉源代码生成可执行机器码这种AI语言则把规格描述翻译成一组可执行的Agent流程、提示词策略和校验规则。2. 现有工具描述AI系统时的四个断层在提出任何新东西之前先把旧东西的问题看清楚。我梳理了当前描述AI系统时最常见的四个断层每个都对应一类让工程师头疼的真实场景。断层一自然语言提示词与代码之间存在“翻译损耗”。现在的AI Agent配置很大一部分是以自然语言提示词存在的。提示词写在配置文件里写在代码字符串里甚至写在产品经理给开发者的文档里。它的优点是灵活缺点是没法测试、没法版本对比、没法约束。你改了一个词可能让整个Agent的好评率跌掉五个点但代码层面完全看不出原因。提示词本身不是程序它缺乏结构、缺乏变量、缺乏类型本质上是一种“一次性口头订单”。真正严肃的AI工程不能把核心逻辑寄托在一段没有约束的散文上。断层二控制流与数据流纠缠不清。一个像样的Agent绝不只是“输入一句输出一句”。它需要循环检索不到结果时怎么办生成内容被安全策略拦截了怎么办多Agent协作中某个环节超时了怎么办这些控制逻辑如果用Python写需要手动管理状态机如果用Rust写要考虑生命周期和错误处理。但站在用户视角这些决策本质上都属于“任务描述”的一部分——你希望系统在什么条件下重试、在什么条件下放弃、在什么条件下切换策略。现在的做法是让工程师把这类逻辑散落在框架回调函数里既难改也难读。断层三非确定性在类型系统里没有位置。传统语言的类型系统擅长表达“这是一个整数”“这是一个字符串”但AI系统里到处是概率、置信度、采样温度、随机种子。同一个prompt不同温度下输出完全不同同一个检索器不同top-k下召回结果差别很大。这些“不确定性的量”目前只能靠参数配置来体现而无法成为类型系统的一部分。结果就是错误处理很笨拙测试很难稳定复现跨团队协作时大家对“这个接口会返回什么样的结果”心里完全没底。断层四资源边界和权限边界表达模糊。大模型时代的安全问题很大程度上不是模型“坏”而是边界没有描述清楚。一个Agent能用哪些知识库能调哪些工具输出要不要过滤个人信息哪些数据不允许进入上下文窗口这些问题在现有语言里没有专门的表达位置。你可以写一堆if判断可以在框架配置里加白名单但本质上这些约束游离在系统描述之外导致审计、合规、安全评审都非常困难。尤其是涉及到具体行业落地时“AI安全工程师”和“AI应用与安全工程师”这类角色最常抱怨的就是你没法从代码里快速回答“这个系统到底有哪些边界”。这四个断层叠加起来就能解释当下AI工程的荒诞感我们一边用最精密的工程手段训练模型一边用最原始的手段去编排模型。AI语言构想的核心动机就是给上述断层提供一套统一的描述框架。3. “AI语言”的设计骨架以意图为核心的分层描述模型那么这个“AI语言”到底长什么样我先说设计原则再给语法草图。设计原则可以用一句话概括把任务规格写得像一份合同而不是像一段代码。所谓“合同”就是写明双方责任、资源范围、验收条件、违约处理。具体到语言设计上我设想了五个核心概念**task任务**是顶层单位描述一个完整的AI行为类似传统语言里的函数或类。每个task必须有一个name、一个version以及一段自然语言级别的目的描述——这段描述不是给机器执行的prompt而是给人看的规格说明同时也是机器的意图锚点。**resource资源**是把外部依赖统一表达出来。模型、知识库、工具API、数据库、缓存全都属于资源。每个资源有类型、有访问权限、有加载策略。这样做的价值在于AI系统的依赖不再散落在prompt和代码里而是一进制可审计的清单。**contract契约**是AI语言里最关键的语法概念。它定义输入输出接口以及验收条件。比如“输入是1到2000字符的用户消息”“输出必须包含引用来源”“不能输出指定名单上的实体”。任何AI task执行完运行时都会检查契约是否满足不满足就触发修复或降级。这等于把传统编程里的“类型检查”升级成了“语义检查”。**flow流程**是唯一保留显式控制流的地方。为什么保留因为不是所有AI系统都能完全自由地编排步骤。有些场景必须固定顺序先身份验证再查知识库最后生成回复。在这个层面允许人也允许机器介入但flow应当是可选而非必须的。AI语言默认拥抱“让运行时决定最佳执行路径”只有需要强约束时才显式声明flow。**guard守卫**负责安全与合规边界。它独立于任务流程存在是全局的、不可被业务逻辑绕过的保护层。守卫可以声明“禁止PII进入模型上下文”“所有模型调用必须记录日志”“输出必须通过内容安全过滤”。理论上讲guard是AI语言对“AI安全工程师”这个角色最大的贡献——安全策略终于能被单独写、单独审、单独测试了。这五个概念构成了一个分层模型最外层是业务方看得懂的task描述中间层是工程师调整的flow和contract最底层是编译器解释器负责解析的resource与guard。上层告诉系统“我们要什么”下层决定系统“怎么能安全地做到”。这个分层模型也是我坚持称为“程序描述语言”而不是“编程语言”的原因——它更像IEEE里的规格说明语言只是规格的对象变成了AI系统。4. 一段虚构的AI语言代码语法草图与运行语义纸上谈兵没有说服力我直接给一段虚构的语法草图。下面这段代码描述的是一个“客服工单智能分诊与回复”的例子你可以把它理解成传统编程里的伪代码但我尽量把语法设计得接近真实语言task 客服工单智能分诊与回复 { version: 0.1 purpose: 根据帮助文档对用户问题进行意图分诊并生成带引用的回复 resource knowledge { source: vector-db(help-docs) sync: daily permission: read-only } resource model { provider: openai-compatible(gpt-4o) options: { temperature: 0.2, max_tokens: 512 } } contract { input user_message: text(1..2000) output reply: text expected: { contains_citation true, no_unsafe_content true, reply_length 500 } } guard { block: [pii, profanity, unsafe] log: all_model_calls, all_retrievals allowed_tools: [knowledge.search] } flow { intent classify(model, user_message); docs retrieve(knowledge, [user_message, intent]); draft generate(model, context[docs, user_message], system客服助手); reply validate(draft, contract); return repair(reply); } }我来逐个解释这段代码的“运行语义”。这个语言不是直接跑给模型看的而是先经过一个编译器或解释器生成一份“执行计划”。执行计划里包含三样东西每个步骤具体的prompt模板、步骤之间的数据流、以及需要检查的规则。第一步intent classify(model, user_message)运行时会对model资源发起一次专用分类任务。值得注意的细节是classify是语言内置的语义操作不是模型输出一个JSON再自己解析。编译器知道如何把这个操作转化为一次带结构化输出的模型调用并在输出不合规时自动重试。第二步docs retrieve(knowledge, [user_message, intent])表示一次受限的检索操作。knowledge资源在guard里被声明为read-only同时guard的allowed_tools限制了运行时的工具调用范围。如果在flow里试图调用一个不在允许列表里的工具编译器会直接报错。这相当于把权限校验提到了编译期而不是运行期。第三步生成后validate(draft, contract)是一个值得一提的设计。传统语言里函数返回什么就返回什么AI语言里一个task的输出必须满足contract里声明的语义条件。运行时会把draft送进一个轻量级验证器检查它是否真的包含引用、是否触发全球内容安全规则、长度是否超限。如果验证失败flow里的repair(reply)会触发一次“修复”操作——把错误信息拼进新prompt让模型自己修改输出。这个机制我称它为“语义级异常处理”它对应了真实AI系统里最常用的纠错回环只是把它显式化了。我还想在语法上强调两点。第一purpose字段是给人类读的也是给编译器的“意图提示”用的。编译器在生成prompt时会把purpose并入系统提示词在生成执行计划时purpose可以作为模型选择、参数调整的参考。第二guard是强制性的吗我的构想里至少在正式环境是强制性的。如果一个task没有声明guard编译器可以拒绝编译或强制加载默认守卫。安全不能靠自觉这点尤其适用于To B和To G场景。这种语言和现有DSL最大的区别在于它不只是配置而是有“语义检查”能力的描述。传统的DSL比如yaml配置只能定义“有什么”AI语言还要定义“必须达到什么”并且运行时真的去验证。5. 为什么Rust可能成为AI语言的最佳底座聊到实现层面很多人会首先想到Python——毕竟大模型生态几乎都在Python里。但我的判断是如果AI语言要真正走向工程化Rust反而是更合适的底座。这个判断和近期社区里“基于Rust语言AI Agent”的热度上升是吻合的而我认为这种热度背后有结构性的原因。Rust的核心优势有三个。第一是内存安全与并发安全。AI Agent系统本质上是一堆并发任务的编排检索线程、模型调用线程、日志线程、安全过滤线程同时运转。Rust的所有权模型可以强制避免数据竞争这在Python里要靠经验或事件循环来规避在Rust里则被编译器盯死。第二是无GC的确定性。AI语言需要精确控制延迟和资源占用尤其是在边缘设备或实时推理场景下垃圾回收带来的不确定停顿可能会让整个agent行为偏离预期。第三是可靠的类型系统与模式匹配。AI语言里需要频繁处理“成功、失败、重试、降级、违禁”这类带tag的枚举状态Rust的enum和Result、Option类型几乎是天生契合的。我构想的实现路径是这样的AI语言不是另一个从零写的脚本解释器而是一个“规格描述编译器”前端负责解析AI语言语法后端生成Rust代码或直接生成AST执行图。生成的代码落在某个Rust Agent框架上——比如现成的agent runtime由这个runtime负责并发调度、重试、资源管理。Rust编译器本身就成了AI语言的第一道防线AI语言里声明式和约束式的语义可以被翻译成强类型的Rust结构很多contract不满足的情况能在编译期就暴露出来。举个例子AI语言里的resource声明翻译成Rust后会变成带权限标记的结构体struct Resource { pool: ResourcePool, permission: Permission }。ai语言的guard翻译成Rust宏进一步展开为对模型调用函数的包装强制每次调用前经过安全过滤器。这种“规格层—执行层—系统层”的依赖关系让AI系统每一层都有自己的职责而不是像现在这样所有逻辑挤在Python里。当然这不是说Python毫无优势。做原型、做交互实验、做快速验证Python依然最快。但AI语言处理的是“正式的系统描述”应该更接近基础设施而Rust在这方面的严谨性是加分项。我甚至设想过一个很具体的产品形态用AI语言写一个“Agent规格文件”然后通过命令行工具ai run spec.ai编译并执行通过ai audit spec.ai输出完整的资源清单和守卫清单。这让“AI训练师”“AI安全工程师”这类角色第一次有了一个可以开会评审的“代码级产物”。6. 从构想到落地场景、路径与必须直面的边界聊完了设计最后讲怎么落地以及我会保持什么样的怀疑心态。先说场景我长期看好三个方向。第一个方向是企业级AI系统的治理与审计。现在的企业汇入AI安全工程师、AI应用与安全工程师后最头疼的是没法向监管和内部风控演示“这个系统到底怎么运作的”。AI语言天然适合生成审计报告每个任务有多少资源、多少guard、多少次模型调用全在一份etxt文件里。安全人员可以像review代码一样review规格而不是去看一堆散落的prompt。第二个方向是教育与科研。人工智能方向的课程教材、导论、期末大作业很容易陷入“调API写小demo”的低水平重复。如果有一门AI语言作为教学载体学生学的是“如何描述一个AI任务”、“如何定义安全边界”比盲目堆功能更能培养工程素养。科研论文里用AI语言描述实验设置也能减少“复现不了”的尴尬——模型版本、检索器参数、交互策略全部以规格形式公开。第三个方向是多Agent系统的编排。单个Agent用Python写没问题但几十个Agent、上千个协作任务时Orchestration层面需要的就是一份可合并、可继承、可版本对比的规格文档。AI语言里task与task之间可以复用契约、组合守卫这比在代码里互相调函数要清晰得多。落地路径我建议分四步走步子太大会摔。第一步先用Rust内部实现一个Embedded DSL把task、contract、guard四个核心概念做成宏和结构体团队内部小范围试用。第二步根据真实项目反馈把DSL“提纯”——凡是反复手工修改的部分就值得变成语法糖或独立语法。第三步实现独立的解析器和编译器前端输出中间表示接入Rust agent runtime。第四步等社区有一定共识再考虑做IDE插件、LSP服务、以及规格交换标准。但必须说这个构想还有三个我现在无法回避的边界。第一是自然语言与精确约束的矛盾。AI语言想在purpose字段使用自然语言又想在其他地方保持强约束。如果自然语言理解错了任务后面所有契约守卫都是空转。所以“意图正确性”会是一个永远需要人来兜底的环节AI语言不能彻底解决“需求理解错”的问题。第二是评判标准的不可穷尽性。contract里的expected条件再丰富也覆盖不了真实世界里千奇百怪的bad case。语言设计者不能因为有了语义验证就放松对测试集、评估集的建设。契约只是“最低要求”不是“高质量保证”。第三是标准化阻力。AI语言如果要成为通用标准必须跟模型厂商、框架社区、安全监管机构都形成共识。这不是技术问题而是生态博弈。也许最终它不会成为一个独立的编程语言而是以一种“配置家族”或“交换格式”的形式存在那也算实现了我一半的目标。我不会神话这个构想。它在现在的形态下更像是一个思考框架当你设计AI系统时试着先写一份“规格合同”——写明资源、契约、守卫然后才让工程师去实现。就算AI语言永远不落地这套思维方式也足以让AI工程项目少踩很多坑。就我个人在真实Agent项目里的体感来说当一个系统只有两三个Agent时用现有语言硬写完全足够但一旦任务规模超过某个临界点缺的就不只是更强的执行层而是一层能让所有人对齐的“描述层”。AI语言能不能成为那层描述我还没十足把握但我确信方向没错。至少从下一次动手写Agent前先写一份“可执行的规格”开始变化的苗头就已经出现了。
最近在帮团队梳理一套RAG Agent的调用链时我盯着满屏的Python代码突然问身边的同事如果让一个不懂代码的产品经理来描述这个系统的行为他会怎么讲大概率是“用户问一个问题我们从知识库里找到相关片段让模型生成回答再附上引用出处”。这种自然语言描述和真实代码之间的鸿沟已经大到让人有点不安了。当AI系统越做越复杂我们是不是需要一种专门用来“描述AI程序”的语言这不是拍脑袋想出来的概念而是我在同时接触Python Agent框架、Rust Agent生态和提示词工程之后越来越强烈的直觉——我们缺的不是更强的模型而是一层能把“意图”和“实现”重新分开的描述语言。这篇文章就把我脑内的“AI语言”构想完整写出来它不打算替代Python或Rust而是想成为人和AI系统之间的一张可执行的蓝图。1. AI时代编程范式正在发生什么变化从“实现逻辑”到“描述意图”老一代程序员写代码本质是在给机器写剧本先做这个再做那个如果条件成立就跳到另一条路。这种“实现逻辑”的范式统治了计算机行业七十年编译器、操作系统、数据库、Web服务统统建立在这套“告诉机器每一步怎么做”的根基上。但到了大模型时代事情开始变得微妙。当我们调用一个聊天模型时我们不再逐行指示模型如何处理token而是用自然语言描述“你是一个客服助手请根据以下文档回答用户问题”。模型自己完成剩余的大量推理工作——理解语义、组织知识、生成语气合适的回复。代码写的东西悄悄从“如何做”变成了“做什么”。这个转变不是渐进式的它正在动摇编程范式的底层假设。传统编程里我们有一整套精确的工具来表达逻辑类型系统、条件分支、循环、函数调用、异常处理。但AI系统里最核心的东西——意图、上下文、置信度、不确定性、安全边界——这些概念在传统语言里几乎找不到直接对应的语法结构。你可以用Python写一个Agent循环用Rust写一个推理管线但你会发现代码里大部分时间在处理“胶水逻辑”把prompt拼好、处理重试、解析JSON输出、检查是否符合格式。真正属于AI的那部分反而被埋在了一层又一层工具代码下面。我印象最深的一个项目是给某业务线做一个多Agent协作系统。系统里有意图识别Agent、知识检索Agent、写作Agent、质检Agent。跑起来之后最困难的不是让模型输出正确答案而是让这几个Agent之间的协作顺序、容错策略、上下文传递变得可理解、可测试、可解释。每次改需求产品经理说“某个问题没有引用来源需要回退”我就得在agent框架配置里翻半天。那一刻我意识到问题不在于哪个模型不够强而在于我们描述这整套系统的方式太原始了。于是我开始琢磨一种“程序描述语言”Program Description Language简称PDL式的构想。它不描述算法本身而是描述AI系统应该具备的行为、约束、资源和验收标准。传统的编译器吃掉源代码生成可执行机器码这种AI语言则把规格描述翻译成一组可执行的Agent流程、提示词策略和校验规则。2. 现有工具描述AI系统时的四个断层在提出任何新东西之前先把旧东西的问题看清楚。我梳理了当前描述AI系统时最常见的四个断层每个都对应一类让工程师头疼的真实场景。断层一自然语言提示词与代码之间存在“翻译损耗”。现在的AI Agent配置很大一部分是以自然语言提示词存在的。提示词写在配置文件里写在代码字符串里甚至写在产品经理给开发者的文档里。它的优点是灵活缺点是没法测试、没法版本对比、没法约束。你改了一个词可能让整个Agent的好评率跌掉五个点但代码层面完全看不出原因。提示词本身不是程序它缺乏结构、缺乏变量、缺乏类型本质上是一种“一次性口头订单”。真正严肃的AI工程不能把核心逻辑寄托在一段没有约束的散文上。断层二控制流与数据流纠缠不清。一个像样的Agent绝不只是“输入一句输出一句”。它需要循环检索不到结果时怎么办生成内容被安全策略拦截了怎么办多Agent协作中某个环节超时了怎么办这些控制逻辑如果用Python写需要手动管理状态机如果用Rust写要考虑生命周期和错误处理。但站在用户视角这些决策本质上都属于“任务描述”的一部分——你希望系统在什么条件下重试、在什么条件下放弃、在什么条件下切换策略。现在的做法是让工程师把这类逻辑散落在框架回调函数里既难改也难读。断层三非确定性在类型系统里没有位置。传统语言的类型系统擅长表达“这是一个整数”“这是一个字符串”但AI系统里到处是概率、置信度、采样温度、随机种子。同一个prompt不同温度下输出完全不同同一个检索器不同top-k下召回结果差别很大。这些“不确定性的量”目前只能靠参数配置来体现而无法成为类型系统的一部分。结果就是错误处理很笨拙测试很难稳定复现跨团队协作时大家对“这个接口会返回什么样的结果”心里完全没底。断层四资源边界和权限边界表达模糊。大模型时代的安全问题很大程度上不是模型“坏”而是边界没有描述清楚。一个Agent能用哪些知识库能调哪些工具输出要不要过滤个人信息哪些数据不允许进入上下文窗口这些问题在现有语言里没有专门的表达位置。你可以写一堆if判断可以在框架配置里加白名单但本质上这些约束游离在系统描述之外导致审计、合规、安全评审都非常困难。尤其是涉及到具体行业落地时“AI安全工程师”和“AI应用与安全工程师”这类角色最常抱怨的就是你没法从代码里快速回答“这个系统到底有哪些边界”。这四个断层叠加起来就能解释当下AI工程的荒诞感我们一边用最精密的工程手段训练模型一边用最原始的手段去编排模型。AI语言构想的核心动机就是给上述断层提供一套统一的描述框架。3. “AI语言”的设计骨架以意图为核心的分层描述模型那么这个“AI语言”到底长什么样我先说设计原则再给语法草图。设计原则可以用一句话概括把任务规格写得像一份合同而不是像一段代码。所谓“合同”就是写明双方责任、资源范围、验收条件、违约处理。具体到语言设计上我设想了五个核心概念**task任务**是顶层单位描述一个完整的AI行为类似传统语言里的函数或类。每个task必须有一个name、一个version以及一段自然语言级别的目的描述——这段描述不是给机器执行的prompt而是给人看的规格说明同时也是机器的意图锚点。**resource资源**是把外部依赖统一表达出来。模型、知识库、工具API、数据库、缓存全都属于资源。每个资源有类型、有访问权限、有加载策略。这样做的价值在于AI系统的依赖不再散落在prompt和代码里而是一进制可审计的清单。**contract契约**是AI语言里最关键的语法概念。它定义输入输出接口以及验收条件。比如“输入是1到2000字符的用户消息”“输出必须包含引用来源”“不能输出指定名单上的实体”。任何AI task执行完运行时都会检查契约是否满足不满足就触发修复或降级。这等于把传统编程里的“类型检查”升级成了“语义检查”。**flow流程**是唯一保留显式控制流的地方。为什么保留因为不是所有AI系统都能完全自由地编排步骤。有些场景必须固定顺序先身份验证再查知识库最后生成回复。在这个层面允许人也允许机器介入但flow应当是可选而非必须的。AI语言默认拥抱“让运行时决定最佳执行路径”只有需要强约束时才显式声明flow。**guard守卫**负责安全与合规边界。它独立于任务流程存在是全局的、不可被业务逻辑绕过的保护层。守卫可以声明“禁止PII进入模型上下文”“所有模型调用必须记录日志”“输出必须通过内容安全过滤”。理论上讲guard是AI语言对“AI安全工程师”这个角色最大的贡献——安全策略终于能被单独写、单独审、单独测试了。这五个概念构成了一个分层模型最外层是业务方看得懂的task描述中间层是工程师调整的flow和contract最底层是编译器解释器负责解析的resource与guard。上层告诉系统“我们要什么”下层决定系统“怎么能安全地做到”。这个分层模型也是我坚持称为“程序描述语言”而不是“编程语言”的原因——它更像IEEE里的规格说明语言只是规格的对象变成了AI系统。4. 一段虚构的AI语言代码语法草图与运行语义纸上谈兵没有说服力我直接给一段虚构的语法草图。下面这段代码描述的是一个“客服工单智能分诊与回复”的例子你可以把它理解成传统编程里的伪代码但我尽量把语法设计得接近真实语言task 客服工单智能分诊与回复 { version: 0.1 purpose: 根据帮助文档对用户问题进行意图分诊并生成带引用的回复 resource knowledge { source: vector-db(help-docs) sync: daily permission: read-only } resource model { provider: openai-compatible(gpt-4o) options: { temperature: 0.2, max_tokens: 512 } } contract { input user_message: text(1..2000) output reply: text expected: { contains_citation true, no_unsafe_content true, reply_length 500 } } guard { block: [pii, profanity, unsafe] log: all_model_calls, all_retrievals allowed_tools: [knowledge.search] } flow { intent classify(model, user_message); docs retrieve(knowledge, [user_message, intent]); draft generate(model, context[docs, user_message], system客服助手); reply validate(draft, contract); return repair(reply); } }我来逐个解释这段代码的“运行语义”。这个语言不是直接跑给模型看的而是先经过一个编译器或解释器生成一份“执行计划”。执行计划里包含三样东西每个步骤具体的prompt模板、步骤之间的数据流、以及需要检查的规则。第一步intent classify(model, user_message)运行时会对model资源发起一次专用分类任务。值得注意的细节是classify是语言内置的语义操作不是模型输出一个JSON再自己解析。编译器知道如何把这个操作转化为一次带结构化输出的模型调用并在输出不合规时自动重试。第二步docs retrieve(knowledge, [user_message, intent])表示一次受限的检索操作。knowledge资源在guard里被声明为read-only同时guard的allowed_tools限制了运行时的工具调用范围。如果在flow里试图调用一个不在允许列表里的工具编译器会直接报错。这相当于把权限校验提到了编译期而不是运行期。第三步生成后validate(draft, contract)是一个值得一提的设计。传统语言里函数返回什么就返回什么AI语言里一个task的输出必须满足contract里声明的语义条件。运行时会把draft送进一个轻量级验证器检查它是否真的包含引用、是否触发全球内容安全规则、长度是否超限。如果验证失败flow里的repair(reply)会触发一次“修复”操作——把错误信息拼进新prompt让模型自己修改输出。这个机制我称它为“语义级异常处理”它对应了真实AI系统里最常用的纠错回环只是把它显式化了。我还想在语法上强调两点。第一purpose字段是给人类读的也是给编译器的“意图提示”用的。编译器在生成prompt时会把purpose并入系统提示词在生成执行计划时purpose可以作为模型选择、参数调整的参考。第二guard是强制性的吗我的构想里至少在正式环境是强制性的。如果一个task没有声明guard编译器可以拒绝编译或强制加载默认守卫。安全不能靠自觉这点尤其适用于To B和To G场景。这种语言和现有DSL最大的区别在于它不只是配置而是有“语义检查”能力的描述。传统的DSL比如yaml配置只能定义“有什么”AI语言还要定义“必须达到什么”并且运行时真的去验证。5. 为什么Rust可能成为AI语言的最佳底座聊到实现层面很多人会首先想到Python——毕竟大模型生态几乎都在Python里。但我的判断是如果AI语言要真正走向工程化Rust反而是更合适的底座。这个判断和近期社区里“基于Rust语言AI Agent”的热度上升是吻合的而我认为这种热度背后有结构性的原因。Rust的核心优势有三个。第一是内存安全与并发安全。AI Agent系统本质上是一堆并发任务的编排检索线程、模型调用线程、日志线程、安全过滤线程同时运转。Rust的所有权模型可以强制避免数据竞争这在Python里要靠经验或事件循环来规避在Rust里则被编译器盯死。第二是无GC的确定性。AI语言需要精确控制延迟和资源占用尤其是在边缘设备或实时推理场景下垃圾回收带来的不确定停顿可能会让整个agent行为偏离预期。第三是可靠的类型系统与模式匹配。AI语言里需要频繁处理“成功、失败、重试、降级、违禁”这类带tag的枚举状态Rust的enum和Result、Option类型几乎是天生契合的。我构想的实现路径是这样的AI语言不是另一个从零写的脚本解释器而是一个“规格描述编译器”前端负责解析AI语言语法后端生成Rust代码或直接生成AST执行图。生成的代码落在某个Rust Agent框架上——比如现成的agent runtime由这个runtime负责并发调度、重试、资源管理。Rust编译器本身就成了AI语言的第一道防线AI语言里声明式和约束式的语义可以被翻译成强类型的Rust结构很多contract不满足的情况能在编译期就暴露出来。举个例子AI语言里的resource声明翻译成Rust后会变成带权限标记的结构体struct Resource { pool: ResourcePool, permission: Permission }。ai语言的guard翻译成Rust宏进一步展开为对模型调用函数的包装强制每次调用前经过安全过滤器。这种“规格层—执行层—系统层”的依赖关系让AI系统每一层都有自己的职责而不是像现在这样所有逻辑挤在Python里。当然这不是说Python毫无优势。做原型、做交互实验、做快速验证Python依然最快。但AI语言处理的是“正式的系统描述”应该更接近基础设施而Rust在这方面的严谨性是加分项。我甚至设想过一个很具体的产品形态用AI语言写一个“Agent规格文件”然后通过命令行工具ai run spec.ai编译并执行通过ai audit spec.ai输出完整的资源清单和守卫清单。这让“AI训练师”“AI安全工程师”这类角色第一次有了一个可以开会评审的“代码级产物”。6. 从构想到落地场景、路径与必须直面的边界聊完了设计最后讲怎么落地以及我会保持什么样的怀疑心态。先说场景我长期看好三个方向。第一个方向是企业级AI系统的治理与审计。现在的企业汇入AI安全工程师、AI应用与安全工程师后最头疼的是没法向监管和内部风控演示“这个系统到底怎么运作的”。AI语言天然适合生成审计报告每个任务有多少资源、多少guard、多少次模型调用全在一份etxt文件里。安全人员可以像review代码一样review规格而不是去看一堆散落的prompt。第二个方向是教育与科研。人工智能方向的课程教材、导论、期末大作业很容易陷入“调API写小demo”的低水平重复。如果有一门AI语言作为教学载体学生学的是“如何描述一个AI任务”、“如何定义安全边界”比盲目堆功能更能培养工程素养。科研论文里用AI语言描述实验设置也能减少“复现不了”的尴尬——模型版本、检索器参数、交互策略全部以规格形式公开。第三个方向是多Agent系统的编排。单个Agent用Python写没问题但几十个Agent、上千个协作任务时Orchestration层面需要的就是一份可合并、可继承、可版本对比的规格文档。AI语言里task与task之间可以复用契约、组合守卫这比在代码里互相调函数要清晰得多。落地路径我建议分四步走步子太大会摔。第一步先用Rust内部实现一个Embedded DSL把task、contract、guard四个核心概念做成宏和结构体团队内部小范围试用。第二步根据真实项目反馈把DSL“提纯”——凡是反复手工修改的部分就值得变成语法糖或独立语法。第三步实现独立的解析器和编译器前端输出中间表示接入Rust agent runtime。第四步等社区有一定共识再考虑做IDE插件、LSP服务、以及规格交换标准。但必须说这个构想还有三个我现在无法回避的边界。第一是自然语言与精确约束的矛盾。AI语言想在purpose字段使用自然语言又想在其他地方保持强约束。如果自然语言理解错了任务后面所有契约守卫都是空转。所以“意图正确性”会是一个永远需要人来兜底的环节AI语言不能彻底解决“需求理解错”的问题。第二是评判标准的不可穷尽性。contract里的expected条件再丰富也覆盖不了真实世界里千奇百怪的bad case。语言设计者不能因为有了语义验证就放松对测试集、评估集的建设。契约只是“最低要求”不是“高质量保证”。第三是标准化阻力。AI语言如果要成为通用标准必须跟模型厂商、框架社区、安全监管机构都形成共识。这不是技术问题而是生态博弈。也许最终它不会成为一个独立的编程语言而是以一种“配置家族”或“交换格式”的形式存在那也算实现了我一半的目标。我不会神话这个构想。它在现在的形态下更像是一个思考框架当你设计AI系统时试着先写一份“规格合同”——写明资源、契约、守卫然后才让工程师去实现。就算AI语言永远不落地这套思维方式也足以让AI工程项目少踩很多坑。就我个人在真实Agent项目里的体感来说当一个系统只有两三个Agent时用现有语言硬写完全足够但一旦任务规模超过某个临界点缺的就不只是更强的执行层而是一层能让所有人对齐的“描述层”。AI语言能不能成为那层描述我还没十足把握但我确信方向没错。至少从下一次动手写Agent前先写一份“可执行的规格”开始变化的苗头就已经出现了。
