书接上文,我们探讨了 Wenli (文理) 诞生的初衷。今天,随着 spec.py 规范的明确以及 test_parser.py 验证逻辑的跑通,我想更深入地聊聊它的核心设计哲学,以及我们正在构筑的 AI 原生编程新范式。完整的语言规范可以在这里找到,现在该规范使用简体中文描述,相信只要符合 EBNF 范式,可以非常方便地为 Wenli 创建各种形式的方言版本并使用我们正在开发的工具链。
Wenli 不仅仅是另一种脚本语言,它是一场实验。我们的目标是打破自然语言的“模糊性”与机器指令的“确定性”之间的屏障。通过 Lark 解析器,Wenli 已经能够将类自然语言的语法结构精准转化为抽象数据树( ADT ),为后续的 AI 代理( Agent )调用打下了坚实的语法基础。
为了直观理解 Wenli 的表达力,我们来看一个典型的“技能调用”场景。
---
# 核心翻译流水线
## 输入:原始链接、目标语言(字符串)
## 参数:
- 最大重试次数:3
- 严格模式:真
- 默认模型:“gpt-4o”(模型类型)
## 输出:
- 最终结果:Markdown 文本
- 总耗时:数值
#### 这是单行注释,不应该被解析进 AST
使用网页加载器处理原始链接,保存为网页源码( HTML 文本)、加载状态。
- 超时时间:30
- 代理:“http://localhost:8080”
如果使用状态检查器处理加载状态以得到加载成功为假,则:
报错“网页加载失败,无法继续”。
否则:
“提取主要正文,翻译为{目标语言}”,保存为提取正文。
> 网页源码
- 温度:0.7
结束判断加载成功。
---
# 批量数据与循环测试
## 输入:文件列表
## 输出:结果报告
使用初使化工具处理文件列表,保存为队列。
对于队列中的每一个文件:
如果“检查文件类型”以得到是否为图片为真,则:
“描述这张图片:{文件}”,保存为图片描述。
- 视觉模式:真
否则:
使用文本读取器处理文件,保存为文本内容。
结束判断是否为图片。
结束处理文件。
---
# 代码生成器与多重赋值测试
## 输入:用户需求
## 输出:
- 代码行数:数值
` ``python
def setup_env():
print("Environment ready for AST testing!")
` ``
“生成相应的测试代码:{用户需求}”,保存为测试代码(代码文本)。使用保存器处理测试代码、用户需求,保存为保存状态。
“{测试代码} 保存到 临时文件夹 并运行”,保存为临时文件路径。
- 工具:写入文件、用户确认
`wc -l {临时文件路径}`,保存为代码行数。
> 临时文件路径
def 核心翻译流水线(原始链接, 目标语言: 字符串, 最大重试次数=3, 严格模式=真, 默认模型=模型类型(gpt-4o)) -> tuple[Markdown 文本, 数值]:
网页源码: HTML 文本, 加载状态 = 网页加载器(原始链接, kwargs={'超时时间': '30', '代理': 'http://localhost:8080'})
if (加载成功 := 状态检查器(加载状态)) == False:
raise RuntimeError(网页加载失败,无法继续)
else:
提取正文 = llm_agent('提取主要正文,翻译为{目标语言}', args=(目标语言,), kwargs={'温度': 0.7}, history=['网页源码'])
return 最终结果, 总耗时
----------------------------------------
def 批量数据与循环测试(文件列表) -> tuple[Any]:
队列 = 初使化工具(文件列表)
for 文件 in 队列:
if (是否为图片 := llm_agent('检查文件类型')) == True:
图片描述 = llm_agent('描述这张图片:{文件}', args=(文件,), kwargs={'视觉模式': '真'})
else:
文本内容 = 文本读取器(文件)
return 结果报告
----------------------------------------
def 代码生成器与多重赋值测试(用户需求) -> tuple[数值]:
def setup_env():
print("Environment ready for AST testing!")
测试代码: 代码文本 = llm_agent('生成相应的测试代码:{用户需求}', args=(用户需求,))
保存状态 = 保存器(测试代码, 用户需求)
临时文件路径 = llm_agent('{测试代码} 保存到 临时文件夹 并运行', args=(测试代码,), tools=['写入文件', '用户确认'])
代码行数 = run_shell(wc -l {临时文件路径}, history=['临时文件路径'])
return 代码行数
----------------------------------------
Wenli 的核心命名便揭示了它的灵魂:“文”代表语言的表达能力与灵活性,“理”代表严谨的架构逻辑与执行约束。
我们不希望 Wenli 变成一个漫无边际的 Prompt 集合,也不希望它像 C++ 那样充满内存管理的琐碎细节。
Wenli 在语法层面原生集成了现代 AI 开发的必备要素:
True)。CONTEXT 被自动注入,无需在函数间层层传递。目前我们已经完成了语法的解析与校验,接下来的开发计划将围绕如何让 Wenli “跑起来”且“好用”展开:
Wenli 不仅仅是在写程序,它是在为 AI 编织思考的纹理。 我们相信,未来的编程不再是人去适应机器,而是人与机器共同拥有一种“文理兼修”的语言。欢迎对此感兴趣的 Geek 们一起交流,共同见证 Wenli 的进化。欢迎大家一起讨论!
1
metalvest 2 天前
AI 代理( Agent )能稳定调用的前提是模型训练数据里必须有大量用这个语言编写的源码
|
2
uorz OP Wenli 并非设计给 AI agent 直接使用的,相反地,更像一种原生支持调用 LLM 的框架。就像 Claude code 或者 Gemini 的 plan mode,我们希望能显示地把云端强力模型制定的计划表示为 wenli 语言描述的运行规则,然后交由本地模型在 wenli 的运行时框架中执行这个计划。当然,这个计划也可以方便人类程序员进行编辑,或者大概表述运行逻辑后由云端大模型进行翻译为符合语言规范的 wenli 代码。为了方便本地小模型进行高效运行,我们还设计了一系列减少上下文 token 的机制。
|
3
uorz OP 传统编程语言太死了,必须要考虑到各种情况才能保证程序按既定规范运行下去,而现在的纯 LLM Agent 又太活了,在本地模型上跑一会儿就不知道飞到啥地方去了,我观察了一下主要是信息太多本地小模型过载了。wenli 希望能在二者之间找到一个平衡点。可以认为 wenli 的运行时也是一种 agent 框架,可以让代理能采用人类的知识同时保持一定的自主性。
|