MALDA：用编程语言语法统一提示词与工具调用，重塑AI Agent开发范式

你第一次听说“把提示词和工具调用直接写成编程语言语法”时，是什么感觉？是觉得这又是一个为了酷而酷的抽象概念，还是隐约感到这背后可能藏着某种更本质的转变？

最近，一个名为MALDA的项目进入了我的视野。它的核心主张非常直接：让 LLM 的提示词（Prompts）和工具调用（Tools）成为编程语言的一等公民，成为语法本身。这听起来有点抽象，但如果你曾为构建一个可靠的 AI Agent 而头疼——反复调试提示词模板、处理工具调用的 JSON 格式、管理对话状态、拼接上下文——你就能立刻明白这个想法试图解决什么。它不是在现有框架上打补丁，而是试图重新定义我们“编程”智能体的方式。

过去，我们写程序是“指令驱动”的：我们告诉计算机每一步做什么。后来，我们写提示词是“目标驱动”的：我们告诉模型我们想要什么，但具体步骤是黑箱。而 MALDA 似乎在探索第三条路：一种“声明式协作”的编程范式。它把人类的高层意图（通过提示词表达）和机器的确定性能力（通过工具调用）编织进同一种语法结构里，让两者能在一个统一的、可读的文本文件中协同工作。

这不仅仅是语法糖。它触及了一个更深层的问题：当 AI 成为生产流程的一部分时，我们与它协作的界面应该是什么样子？是继续在代码里拼接字符串，还是应该有一种更优雅、更结构化、也更像“编程”的方式？MALDA 提供了一个非常有趣的答案。接下来，我将从几个层面拆解这个想法，看看它到底改变了什么，以及我们如何理解这种新的“编程”体验。

1. 从“拼接字符串”到“编写语法”：重新理解与 LLM 的协作界面

在传统的 LLM 应用开发中，尤其是在构建 Agent 时，我们的工作流通常是割裂的。你可能会在 Python 代码中做这样的事：

# 1. 定义一个工具（函数） def get_weather(city: str) -> str: # 调用某个天气 API return f"The 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": "What's the weather in Shanghai?"} ] # 5. 调用 LLM API，解析其输出，判断是自然语言回复还是工具调用，再执行工具，再把结果塞回上下文... response = llm.chat(messages, tools=tools) 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("What's 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 的愿景里，工具调用应该是“一等公民”。这意味着：

1. 定义即注册：用tool关键字定义一个函数，这个函数自动就对 MALDA 运行时和 LLM 可见，无需额外的描述文件。
2. 类型安全：工具的参数和返回值可以有类型（如string,number,WeatherData），这些类型信息可以同时用于本地代码的校验，并生成更精确的提示给 LLM。
3. 调用透明化：在 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 这类项目有一个合理的预期定位：

4.2. 上手路径：从“观察者”到“建设者”

如果你对 MALDA 感兴趣，可以遵循以下路径逐步深入：

1. 第一阶段：阅读与理解

   • 找到项目：在 GitHub 等平台搜索 “MALDA” 项目，阅读它的 README、文档和示例代码。理解其核心语法设计。
   • 分析示例：不要只看语法，尝试在脑中“翻译”它的示例。思考每一行 MALDA 代码对应到传统的 Python/框架代码会是什么样子。这能帮你理解它抽象了什么，又暴露了什么。
   • 思考设计取舍：问自己：为什么设计者要这样设计这个语法？如果让我来设计，我会怎么做？这能极大地提升你对 LLM 应用开发本质的理解。

2. 第二阶段：小范围实验

   • 搭建环境：按照官方指南，尝试在本地或沙箱环境中运行最简单的 “Hello World” 示例。
   • 复现教程：动手完成官方教程中的一个完整小项目，比如一个能调用搜索和计算器的问答助手。
   • 修改与调试：尝试修改示例中的提示词、增加一个简单的工具，观察行为变化。重点体验它的调试体验：当出错时，错误信息清晰吗？有日志可查吗？

3. 第三阶段：解决一个真实的小问题

   • 选择一个微痛点：从你自己的工作或学习中，找一个可以用简单 Agent 解决的小任务。例如：自动整理每日邮件摘要、根据技术文档回答简单问题、格式化数据。
   • 用 MALDA 实现：尝试完全用 MALDA 来实现它。在这个过程中，你会遇到真实的问题：生态缺失（某个工具没有现成封装）、调试困难、性能不如预期等。
   • 对比评估：用你熟悉的传统方式（如 Python + OpenAI SDK + 自定义逻辑）再实现一遍。对比两者的开发时间、代码行数、可读性、运行稳定性和心智负担。这个对比结果对你个人最有价值。

4. 第四阶段：贡献与反馈

   • 如果你喜欢这个方向，可以考虑为项目做贡献。贡献不一定是写核心代码，可以包括：报告 Bug、改进文档、编写更丰富的示例、为编辑器开发语法高亮插件。
   • 在社区中分享你的使用经验和对比评估。理性的反馈是早期项目最需要的养分。

4.3. 长期视角：关注范式，而非具体工具

无论 MALDA 这个特定项目最终成功与否，它所代表的“语言化”或“声明式”编排 LLM 的范式都值得持续关注。类似的想法可能以不同的形式出现：其他新语言、现有语言的扩展（如 Python 装饰器宏）、IDE 插件、或者低代码平台的后端。

作为开发者，我们应该培养的是对这种范式的理解能力：

• 识别核心抽象：它如何表示“意图”、“工具”、“上下文”和“决策”？
• 评估抽象质量：这个抽象是否减少了冗余代码？是否带来了新的调试复杂度？在灵活性和易用性之间取得了什么平衡？
• 预见演进方向：下一步，这类语言可能会在类型系统（如何为 LLM 的不确定性设计类型？）、并发模型（如何编排多个 Agent 协作？）、可视化（能否将 MALDA 代码图形化表示？）等方面进行探索。

MALDA 像是一份来自未来的设计草图，它可能不完美，但清晰地指出了当前 LLM 应用开发模式中的“摩擦点”，并大胆地提出了一个整合方案。对于身处技术变革浪潮中的我们，最重要的不是立刻找到一把“银弹”，而是保持开放的心态，去理解、尝试和批判这些新思想，从中提取能真正优化我们工作流的精华。最终，我们或许不会完全转向某一种新语言，但我们在传统编程中编排 AI 的方式，一定会因为这些探索而变得更好。