你第一次听说“把提示词和工具调用直接写成编程语言语法”时是什么感觉是觉得这又是一个为了酷而酷的抽象概念还是隐约感到这背后可能藏着某种更本质的转变最近一个名为MALDA的项目进入了我的视野。它的核心主张非常直接让 LLM 的提示词Prompts和工具调用Tools成为编程语言的一等公民成为语法本身。这听起来有点抽象但如果你曾为构建一个可靠的 AI Agent 而头疼——反复调试提示词模板、处理工具调用的 JSON 格式、管理对话状态、拼接上下文——你就能立刻明白这个想法试图解决什么。它不是在现有框架上打补丁而是试图重新定义我们“编程”智能体的方式。过去我们写程序是“指令驱动”的我们告诉计算机每一步做什么。后来我们写提示词是“目标驱动”的我们告诉模型我们想要什么但具体步骤是黑箱。而 MALDA 似乎在探索第三条路一种“声明式协作”的编程范式。它把人类的高层意图通过提示词表达和机器的确定性能力通过工具调用编织进同一种语法结构里让两者能在一个统一的、可读的文本文件中协同工作。这不仅仅是语法糖。它触及了一个更深层的问题当 AI 成为生产流程的一部分时我们与它协作的界面应该是什么样子是继续在代码里拼接字符串还是应该有一种更优雅、更结构化、也更像“编程”的方式MALDA 提供了一个非常有趣的答案。接下来我将从几个层面拆解这个想法看看它到底改变了什么以及我们如何理解这种新的“编程”体验。1. 从“拼接字符串”到“编写语法”重新理解与 LLM 的协作界面在传统的 LLM 应用开发中尤其是在构建 Agent 时我们的工作流通常是割裂的。你可能会在 Python 代码中做这样的事# 1. 定义一个工具函数 def get_weather(city: str) - str: # 调用某个天气 API return fThe weather in {city} is sunny. # 2. 将工具“描述”给 LLM通常是一个 JSON Schema tools [ { type: function, function: { name: get_weather, description: Get the current weather for a city., parameters: {...} } } ] # 3. 编写一个系统提示词告诉 LLM 可以使用这些工具 system_prompt You are a helpful assistant. You can use tools to get information. When you need to use a tool, output a JSON object like: {tool: get_weather, input: {city: Beijing}}. # 4. 在代码中拼接对话历史、用户输入、工具描述和提示词 messages [ {role: system, content: system_prompt}, {role: user, content: Whats the weather in Shanghai?} ] # 5. 调用 LLM API解析其输出判断是自然语言回复还是工具调用再执行工具再把结果塞回上下文... response llm.chat(messages, toolstools) if response.tool_calls: # 解析并执行工具 tool_name response.tool_calls[0].function.name tool_args json.loads(response.tool_calls[0].function.arguments) result call_tool(tool_name, tool_args) # 把结果追加到 messages 中再次调用 LLM... messages.append({role: tool, content: result, tool_call_id: ...}) final_response llm.chat(messages)这个过程充满了“胶水代码”。工具的定义、描述、调用和结果的回传被分散在函数定义、JSON Schema、提示词字符串和流程控制代码中。提示词本身是游离在程序逻辑之外的字符串模板它的结构、占位符和工具调用指令与编程语言的语法检查、类型系统、模块化能力完全无关。MALDA 的核心思想就是消除这种割裂。它试图创造一种语言在这个语言里提示词不是字符串而是一种特殊的语句或块。它可以有结构可以引用变量可以被组合和复用。工具调用不是通过解析 JSON 来触发而是一种内置的操作符或函数调用语法。调用工具就像调用一个本地函数一样自然。整个 Agent 的工作流可以用一个.malda文件来描述。这个文件同时包含了“要做什么”提示词和“能做什么”工具以及它们之间的协作逻辑。想象一下如果上面的天气查询 Agent 可以用 MALDA 这样写请注意以下是基于其理念的示意非官方精确语法// 定义一个工具语法上它就是一个函数声明 tool get_weather(city: string) - string { // 这里可以是本地实现也可以是远程 API 调用封装 return api_call(weather.com, city); } // 定义一个“助手”它本质上是一个带有预设提示词和可用工具集的执行单元 assistant WeatherBot { // 系统提示词直接写在这里成为助手定义的一部分 system: You are a weather expert. Answer questions concisely. Use the get_weather tool when needed. ; // 声明这个助手可以使用的工具 tools: [get_weather]; // 定义一个对话流程或任务 task respond(query: string) - string { // 将用户查询和上下文“喂”给这个助手并自动处理工具调用循环 let response this.chat(query); return response; } } // 使用这个助手 let bot WeatherBot(); let answer bot.respond(Whats the weather in Shanghai and Beijing?); print(answer);在这个示意中最关键的转变是提示词和工具被“内化”到了语言运行时里。当你写this.chat(query)时语言运行时知道WeatherBot有一个系统提示词和一组工具它会自动帮你完成我们之前用大量胶水代码所做的所有事情组装消息、调用模型、解析输出、执行工具、循环直到完成。这带来的直接好处是可读性Agent 的逻辑集中在一个文件中意图更清晰。可维护性修改提示词或增删工具就像修改普通代码一样。可复用性助手和工具可以作为模块被导入和组合。开发体验理论上可以获得语法高亮、代码补全、静态检查如果语言支持等 IDE 支持。但它的价值远不止于此。它实际上是在定义一种新的DSL领域特定语言专门用于编排 LLM 与外部世界的交互。这个 DSL 的“领域”就是“人机协作任务”。2. 语法即契约MALDA 如何统一意图声明与能力调用MALDA 的雄心是让语法本身成为人、LLM 和工具之间的一份“可执行契约”。要理解这一点我们需要拆解几个关键概念。2.1 提示词作为“声明式语句”在普通编程中if、for、function是命令式语法告诉计算机确切的步骤。在 MALDA 中一段提示词可能更像一个声明式语句。它不描述“如何”一步步思考而是声明“在这个上下文中你应该扮演什么角色遵循什么原则拥有什么知识”。例如可能有一种语法来“声明”一个角色role Expert { identity: A senior software architect with 20 years of experience.; principle: Prioritize system reliability and maintainability over clever tricks.; knowledge_base: include(docs/architecture_guidelines.md); }这个role块本身不产生任何计算但它定义了一个“计算上下文”。当后面的chat或task语句引用这个role时它的所有声明都会被自动注入到给 LLM 的上下文中。这比在字符串里拼接“You are a...”要结构化得多。2.2 工具调用作为“一等公民”在大多数 LLM 框架中工具调用是“二等公民”。你需要先定义函数再生成它的描述再在提示词里用自然语言告诉模型“你可以用这个工具”最后在代码里解析模型的输出并调用对应的函数。在 MALDA 的愿景里工具调用应该是“一等公民”。这意味着定义即注册用tool关键字定义一个函数这个函数自动就对 MALDA 运行时和 LLM 可见无需额外的描述文件。类型安全工具的参数和返回值可以有类型如string,number,WeatherData这些类型信息可以同时用于本地代码的校验并生成更精确的提示给 LLM。调用透明化在 MALDA 脚本中调用一个工具可能看起来就是let result get_weather(“Shanghai”)。运行时知道get_weather是一个工具它可能会选择直接执行如果上下文明确不需要 LLM 判断。或者在chat上下文中将这个调用“代理”给 LLM 去决定是否使用以及如何传参。但这一切对开发者是透明的开发者写的是统一的函数调用语法。2.3. 控制流与 LLM 决策的融合这是最有趣也最挑战的部分。传统程序的控制流if-else, loop是确定性的。LLM 的“思维链”是不确定的。MALDA 这类语言需要设计语法来融合两者。一种可能的方式是引入“不确定性”操作符或关键字。例如let user_intent classify(query); // classify 可能是一个 LLM 调用的封装 match (user_intent) { Intent::QueryWeather { let city extract_entity(query); // 另一个 LLM 调用 let report get_weather(city); format_response(report); } Intent::SetReminder { // 处理设置提醒... } }在这里classify和extract_entity看起来像函数但它们的实现背后是 LLM 调用。MALDA 运行时需要管理这些调用的输入输出、错误处理和上下文传递。另一种更激进的方式是允许提示词片段参与控制流。比如一个reasoning块它的内容会作为 LLM 的“思考过程”被记录和利用但不直接输出给用户。2.4. 状态管理与会话上下文一个复杂的 Agent 往往是有状态的它记得之前的对话记得执行过的工具结果。在传统代码中我们需要精心设计数据结构来维护这个状态。在 MALDA 中状态管理可能成为语法的一部分。例如可能有一个内置的session或context对象自动维护对话历史。或者助手的定义中隐含着状态机的概念不同的task或state切换时上下文会被自动管理。这其中的核心契约是开发者用一种融合了自然语言提示词和编程语言工具、逻辑的语法来编写“智能程序”。MALDA 编译器或解释器负责将这份契约“编译”成底层 LLM API 调用、工具执行和状态管理的具体操作。语法成为了协作的界面和契约。3. 理想与现实的缝隙MALDA 落地面临的核心挑战将如此前沿的理念转化为可用的工具必然会遇到一系列工程和设计上的挑战。在兴奋之余我们必须冷静看待这些缝隙这决定了 MALDA 是止步于一个酷炫的实验还是能真正提升我们的开发效率。3.1. 抽象泄漏问题所有优秀的抽象都会在某个时刻发生“泄漏”。MALDA 试图隐藏 LLM 调用的复杂性但 LLM 的本质是不确定性和模糊性。当 MALDA 程序行为不符合预期时调试将变得异常困难。问题定位是提示词写的有问题是工具定义不清晰是 LLM 本身“抽风”了还是运行时状态管理出错了在传统的胶水代码中你可以在每一步打印日志。在高度抽象的 MALDA 中你需要一套同样强大的调试和观测工具。比如能够可视化每一步的提示词组装、LLM 的原始输入输出、工具调用的决策过程。错误处理LLM 可能拒绝调用工具可能以错误格式调用可能调用不存在的工具。这些错误如何在 MALDA 语法层面表达和处理是引入try...catch包围chat操作还是需要定义一套错误类型系统3.2. 性能与成本考量MALDA 的简洁语法背后可能隐藏着多次 LLM 调用。例如一个简单的match语句如果每个分支判断都依赖 LLM成本会急剧上升。隐式调用语法越简洁隐式的 LLM 调用可能越多。开发者需要清楚每一行“像代码”的语句背后是否以及何时会触发昂贵的 API 调用。这需要语言提供清晰的成本透明化机制比如在开发模式中报告每次调用和 Token 消耗。优化空间在传统代码中开发者可以精细控制缓存、合并请求、提前退出。在 MALDA 中这些优化能否通过编译器/解释器自动完成还是需要暴露一些高级配置给开发者这需要在“简洁”和“可控”之间找到平衡。3.3. 生态与工具链的匮乏一门新语言的生存离不开生态。包管理如何分享和复用写好的assistant或tool需要有类似npm或pip的包管理器。编辑器支持语法高亮、智能补全、跳转到定义、悬浮提示对于开发体验至关重要。这需要为 VS Code 等编辑器开发插件。测试框架如何测试一个 MALDA 程序传统的单元测试针对确定性函数。测试一个依赖 LLM 的 Agent 需要模拟 LLM 的响应或者使用基于评估的测试。需要专门的测试框架。部署与监控如何将一个.malda文件部署为服务如何监控它的运行状态、调用链和成本这需要配套的运维工具。3.4. 灵活性与表达能力的权衡MALDA 设计者需要决定语言的“边界”。它应该有多“通用”是一个完整的通用语言吗像 Python 一样能处理任何计算任务那会非常复杂。还是一个专注于编排的 DSL只处理与 LLM 交互、工具调用和状态管理相关的逻辑复杂的计算则委托给外部工具或函数。这更可能成功但意味着开发者经常需要在 MALDA 和宿主语言如 Python之间切换。过于复杂的语法会失去简洁性的优势过于简单又无法应对复杂场景。这个权衡极其困难。4. 从概念到实践我们该如何看待与尝试这类新范式尽管面临挑战但 MALDA 所代表的方向——用更高级、更集成的语言来编排 AI 能力——无疑是正确的。它不仅仅是另一个框架而是一次对开发者体验和思维模式的升级尝试。对于想要探索前沿的开发者以下是一些务实的建议。4.1. 定位它是什么不是什么首先我们需要对 MALDA 这类项目有一个合理的预期定位特性是什么可能不是什么核心价值提升开发效率与体验通过统一语法减少胶水代码让 Agent 逻辑更清晰、更易维护。不是让 LLM 变得更聪明或能力更强。底层模型的能力边界不变。适用场景快速原型、中等复杂度的自动化 Agent、标准化的人机协作流程。例如客服机器人初版、数据分析助手、信息查询管道。不适合对性能和成本有极端要求的超大规模生产系统初期也不适合需要极精细控制每一字节 Token 和每一次网络请求的场景。学习曲线需要同时理解LLM 工作原理和新语言的语法/范式。对于熟悉 Agent 开发的开发者上手可能很快。不是“无代码”工具它仍然是编程只是抽象层次更高。成熟度极早期阶段。是探索未来可能性的实验性项目。不是可以替代 LangChain、LlamaIndex 等成熟框架的现成解决方案。4.2. 上手路径从“观察者”到“建设者”如果你对 MALDA 感兴趣可以遵循以下路径逐步深入第一阶段阅读与理解找到项目在 GitHub 等平台搜索 “MALDA” 项目阅读它的 README、文档和示例代码。理解其核心语法设计。分析示例不要只看语法尝试在脑中“翻译”它的示例。思考每一行 MALDA 代码对应到传统的 Python/框架代码会是什么样子。这能帮你理解它抽象了什么又暴露了什么。思考设计取舍问自己为什么设计者要这样设计这个语法如果让我来设计我会怎么做这能极大地提升你对 LLM 应用开发本质的理解。第二阶段小范围实验搭建环境按照官方指南尝试在本地或沙箱环境中运行最简单的 “Hello World” 示例。复现教程动手完成官方教程中的一个完整小项目比如一个能调用搜索和计算器的问答助手。修改与调试尝试修改示例中的提示词、增加一个简单的工具观察行为变化。重点体验它的调试体验当出错时错误信息清晰吗有日志可查吗第三阶段解决一个真实的小问题选择一个微痛点从你自己的工作或学习中找一个可以用简单 Agent 解决的小任务。例如自动整理每日邮件摘要、根据技术文档回答简单问题、格式化数据。用 MALDA 实现尝试完全用 MALDA 来实现它。在这个过程中你会遇到真实的问题生态缺失某个工具没有现成封装、调试困难、性能不如预期等。对比评估用你熟悉的传统方式如 Python OpenAI SDK 自定义逻辑再实现一遍。对比两者的开发时间、代码行数、可读性、运行稳定性和心智负担。这个对比结果对你个人最有价值。第四阶段贡献与反馈如果你喜欢这个方向可以考虑为项目做贡献。贡献不一定是写核心代码可以包括报告 Bug、改进文档、编写更丰富的示例、为编辑器开发语法高亮插件。在社区中分享你的使用经验和对比评估。理性的反馈是早期项目最需要的养分。4.3. 长期视角关注范式而非具体工具无论 MALDA 这个特定项目最终成功与否它所代表的“语言化”或“声明式”编排 LLM 的范式都值得持续关注。类似的想法可能以不同的形式出现其他新语言、现有语言的扩展如 Python 装饰器宏、IDE 插件、或者低代码平台的后端。作为开发者我们应该培养的是对这种范式的理解能力识别核心抽象它如何表示“意图”、“工具”、“上下文”和“决策”评估抽象质量这个抽象是否减少了冗余代码是否带来了新的调试复杂度在灵活性和易用性之间取得了什么平衡预见演进方向下一步这类语言可能会在类型系统如何为 LLM 的不确定性设计类型、并发模型如何编排多个 Agent 协作、可视化能否将 MALDA 代码图形化表示等方面进行探索。MALDA 像是一份来自未来的设计草图它可能不完美但清晰地指出了当前 LLM 应用开发模式中的“摩擦点”并大胆地提出了一个整合方案。对于身处技术变革浪潮中的我们最重要的不是立刻找到一把“银弹”而是保持开放的心态去理解、尝试和批判这些新思想从中提取能真正优化我们工作流的精华。最终我们或许不会完全转向某一种新语言但我们在传统编程中编排 AI 的方式一定会因为这些探索而变得更好。