基于llm-python框架构建生产级LLM应用：从核心概念到工程实践

1. 项目概述与核心价值

最近在折腾大语言模型（LLM）应用开发的朋友，估计都绕不开一个核心问题：如何快速、高效地构建一个能与LLM交互的Python应用？是直接调用OpenAI的API，还是自己部署开源模型？代码结构怎么组织才清晰？异步调用、流式响应、工具调用这些功能怎么优雅地实现？如果你也正被这些问题困扰，那么今天要聊的这个开源项目onlyphantom/llm-python，很可能就是你一直在找的“脚手架”和“工具箱”。

简单来说，llm-python是一个为构建生产级LLM应用而设计的Python框架。它不是一个模型，而是一个精心设计的开发框架，旨在将开发者从繁琐的API调用封装、会话管理、工具集成等底层细节中解放出来，让你能更专注于应用逻辑本身。我第一次接触它，是因为厌倦了在每个新项目里重复编写几乎相同的openai.ChatCompletion.create调用，以及处理各种模型提供商（如OpenAI、Anthropic、Google等）之间细微但恼人的API差异。llm-python提供了一个统一的、面向对象的接口，让你可以用几乎相同的方式与不同的模型后端对话，这极大地提升了开发效率和代码的可维护性。

这个框架的核心价值在于“标准化”和“可扩展性”。它定义了一套清晰的抽象，比如Agent、Tool、Message、Session，让你可以用一种声明式、模块化的方式来构建复杂的LLM工作流。无论是构建一个简单的问答机器人，还是一个集成了网络搜索、代码执行、数据库查询的智能助手，llm-python都能提供坚实的底层支持。对于中小型团队或个人开发者而言，采用这样一个框架，可以避免重复造轮子，快速搭建起具备专业水准的LLM应用原型，甚至直接用于生产环境。

2. 核心架构与设计哲学拆解

要真正用好llm-python，不能只停留在调用层面，理解其背后的设计哲学和核心架构至关重要。这能帮助你在遇到复杂需求时，知道如何正确地扩展和定制，而不是被框架限制住。

2.1 分层抽象：从底层连接到高层应用

llm-python的架构可以清晰地分为几个层次，这种分层设计是其灵活性的基础。

最底层是模型提供商适配层（Provider Adapters）。这一层负责与具体的LLM API（如OpenAI的ChatGPT、Anthropic的Claude、Google的Gemini，或是本地部署的Ollama、vLLM服务）进行通信。框架已经内置了多个主流提供商的适配器。每个适配器都实现了统一的接口，将不同提供商的API参数映射到框架内部的标准参数上。例如，无论底层是gpt-4还是claude-3-opus，你在框架中配置模型名称、温度（temperature）、最大令牌数（max_tokens）的方式都是一致的。这解决了多模型支持的核心痛点。

中间层是核心运行时（Core Runtime）。这一层包含了会话管理、消息历史记录、工具调用调度、流式响应处理等核心功能。Session对象是这里的关键，它维护了一次对话的完整上下文（即Message的历史记录）。当你调用一个Agent的run方法时，运行时引擎会负责：1. 从Session中获取历史消息；2. 将当前查询和工具定义（如果有）格式化为符合特定模型要求的提示（Prompt）；3. 调用底层的Provider Adapter；4. 解析模型的返回结果，特别是识别出其中的工具调用（Tool Call）请求；5. 如果需要，执行工具并生成新的消息，然后再次调用模型，直到模型返回最终的自然语言答案。这一整套复杂的流程被框架封装了起来，对开发者几乎是透明的。

最上层是应用构建块（Application Building Blocks）。这就是开发者直接交互的部分，主要是Agent和Tool。Agent是一个智能体的抽象，你可以把它理解为一个配备了特定工具、拥有特定系统指令（System Prompt）和对话风格的“角色”。Tool则是赋予Agent行动能力的扩展，一个Tool本质上是一个Python函数，加上一些元数据描述（名称、描述、参数JSON Schema）。框架负责将Tool的描述注入到给模型的提示中，并在模型请求调用时，安全地执行对应的Python函数。

这种分层设计的好处是显而易见的：底层模型的更换不会影响上层的业务逻辑；核心的会话、工具逻辑只需实现一次，便可复用；上层的Agent和Tool定义直观易懂，符合开发者的思维习惯。

