1. 先搞清楚 MALDA 到底是什么以及它想解决什么问题看到 MALDA 这个标题第一反应可能是又一个新的编程语言或者框架。但它的核心描述——“a language where LLM prompts and tools are syntax”——直接点明了它的定位它试图把与大语言模型LLM的交互Prompts和外部工具调用Tools变成语言本身的语法结构。这解决了一个非常实际的痛点。现在做 LLM 应用开发无论是构建一个智能助手还是一个自动化流程你通常需要写很多胶水代码。比如你需要写一个函数去构造发给 LLM 的提示词Prompt再写另一个函数去解析 LLM 的回复判断它是否要调用某个工具比如查天气、查数据库然后再写代码去执行这个工具最后可能还要把工具的结果再塞回给 LLM 生成最终回复。这个过程繁琐、容易出错而且代码结构分散可读性差。MALDA 的想法是能不能让这个过程更“原生”就像你在 Python 里写for item in list:一样自然在 MALDA 里你或许可以直接写ask llm “分析用户意图” with user_input或者call tool “get_weather” for city让这些操作成为语言的一等公民。这样一来整个 LLM 应用的逻辑就可以用更简洁、更声明式的方式写出来而不是被各种if-else、字符串拼接和 API 调用包装所淹没。所以MALDA 最适合的读者是那些已经在用 OpenAI API、Claude API 或者其他 LLM 服务构建应用的开发者尤其是感觉自己在重复编写大量 Prompt 工程和工具调用编排代码的人。它不是一个给 LLM 本身增加能力的工具而是一个旨在提升开发者效率、让 LLM 应用代码更清晰、更易维护的开发语言或领域特定语言DSL。2. 理解“Prompt 和 Tool 作为语法”意味着什么要理解 MALDA不能只看概念得拆开看它承诺的“语法”具体体现在哪里。我们可以从几个常见的 LLM 应用开发场景来对比。2.1 传统方式胶水代码模式假设我们要做一个简单的任务用户问“北京天气怎么样”系统需要调用天气查询工具然后组织回答。用传统的 Python 伪代码可能是这样的# 1. 构造Prompt def construct_prompt(user_input): prompt f 你是一个助手。请分析用户输入如果需要调用工具请严格按照以下JSON格式回复 {{action: call_tool, tool_name: 工具名, parameters: {{key: value}}}} 如果不需要工具直接回答。 用户输入{user_input} return prompt # 2. 调用LLM response openai_chat_completion(construct_prompt(“北京天气怎么样”)) # 3. 解析LLM回复 try: parsed json.loads(response) if parsed[“action”] “call_tool”: tool_name parsed[“tool_name”] params parsed[“parameters”] # 4. 路由到具体工具 if tool_name “get_weather”: weather_data call_weather_api(params[“city”]) # 5. 再次构造Prompt将工具结果给LLM follow_up_prompt f“工具返回的结果是{weather_data}请根据此结果生成对用户的友好回复。” final_response openai_chat_completion(follow_up_prompt) print(final_response) except json.JSONDecodeError: # 6. 处理LLM没有返回JSON的情况直接回答 print(response)这个过程里Prompt 是藏在字符串模板里的工具调用逻辑是藏在if-else和函数调用里的。代码的意图“先分析再调用工具最后合成回答”被实现细节淹没了。2.2 MALDA 的理想形态声明式语法如果 MALDA 实现了它的目标同样的逻辑可能会被写成这样这是基于其理念的假设性语法-- 定义一个工具 tool get_weather(city: String) - WeatherInfo { // 实现具体的API调用 return fetch_from_api(“weather.com”, city) } -- 主流程 process user_query(input: String) - String { -- 将用户输入交给LLM进行意图分析分析结果绑定到 intent 变量 intent : llm.analyze “分析用户意图: {{input}}” -- 根据意图条件性地执行工具调用。这本身是语言语法的一部分。 if intent.requires_tool and intent.tool_name “weather” { -- 调用工具语法上就像调用一个普通函数但语言知道这是外部工具 weather_data : use tool get_weather with city intent.parameters.city -- 再次使用LLM将工具结果格式化为回复。Prompt 是内联的语法元素。 final_response : llm.format “根据以下天气数据生成回复: {{weather_data}}” return final_response } else { -- 不需要工具直接让LLM回答 return llm.answer “直接回答用户: {{input}}” } }在这个假设的例子中你可以看到几个关键点llm.analyzellm.formatllm.answer这些可能成为 MALDA 的内置关键字或标准库函数用于发起 LLM 调用。后面的字符串不是普通的字符串而是具有特殊意义的Prompt 语法块。语言运行时可能会自动处理这些块的构造、变量替换{{input}}和发送。use tool ...这是一个工具调用语法。它明确声明了这里要执行一个外部操作。语言运行时负责找到对应的tool定义执行它并管理其生命周期如超时、错误处理。流程清晰代码的阅读顺序就是业务的执行顺序“分析 - 判断 - 调用工具 - 格式化结果”。没有中间胶水代码的跳转。这意味着什么意味着开发者可以更专注于业务逻辑“要做什么”而不是实现细节“怎么做”。语言层面提供了对 LLM 交互和工具调用的抽象减少了样板代码理论上也能带来更好的错误处理、日志记录和调试支持因为这些都可以集成在语言运行时里。3. 如何上手体验或评估类似 MALDA 的方案目前 MALDA 可能还是一个早期项目或研究构想。对于开发者来说更实际的不是等待 MALDA 成熟而是理解这个方向并评估现有的、能提供类似价值的工具或框架。我们可以把“Prompt和Tool作为语法”这个理念拆解成几个可评估的维度。3.1 评估维度一Prompt 作为一等公民一个好的、支持“Prompt 即代码”的方案应该具备模板化与变量注入能方便地将变量嵌入 Prompt避免字符串拼接。类型安全如果可能对注入变量进行类型检查。组合与复用能够将小的 Prompt 片段组合成复杂的 Prompt。版本管理Prompt 应该能和代码一起进行版本控制而不是散落在数据库或界面上。现有近似方案LangChain 的PromptTemplate提供了模板化和变量注入。专用 Prompt 管理工具如 PromptHub但可能增加复杂度。在代码中使用 Python 的 f-string 或string.Template是最基础的实现但缺乏结构和复用性。3.2 评估维度二Tool 调用作为核心抽象一个好的方案应该让工具调用变得声明式和可靠声明式定义能够清晰地定义工具的名称、输入参数类型、输出类型和描述。自动路由根据 LLM 的输出或预定义的规则自动将请求路由到正确的工具函数。错误处理与重试工具调用失败时有标准的重试或降级机制。执行上下文管理管理工具调用所需的认证、会话等信息。现有近似方案LangChain / LlamaIndex 的Tool抽象你可以用装饰器或类来定义一个工具并将其加入 Agent 的工具箱。Agent 负责调用。OpenAI 的Function Calling(现为Tools)在 API 层面定义了工具调用的格式LLM 可以输出结构化的工具调用请求。但后续的执行、错误处理仍需开发者编码。Semantic Kernel / AutoGen这些框架提供了更高级的 Agent 编排能力工具调用是其中的核心模块。3.3 评估维度三流畅的控制流这是 MALDA 理念中最吸引人的部分将 LLM 决策和工具调用自然地融入if,for,while等控制流中。条件执行根据 LLM 的分析结果决定是否、以及调用哪个工具。循环与迭代例如让 LLM 分析一个复杂任务拆分成多个子任务然后循环调用工具完成。状态管理在多次 LLM 调用和工具调用之间维护和传递对话状态或任务上下文。现有方案的挑战 现有的框架如 LangChain Agent虽然能实现复杂流程但其控制流往往隐藏在 Agent 的“推理-执行”循环内部或者通过SequentialChain等来编排代码的“命令式”感觉依然很强声明性不够。MALDA 设想的是更高级别的抽象。3.4 动手实验用现有技术栈模拟 MALDA 风格虽然还没有 MALDA但我们可以用 Python 和现有框架写一段风格上更接近“声明式”的代码体会一下其思路。这里以简单的链式调用为例# 假设我们有一些辅助类让代码看起来更“语法化” class MALDAFlow: def __init__(self, initial_input): self.context {“input”: initial_input} self.steps [] def analyze_with(self, prompt_template): # 模拟 llm.analyze 步骤 self.steps.append((“analyze”, prompt_template)) return self def call_tool_if(self, condition_func, tool_name, **tool_params): # 模拟条件性工具调用 self.steps.append((“call_tool_if”, condition_func, tool_name, tool_params)) return self def format_with(self, prompt_template): # 模拟 llm.format 步骤 self.steps.append((“format”, prompt_template)) return self def run(self, llm_client, tool_registry): # 简单的运行时按顺序执行步骤 for step in self.steps: if step[0] “analyze”: prompt step[1].format(**self.context) analysis llm_client(prompt) self.context[“analysis”] analysis # 这里可以解析 analysis更新 context elif step[0] “call_tool_if”: _, condition_func, tool_name, params step if condition_func(self.context): tool tool_registry[tool_name] result tool(**params) self.context[f“{tool_name}_result”] result elif step[0] “format”: prompt step[1].format(**self.context) final_response llm_client(prompt) self.context[“final_response”] final_response return self.context[“final_response”] # 使用示例风格上更声明式 flow (MALDAFlow(“北京天气怎么样”) .analyze_with(“分析用户‘{input}’的意图如果需要工具输出工具名和参数。”) .call_tool_if(lambda ctx: “weather” in ctx.get(“analysis”, “”), “get_weather”, city“北京”) # 这里的city可以更动态地从analysis解析 .format_with(“根据天气数据 {get_weather_result} 生成友好回复。”) ) # result flow.run(llm_client, tools) # 需要传入实际的llm客户端和工具字典这段代码虽然简陋但它展示了如何通过构建一个简单的 DSL 或流畅接口Fluent Interface让业务逻辑的编排看起来更清晰。真正的 MALDA 语言编译器或解释器做的就是将更优雅的语法转换成类似run方法里的那些执行逻辑。4. 在真实项目中应用此类理念的实践建议如果你被 MALDA 的理念吸引并想在当前的项目中引入更清晰、更可维护的 LLM 应用代码可以遵循以下路径而不是等待一个全新的语言。4.1 第一步建立清晰的 Prompt 管理规范不要将 Prompt 硬编码在业务逻辑字符串里。集中管理创建一个prompts/目录用.yaml、.json或.py文件来存储所有 Prompt 模板。# prompts/intent_analysis.yaml system: “你是一个意图分析助手。” user_template: “分析用户输入‘{{user_input}}’判断是否需要调用工具。若需要输出JSON格式{\”tool\”: \”工具名\”, \”params\”: {\”key\”: \”value\”}}。”使用模板引擎在代码中使用Jinja2或string.Template来渲染 Prompt确保变量替换的安全和灵活。from jinja2 import Template with open(‘prompts/intent_analysis.yaml’) as f: prompt_config yaml.safe_load(f) template Template(prompt_config[‘user_template’]) rendered_prompt template.render(user_input“北京天气”)版本化将这些 Prompt 文件纳入 Git 管理方便追踪变更和进行 A/B 测试。4.2 第二步标准化工具定义与注册为你的每一个外部能力API、数据库查询、计算函数创建清晰的定义。使用 Pydantic 定义输入输出这能提供类型提示和验证。from pydantic import BaseModel class GetWeatherInput(BaseModel): city: str unit: str “celsius” # 默认值 class GetWeatherOutput(BaseModel): temperature: float condition: str def get_weather(params: GetWeatherInput) - GetWeatherOutput: # ... 实际调用逻辑 return GetWeatherOutput(temperature22.5, condition“晴朗”)创建工具注册表用一个全局字典或类来管理所有可用工具。class ToolRegistry: def __init__(self): self._tools {} def register(self, name: str, func: Callable, input_model): self._tools[name] {“func”: func, “input_model”: input_model} def call(self, name: str, params: dict): tool_info self._tools[name] # 使用Pydantic验证输入 validated_input tool_info[“input_model”](**params) return tool_info[“func”](validated_input) registry ToolRegistry() registry.register(“get_weather”, get_weather, GetWeatherInput)4.3 第三步构建一个轻量级的“运行时”或编排器这是将前两步粘合起来模拟 MALDA “语法”执行环境的关键。设计一个简单的状态机或工作流引擎你的核心业务逻辑可以描述为一系列步骤。每个步骤可以是“调用LLM分析”、“根据结果判断”、“执行工具”、“合成最终回复”。使用状态上下文Context创建一个字典或对象在整个流程中传递输入、中间结果如 LLM 分析结果、工具调用结果和最终输出。实现错误处理与回退在编排器中统一处理 LLM 调用异常、工具调用失败、输出格式不符等情况。例如工具调用失败后可以尝试重试或者让 LLM 根据失败信息生成一个降级回复。一个极简的编排器核心循环可能像这样def orchestrate(user_input: str, registry: ToolRegistry, llm_client) - str: context {“user_input”: user_input} # 步骤1: 意图分析 analysis_prompt render_prompt(“intent_analysis”, context) llm_response llm_client(analysis_prompt) intent parse_intent(llm_response) # 解析出是否需要工具及参数 context[“intent”] intent # 步骤2: 条件性工具执行 if intent.requires_tool: try: tool_result registry.call(intent.tool_name, intent.tool_params) context[“tool_result”] tool_result except Exception as e: context[“tool_error”] str(e) # 可以在这里决定是重试、换工具还是直接让LLM道歉 # 步骤3: 生成最终回复 final_prompt render_prompt(“final_response”, context) final_answer llm_client(final_prompt) return final_answer4.4 第四步关注可观测性与调试当 Prompt 和工具调用被抽象后调试不能变得更难。你需要记录完整的执行轨迹记录每一次 LLM 调用的输入Prompt和输出每一次工具调用的输入和输出。这比打印日志更结构化。可视化工作流如果流程复杂考虑将你的“编排器”步骤可视化便于理解执行路径和定位问题。对中间结果进行断言在开发阶段可以对intent解析结果、tool_result等关键中间变量进行断言或验证确保流程按预期进行。5. 当前技术生态下的替代方案与边界MALDA 是一个前瞻性的理念在它成熟之前我们已经有一些强大的替代方案但它们各有侧重和边界。5.1 成熟框架方案LangChain / LangGraph优势生态最丰富提供了从 Prompt 模板、工具定义、多种 Agent 类型到复杂工作流LangGraph的全套解决方案。最接近“开箱即用”的 LLM 应用开发框架。边界学习曲线较陡抽象层次多有时为了完成简单任务需要理解复杂的概念。代码风格上它提供了声明式的组件Chains, Agents但组装它们的过程依然是命令式的 Python 代码。LlamaIndex优势在检索增强生成RAG领域非常强大对文档加载、索引、检索的抽象做得很好。其“查询引擎”可以看作是一种特殊的工具。边界核心优势在 RAG对于需要复杂多工具协作和自定义控制流的通用 Agent 场景可能不如 LangChain 全面。Semantic Kernel优势由微软推出与 .NET 生态结合紧密也支持 Python。提出了“插件”Plugins和“规划器”Planner的概念强调将传统代码能力Native Functions与语义能力LLM结合。边界相对于 LangChain社区规模和第三方集成稍小。其设计哲学需要一定时间适应。AutoGen优势专注于多智能体对话非常适合构建需要多个 LLM 智能体相互协作、辩论、评审的复杂场景。其“对话”本身就是核心抽象。边界对于简单的“用户-工具”单代理场景可能显得重量级。调试多智能体对话的复杂性较高。5.2 低代码/无代码平台一些平台如 Zapier、Make、n8n 的 AI 模块或新兴的windmill、langflow允许你通过图形化界面连接 LLM 和工具。这在一定程度上实现了“声明式”编排将逻辑可视化。优势快速原型无需编码适合业务人员或简单自动化。边界灵活性受限于平台提供的模块复杂逻辑难以实现版本控制和调试困难不适合集成到复杂软件系统中。5.3 自行构建轻量级 DSL对于有特定需求的团队基于 Python 或 JavaScript 构建一个内部使用的轻量级 DSL 是可行的正如我们在第 3.4 节演示的那样。优势完全定制与现有技术栈无缝集成可以做得非常符合团队习惯。边界开发维护成本高需要设计语法或流畅接口、运行时、调试工具容易造出一个不完善且缺乏生态的“轮子”。5.4 核心边界与挑战无论选择哪种方案都要清醒认识到当前的技术边界LLM 输出的不确定性LLM 可能不按你期望的格式输出导致解析失败。需要健壮的解析和重试机制。工具调用的可靠性外部 API 会失败、超时。编排器必须有错误处理和降级策略。成本与延迟每次 LLM 调用和工具调用都增加成本和延迟。复杂的多步流程需要仔细设计避免不必要的调用。状态管理复杂性在多轮对话或长任务中维护上下文状态是一个挑战。测试困难由于 LLM 的随机性和外部工具的不可控性为这类应用编写自动化测试比传统软件更困难。MALDA 所描绘的愿景正是试图在语言层面解决这些挑战的一部分尤其是提升开发效率和代码可读性。在它到来之前通过规范、框架和良好的架构设计我们完全可以在现有技术栈上写出清晰、可维护的 LLM 应用代码。关键是把 Prompt 和 Tool 当作你应用程序中的一等公民来对待为它们设计清晰的接口和生命周期而不是散落在代码各处临时拼凑。 MALDA：将LLM提示词与工具调用原生为编程语法的开发范式
1. 先搞清楚 MALDA 到底是什么以及它想解决什么问题看到 MALDA 这个标题第一反应可能是又一个新的编程语言或者框架。但它的核心描述——“a language where LLM prompts and tools are syntax”——直接点明了它的定位它试图把与大语言模型LLM的交互Prompts和外部工具调用Tools变成语言本身的语法结构。这解决了一个非常实际的痛点。现在做 LLM 应用开发无论是构建一个智能助手还是一个自动化流程你通常需要写很多胶水代码。比如你需要写一个函数去构造发给 LLM 的提示词Prompt再写另一个函数去解析 LLM 的回复判断它是否要调用某个工具比如查天气、查数据库然后再写代码去执行这个工具最后可能还要把工具的结果再塞回给 LLM 生成最终回复。这个过程繁琐、容易出错而且代码结构分散可读性差。MALDA 的想法是能不能让这个过程更“原生”就像你在 Python 里写for item in list:一样自然在 MALDA 里你或许可以直接写ask llm “分析用户意图” with user_input或者call tool “get_weather” for city让这些操作成为语言的一等公民。这样一来整个 LLM 应用的逻辑就可以用更简洁、更声明式的方式写出来而不是被各种if-else、字符串拼接和 API 调用包装所淹没。所以MALDA 最适合的读者是那些已经在用 OpenAI API、Claude API 或者其他 LLM 服务构建应用的开发者尤其是感觉自己在重复编写大量 Prompt 工程和工具调用编排代码的人。它不是一个给 LLM 本身增加能力的工具而是一个旨在提升开发者效率、让 LLM 应用代码更清晰、更易维护的开发语言或领域特定语言DSL。2. 理解“Prompt 和 Tool 作为语法”意味着什么要理解 MALDA不能只看概念得拆开看它承诺的“语法”具体体现在哪里。我们可以从几个常见的 LLM 应用开发场景来对比。2.1 传统方式胶水代码模式假设我们要做一个简单的任务用户问“北京天气怎么样”系统需要调用天气查询工具然后组织回答。用传统的 Python 伪代码可能是这样的# 1. 构造Prompt def construct_prompt(user_input): prompt f 你是一个助手。请分析用户输入如果需要调用工具请严格按照以下JSON格式回复 {{action: call_tool, tool_name: 工具名, parameters: {{key: value}}}} 如果不需要工具直接回答。 用户输入{user_input} return prompt # 2. 调用LLM response openai_chat_completion(construct_prompt(“北京天气怎么样”)) # 3. 解析LLM回复 try: parsed json.loads(response) if parsed[“action”] “call_tool”: tool_name parsed[“tool_name”] params parsed[“parameters”] # 4. 路由到具体工具 if tool_name “get_weather”: weather_data call_weather_api(params[“city”]) # 5. 再次构造Prompt将工具结果给LLM follow_up_prompt f“工具返回的结果是{weather_data}请根据此结果生成对用户的友好回复。” final_response openai_chat_completion(follow_up_prompt) print(final_response) except json.JSONDecodeError: # 6. 处理LLM没有返回JSON的情况直接回答 print(response)这个过程里Prompt 是藏在字符串模板里的工具调用逻辑是藏在if-else和函数调用里的。代码的意图“先分析再调用工具最后合成回答”被实现细节淹没了。2.2 MALDA 的理想形态声明式语法如果 MALDA 实现了它的目标同样的逻辑可能会被写成这样这是基于其理念的假设性语法-- 定义一个工具 tool get_weather(city: String) - WeatherInfo { // 实现具体的API调用 return fetch_from_api(“weather.com”, city) } -- 主流程 process user_query(input: String) - String { -- 将用户输入交给LLM进行意图分析分析结果绑定到 intent 变量 intent : llm.analyze “分析用户意图: {{input}}” -- 根据意图条件性地执行工具调用。这本身是语言语法的一部分。 if intent.requires_tool and intent.tool_name “weather” { -- 调用工具语法上就像调用一个普通函数但语言知道这是外部工具 weather_data : use tool get_weather with city intent.parameters.city -- 再次使用LLM将工具结果格式化为回复。Prompt 是内联的语法元素。 final_response : llm.format “根据以下天气数据生成回复: {{weather_data}}” return final_response } else { -- 不需要工具直接让LLM回答 return llm.answer “直接回答用户: {{input}}” } }在这个假设的例子中你可以看到几个关键点llm.analyzellm.formatllm.answer这些可能成为 MALDA 的内置关键字或标准库函数用于发起 LLM 调用。后面的字符串不是普通的字符串而是具有特殊意义的Prompt 语法块。语言运行时可能会自动处理这些块的构造、变量替换{{input}}和发送。use tool ...这是一个工具调用语法。它明确声明了这里要执行一个外部操作。语言运行时负责找到对应的tool定义执行它并管理其生命周期如超时、错误处理。流程清晰代码的阅读顺序就是业务的执行顺序“分析 - 判断 - 调用工具 - 格式化结果”。没有中间胶水代码的跳转。这意味着什么意味着开发者可以更专注于业务逻辑“要做什么”而不是实现细节“怎么做”。语言层面提供了对 LLM 交互和工具调用的抽象减少了样板代码理论上也能带来更好的错误处理、日志记录和调试支持因为这些都可以集成在语言运行时里。3. 如何上手体验或评估类似 MALDA 的方案目前 MALDA 可能还是一个早期项目或研究构想。对于开发者来说更实际的不是等待 MALDA 成熟而是理解这个方向并评估现有的、能提供类似价值的工具或框架。我们可以把“Prompt和Tool作为语法”这个理念拆解成几个可评估的维度。3.1 评估维度一Prompt 作为一等公民一个好的、支持“Prompt 即代码”的方案应该具备模板化与变量注入能方便地将变量嵌入 Prompt避免字符串拼接。类型安全如果可能对注入变量进行类型检查。组合与复用能够将小的 Prompt 片段组合成复杂的 Prompt。版本管理Prompt 应该能和代码一起进行版本控制而不是散落在数据库或界面上。现有近似方案LangChain 的PromptTemplate提供了模板化和变量注入。专用 Prompt 管理工具如 PromptHub但可能增加复杂度。在代码中使用 Python 的 f-string 或string.Template是最基础的实现但缺乏结构和复用性。3.2 评估维度二Tool 调用作为核心抽象一个好的方案应该让工具调用变得声明式和可靠声明式定义能够清晰地定义工具的名称、输入参数类型、输出类型和描述。自动路由根据 LLM 的输出或预定义的规则自动将请求路由到正确的工具函数。错误处理与重试工具调用失败时有标准的重试或降级机制。执行上下文管理管理工具调用所需的认证、会话等信息。现有近似方案LangChain / LlamaIndex 的Tool抽象你可以用装饰器或类来定义一个工具并将其加入 Agent 的工具箱。Agent 负责调用。OpenAI 的Function Calling(现为Tools)在 API 层面定义了工具调用的格式LLM 可以输出结构化的工具调用请求。但后续的执行、错误处理仍需开发者编码。Semantic Kernel / AutoGen这些框架提供了更高级的 Agent 编排能力工具调用是其中的核心模块。3.3 评估维度三流畅的控制流这是 MALDA 理念中最吸引人的部分将 LLM 决策和工具调用自然地融入if,for,while等控制流中。条件执行根据 LLM 的分析结果决定是否、以及调用哪个工具。循环与迭代例如让 LLM 分析一个复杂任务拆分成多个子任务然后循环调用工具完成。状态管理在多次 LLM 调用和工具调用之间维护和传递对话状态或任务上下文。现有方案的挑战 现有的框架如 LangChain Agent虽然能实现复杂流程但其控制流往往隐藏在 Agent 的“推理-执行”循环内部或者通过SequentialChain等来编排代码的“命令式”感觉依然很强声明性不够。MALDA 设想的是更高级别的抽象。3.4 动手实验用现有技术栈模拟 MALDA 风格虽然还没有 MALDA但我们可以用 Python 和现有框架写一段风格上更接近“声明式”的代码体会一下其思路。这里以简单的链式调用为例# 假设我们有一些辅助类让代码看起来更“语法化” class MALDAFlow: def __init__(self, initial_input): self.context {“input”: initial_input} self.steps [] def analyze_with(self, prompt_template): # 模拟 llm.analyze 步骤 self.steps.append((“analyze”, prompt_template)) return self def call_tool_if(self, condition_func, tool_name, **tool_params): # 模拟条件性工具调用 self.steps.append((“call_tool_if”, condition_func, tool_name, tool_params)) return self def format_with(self, prompt_template): # 模拟 llm.format 步骤 self.steps.append((“format”, prompt_template)) return self def run(self, llm_client, tool_registry): # 简单的运行时按顺序执行步骤 for step in self.steps: if step[0] “analyze”: prompt step[1].format(**self.context) analysis llm_client(prompt) self.context[“analysis”] analysis # 这里可以解析 analysis更新 context elif step[0] “call_tool_if”: _, condition_func, tool_name, params step if condition_func(self.context): tool tool_registry[tool_name] result tool(**params) self.context[f“{tool_name}_result”] result elif step[0] “format”: prompt step[1].format(**self.context) final_response llm_client(prompt) self.context[“final_response”] final_response return self.context[“final_response”] # 使用示例风格上更声明式 flow (MALDAFlow(“北京天气怎么样”) .analyze_with(“分析用户‘{input}’的意图如果需要工具输出工具名和参数。”) .call_tool_if(lambda ctx: “weather” in ctx.get(“analysis”, “”), “get_weather”, city“北京”) # 这里的city可以更动态地从analysis解析 .format_with(“根据天气数据 {get_weather_result} 生成友好回复。”) ) # result flow.run(llm_client, tools) # 需要传入实际的llm客户端和工具字典这段代码虽然简陋但它展示了如何通过构建一个简单的 DSL 或流畅接口Fluent Interface让业务逻辑的编排看起来更清晰。真正的 MALDA 语言编译器或解释器做的就是将更优雅的语法转换成类似run方法里的那些执行逻辑。4. 在真实项目中应用此类理念的实践建议如果你被 MALDA 的理念吸引并想在当前的项目中引入更清晰、更可维护的 LLM 应用代码可以遵循以下路径而不是等待一个全新的语言。4.1 第一步建立清晰的 Prompt 管理规范不要将 Prompt 硬编码在业务逻辑字符串里。集中管理创建一个prompts/目录用.yaml、.json或.py文件来存储所有 Prompt 模板。# prompts/intent_analysis.yaml system: “你是一个意图分析助手。” user_template: “分析用户输入‘{{user_input}}’判断是否需要调用工具。若需要输出JSON格式{\”tool\”: \”工具名\”, \”params\”: {\”key\”: \”value\”}}。”使用模板引擎在代码中使用Jinja2或string.Template来渲染 Prompt确保变量替换的安全和灵活。from jinja2 import Template with open(‘prompts/intent_analysis.yaml’) as f: prompt_config yaml.safe_load(f) template Template(prompt_config[‘user_template’]) rendered_prompt template.render(user_input“北京天气”)版本化将这些 Prompt 文件纳入 Git 管理方便追踪变更和进行 A/B 测试。4.2 第二步标准化工具定义与注册为你的每一个外部能力API、数据库查询、计算函数创建清晰的定义。使用 Pydantic 定义输入输出这能提供类型提示和验证。from pydantic import BaseModel class GetWeatherInput(BaseModel): city: str unit: str “celsius” # 默认值 class GetWeatherOutput(BaseModel): temperature: float condition: str def get_weather(params: GetWeatherInput) - GetWeatherOutput: # ... 实际调用逻辑 return GetWeatherOutput(temperature22.5, condition“晴朗”)创建工具注册表用一个全局字典或类来管理所有可用工具。class ToolRegistry: def __init__(self): self._tools {} def register(self, name: str, func: Callable, input_model): self._tools[name] {“func”: func, “input_model”: input_model} def call(self, name: str, params: dict): tool_info self._tools[name] # 使用Pydantic验证输入 validated_input tool_info[“input_model”](**params) return tool_info[“func”](validated_input) registry ToolRegistry() registry.register(“get_weather”, get_weather, GetWeatherInput)4.3 第三步构建一个轻量级的“运行时”或编排器这是将前两步粘合起来模拟 MALDA “语法”执行环境的关键。设计一个简单的状态机或工作流引擎你的核心业务逻辑可以描述为一系列步骤。每个步骤可以是“调用LLM分析”、“根据结果判断”、“执行工具”、“合成最终回复”。使用状态上下文Context创建一个字典或对象在整个流程中传递输入、中间结果如 LLM 分析结果、工具调用结果和最终输出。实现错误处理与回退在编排器中统一处理 LLM 调用异常、工具调用失败、输出格式不符等情况。例如工具调用失败后可以尝试重试或者让 LLM 根据失败信息生成一个降级回复。一个极简的编排器核心循环可能像这样def orchestrate(user_input: str, registry: ToolRegistry, llm_client) - str: context {“user_input”: user_input} # 步骤1: 意图分析 analysis_prompt render_prompt(“intent_analysis”, context) llm_response llm_client(analysis_prompt) intent parse_intent(llm_response) # 解析出是否需要工具及参数 context[“intent”] intent # 步骤2: 条件性工具执行 if intent.requires_tool: try: tool_result registry.call(intent.tool_name, intent.tool_params) context[“tool_result”] tool_result except Exception as e: context[“tool_error”] str(e) # 可以在这里决定是重试、换工具还是直接让LLM道歉 # 步骤3: 生成最终回复 final_prompt render_prompt(“final_response”, context) final_answer llm_client(final_prompt) return final_answer4.4 第四步关注可观测性与调试当 Prompt 和工具调用被抽象后调试不能变得更难。你需要记录完整的执行轨迹记录每一次 LLM 调用的输入Prompt和输出每一次工具调用的输入和输出。这比打印日志更结构化。可视化工作流如果流程复杂考虑将你的“编排器”步骤可视化便于理解执行路径和定位问题。对中间结果进行断言在开发阶段可以对intent解析结果、tool_result等关键中间变量进行断言或验证确保流程按预期进行。5. 当前技术生态下的替代方案与边界MALDA 是一个前瞻性的理念在它成熟之前我们已经有一些强大的替代方案但它们各有侧重和边界。5.1 成熟框架方案LangChain / LangGraph优势生态最丰富提供了从 Prompt 模板、工具定义、多种 Agent 类型到复杂工作流LangGraph的全套解决方案。最接近“开箱即用”的 LLM 应用开发框架。边界学习曲线较陡抽象层次多有时为了完成简单任务需要理解复杂的概念。代码风格上它提供了声明式的组件Chains, Agents但组装它们的过程依然是命令式的 Python 代码。LlamaIndex优势在检索增强生成RAG领域非常强大对文档加载、索引、检索的抽象做得很好。其“查询引擎”可以看作是一种特殊的工具。边界核心优势在 RAG对于需要复杂多工具协作和自定义控制流的通用 Agent 场景可能不如 LangChain 全面。Semantic Kernel优势由微软推出与 .NET 生态结合紧密也支持 Python。提出了“插件”Plugins和“规划器”Planner的概念强调将传统代码能力Native Functions与语义能力LLM结合。边界相对于 LangChain社区规模和第三方集成稍小。其设计哲学需要一定时间适应。AutoGen优势专注于多智能体对话非常适合构建需要多个 LLM 智能体相互协作、辩论、评审的复杂场景。其“对话”本身就是核心抽象。边界对于简单的“用户-工具”单代理场景可能显得重量级。调试多智能体对话的复杂性较高。5.2 低代码/无代码平台一些平台如 Zapier、Make、n8n 的 AI 模块或新兴的windmill、langflow允许你通过图形化界面连接 LLM 和工具。这在一定程度上实现了“声明式”编排将逻辑可视化。优势快速原型无需编码适合业务人员或简单自动化。边界灵活性受限于平台提供的模块复杂逻辑难以实现版本控制和调试困难不适合集成到复杂软件系统中。5.3 自行构建轻量级 DSL对于有特定需求的团队基于 Python 或 JavaScript 构建一个内部使用的轻量级 DSL 是可行的正如我们在第 3.4 节演示的那样。优势完全定制与现有技术栈无缝集成可以做得非常符合团队习惯。边界开发维护成本高需要设计语法或流畅接口、运行时、调试工具容易造出一个不完善且缺乏生态的“轮子”。5.4 核心边界与挑战无论选择哪种方案都要清醒认识到当前的技术边界LLM 输出的不确定性LLM 可能不按你期望的格式输出导致解析失败。需要健壮的解析和重试机制。工具调用的可靠性外部 API 会失败、超时。编排器必须有错误处理和降级策略。成本与延迟每次 LLM 调用和工具调用都增加成本和延迟。复杂的多步流程需要仔细设计避免不必要的调用。状态管理复杂性在多轮对话或长任务中维护上下文状态是一个挑战。测试困难由于 LLM 的随机性和外部工具的不可控性为这类应用编写自动化测试比传统软件更困难。MALDA 所描绘的愿景正是试图在语言层面解决这些挑战的一部分尤其是提升开发效率和代码可读性。在它到来之前通过规范、框架和良好的架构设计我们完全可以在现有技术栈上写出清晰、可维护的 LLM 应用代码。关键是把 Prompt 和 Tool 当作你应用程序中的一等公民来对待为它们设计清晰的接口和生命周期而不是散落在代码各处临时拼凑。