发送一个空程序，AI就学会了你的语言

1次空请求，0行代码，返回来8条运行限制和完整语言手册。听上去像是偷懒的幻想，却真实地存在于Neander语言的冷启动设计中。在通常的对话系统或代理模型里，一个智能体想要调用API、编写程序，必须先知道这门语言的语法和规则——可要获取这些规则，又得先能用这门语言发出请求，典型的鸡生蛋、蛋生鸡。

Neander的解法毫不复杂：交给智能体一个特殊的默认动作。当一个刚刚苏醒、对语言一无所知的冷启动代理，第一次接触Neander运行时（比如一个叫Grotto的实现），它唯一能做的就是提交一个“空程序”。这个空程序不是什么占位符或语法糖，它就是字面意义上的空白输入，一行代码也没有。

运行时收到这个空程序后，不会把它当成语法错误抛出来。规范明确要求，空程序是一种合法的输入，必须用一套特殊的响应信封来接待。信封里装了两样东西：一份完整的Neander参考文档，详细描述语言该怎么用；一份当前运行时环境的配置快照，把所有运行限制摊开摆在智能体面前。

这份响应信封长得很像一段格式化数据。成功的标志位是true，结果的字段里就是“# The Neander Reference...”那种原汁原味的语言说明书。元数据区域则展开了一串具体数字：
· neanderVersion 是1，代表语言版本；
· thalerBudget 给出500的预算额度；
· memoryBudgetKb 设为1024，意味着可用内存不能超过1MB；
· maxDurationMs 定在30000毫秒，一次程序最长跑30秒；
· perCallTimeoutMs 是5000毫秒，单个调用最多等5秒；
· maxProgramSizeBytes 限制在262144字节，也就是256KB的程序体量；
· maxNestingDepth 给到128层嵌套上限；
· maxRepeatLimit 拉到10000次循环封顶。

一趟往返，智能体就同时拿到了“怎么用”和“能用到什么程度”的所有信息。这背后依赖Neander世界的一条铁律：一切都算程序，包括请求使用手册这件事本身。所以当你空着手去找运行时，本质上也是在提交一个特定的程序，一个专门用来问“请告诉我游戏规则”的程序。

运作机制里还有一个讨巧的优化。像Grotto这样的运行时在处理空程序时，根本不会像对待普通程序那样去启动一个工作进程做词法分析和语法解析。调度器一眼就认出这是个空请求，直接从缓存里拽出已经备好的参考响应，连解析器的边都不沾。这也意味着，一次冷启动所消耗的资源极其有限，几乎可以忽略不计。

站在嵌入应用的角度看，这种开箱即用的自举能力加上运行时自带的“发现”机制（上次已经聊过，智能体能用discover动词动态探查可用API），实在是一种便利的组合。应用开发者需要做的，只不过是把自家API注册到运行时里，再把智能体跟运行时连起来。剩下的，就是向智能体通知那项关键的submitProgram操作已经可以使用了。

通知的方式不限，视底层技术而定，但内容上最好附带一个善意的提醒：别多想，先发一个空程序过去，了解一下语言再说。这句话就像给初来乍到的熟客递上一杯温水，成本接近零，却能让智能体少走一大圈冤枉路。毕竟当下的智能体虽然聪明，但真没到能读心的地步。

既然说到了Neander参考文档，那就还得提一下它的设计定位。实际上，Neander存在两份性质完全不同的文档，这种拆分是有意为之的，因为它们面对的是两类截然不同的受众。

第一份就是运行时返回给智能体的那份参考手册。它走的是实例驱动路线，由三部分组成：让智能体快速上手起步的“入门指南”；一本可以复制粘贴就直接能用的“烹饪书”，里面全是拿来就上手的代码配方；最后才是供查阅用的正式语言参考，适合有经验的智能体按需翻看。整本文档只回答“如何做”的问题，从不解释“语言为什么这么设计”。

第二份文档是语言的规范本身，它又厚又严谨，是那个追求精确无误、穷尽一切细节的官方定义。这份文档的读者压根不是普通写程序的智能体，而是那些打算自己动手实现一套Neander运行时的“编码代理”——它们需要知道每一个角落的准确定义，以便去规划并执行运行时本身的搭建。也正因如此，规范里不会有那些温情的菜谱和示例，只有冷静的规则集合。

把引导、自举和文档分层串起来看，Neander给出的是一种相当克制的冷启动哲学：不预设任何先验知识，不依赖外部配置中心，只在运行时的联网约定里埋下一个“空请求等于给手册”的硬通道。这个通道既是新手村门口的告示板，也是零认知成本的安全网，让一个连语言长什么样都不知道的智能体，能够循着一条最低能耗的路径，自己把起点踩实了。