2.2 面向消息的编程模型

与许多直接操作字符串提示的库不同，llm-python采用了严格的面向消息的编程模型。所有的交互都被建模为Message对象。一个Message通常包含role（角色，如user,assistant,system,tool）和content（内容）。

这种设计直接映射了现代Chat API（如OpenAI的ChatCompletion）的底层数据格式，使得框架能够高效、无损地与后端API交互。更重要的是，它强制开发者以结构化的方式思考对话流。例如，当模型决定调用一个工具时，它不会直接在回复文本中说“我要搜索”，而是会返回一个结构化的ToolCall对象。框架会将其转换为一个role为assistant但包含tool_calls的Message。接着，框架执行工具，并将执行结果封装为一个role为tool的Message，其content是工具执行的结果。最后，这个新的tool消息和之前的对话历史一起，被再次发送给模型，让模型基于工具结果生成最终回复。

这个过程如果手动实现会非常繁琐且容易出错。llm-python自动管理了这一切，你只需要定义好Tool，框架就能处理好工具调用的整个生命周期。这种“消息即状态”的模型，也使得会话的持久化、回放、调试变得非常容易，因为整个对话就是一系列Message对象的序列。

2.3 强调类型安全与开发体验

项目大量使用了Python的类型提示（Type Hints），这不仅使得代码在IDE中能有极佳的自动补全和错误检查体验，也通过Pydantic模型确保了数据在框架内部流转时的结构正确性。例如，当你定义一个Tool时，你需要用Pydantic的BaseModel来严格定义其输入参数的Schema。这保证了：

1. 模型收到的工具描述是清晰、格式正确的。
2. 在调用工具前，框架会先用Schema验证传入的参数，防止无效或恶意输入。
3. 开发者能清晰地知道每个工具需要什么参数，返回什么类型的数据。

这种对类型安全的重视，虽然增加了初期的一点点定义成本，但在构建复杂应用时，能极大减少运行时错误，提升代码的健壮性和可维护性。它反映了一种面向生产环境的严肃态度。

3. 从零开始：快速上手与核心概念实战

理论说了这么多，我们直接动手，通过构建一个简单的“天气查询助手”来感受一下llm-python的魅力。这个助手能理解用户关于天气的询问，并调用一个模拟的天气查询工具来回答问题。

3.1 环境搭建与安装

首先，确保你的Python版本在3.8以上。创建一个新的虚拟环境是一个好习惯。

# 创建并激活虚拟环境（以venv为例） python -m venv venv source venv/bin/activate # Linux/macOS # venv\Scripts\activate # Windows # 安装 llm-python 框架 pip install llm-python

由于llm-python是一个框架，它本身不绑定任何具体的模型提供商。你需要额外安装你计划使用的提供商SDK。例如，如果你使用OpenAI：

pip install openai

然后，你需要设置API密钥。最安全的方式是通过环境变量：

# 在终端中设置，或写入你的 .bashrc / .zshrc / .env 文件 export OPENAI_API_KEY='你的-api-key-here'

3.2 定义你的第一个工具（Tool）

工具是智能体能力的延伸。我们来定义一个模拟的天气查询工具。

from pydantic import BaseModel, Field from llm import Tool # 1. 定义工具输入参数的模型 class WeatherQueryInput(BaseModel): location: str = Field(description="城市名称，例如：北京、Shanghai") date: str = Field(default="today", description="查询日期，例如：today, tomorrow, 2024-05-20") # 2. 实现工具函数本身 def get_weather_info(location: str, date: str) -> str: """模拟的天气查询函数。在实际应用中，这里会调用真实的天气API。""" # 这里我们返回一个模拟的响应 weather_data = { "北京": {"today": "晴，15~25°C，微风", "tomorrow": "多云，18~28°C，东南风3级"}, "上海": {"today": "小雨，18~22°C，东风2级", "tomorrow": "阴，19~24°C，东风1级"}, "New York": {"today": "Partly cloudy, 10~18°C", "tomorrow": "Sunny, 12~20°C"}, } location_key = location # 简单的数据回退逻辑 if location not in weather_data: location_key = list(weather_data.keys())[0] # 默认返回第一个城市 forecast = weather_data[location_key].get(date, "暂无该日期预报") return f"{location}{date}的天气情况是：{forecast}" # 3. 使用Tool装饰器创建工具实例 # 装饰器将函数和输入模型绑定，并添加工具描述。 weather_tool = Tool( function=get_weather_info, input_model=WeatherQueryInput, description="根据城市和日期查询天气信息。" )

