1. 从“自由发挥”到“按需输出”为什么我们需要结构化输出在构建基于大语言模型的应用时我们常常面临一个核心矛盾模型的创造力与应用的确定性需求之间的冲突。想象一下你开发了一个智能客服助手用户问“帮我查一下明天的天气和航班信息”。一个未经约束的模型可能会天马行空地回复“明天是个阳光明媚的好日子适合出行。至于航班我建议您选择上午的班次避开高峰……” 这种回答虽然通顺但对于一个需要精确执行查询操作的系统来说毫无用处。我们需要的是类似{action: query_weather, parameters: {date: 2023-10-27, location: 北京}}这样结构清晰、机器可读的指令。这就是“结构化输出”要解决的根本问题。它不是一个可有可无的“锦上添花”而是连接人类自然语言指令与后端确定性业务逻辑的“关键桥梁”。在 LangChain 的生态中ToolStrategy和ProviderStrategy正是实现这一桥梁的两大核心设计模式。前者决定了模型如何“思考”和“选择”工具后者决定了模型如何“格式化”和“输出”结果。理解它们意味着你掌握了让 LLM 从“聊天伙伴”转变为“可靠执行者”的钥匙。2. 策略基石深入理解 ToolStrategy 的设计哲学ToolStrategy的核心使命是指导语言模型如何从一堆可用的工具Tools中选出当前最合适的一个或多个来执行任务。这听起来简单但背后涉及模型对工具功能的理解、对用户意图的解析以及复杂的决策逻辑。2.1 常见的 ToolStrategy 实现与选型逻辑LangChain 提供了几种内置的策略每种都对应着不同的应用场景和复杂度。2.1.1DefaultToolStrategy简单直接的“单步调用”这是最基础、最常用的策略。它的工作模式是模型根据当前对话历史和用户查询直接决定调用哪一个工具并生成该工具所需的输入参数。工作原理策略内部通常会将所有可用工具的名称和描述description拼接到给模型的系统提示System Prompt中模型基于这些信息做选择。例如提示词可能是“你可以使用以下工具1.search_web: 用于搜索网络信息。2.calculator: 用于执行数学计算。请根据用户问题决定使用哪个工具。”适用场景任务简单、明确一次对话回合通常只涉及一个工具调用。例如问答机器人、简单的数据查询。实操心得工具描述是关键description字段必须清晰、准确最好包含典型用例和输入格式示例。模糊的描述会导致模型误选。警惕工具过载当工具数量超过10-15个时模型的决策准确率会显著下降。此时需要考虑对工具进行分层或使用更复杂的策略。2.1.2MultiToolStrategy处理复杂、多步骤的“工作流”当用户的一个请求需要按顺序调用多个工具才能完成时就需要MultiToolStrategy。例如“查一下北京明天的天气然后根据天气推荐一个室内或室外的活动最后把这个活动计划总结成邮件草稿”。这需要依次调用weather_tool、recommendation_tool和email_draft_tool。工作原理该策略会引导模型进行“规划-执行”循环。模型先规划一个步骤序列Plan然后逐步执行每一步的执行结果会成为下一步的上下文。高级实现可能会让模型在遇到意外结果时重新规划。实现要点状态管理必须妥善管理每个工具调用的输入、输出和中间状态。LangChain 的AgentExecutor是管理此循环的常用组件。错误处理与重规划某个工具调用失败如返回错误或意外结果时策略应能引导模型调整后续步骤。这需要在提示词中明确设计。踩坑记录最大的坑在于“幻觉规划”。模型可能会规划出一个逻辑上合理、但某个工具根本不支持的步骤。例如规划让calculator工具去“查询股票价格”。必须在规划阶段就加入工具能力校验或者在提示词中强调“仅使用所提供工具”。2.1.3DynamicToolStrategy运行时决定工具的“弹性架构”在某些高级场景下可用的工具集不是固定的而是在运行时根据上下文动态生成或筛选的。例如一个企业级助手不同部门的员工登录后能看到和使用的工具集是不同的。工作原理在每次模型决策前策略会根据当前会话的上下文如用户身份、对话历史、系统状态动态地计算并提供一个工具子集然后模型在这个子集中进行选择。技术实现通常需要与一个外部的“工具注册中心”或权限服务集成。在调用链的run方法开始时先根据上下文查询可用工具列表再注入到提示词中。核心价值实现了权限隔离和功能定制化提升了系统安全性和用户体验的针对性。注意选择哪种ToolStrategy本质上是在“决策灵活性”、“系统复杂度”和“可靠性”之间做权衡。对于绝大多数应用从DefaultToolStrategy开始是完全正确的。只有当业务逻辑天然是多步骤的才考虑MultiToolStrategy。DynamicToolStrategy则适用于大型、多租户的复杂系统。2.2 自定义 ToolStrategy当内置策略无法满足时LangChain 内置的策略覆盖了常见场景但真实业务往往千奇百怪。你可能需要自定义策略。例如你需要一个“投票策略”让模型同时生成2-3个可能的工具选择然后通过一个轻量级校验模型或规则引擎来投票决定最终使用哪个以提高准确性。自定义策略通常需要继承基类并重写核心方法from langchain.tools import BaseTool from typing import List, Optional, Any from langchain.schema import AgentAction class CustomVotingToolStrategy(BaseToolStrategy): 一个自定义的投票策略示例。 def select_tool( self, tools: List[BaseTool], query: str, history: Optional[List[dict]] None, **kwargs: Any ) - Optional[AgentAction]: # 1. 准备上下文和提示词让模型生成N个候选工具及理由 prompt self._build_candidate_prompt(tools, query, history) candidate_choices self.llm.invoke(prompt) # 2. 解析出多个候选 (tool_name, input, confidence) parsed_candidates self._parse_candidates(candidate_choices) # 3. 使用简单的规则进行投票例如选择置信度最高的或出现次数最多的 final_choice self._vote(parsed_candidates) # 4. 返回 LangChain 标准格式的 AgentAction if final_choice: return AgentAction( toolfinal_choice[tool_name], tool_inputfinal_choice[input], logf使用投票策略最终选择 {final_choice[tool_name]}置信度 {final_choice[confidence]} ) return None # ... 实现 _build_candidate_prompt, _parse_candidates, _vote 等方法自定义策略的核心考量性能每次调用都进行多轮生成和投票会显著增加延迟和成本。需要评估是否值得。与执行器的集成确保你的策略返回的AgentAction对象能被下游的AgentExecutor正确处理。错误处理在投票、解析等任何环节失败时必须有降级方案如退回默认策略。3. 输出契约ProviderStrategy 如何确保格式万无一失如果说ToolStrategy解决了“用什么”的问题那么ProviderStrategy就解决了“怎么输出”的问题。它的目标是强制模型按照预定义的结构如 JSON Schema、Pydantic Model来生成内容确保输出能被程序稳定解析。3.1 基于函数调用Function Calling的强约束这是目前最主流、最可靠的实现方式尤其被 OpenAI、Anthropic 等主流 API 原生支持。工作原理你不直接让模型“生成一段 JSON”而是为每个工具或任务定义一个“函数”Function包含函数名、描述和严格的参数模式JSON Schema。你将这个函数定义列表传给模型模型以“函数调用请求”的形式响应。这个请求本身就是一个结构化的 JSON 对象包含了要调用的函数名和参数。在 LangChain 中的体现当你使用bind_tools()方法将 Pydantic 模型或工具列表绑定到 LLM 实例时底层就是在利用 Function Calling 能力。ProviderStrategy在这里的工作是适配不同模型供应商Provider对 Function Calling 的细微差异。绝对优势近乎100%的格式合规率由于是模型供应商在架构层面支持输出的结构错误率极低。开发体验好直接使用 Pydantic 模型来定义结构类型提示和验证一气呵成。一个关键细节不同供应商的“函数调用”格式可能有细微差别。OpenAI 用的是tool_callsAnthropic Claude 用的是tools或tool_use。一个好的ProviderStrategy如 LangChain 内置的集成会自动处理这些差异为上层提供统一的接口。3.2 基于输出解析器Output Parsers的后处理方案当你的模型供应商不支持原生 Function Calling例如使用一些开源模型自托管时这是备选方案。工作原理你仍然要求模型生成文本但在提示词中极其详细地描述输出格式例如“请严格按照以下 JSON 格式输出{city: 字符串, temperature: 整数}”。然后使用一个OutputParser如JsonOutputParser、PydanticOutputParser来解析模型的文本回复并尝试将其转换为目标结构。LangChain 的PydanticOutputParser实战from langchain.output_parsers import PydanticOutputParser from langchain_core.pydantic_v1 import BaseModel, Field from langchain_openai import ChatOpenAI class WeatherInfo(BaseModel): city: str Field(description城市名) temperature: int Field(description温度单位摄氏度) condition: str Field(description天气状况如晴、多云、雨) parser PydanticOutputParser(pydantic_objectWeatherInfo) # 构造提示词自动将格式说明插入 prompt ChatPromptTemplate.from_messages([ (system, 你是一个天气助手。{format_instructions}), (human, 查询{query}的天气) ]).partial(format_instructionsparser.get_format_instructions()) chain prompt | ChatOpenAI(modelgpt-3.5-turbo) | parser result chain.invoke({query: 北京}) # result 将是一个 WeatherInfo 实例或抛出解析错误严重缺陷与应对格式漂移Format Drifting模型可能会忽略部分格式指令输出里多一个逗号、少一个引号、添加无关解释文本导致解析失败。这是此方案最大的痛点。应对策略提示词工程在系统提示中反复、强硬地强调格式要求并使用“json ...”代码块包裹等技巧。使用更聪明的解析器如JsonOutputWithRetriesParser它会在解析失败时尝试自动修复 JSON如补全引号、括号或者甚至将错误信息和原始输出重新发给模型请求修正。后置校验与清洗在解析后使用 Pydantic 模型自带的校验对字段类型、范围进行检查对于关键应用不接受的字段要坚决过滤。3.3 混合策略与降级方案在实际生产环境中我们往往采用混合策略以平衡可靠性、成本和灵活性。3.3.1 主备模式策略优先使用支持 Function Calling 的强大但昂贵的模型如 GPT-4。如果因为速率限制或成本问题失败则降级到使用 Output Parser 的廉价模型如 GPT-3.5-Turbo 或开源模型。实现可以设计一个FallbackProviderStrategy它内部封装了两个策略实例。在主策略调用失败或超时时自动切换至备选策略并可能对提示词进行适配例如为主策略准备函数定义为备选策略准备详细的格式文本。3.3.2 校验与修复链路即使使用 Function Calling模型生成的参数值也可能不符合业务逻辑例如temperature字段返回了字符串 “很热”。因此一个健壮的ProviderStrategy应该包含一个“结构化输出校验层”。语法校验由 JSON Schema 或 Pydantic 完成确保类型、必填字段等正确。语义校验自定义业务规则校验。例如日期不能是过去时城市名必须在支持列表中。自动修复当校验失败时不是直接向用户报错而是将错误信息如“字段‘温度’需要整数但收到了‘很热’”和原始查询重新构造一个修正请求发送给模型让它重新生成。这个过程可以循环1-2次。4. 实战架构将 ToolStrategy 与 ProviderStrategy 编织成可靠应用理解了这两个独立的概念后最关键的一步是将它们组合起来形成一个完整的、可维护的智能体Agent架构。下面是一个基于 LangChain 最新表达式语言LCEL的推荐架构。4.1 核心组件与数据流用户输入 | v [ Agent 入口 (Runnable) ] | v [ ToolStrategy ] - 选择工具生成 AgentAction | v [ AgentExecutor ] - 执行工具获取 Observation | v [ 循环判断 ] - 是否继续 - 是返回 [ToolStrategy] | v (否结束) [ ProviderStrategy ] - 将最终结果格式化为 Final Answer | v 结构化输出代码示例一个自定义的、结合了两大策略的智能体链from langchain.agents import AgentExecutor, create_react_agent from langchain_core.agents import AgentFinish from langchain_core.tools import BaseTool from langchain_core.prompts import ChatPromptTemplate from langchain_openai import ChatOpenAI from typing import List, Union from my_custom_strategies import MyCustomToolStrategy, MyStructuredProviderStrategy class StructuredOutputAgent: def __init__( self, tools: List[BaseTool], llm: ChatOpenAI, tool_strategy: MyCustomToolStrategy, provider_strategy: MyStructuredProviderStrategy, max_iterations: int 5 ): self.tools tools self.llm llm self.tool_strategy tool_strategy self.provider_strategy provider_strategy self.max_iterations max_iterations # 1. 定义核心提示词 self.prompt ChatPromptTemplate.from_messages([ (system, 你是专业助手。请使用工具解决问题。), (human, {input}), (placeholder, {agent_scratchpad}) # 用于记录思考过程 ]) # 2. 创建基础的 ReAct 智能体LangChain 内置 self.base_agent create_react_agent(llm, tools, self.prompt) def run(self, user_input: str) - dict: # 返回结构化结果 # 初始化状态 intermediate_steps [] iterations 0 while iterations self.max_iterations: iterations 1 # **步骤A: 使用 ToolStrategy 决定下一步行动** # 这里简化了实际中 ToolStrategy 的逻辑可能内嵌在 base_agent 的决策中 # 我们假设经过 custom strategy 处理后得到 action agent_action self.tool_strategy.select_tool( toolsself.tools, queryuser_input, historyintermediate_steps ) if isinstance(agent_action, AgentFinish): # 如果策略直接决定结束则进入最终输出阶段 final_answer agent_action.return_values[output] break # **步骤B: 执行工具** tool_to_use next(t for t in self.tools if t.name agent_action.tool) observation tool_to_use.invoke(agent_action.tool_input) intermediate_steps.append((agent_action, observation)) # 判断是否应该结束例如工具返回了明确结果 # 这里可以加入自定义逻辑比如检查 observation 是否包含最终答案 if self._should_finish(observation): final_answer observation break else: # 循环超过最大次数 final_answer {error: 超过最大思考次数未能解决问题。} # **步骤C: 使用 ProviderStrategy 格式化最终答案** structured_output self.provider_strategy.format_output( raw_answerfinal_answer, original_queryuser_input, contextintermediate_steps ) return structured_output def _should_finish(self, observation: Any) - bool: # 自定义逻辑根据工具执行结果判断是否结束循环 # 例如如果工具返回了完整的数据则结束 return isinstance(observation, dict) and final_data in observation4.2 性能优化与监控要点在真实生产环境部署时除了功能正确还需关注以下方面策略选择的延迟开销复杂的ToolStrategy如多轮投票会显著增加每个推理步骤的延迟。需要在关键路径上监控strategy_selection_latency指标。如果延迟过高考虑缓存策略决策结果对于相同或相似查询。工具描述的优化这是影响ToolStrategy准确性的最重要因素。定期进行 A/B 测试用不同的描述语对比工具选择的准确率。描述应遵循“动作对象约束”的格式例如“calculate_distance计算两个地理坐标点之间的直线距离。输入应为包含lat1, lon1, lat2, lon2四个数字的 JSON 对象。”结构化输出的验证看门狗Watchdog即使使用了 Function Calling也要设立一个最后防线。在ProviderStrategy的输出层之后添加一个独立的验证服务。这个服务用更严格的 JSON Schema 或业务规则校验输出对于校验失败且自动修复也无效的请求触发人工审核或降级到安全回复如“我暂时无法处理这个请求”。可观测性Observability在日志中完整记录每个回合的决策链路输入 - ToolStrategy 的中间决策信息如候选列表、置信度- 选择的工具及输入 - 工具输出 - ProviderStrategy 的格式化结果。这为排查错误、优化策略提供了黄金数据。5. 避坑指南从理论到实践的血泪教训结合我个人和团队在多个项目中实施结构化输出的经验以下是一些教科书里不会写的“坑”。5.1 工具冲突与模糊性当两个工具的描述非常相似时例如search_product和query_inventory模型极易混淆。解决方案除了优化描述可以引入“工具排除”机制。在ToolStrategy中如果模型连续两次在相似工具间摇摆并导致错误可以临时禁用其中一个工具强制引导流程。5.2 结构化输出中的“额外话”问题即使使用 Function Calling有些模型特别是经过微调的仍可能在 JSON 前后添加解释性文字如“好的这是你要的数据”。解决方案在调用模型 API 时仔细检查其参数。例如OpenAI 的response_format设置为{ type: json_object }能极大抑制这种行为。同时在解析前写一个简单的文本预处理函数用正则表达式提取第一个出现的完整 JSON 对象。5.3 长上下文下的策略失效当对话历史非常长时模型可能会“忘记”或忽略系统提示中关于工具和格式的指令。解决方案实现“关键指令重复”机制。每隔一定轮数如5轮或当检测到模型开始自由发挥时在用户消息前以系统消息的身份重新插入精简版的工具列表和输出格式要求。这类似于给模型一个“记忆刷新”。5.4 成本与延迟的权衡复杂的策略和多次重试会直接增加 Token 消耗和请求延迟。解决方案建立成本监控。为不同的用户请求类型或优先级配置不同的策略组合。例如对 VIP 用户或复杂任务使用高成本、高准确率的策略GPT-4 复杂投票对普通查询使用低成本策略GPT-3.5 简单解析。通过特征路由实现差异化服务。最终ToolStrategy和ProviderStrategy不是两个孤立的配置项而是塑造智能体行为与可靠性的左右手。它们的精妙配合决定了你的 AI 应用是停留在“玩具”阶段还是能真正融入生产流程稳定地创造价值。理解其原理谨慎地选型与设计并在实践中持续迭代优化是每一个 LangChain 开发者构建鲁棒应用的必修课。 LangChain结构化输出：ToolStrategy与ProviderStrategy实战指南
1. 从“自由发挥”到“按需输出”为什么我们需要结构化输出在构建基于大语言模型的应用时我们常常面临一个核心矛盾模型的创造力与应用的确定性需求之间的冲突。想象一下你开发了一个智能客服助手用户问“帮我查一下明天的天气和航班信息”。一个未经约束的模型可能会天马行空地回复“明天是个阳光明媚的好日子适合出行。至于航班我建议您选择上午的班次避开高峰……” 这种回答虽然通顺但对于一个需要精确执行查询操作的系统来说毫无用处。我们需要的是类似{action: query_weather, parameters: {date: 2023-10-27, location: 北京}}这样结构清晰、机器可读的指令。这就是“结构化输出”要解决的根本问题。它不是一个可有可无的“锦上添花”而是连接人类自然语言指令与后端确定性业务逻辑的“关键桥梁”。在 LangChain 的生态中ToolStrategy和ProviderStrategy正是实现这一桥梁的两大核心设计模式。前者决定了模型如何“思考”和“选择”工具后者决定了模型如何“格式化”和“输出”结果。理解它们意味着你掌握了让 LLM 从“聊天伙伴”转变为“可靠执行者”的钥匙。2. 策略基石深入理解 ToolStrategy 的设计哲学ToolStrategy的核心使命是指导语言模型如何从一堆可用的工具Tools中选出当前最合适的一个或多个来执行任务。这听起来简单但背后涉及模型对工具功能的理解、对用户意图的解析以及复杂的决策逻辑。2.1 常见的 ToolStrategy 实现与选型逻辑LangChain 提供了几种内置的策略每种都对应着不同的应用场景和复杂度。2.1.1DefaultToolStrategy简单直接的“单步调用”这是最基础、最常用的策略。它的工作模式是模型根据当前对话历史和用户查询直接决定调用哪一个工具并生成该工具所需的输入参数。工作原理策略内部通常会将所有可用工具的名称和描述description拼接到给模型的系统提示System Prompt中模型基于这些信息做选择。例如提示词可能是“你可以使用以下工具1.search_web: 用于搜索网络信息。2.calculator: 用于执行数学计算。请根据用户问题决定使用哪个工具。”适用场景任务简单、明确一次对话回合通常只涉及一个工具调用。例如问答机器人、简单的数据查询。实操心得工具描述是关键description字段必须清晰、准确最好包含典型用例和输入格式示例。模糊的描述会导致模型误选。警惕工具过载当工具数量超过10-15个时模型的决策准确率会显著下降。此时需要考虑对工具进行分层或使用更复杂的策略。2.1.2MultiToolStrategy处理复杂、多步骤的“工作流”当用户的一个请求需要按顺序调用多个工具才能完成时就需要MultiToolStrategy。例如“查一下北京明天的天气然后根据天气推荐一个室内或室外的活动最后把这个活动计划总结成邮件草稿”。这需要依次调用weather_tool、recommendation_tool和email_draft_tool。工作原理该策略会引导模型进行“规划-执行”循环。模型先规划一个步骤序列Plan然后逐步执行每一步的执行结果会成为下一步的上下文。高级实现可能会让模型在遇到意外结果时重新规划。实现要点状态管理必须妥善管理每个工具调用的输入、输出和中间状态。LangChain 的AgentExecutor是管理此循环的常用组件。错误处理与重规划某个工具调用失败如返回错误或意外结果时策略应能引导模型调整后续步骤。这需要在提示词中明确设计。踩坑记录最大的坑在于“幻觉规划”。模型可能会规划出一个逻辑上合理、但某个工具根本不支持的步骤。例如规划让calculator工具去“查询股票价格”。必须在规划阶段就加入工具能力校验或者在提示词中强调“仅使用所提供工具”。2.1.3DynamicToolStrategy运行时决定工具的“弹性架构”在某些高级场景下可用的工具集不是固定的而是在运行时根据上下文动态生成或筛选的。例如一个企业级助手不同部门的员工登录后能看到和使用的工具集是不同的。工作原理在每次模型决策前策略会根据当前会话的上下文如用户身份、对话历史、系统状态动态地计算并提供一个工具子集然后模型在这个子集中进行选择。技术实现通常需要与一个外部的“工具注册中心”或权限服务集成。在调用链的run方法开始时先根据上下文查询可用工具列表再注入到提示词中。核心价值实现了权限隔离和功能定制化提升了系统安全性和用户体验的针对性。注意选择哪种ToolStrategy本质上是在“决策灵活性”、“系统复杂度”和“可靠性”之间做权衡。对于绝大多数应用从DefaultToolStrategy开始是完全正确的。只有当业务逻辑天然是多步骤的才考虑MultiToolStrategy。DynamicToolStrategy则适用于大型、多租户的复杂系统。2.2 自定义 ToolStrategy当内置策略无法满足时LangChain 内置的策略覆盖了常见场景但真实业务往往千奇百怪。你可能需要自定义策略。例如你需要一个“投票策略”让模型同时生成2-3个可能的工具选择然后通过一个轻量级校验模型或规则引擎来投票决定最终使用哪个以提高准确性。自定义策略通常需要继承基类并重写核心方法from langchain.tools import BaseTool from typing import List, Optional, Any from langchain.schema import AgentAction class CustomVotingToolStrategy(BaseToolStrategy): 一个自定义的投票策略示例。 def select_tool( self, tools: List[BaseTool], query: str, history: Optional[List[dict]] None, **kwargs: Any ) - Optional[AgentAction]: # 1. 准备上下文和提示词让模型生成N个候选工具及理由 prompt self._build_candidate_prompt(tools, query, history) candidate_choices self.llm.invoke(prompt) # 2. 解析出多个候选 (tool_name, input, confidence) parsed_candidates self._parse_candidates(candidate_choices) # 3. 使用简单的规则进行投票例如选择置信度最高的或出现次数最多的 final_choice self._vote(parsed_candidates) # 4. 返回 LangChain 标准格式的 AgentAction if final_choice: return AgentAction( toolfinal_choice[tool_name], tool_inputfinal_choice[input], logf使用投票策略最终选择 {final_choice[tool_name]}置信度 {final_choice[confidence]} ) return None # ... 实现 _build_candidate_prompt, _parse_candidates, _vote 等方法自定义策略的核心考量性能每次调用都进行多轮生成和投票会显著增加延迟和成本。需要评估是否值得。与执行器的集成确保你的策略返回的AgentAction对象能被下游的AgentExecutor正确处理。错误处理在投票、解析等任何环节失败时必须有降级方案如退回默认策略。3. 输出契约ProviderStrategy 如何确保格式万无一失如果说ToolStrategy解决了“用什么”的问题那么ProviderStrategy就解决了“怎么输出”的问题。它的目标是强制模型按照预定义的结构如 JSON Schema、Pydantic Model来生成内容确保输出能被程序稳定解析。3.1 基于函数调用Function Calling的强约束这是目前最主流、最可靠的实现方式尤其被 OpenAI、Anthropic 等主流 API 原生支持。工作原理你不直接让模型“生成一段 JSON”而是为每个工具或任务定义一个“函数”Function包含函数名、描述和严格的参数模式JSON Schema。你将这个函数定义列表传给模型模型以“函数调用请求”的形式响应。这个请求本身就是一个结构化的 JSON 对象包含了要调用的函数名和参数。在 LangChain 中的体现当你使用bind_tools()方法将 Pydantic 模型或工具列表绑定到 LLM 实例时底层就是在利用 Function Calling 能力。ProviderStrategy在这里的工作是适配不同模型供应商Provider对 Function Calling 的细微差异。绝对优势近乎100%的格式合规率由于是模型供应商在架构层面支持输出的结构错误率极低。开发体验好直接使用 Pydantic 模型来定义结构类型提示和验证一气呵成。一个关键细节不同供应商的“函数调用”格式可能有细微差别。OpenAI 用的是tool_callsAnthropic Claude 用的是tools或tool_use。一个好的ProviderStrategy如 LangChain 内置的集成会自动处理这些差异为上层提供统一的接口。3.2 基于输出解析器Output Parsers的后处理方案当你的模型供应商不支持原生 Function Calling例如使用一些开源模型自托管时这是备选方案。工作原理你仍然要求模型生成文本但在提示词中极其详细地描述输出格式例如“请严格按照以下 JSON 格式输出{city: 字符串, temperature: 整数}”。然后使用一个OutputParser如JsonOutputParser、PydanticOutputParser来解析模型的文本回复并尝试将其转换为目标结构。LangChain 的PydanticOutputParser实战from langchain.output_parsers import PydanticOutputParser from langchain_core.pydantic_v1 import BaseModel, Field from langchain_openai import ChatOpenAI class WeatherInfo(BaseModel): city: str Field(description城市名) temperature: int Field(description温度单位摄氏度) condition: str Field(description天气状况如晴、多云、雨) parser PydanticOutputParser(pydantic_objectWeatherInfo) # 构造提示词自动将格式说明插入 prompt ChatPromptTemplate.from_messages([ (system, 你是一个天气助手。{format_instructions}), (human, 查询{query}的天气) ]).partial(format_instructionsparser.get_format_instructions()) chain prompt | ChatOpenAI(modelgpt-3.5-turbo) | parser result chain.invoke({query: 北京}) # result 将是一个 WeatherInfo 实例或抛出解析错误严重缺陷与应对格式漂移Format Drifting模型可能会忽略部分格式指令输出里多一个逗号、少一个引号、添加无关解释文本导致解析失败。这是此方案最大的痛点。应对策略提示词工程在系统提示中反复、强硬地强调格式要求并使用“json ...”代码块包裹等技巧。使用更聪明的解析器如JsonOutputWithRetriesParser它会在解析失败时尝试自动修复 JSON如补全引号、括号或者甚至将错误信息和原始输出重新发给模型请求修正。后置校验与清洗在解析后使用 Pydantic 模型自带的校验对字段类型、范围进行检查对于关键应用不接受的字段要坚决过滤。3.3 混合策略与降级方案在实际生产环境中我们往往采用混合策略以平衡可靠性、成本和灵活性。3.3.1 主备模式策略优先使用支持 Function Calling 的强大但昂贵的模型如 GPT-4。如果因为速率限制或成本问题失败则降级到使用 Output Parser 的廉价模型如 GPT-3.5-Turbo 或开源模型。实现可以设计一个FallbackProviderStrategy它内部封装了两个策略实例。在主策略调用失败或超时时自动切换至备选策略并可能对提示词进行适配例如为主策略准备函数定义为备选策略准备详细的格式文本。3.3.2 校验与修复链路即使使用 Function Calling模型生成的参数值也可能不符合业务逻辑例如temperature字段返回了字符串 “很热”。因此一个健壮的ProviderStrategy应该包含一个“结构化输出校验层”。语法校验由 JSON Schema 或 Pydantic 完成确保类型、必填字段等正确。语义校验自定义业务规则校验。例如日期不能是过去时城市名必须在支持列表中。自动修复当校验失败时不是直接向用户报错而是将错误信息如“字段‘温度’需要整数但收到了‘很热’”和原始查询重新构造一个修正请求发送给模型让它重新生成。这个过程可以循环1-2次。4. 实战架构将 ToolStrategy 与 ProviderStrategy 编织成可靠应用理解了这两个独立的概念后最关键的一步是将它们组合起来形成一个完整的、可维护的智能体Agent架构。下面是一个基于 LangChain 最新表达式语言LCEL的推荐架构。4.1 核心组件与数据流用户输入 | v [ Agent 入口 (Runnable) ] | v [ ToolStrategy ] - 选择工具生成 AgentAction | v [ AgentExecutor ] - 执行工具获取 Observation | v [ 循环判断 ] - 是否继续 - 是返回 [ToolStrategy] | v (否结束) [ ProviderStrategy ] - 将最终结果格式化为 Final Answer | v 结构化输出代码示例一个自定义的、结合了两大策略的智能体链from langchain.agents import AgentExecutor, create_react_agent from langchain_core.agents import AgentFinish from langchain_core.tools import BaseTool from langchain_core.prompts import ChatPromptTemplate from langchain_openai import ChatOpenAI from typing import List, Union from my_custom_strategies import MyCustomToolStrategy, MyStructuredProviderStrategy class StructuredOutputAgent: def __init__( self, tools: List[BaseTool], llm: ChatOpenAI, tool_strategy: MyCustomToolStrategy, provider_strategy: MyStructuredProviderStrategy, max_iterations: int 5 ): self.tools tools self.llm llm self.tool_strategy tool_strategy self.provider_strategy provider_strategy self.max_iterations max_iterations # 1. 定义核心提示词 self.prompt ChatPromptTemplate.from_messages([ (system, 你是专业助手。请使用工具解决问题。), (human, {input}), (placeholder, {agent_scratchpad}) # 用于记录思考过程 ]) # 2. 创建基础的 ReAct 智能体LangChain 内置 self.base_agent create_react_agent(llm, tools, self.prompt) def run(self, user_input: str) - dict: # 返回结构化结果 # 初始化状态 intermediate_steps [] iterations 0 while iterations self.max_iterations: iterations 1 # **步骤A: 使用 ToolStrategy 决定下一步行动** # 这里简化了实际中 ToolStrategy 的逻辑可能内嵌在 base_agent 的决策中 # 我们假设经过 custom strategy 处理后得到 action agent_action self.tool_strategy.select_tool( toolsself.tools, queryuser_input, historyintermediate_steps ) if isinstance(agent_action, AgentFinish): # 如果策略直接决定结束则进入最终输出阶段 final_answer agent_action.return_values[output] break # **步骤B: 执行工具** tool_to_use next(t for t in self.tools if t.name agent_action.tool) observation tool_to_use.invoke(agent_action.tool_input) intermediate_steps.append((agent_action, observation)) # 判断是否应该结束例如工具返回了明确结果 # 这里可以加入自定义逻辑比如检查 observation 是否包含最终答案 if self._should_finish(observation): final_answer observation break else: # 循环超过最大次数 final_answer {error: 超过最大思考次数未能解决问题。} # **步骤C: 使用 ProviderStrategy 格式化最终答案** structured_output self.provider_strategy.format_output( raw_answerfinal_answer, original_queryuser_input, contextintermediate_steps ) return structured_output def _should_finish(self, observation: Any) - bool: # 自定义逻辑根据工具执行结果判断是否结束循环 # 例如如果工具返回了完整的数据则结束 return isinstance(observation, dict) and final_data in observation4.2 性能优化与监控要点在真实生产环境部署时除了功能正确还需关注以下方面策略选择的延迟开销复杂的ToolStrategy如多轮投票会显著增加每个推理步骤的延迟。需要在关键路径上监控strategy_selection_latency指标。如果延迟过高考虑缓存策略决策结果对于相同或相似查询。工具描述的优化这是影响ToolStrategy准确性的最重要因素。定期进行 A/B 测试用不同的描述语对比工具选择的准确率。描述应遵循“动作对象约束”的格式例如“calculate_distance计算两个地理坐标点之间的直线距离。输入应为包含lat1, lon1, lat2, lon2四个数字的 JSON 对象。”结构化输出的验证看门狗Watchdog即使使用了 Function Calling也要设立一个最后防线。在ProviderStrategy的输出层之后添加一个独立的验证服务。这个服务用更严格的 JSON Schema 或业务规则校验输出对于校验失败且自动修复也无效的请求触发人工审核或降级到安全回复如“我暂时无法处理这个请求”。可观测性Observability在日志中完整记录每个回合的决策链路输入 - ToolStrategy 的中间决策信息如候选列表、置信度- 选择的工具及输入 - 工具输出 - ProviderStrategy 的格式化结果。这为排查错误、优化策略提供了黄金数据。5. 避坑指南从理论到实践的血泪教训结合我个人和团队在多个项目中实施结构化输出的经验以下是一些教科书里不会写的“坑”。5.1 工具冲突与模糊性当两个工具的描述非常相似时例如search_product和query_inventory模型极易混淆。解决方案除了优化描述可以引入“工具排除”机制。在ToolStrategy中如果模型连续两次在相似工具间摇摆并导致错误可以临时禁用其中一个工具强制引导流程。5.2 结构化输出中的“额外话”问题即使使用 Function Calling有些模型特别是经过微调的仍可能在 JSON 前后添加解释性文字如“好的这是你要的数据”。解决方案在调用模型 API 时仔细检查其参数。例如OpenAI 的response_format设置为{ type: json_object }能极大抑制这种行为。同时在解析前写一个简单的文本预处理函数用正则表达式提取第一个出现的完整 JSON 对象。5.3 长上下文下的策略失效当对话历史非常长时模型可能会“忘记”或忽略系统提示中关于工具和格式的指令。解决方案实现“关键指令重复”机制。每隔一定轮数如5轮或当检测到模型开始自由发挥时在用户消息前以系统消息的身份重新插入精简版的工具列表和输出格式要求。这类似于给模型一个“记忆刷新”。5.4 成本与延迟的权衡复杂的策略和多次重试会直接增加 Token 消耗和请求延迟。解决方案建立成本监控。为不同的用户请求类型或优先级配置不同的策略组合。例如对 VIP 用户或复杂任务使用高成本、高准确率的策略GPT-4 复杂投票对普通查询使用低成本策略GPT-3.5 简单解析。通过特征路由实现差异化服务。最终ToolStrategy和ProviderStrategy不是两个孤立的配置项而是塑造智能体行为与可靠性的左右手。它们的精妙配合决定了你的 AI 应用是停留在“玩具”阶段还是能真正融入生产流程稳定地创造价值。理解其原理谨慎地选型与设计并在实践中持续迭代优化是每一个 LangChain 开发者构建鲁棒应用的必修课。