1. 项目概述从“全能模型”到“专业分工”的范式转变最近在折腾各种AI应用和智能体Agent时我越来越清晰地感受到一个趋势模型本身正在变得越来越“懒”或者说越来越“聪明地懒”。这里的“懒”不是贬义词而是指模型的核心职责正在发生一次深刻的范式转移。过去我们总希望一个大模型能包揽一切——理解、推理、规划、执行甚至直接调用外部API。但现实是这种“全能选手”的构想不仅让模型变得臃肿、响应慢更在复杂、长链条的任务中频频出错可靠性堪忧。现在一个更清晰、更高效的分工模式正在成为共识也就是标题所说的模型只负责判断Runtime才真正执行。这听起来像是一句简单的技术口号但它背后蕴含的是整个AI应用架构设计理念的革新。简单来说模型尤其是大语言模型LLM的角色从“执行者”退回到了“决策者”或“指挥官”。它的核心任务不再是亲自去写一行代码、发一个HTTP请求而是理解用户意图拆解任务步骤并在关键时刻做出“该调用哪个工具”、“参数应该是什么”的判断。而真正去执行这些具体操作——无论是调用一个计算器、查询数据库、发送邮件还是控制一个机器人手臂——则交给一个专门、稳定、可控的“运行时Runtime”环境。这个模式就是工具使用Tool Use的核心。它不是什么全新的概念但在开源模型能力突飞猛进比如单日处理万亿级Token的模型出现、Agent框架遍地开花的今天其重要性被提到了前所未有的高度。为什么因为当我们不再仅仅满足于让模型“聊聊天”而是希望它真正能替我们完成工作流时执行环节的稳定性、安全性和效率就成了生命线。一个只会“纸上谈兵”的模型是没用的它必须能可靠地驱动现实世界中的工具。而这个驱动引擎就是Runtime。2. 核心思路拆解为什么“判断”与“执行”必须分离要理解这个分工的必要性我们需要从模型的特性和实际应用的需求两个层面来看。2.1 大语言模型的本质与局限首先我们必须认清大语言模型的本质它是一个基于概率的、生成文本的“超级模仿者”。它通过学习海量文本数据中的模式和关联学会了以惊人的流畅度进行对话、分析和推理。然而这种能力存在几个根本性的局限非确定性模型的输出是概率性的同一输入可能产生不同的输出。这对于创意写作是优点但对于要求精确、可重复的操作指令如发送一封特定收件人、特定内容的邮件则是灾难。幻觉与事实性错误模型会“自信地”编造不存在的信息或给出错误的代码、命令。让它直接生成并执行系统命令无异于将系统安全交给一个偶尔会胡言乱语的天才。缺乏实时性与状态感知模型的训练数据是静态的它不知道当前时间、不知道你的邮箱里刚收到的新邮件、不知道某个API服务是否暂时宕机。它无法感知动态变化的外部世界状态。无实际操作能力模型只是一段代码运行在计算设备上。它本身没有“手”去点击按钮没有“嘴”去发出网络请求。所有的外部交互都必须通过编程接口API来实现。如果让模型既做判断决定发邮件又负责执行拼接SMTP请求并发送就相当于让一位战略指挥官同时去前线扣动扳机。指挥官可能会因为“幻觉”把坐标报错也可能因为不熟悉枪械构造而卡壳。结果就是任务失败甚至造成“友军误伤”系统错误、数据泄露。2.2 Runtime的核心价值可靠性、安全性与效率将执行权交给Runtime正是为了弥补模型的上述缺陷。一个设计良好的Runtime环境扮演着以下几个关键角色可靠的执行器Runtime是确定性的代码。你告诉它调用send_email(to, subject, body)只要参数正确、网络通畅它就会严格按照定义好的逻辑去执行不会自己“发挥”。这保证了操作结果的可靠性和可预测性。安全的沙箱Runtime可以对模型发来的指令进行校验和过滤。例如它可以禁止模型执行rm -rf /这样的危险命令或者对数据库查询进行权限检查和SQL注入防护。它是模型与真实世界之间的“安全阀”和“防火墙”。状态的管家Runtime可以维护任务执行过程中的状态。比如它知道上一步从数据库查询的结果是什么并可以将这个结果作为下一步工具调用的输入。模型不需要也不应该在上下文里记住所有中间结果只需关注当前步骤的决策。资源的抽象层Runtime将各种外部工具API、数据库、本地函数封装成统一的、模型易于理解的接口通常是函数描述。模型不需要知道SMTP协议的细节它只需要知道有一个叫send_email的工具可用。这极大地降低了模型认知负担也提升了系统的可维护性。这种分离带来了架构上的清晰度。模型专注于自己擅长的领域理解、规划和高级决策属于哪个领域该用哪个工具参数大概是什么。Runtime则专注于自己擅长的领域精确、安全、高效地调用具体功能。两者通过定义清晰的接口如OpenAI的Function Calling标准或ReAct格式的指令进行协作。3. 核心组件与工作流程详解一个典型的基于“模型判断 Runtime执行”的Tool Use系统通常包含以下几个核心组件它们协同工作的流程构成了智能体Agent的“思考-行动”循环。3.1 模型LLM决策大脑模型是整个系统的“大脑”。它的输入是用户的请求和当前对话历史或任务状态输出是对下一步行动的决策。这个决策通常表现为两种形式结构化调用Function Calling模型直接输出一个结构化的JSON对象指明它想要调用的工具名称和具体的参数。这是目前最主流、最清晰的方式。{ tool: get_weather, arguments: { city: 北京, date: 2023-10-27 } }文本指令如ReAct格式模型输出一段包含Thought:、Action:、Action Input:的文本。Runtime需要解析这段文本来提取工具和参数。这种方式更灵活但解析更复杂容易出错。注意模型在这里的“判断”是广义的。它不仅包括“选择哪个工具”还包括参数校验与补全。例如用户说“看看北京的天气”模型需要判断出工具是get_weather并补全参数city为“北京”同时基于常识或对话历史将date参数默认为今天。如果用户说“看看北京后天的天气”模型还需要计算出具体的日期值。这个“补全”和“计算”的过程是模型核心价值的体现它把模糊的用户语言转化为了精确的可执行指令。3.2 工具注册表Tool Registry能力目录Runtime需要知道它有哪些“武器”可用。工具注册表就是一个所有可用工具的清单。每个工具的定义通常包括名称name唯一标识符如calculate。描述description用自然语言描述这个工具的功能。这部分描述对于模型至关重要模型就是通过阅读这些描述来学习何时该调用这个工具。描述应清晰、准确包含适用场景和参数说明。参数模式parameters schema定义工具需要的参数包括名称、类型、是否必需、描述等。通常以JSON Schema格式定义。执行函数function一个具体的、可执行的函数或方法当模型决定调用此工具时Runtime会运行这个函数。例如一个计算器工具的注册可能如下所示伪代码{ name: calculate, description: 执行一个数学计算。支持加()、减(-)、乘(*)、除(/)、幂(**)等运算符。, parameters: { type: object, properties: { expression: { type: string, description: 数学表达式例如 (3 5) * 2 } }, required: [expression] }, function: lambda expression: eval(expression) # 注意实际中应对eval做安全限制 }3.3 运行时Runtime调度与执行引擎Runtime是系统的“心脏”和“双手”。它负责以下工作请求调度接收用户的初始查询将其与工具注册表一起发送给模型请求模型的“判断”即工具调用决策。解析与验证接收模型返回的决策JSON或文本解析出工具名称和参数。然后根据工具注册表中的schema验证参数的类型和完整性。如果模型返回calculate工具但没提供expression参数Runtime应该能识别这是一个错误并可能要求模型重新思考或直接向用户请求缺失信息。安全沙箱与参数预处理在执行前Runtime可以进行安全检查。例如对于calculate工具直接使用Python的eval()是极度危险的。一个负责任的Runtime应该将expression限制在仅包含数字和基本运算符的范围内或者使用更安全的表达式求值库如ast.literal_eval或自定义的解析器。执行调用调用工具对应的执行函数传入验证并处理后的参数。结果处理与反馈获取工具执行的结果可能是成功的数据也可能是错误信息。将这个结果格式化后作为新的上下文连同最初的用户问题和历史再次发送给模型让模型来“理解”这个结果并决定下一步是回答问题还是继续调用其他工具。这个“模型判断 - Runtime执行 - 结果反馈 - 模型再判断”的循环就是智能体完成复杂任务的基本单元。3.4 一个完整的工作流程示例假设用户问“请问北京今天的天气怎么样然后告诉我这样的天气是否适合去故宫游玩。”初始请求Runtime收到用户请求。第一次模型调用Runtime将用户请求和已注册的工具列表包含get_weathersearch_web等发给模型。模型分析后判断需要先获取天气信息于是返回{tool: get_weather, arguments: {city: 北京, date: 2023-10-27}}第一次Runtime执行Runtime解析指令验证参数调用get_weather函数。该函数可能调用一个天气API返回{city: 北京, date: 2023-10-27, condition: 晴, temp_max: 18, temp_min: 8, wind: 微风}第二次模型调用Runtime将天气结果和原始问题再次发给模型。模型现在拥有了天气数据它需要判断下一步。它发现用户还问了“是否适合游玩”这可能超出了它固有的知识范围比如故宫在特定天气下的拥挤程度。于是它判断需要搜索更多信息返回{tool: search_web, arguments: {query: 故宫 晴天 游玩 适宜度}}第二次Runtime执行Runtime调用搜索工具获取相关网页摘要。第三次模型调用最终回答Runtime将搜索摘要和所有历史信息原始问题、天气结果发给模型。模型综合所有信息生成最终回答“北京今天晴天气温8-18度微风。这样的天气非常适合游览故宫光线充足拍照效果好但请注意防晒和补水。建议避开中午时段游客可能较多。”输出给用户Runtime将模型的最终回答呈现给用户。在整个过程中模型从未直接调用过任何API。它只做了三次“判断”1. 需要天气数据2. 需要搜索信息3. 综合信息生成回答。而具体的网络请求、数据获取全部由Runtime可靠地完成。4. 主流框架中的实现与选型心得理解了原理我们来看看在实践中如何落地。目前社区中有多种优秀的框架实现了这一模式它们在设计哲学和易用性上各有侧重。4.1 LangChain / LangGraph生态丰富的“瑞士军刀”LangChain是早期将Tool Use模式普及化的框架之一。它的核心概念是Agent、Tool和Chain。实现方式你通过tool装饰器或继承BaseTool类来定义工具描述和参数schema会自动或手动生成。然后你选择一个“代理类型”如create_react_agentcreate_openai_tools_agent将工具列表和LLM模型传给它就创建了一个具备工具使用能力的Agent。优点生态强大拥有海量的社区贡献工具Toolkits从数据库查询到API封装几乎应有尽有。灵活性高通过Chain可以将多个工具调用、模型调用组合成复杂的工作流。LangGraph更进一步提供了基于图Graph的工作流编排能力非常适合有状态、多分支的复杂Agent。文档和教程丰富。缺点抽象层次较高学习曲线陡峭概念较多Model Prompt Chain Agent Memory等新手容易迷惑。有时显得“笨重”对于简单的工具调用场景LangChain的代码可能看起来有些过度设计。执行效率由于其高度的抽象和灵活性在极高性能要求的场景下可能需要优化。实操心得LangChain非常适合快速构建原型和探索复杂Agent场景。对于生产环境建议深入理解其底层原理并对关键路径如提示词模板、解析逻辑进行定制和优化以避免不必要的开销。使用LangGraph来管理超过3个步骤的、有复杂状态流转的工作流会比你手动管理状态清晰得多。4.2 LlamaIndex专注于数据领域的“专家”LlamaIndex最初的设计核心是让LLM能够与私有数据对话检索增强生成RAG。它的Tool Use能力是围绕这一核心构建的。实现方式在LlamaIndex中工具常常与“查询引擎”Query Engine或“检索器”Retriever绑定。你可以将一个查询引擎封装成一个工具当模型需要某方面数据时就调用这个工具进行检索。优点数据集成一流连接各种数据源文档、数据库、API并建立索引是其看家本领过程非常顺畅。“Agentic RAG”它很自然地支持让Agent在推理过程中主动、多次地进行检索而不是一次性检索所有内容这更符合人类的思考方式。与LangChain良好集成可以混合使用。缺点通用性工具生态不如LangChain。其Agent框架的抽象和功能丰富度目前略逊于LangChain/LangGraph。实操心得如果你的Tool Use场景核心是与复杂的、多源的数据系统交互比如需要从公司知识库、CRM、ERP中综合查询信息LlamaIndex是绝佳的起点。它的数据抽象层能帮你省去大量底层集成工作。4.3 简易自制框架轻量可控的“定制方案”对于功能明确、工具数量不多的场景自己实现一个轻量级的Runtime往往是最优解。这能给你带来最大的控制权和最高的运行效率。核心代码结构示例Pythonimport json from typing import Any, Callable, Dict, List # 1. 定义工具类型 class Tool: def __init__(self, name: str, description: str, func: Callable, params_schema: Dict): self.name name self.description description self.func func self.params_schema params_schema # 简化的schema def run(self, **kwargs) - Any: # 这里可以添加参数验证、安全过滤等 return self.func(**kwargs) # 2. 实现几个工具 def get_weather(city: str, date: str) - str: # 模拟API调用 return f{city}在{date}的天气是晴天20度。 def calculate(expression: str) - float: # 安全计算这里仅作示例实际应用需严格限制 allowed_chars set(0123456789-*/(). ) if not all(c in allowed_chars for c in expression): raise ValueError(表达式包含非法字符) return eval(expression) # 3. 创建工具注册表 tools { get_weather: Tool( nameget_weather, description获取指定城市在指定日期的天气信息。, funcget_weather, params_schema{city: {type: string}, date: {type: string}} ), calculate: Tool( namecalculate, description执行一个安全的数学计算。, funccalculate, params_schema{expression: {type: string}} ) } # 4. 模拟LLM判断实际中这里调用真实的LLM API def llm_judge(user_query: str, available_tools: List[Tool]) - Dict: # 这是一个极其简化的模拟。真实场景中这里是一个复杂的提示词工程。 # 假设模型经过思考决定调用计算器 if 计算 in user_query or 算一下 in user_query: # 模拟模型提取参数例如从“算一下35”中提取“35” import re match re.search(r算一下(.), user_query) expression match.group(1) if match else 0 return {tool: calculate, arguments: {expression: expression}} # 否则返回最终答案 return {tool: None, arguments: {}, final_answer: 我不知道如何回答这个问题。} # 5. Runtime核心调度执行循环 def runtime_execute(user_query: str): available_tools_list list(tools.values()) # 第一次判断 decision llm_judge(user_query, available_tools_list) while decision.get(tool): tool_name decision[tool] tool_args decision[arguments] if tool_name not in tools: return f错误工具 {tool_name} 未找到。 tool tools[tool_name] try: # 执行工具 result tool.run(**tool_args) print(f[Runtime] 执行工具 {tool_name} 参数 {tool_args} 结果: {result}) # 将结果作为新上下文模拟再次请求LLM进行下一步判断 # 这里为了简化假设一次工具调用后就直接用结果生成最终答案 decision {tool: None, final_answer: f根据计算结果是{result}} except Exception as e: return f执行工具 {tool_name} 时出错{e} # 返回最终答案 return decision.get(final_answer, 任务完成。) # 测试 if __name__ __main__: user_input 帮我算一下3加5乘以2等于多少 final_output runtime_execute(user_input) print(f用户问题: {user_input}) print(f系统回答: {final_output})自制框架的优势零依赖部署简单。性能极致没有额外抽象层开销。完全可控安全策略、错误处理、状态管理都可以按需定制。深度理解亲手实现一遍对Tool Use机制的理解会远超使用框架。自制框架的挑战需要自己处理所有细节提示词工程、输出解析、错误重试、会话状态管理、工具描述优化等。扩展性当工具数量增多、工作流变复杂时代码可能变得难以维护。选型建议快速原型验证、研究复杂Agent逻辑首选LangChain/LangGraph。利用其丰富的生态快速搭建验证想法的可行性。核心为复杂数据查询与分析的Agent首选LlamaIndex。它的数据连接和检索能力是原生优势。生产环境、工具固定、追求极致性能和可控性推荐自制轻量框架。从上述简易结构开始逐步迭代增加如工具描述自动生成、更鲁棒的解析器、并发执行等高级功能。简单集成如只想在现有应用中加一个智能函数直接使用大模型提供商如OpenAI Anthropic DeepSeek的原生Function Calling API。它们提供了最直接的工具调用接口Runtime部分相对简单。5. 关键实践如何设计一个好的工具工具设计的好坏直接决定了模型“判断”的难易度和准确性。一个糟糕的工具描述会让最聪明的模型也束手无策。5.1 工具描述的“艺术”工具的描述description是模型认识它的唯一窗口。好的描述应该清晰明确直截了当地说明这个工具是干什么的。避免模糊词汇。差“处理数据。”好“根据提供的城市名称和日期从天气服务API获取该地的天气预报详情包括天气状况、最高最低温度和风速。”说明使用场景在什么情况下应该调用这个工具补充“当用户询问关于未来或当前天气、穿衣建议、出行计划受天气影响时使用此工具。”详细说明参数在描述中或通过独立的参数schema清晰说明每个参数的意义、格式和示例。例如city参数应传入城市名称的字符串如“北京”date参数格式应为“YYYY-MM-DD”。使用自然语言关键词包含用户可能提到的同义词。例如搜索工具的描述可以包含“查找”、“搜索”、“查询”、“获取信息”等词帮助模型建立关联。5.2 参数设计的“陷阱”与规避避免开放域参数尽量不要设计像query: str这样完全开放的参数除非你的后端工具能处理任意输入。这容易导致模型滥用或传入无意义内容。尽量将参数约束在有限集合或明确格式内。提供默认值与枚举对于有常见默认值的参数在schema中注明。对于类别型参数使用enum列出所有可能值。这能极大提高模型调用的准确性。temperature_unit: { type: string, enum: [celsius, fahrenheit], description: 温度单位默认为摄氏度celsius。 }处理复合参数有时用户请求包含多个信息点。例如“帮我查下北京和上海明天的天气”。模型需要判断是调用一次工具如果工具支持城市列表还是调用两次。最好的方式是工具设计时就支持数组参数cities: List[str]并在描述中写清楚。如果不行Runtime或模型需要有能力将复杂请求拆分成多个简单调用。5.3 安全与错误处理Runtime的“守门员”职责这是Runtime最关键的责任之一绝不能委托给模型。输入验证与净化对模型传入的参数进行严格检查。检查类型、范围、长度、是否包含恶意字符如SQL注入、命令注入字符。例如对于调用系统命令的工具必须白名单化允许的命令和参数。权限控制不同的工具可能对应不同的权限级别。Runtime应该有一套机制根据当前会话的用户身份决定是否允许调用某个工具。配额与限流防止恶意或错误的循环调用耗尽资源。为工具调用设置频率限制和总量限制。优雅的错误处理工具执行可能失败网络错误、API限流、资源不存在。Runtime应该捕获这些异常并将其转化为模型能够理解的、结构化的错误信息反馈给模型让模型决定是重试、换种方式还是向用户道歉。反馈给模型{error: WEATHER_API_FAILED, message: 天气服务暂时不可用请稍后再试。}而不是直接抛出一段Python的异常堆栈信息。6. 高级模式与未来展望基础的“判断-执行”循环之上还有更高级的模式来增强Agent的能力。6.1 规划与反思让Agent更“深思熟虑”简单的单步工具调用无法解决复杂问题。高级的Agent框架引入了“规划”和“反思”机制。规划Planning在开始执行前模型先制定一个计划大纲。例如“要回答‘准备一场北京三日游’这个问题我需要1. 查询北京未来三天天气2. 搜索热门景点3. 查询景点间的交通4. 综合生成行程。” 然后按照这个计划一步步执行。这能避免Agent在复杂任务中迷失方向。反思Reflection/Self-Critique在执行一步或几步后模型停下来“回顾”一下。检查结果是否合理是否偏离了目标当前计划是否需要调整。例如在搜索景点后发现某个景点因维修关闭模型可以“反思”并调整计划替换另一个景点。这些能力通常通过设计特定的提示词如Chain-of-Thought ReAct或在Runtime中设计多轮次的、包含历史行动和结果的对话上下文来实现。LangGraph的循环和状态机设计就非常适合实现这类带有规划和反思的复杂工作流。6.2 工具学习与自动工具发现目前工具都需要开发者手动定义和注册。未来的方向是自动工具发现与集成。从文档/代码中学习让模型阅读API文档、函数注释甚至代码库自动理解其功能并生成可调用的工具描述。从操作中学习模仿学习通过记录用户在图形界面GUI上的操作点击、输入让模型学习到这个操作序列并将其抽象成一个可重复调用的“工具”。这被称为“像素级”或“UI自动化”的Agent。动态工具组合模型不仅能调用现有工具还能在运行时根据需求通过生成代码片段Code Interpreter模式或组合多个基础工具来创建新的“临时工具”解决问题。6.3 多模态工具调用随着多模态大模型如GPT-4V Claude 3的成熟工具调用的对象不再局限于函数和API。图像/视频处理工具模型可以“看”到一张图片然后判断需要调用“识别图中物体”、“提取图中文字”、“将背景替换成蓝天”等工具。物理世界交互工具通过机器人控制API模型可以指挥机械臂抓取物体或者让自动驾驶汽车执行变道指令。这里的Runtime就是机器人操作系统ROS或车辆控制接口。7. 常见问题与实战避坑指南在实际开发和调试中你会遇到各种各样的问题。以下是一些典型问题及其解决思路。7.1 模型不调用工具总是直接回答这是最常见的问题。原因和解决方案工具描述太差模型看不懂你的工具是干什么的。解决优化工具描述使其更清晰、包含使用场景和示例。可以尝试让一个更强的模型如GPT-4来帮你润色工具描述。提示词Prompt未引导你没有在给模型的系统指令System Prompt中明确要求它使用工具。解决在系统提示中加入明确的指令例如“你是一个助手可以调用工具来帮助用户。当需要获取实时信息、进行计算或执行特定操作时请优先考虑使用提供的工具。请根据工具描述决定是否调用。”模型能力不足一些较小的或未经专门微调的模型工具调用能力较弱。解决换用工具调用能力更强的模型如GPT-4系列、Claude 3系列、DeepSeek最新版本或使用经过“工具使用”数据微调的开源模型。用户问题太简单问题本身不需要工具就能回答。这是正常现象并非所有问题都需要工具。7.2 模型调用了错误的工具或参数不对工具功能重叠或描述模糊两个工具的描述相似模型难以区分。解决细化工具描述突出其独特性和专用场景。例如search_web用于查找通用信息query_database用于查找内部结构化数据。参数提取失败模型没有从用户问题中正确提取出参数。解决在工具描述中提供更明确的参数示例。使用“少样本Few-shot”提示在系统消息中给出几个“用户问题 - 正确工具调用”的例子教模型如何做。如果问题复杂可以让模型进行多轮对话来澄清参数“您想查询哪个城市的天气”这需要Runtime支持将模型的“提问”返回给用户。7.3 工具执行失败或超时网络或依赖服务不稳定这是外部原因。解决在Runtime中为工具调用实现重试机制如指数退避重试并设置合理的超时时间。对于关键工具要有降级方案如缓存旧数据。参数格式错误模型传入了服务不接受的格式。解决在Runtime的执行层做参数格式的强制转换和验证。例如日期字符串统一转换为YYYY-MM-DD格式。权限或配额不足API密钥失效或达到调用上限。解决Runtime需要集成完善的密钥管理和配额监控并在失败时返回清晰的错误信息给模型或用户。7.4 调试与监控困难当Agent行为不符合预期时调试起来比传统程序更困难因为涉及模型“黑箱”决策。记录完整的思维链确保记录下模型每一次的输入包含完整的提示词上下文和输出包括思考过程、工具调用决策。这能帮你分析是提示词问题、工具描述问题还是模型本身的问题。可视化工作流使用像LangSmith这样的平台可以清晰地追踪一次Agent调用中所有的LLM调用、工具执行、输入输出和耗时是调试的神器。单元测试你的工具单独测试每个工具函数确保其功能正常、鲁棒。这是基础。集成测试你的Agent准备一批典型的用户问题运行你的Agent检查其最终回答和中间工具调用序列是否符合预期。这能发现工作流逻辑中的问题。最后一点个人体会构建一个可靠的Tool Use系统是一个典型的“八分工程两分调优”的工作。初期搭建框架和工具可能只占20%的时间剩下80%的时间都会花在优化提示词、打磨工具描述、完善错误处理、增加监控和调试这些“细活儿”上。这个过程没有捷径需要你不断地观察Agent的行为分析日志做出微调。但当你看到Agent能稳定、准确地完成一个复杂任务链时那种成就感是无与伦比的。记住我们的目标不是创造一个“万能”的AI而是打造一个“模型”与“Runtime”精诚合作、各司其职的高效数字助理。 AI应用架构革新：模型专注判断，Runtime负责执行的工具调用范式
1. 项目概述从“全能模型”到“专业分工”的范式转变最近在折腾各种AI应用和智能体Agent时我越来越清晰地感受到一个趋势模型本身正在变得越来越“懒”或者说越来越“聪明地懒”。这里的“懒”不是贬义词而是指模型的核心职责正在发生一次深刻的范式转移。过去我们总希望一个大模型能包揽一切——理解、推理、规划、执行甚至直接调用外部API。但现实是这种“全能选手”的构想不仅让模型变得臃肿、响应慢更在复杂、长链条的任务中频频出错可靠性堪忧。现在一个更清晰、更高效的分工模式正在成为共识也就是标题所说的模型只负责判断Runtime才真正执行。这听起来像是一句简单的技术口号但它背后蕴含的是整个AI应用架构设计理念的革新。简单来说模型尤其是大语言模型LLM的角色从“执行者”退回到了“决策者”或“指挥官”。它的核心任务不再是亲自去写一行代码、发一个HTTP请求而是理解用户意图拆解任务步骤并在关键时刻做出“该调用哪个工具”、“参数应该是什么”的判断。而真正去执行这些具体操作——无论是调用一个计算器、查询数据库、发送邮件还是控制一个机器人手臂——则交给一个专门、稳定、可控的“运行时Runtime”环境。这个模式就是工具使用Tool Use的核心。它不是什么全新的概念但在开源模型能力突飞猛进比如单日处理万亿级Token的模型出现、Agent框架遍地开花的今天其重要性被提到了前所未有的高度。为什么因为当我们不再仅仅满足于让模型“聊聊天”而是希望它真正能替我们完成工作流时执行环节的稳定性、安全性和效率就成了生命线。一个只会“纸上谈兵”的模型是没用的它必须能可靠地驱动现实世界中的工具。而这个驱动引擎就是Runtime。2. 核心思路拆解为什么“判断”与“执行”必须分离要理解这个分工的必要性我们需要从模型的特性和实际应用的需求两个层面来看。2.1 大语言模型的本质与局限首先我们必须认清大语言模型的本质它是一个基于概率的、生成文本的“超级模仿者”。它通过学习海量文本数据中的模式和关联学会了以惊人的流畅度进行对话、分析和推理。然而这种能力存在几个根本性的局限非确定性模型的输出是概率性的同一输入可能产生不同的输出。这对于创意写作是优点但对于要求精确、可重复的操作指令如发送一封特定收件人、特定内容的邮件则是灾难。幻觉与事实性错误模型会“自信地”编造不存在的信息或给出错误的代码、命令。让它直接生成并执行系统命令无异于将系统安全交给一个偶尔会胡言乱语的天才。缺乏实时性与状态感知模型的训练数据是静态的它不知道当前时间、不知道你的邮箱里刚收到的新邮件、不知道某个API服务是否暂时宕机。它无法感知动态变化的外部世界状态。无实际操作能力模型只是一段代码运行在计算设备上。它本身没有“手”去点击按钮没有“嘴”去发出网络请求。所有的外部交互都必须通过编程接口API来实现。如果让模型既做判断决定发邮件又负责执行拼接SMTP请求并发送就相当于让一位战略指挥官同时去前线扣动扳机。指挥官可能会因为“幻觉”把坐标报错也可能因为不熟悉枪械构造而卡壳。结果就是任务失败甚至造成“友军误伤”系统错误、数据泄露。2.2 Runtime的核心价值可靠性、安全性与效率将执行权交给Runtime正是为了弥补模型的上述缺陷。一个设计良好的Runtime环境扮演着以下几个关键角色可靠的执行器Runtime是确定性的代码。你告诉它调用send_email(to, subject, body)只要参数正确、网络通畅它就会严格按照定义好的逻辑去执行不会自己“发挥”。这保证了操作结果的可靠性和可预测性。安全的沙箱Runtime可以对模型发来的指令进行校验和过滤。例如它可以禁止模型执行rm -rf /这样的危险命令或者对数据库查询进行权限检查和SQL注入防护。它是模型与真实世界之间的“安全阀”和“防火墙”。状态的管家Runtime可以维护任务执行过程中的状态。比如它知道上一步从数据库查询的结果是什么并可以将这个结果作为下一步工具调用的输入。模型不需要也不应该在上下文里记住所有中间结果只需关注当前步骤的决策。资源的抽象层Runtime将各种外部工具API、数据库、本地函数封装成统一的、模型易于理解的接口通常是函数描述。模型不需要知道SMTP协议的细节它只需要知道有一个叫send_email的工具可用。这极大地降低了模型认知负担也提升了系统的可维护性。这种分离带来了架构上的清晰度。模型专注于自己擅长的领域理解、规划和高级决策属于哪个领域该用哪个工具参数大概是什么。Runtime则专注于自己擅长的领域精确、安全、高效地调用具体功能。两者通过定义清晰的接口如OpenAI的Function Calling标准或ReAct格式的指令进行协作。3. 核心组件与工作流程详解一个典型的基于“模型判断 Runtime执行”的Tool Use系统通常包含以下几个核心组件它们协同工作的流程构成了智能体Agent的“思考-行动”循环。3.1 模型LLM决策大脑模型是整个系统的“大脑”。它的输入是用户的请求和当前对话历史或任务状态输出是对下一步行动的决策。这个决策通常表现为两种形式结构化调用Function Calling模型直接输出一个结构化的JSON对象指明它想要调用的工具名称和具体的参数。这是目前最主流、最清晰的方式。{ tool: get_weather, arguments: { city: 北京, date: 2023-10-27 } }文本指令如ReAct格式模型输出一段包含Thought:、Action:、Action Input:的文本。Runtime需要解析这段文本来提取工具和参数。这种方式更灵活但解析更复杂容易出错。注意模型在这里的“判断”是广义的。它不仅包括“选择哪个工具”还包括参数校验与补全。例如用户说“看看北京的天气”模型需要判断出工具是get_weather并补全参数city为“北京”同时基于常识或对话历史将date参数默认为今天。如果用户说“看看北京后天的天气”模型还需要计算出具体的日期值。这个“补全”和“计算”的过程是模型核心价值的体现它把模糊的用户语言转化为了精确的可执行指令。3.2 工具注册表Tool Registry能力目录Runtime需要知道它有哪些“武器”可用。工具注册表就是一个所有可用工具的清单。每个工具的定义通常包括名称name唯一标识符如calculate。描述description用自然语言描述这个工具的功能。这部分描述对于模型至关重要模型就是通过阅读这些描述来学习何时该调用这个工具。描述应清晰、准确包含适用场景和参数说明。参数模式parameters schema定义工具需要的参数包括名称、类型、是否必需、描述等。通常以JSON Schema格式定义。执行函数function一个具体的、可执行的函数或方法当模型决定调用此工具时Runtime会运行这个函数。例如一个计算器工具的注册可能如下所示伪代码{ name: calculate, description: 执行一个数学计算。支持加()、减(-)、乘(*)、除(/)、幂(**)等运算符。, parameters: { type: object, properties: { expression: { type: string, description: 数学表达式例如 (3 5) * 2 } }, required: [expression] }, function: lambda expression: eval(expression) # 注意实际中应对eval做安全限制 }3.3 运行时Runtime调度与执行引擎Runtime是系统的“心脏”和“双手”。它负责以下工作请求调度接收用户的初始查询将其与工具注册表一起发送给模型请求模型的“判断”即工具调用决策。解析与验证接收模型返回的决策JSON或文本解析出工具名称和参数。然后根据工具注册表中的schema验证参数的类型和完整性。如果模型返回calculate工具但没提供expression参数Runtime应该能识别这是一个错误并可能要求模型重新思考或直接向用户请求缺失信息。安全沙箱与参数预处理在执行前Runtime可以进行安全检查。例如对于calculate工具直接使用Python的eval()是极度危险的。一个负责任的Runtime应该将expression限制在仅包含数字和基本运算符的范围内或者使用更安全的表达式求值库如ast.literal_eval或自定义的解析器。执行调用调用工具对应的执行函数传入验证并处理后的参数。结果处理与反馈获取工具执行的结果可能是成功的数据也可能是错误信息。将这个结果格式化后作为新的上下文连同最初的用户问题和历史再次发送给模型让模型来“理解”这个结果并决定下一步是回答问题还是继续调用其他工具。这个“模型判断 - Runtime执行 - 结果反馈 - 模型再判断”的循环就是智能体完成复杂任务的基本单元。3.4 一个完整的工作流程示例假设用户问“请问北京今天的天气怎么样然后告诉我这样的天气是否适合去故宫游玩。”初始请求Runtime收到用户请求。第一次模型调用Runtime将用户请求和已注册的工具列表包含get_weathersearch_web等发给模型。模型分析后判断需要先获取天气信息于是返回{tool: get_weather, arguments: {city: 北京, date: 2023-10-27}}第一次Runtime执行Runtime解析指令验证参数调用get_weather函数。该函数可能调用一个天气API返回{city: 北京, date: 2023-10-27, condition: 晴, temp_max: 18, temp_min: 8, wind: 微风}第二次模型调用Runtime将天气结果和原始问题再次发给模型。模型现在拥有了天气数据它需要判断下一步。它发现用户还问了“是否适合游玩”这可能超出了它固有的知识范围比如故宫在特定天气下的拥挤程度。于是它判断需要搜索更多信息返回{tool: search_web, arguments: {query: 故宫 晴天 游玩 适宜度}}第二次Runtime执行Runtime调用搜索工具获取相关网页摘要。第三次模型调用最终回答Runtime将搜索摘要和所有历史信息原始问题、天气结果发给模型。模型综合所有信息生成最终回答“北京今天晴天气温8-18度微风。这样的天气非常适合游览故宫光线充足拍照效果好但请注意防晒和补水。建议避开中午时段游客可能较多。”输出给用户Runtime将模型的最终回答呈现给用户。在整个过程中模型从未直接调用过任何API。它只做了三次“判断”1. 需要天气数据2. 需要搜索信息3. 综合信息生成回答。而具体的网络请求、数据获取全部由Runtime可靠地完成。4. 主流框架中的实现与选型心得理解了原理我们来看看在实践中如何落地。目前社区中有多种优秀的框架实现了这一模式它们在设计哲学和易用性上各有侧重。4.1 LangChain / LangGraph生态丰富的“瑞士军刀”LangChain是早期将Tool Use模式普及化的框架之一。它的核心概念是Agent、Tool和Chain。实现方式你通过tool装饰器或继承BaseTool类来定义工具描述和参数schema会自动或手动生成。然后你选择一个“代理类型”如create_react_agentcreate_openai_tools_agent将工具列表和LLM模型传给它就创建了一个具备工具使用能力的Agent。优点生态强大拥有海量的社区贡献工具Toolkits从数据库查询到API封装几乎应有尽有。灵活性高通过Chain可以将多个工具调用、模型调用组合成复杂的工作流。LangGraph更进一步提供了基于图Graph的工作流编排能力非常适合有状态、多分支的复杂Agent。文档和教程丰富。缺点抽象层次较高学习曲线陡峭概念较多Model Prompt Chain Agent Memory等新手容易迷惑。有时显得“笨重”对于简单的工具调用场景LangChain的代码可能看起来有些过度设计。执行效率由于其高度的抽象和灵活性在极高性能要求的场景下可能需要优化。实操心得LangChain非常适合快速构建原型和探索复杂Agent场景。对于生产环境建议深入理解其底层原理并对关键路径如提示词模板、解析逻辑进行定制和优化以避免不必要的开销。使用LangGraph来管理超过3个步骤的、有复杂状态流转的工作流会比你手动管理状态清晰得多。4.2 LlamaIndex专注于数据领域的“专家”LlamaIndex最初的设计核心是让LLM能够与私有数据对话检索增强生成RAG。它的Tool Use能力是围绕这一核心构建的。实现方式在LlamaIndex中工具常常与“查询引擎”Query Engine或“检索器”Retriever绑定。你可以将一个查询引擎封装成一个工具当模型需要某方面数据时就调用这个工具进行检索。优点数据集成一流连接各种数据源文档、数据库、API并建立索引是其看家本领过程非常顺畅。“Agentic RAG”它很自然地支持让Agent在推理过程中主动、多次地进行检索而不是一次性检索所有内容这更符合人类的思考方式。与LangChain良好集成可以混合使用。缺点通用性工具生态不如LangChain。其Agent框架的抽象和功能丰富度目前略逊于LangChain/LangGraph。实操心得如果你的Tool Use场景核心是与复杂的、多源的数据系统交互比如需要从公司知识库、CRM、ERP中综合查询信息LlamaIndex是绝佳的起点。它的数据抽象层能帮你省去大量底层集成工作。4.3 简易自制框架轻量可控的“定制方案”对于功能明确、工具数量不多的场景自己实现一个轻量级的Runtime往往是最优解。这能给你带来最大的控制权和最高的运行效率。核心代码结构示例Pythonimport json from typing import Any, Callable, Dict, List # 1. 定义工具类型 class Tool: def __init__(self, name: str, description: str, func: Callable, params_schema: Dict): self.name name self.description description self.func func self.params_schema params_schema # 简化的schema def run(self, **kwargs) - Any: # 这里可以添加参数验证、安全过滤等 return self.func(**kwargs) # 2. 实现几个工具 def get_weather(city: str, date: str) - str: # 模拟API调用 return f{city}在{date}的天气是晴天20度。 def calculate(expression: str) - float: # 安全计算这里仅作示例实际应用需严格限制 allowed_chars set(0123456789-*/(). ) if not all(c in allowed_chars for c in expression): raise ValueError(表达式包含非法字符) return eval(expression) # 3. 创建工具注册表 tools { get_weather: Tool( nameget_weather, description获取指定城市在指定日期的天气信息。, funcget_weather, params_schema{city: {type: string}, date: {type: string}} ), calculate: Tool( namecalculate, description执行一个安全的数学计算。, funccalculate, params_schema{expression: {type: string}} ) } # 4. 模拟LLM判断实际中这里调用真实的LLM API def llm_judge(user_query: str, available_tools: List[Tool]) - Dict: # 这是一个极其简化的模拟。真实场景中这里是一个复杂的提示词工程。 # 假设模型经过思考决定调用计算器 if 计算 in user_query or 算一下 in user_query: # 模拟模型提取参数例如从“算一下35”中提取“35” import re match re.search(r算一下(.), user_query) expression match.group(1) if match else 0 return {tool: calculate, arguments: {expression: expression}} # 否则返回最终答案 return {tool: None, arguments: {}, final_answer: 我不知道如何回答这个问题。} # 5. Runtime核心调度执行循环 def runtime_execute(user_query: str): available_tools_list list(tools.values()) # 第一次判断 decision llm_judge(user_query, available_tools_list) while decision.get(tool): tool_name decision[tool] tool_args decision[arguments] if tool_name not in tools: return f错误工具 {tool_name} 未找到。 tool tools[tool_name] try: # 执行工具 result tool.run(**tool_args) print(f[Runtime] 执行工具 {tool_name} 参数 {tool_args} 结果: {result}) # 将结果作为新上下文模拟再次请求LLM进行下一步判断 # 这里为了简化假设一次工具调用后就直接用结果生成最终答案 decision {tool: None, final_answer: f根据计算结果是{result}} except Exception as e: return f执行工具 {tool_name} 时出错{e} # 返回最终答案 return decision.get(final_answer, 任务完成。) # 测试 if __name__ __main__: user_input 帮我算一下3加5乘以2等于多少 final_output runtime_execute(user_input) print(f用户问题: {user_input}) print(f系统回答: {final_output})自制框架的优势零依赖部署简单。性能极致没有额外抽象层开销。完全可控安全策略、错误处理、状态管理都可以按需定制。深度理解亲手实现一遍对Tool Use机制的理解会远超使用框架。自制框架的挑战需要自己处理所有细节提示词工程、输出解析、错误重试、会话状态管理、工具描述优化等。扩展性当工具数量增多、工作流变复杂时代码可能变得难以维护。选型建议快速原型验证、研究复杂Agent逻辑首选LangChain/LangGraph。利用其丰富的生态快速搭建验证想法的可行性。核心为复杂数据查询与分析的Agent首选LlamaIndex。它的数据连接和检索能力是原生优势。生产环境、工具固定、追求极致性能和可控性推荐自制轻量框架。从上述简易结构开始逐步迭代增加如工具描述自动生成、更鲁棒的解析器、并发执行等高级功能。简单集成如只想在现有应用中加一个智能函数直接使用大模型提供商如OpenAI Anthropic DeepSeek的原生Function Calling API。它们提供了最直接的工具调用接口Runtime部分相对简单。5. 关键实践如何设计一个好的工具工具设计的好坏直接决定了模型“判断”的难易度和准确性。一个糟糕的工具描述会让最聪明的模型也束手无策。5.1 工具描述的“艺术”工具的描述description是模型认识它的唯一窗口。好的描述应该清晰明确直截了当地说明这个工具是干什么的。避免模糊词汇。差“处理数据。”好“根据提供的城市名称和日期从天气服务API获取该地的天气预报详情包括天气状况、最高最低温度和风速。”说明使用场景在什么情况下应该调用这个工具补充“当用户询问关于未来或当前天气、穿衣建议、出行计划受天气影响时使用此工具。”详细说明参数在描述中或通过独立的参数schema清晰说明每个参数的意义、格式和示例。例如city参数应传入城市名称的字符串如“北京”date参数格式应为“YYYY-MM-DD”。使用自然语言关键词包含用户可能提到的同义词。例如搜索工具的描述可以包含“查找”、“搜索”、“查询”、“获取信息”等词帮助模型建立关联。5.2 参数设计的“陷阱”与规避避免开放域参数尽量不要设计像query: str这样完全开放的参数除非你的后端工具能处理任意输入。这容易导致模型滥用或传入无意义内容。尽量将参数约束在有限集合或明确格式内。提供默认值与枚举对于有常见默认值的参数在schema中注明。对于类别型参数使用enum列出所有可能值。这能极大提高模型调用的准确性。temperature_unit: { type: string, enum: [celsius, fahrenheit], description: 温度单位默认为摄氏度celsius。 }处理复合参数有时用户请求包含多个信息点。例如“帮我查下北京和上海明天的天气”。模型需要判断是调用一次工具如果工具支持城市列表还是调用两次。最好的方式是工具设计时就支持数组参数cities: List[str]并在描述中写清楚。如果不行Runtime或模型需要有能力将复杂请求拆分成多个简单调用。5.3 安全与错误处理Runtime的“守门员”职责这是Runtime最关键的责任之一绝不能委托给模型。输入验证与净化对模型传入的参数进行严格检查。检查类型、范围、长度、是否包含恶意字符如SQL注入、命令注入字符。例如对于调用系统命令的工具必须白名单化允许的命令和参数。权限控制不同的工具可能对应不同的权限级别。Runtime应该有一套机制根据当前会话的用户身份决定是否允许调用某个工具。配额与限流防止恶意或错误的循环调用耗尽资源。为工具调用设置频率限制和总量限制。优雅的错误处理工具执行可能失败网络错误、API限流、资源不存在。Runtime应该捕获这些异常并将其转化为模型能够理解的、结构化的错误信息反馈给模型让模型决定是重试、换种方式还是向用户道歉。反馈给模型{error: WEATHER_API_FAILED, message: 天气服务暂时不可用请稍后再试。}而不是直接抛出一段Python的异常堆栈信息。6. 高级模式与未来展望基础的“判断-执行”循环之上还有更高级的模式来增强Agent的能力。6.1 规划与反思让Agent更“深思熟虑”简单的单步工具调用无法解决复杂问题。高级的Agent框架引入了“规划”和“反思”机制。规划Planning在开始执行前模型先制定一个计划大纲。例如“要回答‘准备一场北京三日游’这个问题我需要1. 查询北京未来三天天气2. 搜索热门景点3. 查询景点间的交通4. 综合生成行程。” 然后按照这个计划一步步执行。这能避免Agent在复杂任务中迷失方向。反思Reflection/Self-Critique在执行一步或几步后模型停下来“回顾”一下。检查结果是否合理是否偏离了目标当前计划是否需要调整。例如在搜索景点后发现某个景点因维修关闭模型可以“反思”并调整计划替换另一个景点。这些能力通常通过设计特定的提示词如Chain-of-Thought ReAct或在Runtime中设计多轮次的、包含历史行动和结果的对话上下文来实现。LangGraph的循环和状态机设计就非常适合实现这类带有规划和反思的复杂工作流。6.2 工具学习与自动工具发现目前工具都需要开发者手动定义和注册。未来的方向是自动工具发现与集成。从文档/代码中学习让模型阅读API文档、函数注释甚至代码库自动理解其功能并生成可调用的工具描述。从操作中学习模仿学习通过记录用户在图形界面GUI上的操作点击、输入让模型学习到这个操作序列并将其抽象成一个可重复调用的“工具”。这被称为“像素级”或“UI自动化”的Agent。动态工具组合模型不仅能调用现有工具还能在运行时根据需求通过生成代码片段Code Interpreter模式或组合多个基础工具来创建新的“临时工具”解决问题。6.3 多模态工具调用随着多模态大模型如GPT-4V Claude 3的成熟工具调用的对象不再局限于函数和API。图像/视频处理工具模型可以“看”到一张图片然后判断需要调用“识别图中物体”、“提取图中文字”、“将背景替换成蓝天”等工具。物理世界交互工具通过机器人控制API模型可以指挥机械臂抓取物体或者让自动驾驶汽车执行变道指令。这里的Runtime就是机器人操作系统ROS或车辆控制接口。7. 常见问题与实战避坑指南在实际开发和调试中你会遇到各种各样的问题。以下是一些典型问题及其解决思路。7.1 模型不调用工具总是直接回答这是最常见的问题。原因和解决方案工具描述太差模型看不懂你的工具是干什么的。解决优化工具描述使其更清晰、包含使用场景和示例。可以尝试让一个更强的模型如GPT-4来帮你润色工具描述。提示词Prompt未引导你没有在给模型的系统指令System Prompt中明确要求它使用工具。解决在系统提示中加入明确的指令例如“你是一个助手可以调用工具来帮助用户。当需要获取实时信息、进行计算或执行特定操作时请优先考虑使用提供的工具。请根据工具描述决定是否调用。”模型能力不足一些较小的或未经专门微调的模型工具调用能力较弱。解决换用工具调用能力更强的模型如GPT-4系列、Claude 3系列、DeepSeek最新版本或使用经过“工具使用”数据微调的开源模型。用户问题太简单问题本身不需要工具就能回答。这是正常现象并非所有问题都需要工具。7.2 模型调用了错误的工具或参数不对工具功能重叠或描述模糊两个工具的描述相似模型难以区分。解决细化工具描述突出其独特性和专用场景。例如search_web用于查找通用信息query_database用于查找内部结构化数据。参数提取失败模型没有从用户问题中正确提取出参数。解决在工具描述中提供更明确的参数示例。使用“少样本Few-shot”提示在系统消息中给出几个“用户问题 - 正确工具调用”的例子教模型如何做。如果问题复杂可以让模型进行多轮对话来澄清参数“您想查询哪个城市的天气”这需要Runtime支持将模型的“提问”返回给用户。7.3 工具执行失败或超时网络或依赖服务不稳定这是外部原因。解决在Runtime中为工具调用实现重试机制如指数退避重试并设置合理的超时时间。对于关键工具要有降级方案如缓存旧数据。参数格式错误模型传入了服务不接受的格式。解决在Runtime的执行层做参数格式的强制转换和验证。例如日期字符串统一转换为YYYY-MM-DD格式。权限或配额不足API密钥失效或达到调用上限。解决Runtime需要集成完善的密钥管理和配额监控并在失败时返回清晰的错误信息给模型或用户。7.4 调试与监控困难当Agent行为不符合预期时调试起来比传统程序更困难因为涉及模型“黑箱”决策。记录完整的思维链确保记录下模型每一次的输入包含完整的提示词上下文和输出包括思考过程、工具调用决策。这能帮你分析是提示词问题、工具描述问题还是模型本身的问题。可视化工作流使用像LangSmith这样的平台可以清晰地追踪一次Agent调用中所有的LLM调用、工具执行、输入输出和耗时是调试的神器。单元测试你的工具单独测试每个工具函数确保其功能正常、鲁棒。这是基础。集成测试你的Agent准备一批典型的用户问题运行你的Agent检查其最终回答和中间工具调用序列是否符合预期。这能发现工作流逻辑中的问题。最后一点个人体会构建一个可靠的Tool Use系统是一个典型的“八分工程两分调优”的工作。初期搭建框架和工具可能只占20%的时间剩下80%的时间都会花在优化提示词、打磨工具描述、完善错误处理、增加监控和调试这些“细活儿”上。这个过程没有捷径需要你不断地观察Agent的行为分析日志做出微调。但当你看到Agent能稳定、准确地完成一个复杂任务链时那种成就感是无与伦比的。记住我们的目标不是创造一个“万能”的AI而是打造一个“模型”与“Runtime”精诚合作、各司其职的高效数字助理。