关键点解析：

• input_model必须是Pydantic的BaseModel子类。框架会利用它来生成供模型理解的JSON Schema。
• Field中的description至关重要，它是模型决定是否以及如何调用该工具的主要依据。描述应清晰、准确。
• 工具函数本身可以是任何可调用对象，它处理业务逻辑并返回一个字符串（或可序列化为字符串的对象）作为结果。

3.3 创建并运行你的第一个智能体（Agent）

有了工具，我们就可以创建一个能使用该工具的智能体了。

from llm import Agent, Session from llm.providers import OpenAIChat # 导入OpenAI提供商 # 1. 初始化模型提供商 # 这里使用OpenAI的gpt-3.5-turbo模型，你也可以换成 gpt-4, claude-3-haiku 等 provider = OpenAIChat(model="gpt-3.5-turbo") # 2. 创建智能体，并为其装配工具 agent = Agent( provider=provider, tools=[weather_tool], # 将我们定义的天气工具装配给Agent system_prompt="你是一个友好的天气查询助手。请根据用户的问题，调用合适的工具来获取天气信息，然后用清晰、友好的语言回答用户。如果用户询问的地点或日期不在知识范围内，请如实告知。", ) # 3. 创建一个会话（Session） session = Session() # 4. 运行智能体 query = "请问上海明天天气怎么样？" print(f"用户: {query}") response = agent.run(session=session, prompt=query) print(f"助手: {response.content}") # 5. 继续对话（会话保持了历史） follow_up = "那北京今天呢？" print(f"\n用户: {follow_up}") response2 = agent.run(session=session, prompt=follow_up) print(f"助手: {response2.content}")

运行这段代码，你会看到类似以下的输出：

用户: 请问上海明天天气怎么样？ 助手: 上海明天的天气情况是：阴，19~24°C，东风1级。 用户: 那北京今天呢？ 助手: 北京今天的天气情况是：晴，15~25°C，微风。

幕后发生了什么？

1. 当你第一次调用agent.run时，框架将system_prompt、会话历史（初始为空）和用户问题query组合，发送给GPT-3.5。
2. GPT-3.5“看到”了weather_tool的描述，判断出需要调用它，并生成了一个结构化的工具调用请求，指定location为“上海”，date为“tomorrow”。
3. llm-python框架捕获到这个请求，执行get_weather_info("上海", "tomorrow")函数。
4. 将函数返回的结果"上海tomorrow的天气情况是：阴，19~24°C，东风1级。"作为一条tool角色的消息，连同所有历史消息，再次发送给GPT-3.5。
5. GPT-3.5根据工具返回的结果，组织成最终的自然语言回复：“上海明天的天气情况是：阴，19~24°C，东风1级。”
6. 整个交互过程中的所有消息（用户、助手、工具）都被自动添加到了session对象中。
7. 当第二次询问“北京今天”时，session中已经包含了完整的历史，因此模型能理解“今天”指的是上下文中的日期，并正确调用工具。

注意：在实际项目中，system_prompt的设计是门艺术。清晰、具体的指令能极大提升智能体的表现。避免使用模糊的指令，如“尽力帮助用户”，而应使用“你是一个天气助手，只回答与天气相关的问题，对于其他问题，礼貌地表示无法回答。”

4. 进阶应用：构建复杂工作流与流式响应

掌握了基础用法后，我们可以探索更强大的功能，以满足真实场景中更复杂的需求。

4.1 多工具协同与函数调用策略

一个强大的智能体往往需要多个工具。例如，一个研究助手可能需要web_search、read_webpage、calculate等工具。llm-python支持为单个Agent装配多个工具，模型会根据问题自动选择调用一个或多个工具，甚至进行链式调用（使用一个工具的结果作为另一个工具的输入）。

# 假设我们已经定义了 search_web_tool 和 calculate_tool research_agent = Agent( provider=provider, tools=[search_web_tool, calculate_tool, weather_tool], # 装配多个工具 system_prompt="你是一个研究助手，可以联网搜索、计算和查询天气。请根据问题选择最合适的工具。", ) # 模型可能会先调用搜索工具，再基于搜索结果调用计算工具。

工具调用策略：你可以通过Agent的配置来影响模型调用工具的行为。例如，你可以设置tool_choice="auto"（默认，由模型决定）、tool_choice="none"（强制不调用工具）或tool_choice={"type": "function", "function": {"name": "specific_tool"}}（强制调用特定工具）。这在测试或构建确定性工作流时非常有用。

4.2 处理流式响应（Streaming）

对于需要长时间生成文本或希望实现打字机效果的应用，流式响应是必不可少的。llm-python对此提供了优雅的支持。

from llm import Session session = Session() agent = Agent(provider=provider) # 一个没有工具的简单聊天Agent query = "用一段话描述Python编程语言的优点。" print("助手: ", end="", flush=True) # 使用 `run_stream` 方法 for chunk in agent.run_stream(session=session, prompt=query): # chunk.content 是逐步生成的文本片段 print(chunk.content, end="", flush=True) print() # 换行

run_stream方法返回一个生成器，每次yield一个包含部分文本的MessageChunk对象。这允许你在模型生成内容的同时就将其展示给用户，极大地提升了交互体验。在处理流式响应时，你需要自己管理会话中消息的追加。通常，在所有chunk接收完毕后，将完整的回复作为一条assistant消息添加到session中。

4.3 会话管理与持久化

Session对象是对话记忆的核心。在实际应用中，你需要将会话保存下来（例如存入数据库或文件），以便在用户下次访问时恢复。

import json # 将会话保存为字典（可JSON序列化） session_state = session.model_dump() # 使用Pydantic的model_dump方法 with open("session_state.json", "w") as f: json.dump(session_state, f) # 从字典恢复会话 with open("session_state.json", "r") as f: session_state = json.load(f) restored_session = Session(**session_state) # 通过构造函数恢复

Session对象保存了所有的Message。你也可以实现自定义的存储后端，比如集成SQLAlchemy直接存入PostgreSQL，或者使用Redis实现分布式会话共享。

4.4 自定义模型提供商（Provider）

虽然框架内置了主流提供商，但如果你使用的是私有化部署的模型（如通过Ollama、vLLM或公司内部API），你可以轻松实现自己的Provider。

from llm.providers.base import BaseProvider from llm import Message import requests class MyCustomProvider(BaseProvider): def __init__(self, model: str, api_base: str): self.model = model self.api_base = api_base.rstrip('/') def create_completion(self, messages: list[Message], **kwargs) -> Message: # 1. 将框架的Message列表转换为你的API所需的格式 formatted_messages = [] for msg in messages: formatted_messages.append({"role": msg.role, "content": msg.content}) # 2. 构建请求负载 payload = { "model": self.model, "messages": formatted_messages, "stream": False, # ... 其他参数可以从 kwargs 中映射 } # 3. 调用你的API response = requests.post( f"{self.api_base}/v1/chat/completions", json=payload, headers={"Content-Type": "application/json"} ) response.raise_for_status() data = response.json() # 4. 将API响应转换回框架的Message对象 choice = data['choices'][0] return Message( role="assistant", content=choice['message']['content'] ) # 如果需要流式支持，还需要实现 create_completion_stream 方法

实现BaseProvider接口后，你就可以像使用OpenAI一样使用你的自定义提供商了：agent = Agent(provider=MyCustomProvider(...))。这种设计使得llm-python能够无缝接入任何符合类似ChatCompletion接口的LLM服务。

5. 生产环境部署考量与最佳实践

将基于llm-python开发的应用部署到生产环境，需要考虑以下几个关键方面。

5.1 错误处理与重试机制

网络请求和模型调用总有可能失败。必须为关键操作添加健壮的错误处理。

import tenacity from openai import APIError, RateLimitError @tenacity.retry( stop=tenacity.stop_after_attempt(3), # 最多重试3次 wait=tenacity.wait_exponential(multiplier=1, min=4, max=10), # 指数退避 retry=tenacity.retry_if_exception_type((APIError, RateLimitError, requests.exceptions.RequestException)), ) def robust_agent_run(agent, session, prompt): """一个带有重试机制的agent.run包装函数""" try: return agent.run(session=session, prompt=prompt) except RateLimitError as e: # 可以在这里添加更精细的限流处理，如切换到备用模型 print(f"速率限制触发，等待后重试。错误: {e}") raise except APIError as e: # 处理其他API错误，如上下文过长 if "context_length" in str(e).lower(): # 策略：移除会话中最老的一些消息 session.messages = session.messages[2:] # 简单示例，移除最早的一轮对话 print("上下文过长，已清理部分历史。") return robust_agent_run(agent, session, prompt) # 重试 else: raise

使用tenacity这样的重试库可以优雅地处理瞬时故障。对于上下文过长错误，需要设计更复杂的会话修剪策略，例如基于令牌数的修剪或总结式修剪。

5.2 性能优化与成本控制

LLM API调用通常是应用中最耗时的部分，也是成本的主要来源。

1. 缓存（Caching）：对于频繁出现的、结果确定的查询（例如，“Python是什么？”），可以使用缓存来避免重复调用模型。可以在Agent.run层面或自定义Provider层面实现缓存。

from functools import lru_cache import hashlib import json def get_cache_key(messages, model, **kwargs): """生成一个基于输入参数的唯一缓存键""" key_data = { "messages": [(m.role, m.content) for m in messages], "model": model, **kwargs } key_str = json.dumps(key_data, sort_keys=True) return hashlib.md5(key_str.encode()).hexdigest() # 在自定义Provider或代理中，先检查缓存，命中则直接返回，未命中则调用API并存储结果。

2. 异步（Async）支持：如果应用需要同时处理多个请求，或者需要在等待模型响应时处理其他任务，使用异步IO至关重要。llm-python的某些提供商（如OpenAIChat）可能提供了异步方法（如acreate_completion）。你需要确保你的整个调用链（如Web服务器）也是异步的。

3. 成本监控：记录每次调用的模型、令牌使用量（输入+输出）。大多数提供商SDK会在响应中返回usage信息。将这些数据收集到监控系统（如Prometheus）中，可以设置警报，防止意外的高成本。

5.3 安全性与输入输出过滤

将LLM应用开放给用户，安全是重中之重。

1. 提示注入（Prompt Injection）防护：用户输入可能包含试图覆盖system_prompt的恶意指令。虽然无法完全杜绝，但可以采取一些措施：

• 在system_prompt中明确强调角色和边界。
• 对用户输入进行基本的清理和检查。
• 在关键操作前，使用一个独立的“审查”LLM调用来判断用户请求是否安全。

2. 工具执行沙盒化：工具（Tool）能够执行任意Python代码，这是非常强大的，也是极其危险的。绝对不要允许用户直接定义或影响工具的执行。

• 工具函数应只包含必要的、经过严格审查的业务逻辑。
• 如果工具需要执行代码（如code_interpreter），必须在完全隔离的沙盒环境（如Docker容器、安全的子进程）中运行。
• 对工具函数的输入参数进行严格的Pydantic验证和业务逻辑验证。

3. 输出内容过滤：模型的输出可能包含不适当、偏见或有害的内容。必须在将内容返回给用户前进行过滤。可以结合关键词过滤列表和内容安全API（如果提供商支持）来实现。

5.4 可观测性与调试

当应用出现问题时，你需要有能力快速定位。

1. 结构化日志：记录每一次LLM调用的详细信息。

import structlog logger = structlog.get_logger() def logged_run(agent, session, prompt): start_time = time.time() logger.info("llm_call_start", prompt=prompt, session_id=session.id) try: response = agent.run(session=session, prompt=prompt) duration = time.time() - start_time logger.info("llm_call_success", response=response.content[:200], # 记录部分内容 duration=duration, usage=response.usage if hasattr(response, 'usage') else None) return response except Exception as e: logger.error("llm_call_failed", error=str(e), exc_info=True) raise

2. 会话追踪与回放：由于Session对象保存了完整的Message历史，你可以轻松地将整个对话序列存储下来。这对于复现用户问题、分析模型行为、优化system_prompt和工具设计具有不可估量的价值。可以考虑在数据库中为每个会话存储一个JSON格式的消息历史。

3. 中间步骤可视化：对于复杂的工具调用链，将模型“思考”和调用工具的过程可视化出来，是调试的利器。你可以在Agent执行过程中，记录下每个工具调用的请求和响应，并将其展示在管理界面上。

6. 常见问题排查与实战心得

在实际使用llm-python的过程中，你肯定会遇到一些坑。这里分享一些我踩过并总结出来的经验。

6.1 工具调用失败或不被识别

问题：你定义了一个工具，但模型似乎完全忽略它，从不调用。排查步骤：

1. 检查工具描述：这是最常见的原因。模型的function calling能力严重依赖清晰、准确的工具描述。确保Tool的description和输入参数Field的description都写得好。描述应该简明扼要地说明工具的功能和每个参数的意义。可以尝试用GPT-4来帮你优化工具描述。
2. 检查系统提示：system_prompt是否鼓励或要求模型使用工具？一个明确的指令如“请使用你拥有的工具来回答问题”有时是必要的。
3. 检查模型能力：确保你使用的模型支持函数调用（Function Calling）。gpt-3.5-turbo和gpt-4系列都支持，但一些更小或更老的模型可能不支持。
4. 启用调试日志：查看发送给模型的原始消息和接收到的响应。这能帮你确认工具定义是否被正确发送，以及模型是否返回了工具调用请求。

   # 一种简单的调试方式：打印Session中的消息 print(session.messages)

6.2 会话上下文（Token）超限

问题：随着对话轮次增加，出现“context length exceeded”错误。解决方案：

• 主动修剪：在agent.run之前，检查会话历史的大致令牌数（可以使用tiktoken库估算），如果超过阈值（如模型最大限制的80%），则移除最老的消息。llm-python的Session对象可以方便地对messages列表进行操作。
• 总结式修剪：当历史过长时，不是直接删除，而是调用一次模型，让它用一段简短的总结来替代之前的多轮对话，然后将这个总结作为一条新的system消息放入会话。这能保留更多上下文信息，但会增加一次API调用成本。
• 使用更大上下文窗口的模型：例如，从gpt-3.5-turbo-16k升级到gpt-4-32k或claude-3系列（支持200K上下文）。

6.3 流式响应中断或显示异常

问题：在使用run_stream时，响应中途停止，或前端显示出现乱码。排查步骤：

1. 网络稳定性：流式响应对网络稳定性要求更高。确保服务器到模型API之间的连接稳定。
2. 正确处理生成器：确保你的代码完整地迭代了run_stream返回的生成器，并处理了所有可能的异常。

   try: full_response = "" for chunk in agent.run_stream(...): # 处理chunk full_response += chunk.content yield chunk.content # 如果是WebSocket，可以这样流式推送给前端 except Exception as e: logger.error("Streaming interrupted", error=e) # 发送一个错误消息块或关闭流

3. 前端渲染：前端在接收流式数据时，需要正确拼接和处理分块。注意换行符和特殊字符的渲染。

6.4 多轮对话中智能体“遗忘”或行为不一致

问题：在长对话中，智能体似乎忘记了早期的指令或改变了行为风格。原因与解决：这通常是因为system_prompt的影响力随着用户和助手消息的增多而被“稀释”。模型在生成回复时，会更多地关注最近的几条消息。

• 强化系统提示：在system_prompt中使用更强烈、更具体的语言来定义角色和行为规范。
• 周期性重注入：一种高级技巧是，在对话进行到一定轮次后，主动在会话中插入一条role为system的“提醒消息”，重复或强调核心指令。但这需要谨慎设计，避免干扰正常的对话流。

6.5 项目依赖与版本冲突

问题：llm-python与项目中的其他库（如特定版本的pydantic、openai）发生冲突。建议：

• 使用虚拟环境：如前所述，这是Python项目管理的基本要求。
• 关注依赖声明：仔细查看llm-python项目的pyproject.toml或setup.py文件，了解其依赖版本范围。
• 使用Poetry或Pipenv：这些工具能更好地管理依赖树和解决版本冲突。
• 考虑容器化部署：使用Docker将应用及其所有依赖打包成一个镜像，可以彻底解决环境一致性问题。

llm-python作为一个活跃的开源项目，其API和功能也在不断演进。最可靠的信息来源始终是其官方GitHub仓库的README和源码。当遇到棘手问题时，去Issues里搜索或提交新的Issue，往往是最高效的解决途径。这个框架真正强大的地方在于它提供了一个坚实、可扩展的基座，让你能站在巨人的肩膀上，快速构建出想象中那些智能、交互式的LLM应用。