1. 项目概述一个面向未来的AI应用开发框架最近在GitHub上看到一个挺有意思的项目叫“Sargentech-AI/sargentech-ai”。光看这个名字你可能会觉得有点神秘或者猜测它是不是某个特定公司的内部工具。但点进去仔细研究后我发现它其实是一个定位相当清晰的AI应用开发框架。简单来说它想做的事情就是帮助开发者无论是个人还是团队能够更高效、更规范地构建和部署基于大语言模型LLM的应用程序。我自己在AI应用开发这条路上也摸索了几年从早期的简单脚本调用API到后来尝试构建复杂的多智能体系统中间踩过的坑不计其数。最头疼的问题往往不是模型本身而是如何把模型能力稳定、可靠地集成到业务流程里如何管理不同版本的提示词Prompt如何处理复杂的对话状态以及如何将整个应用打包、部署、监控。Sargentech-AI这个项目看起来就是瞄准了这些痛点试图提供一套“开箱即用”的解决方案。它不是一个单一的库更像是一个包含了最佳实践、工具链和脚手架的综合体目标是把AI应用开发从“手工作坊”模式推向“工业化”生产。这个框架适合谁呢我认为主要面向两类开发者。一类是AI应用开发的初学者或独立开发者他们可能对LLM的API调用很熟悉但对于如何构建一个结构清晰、易于维护的完整应用感到迷茫。Sargentech-AI提供的项目结构和约定能让他们快速上手避免在架构设计上走弯路。另一类是中大型团队的技术负责人或架构师他们需要确保团队内的AI项目代码风格统一、部署流程标准化、可观测性完善以提升协作效率和项目质量。这个框架提供了一套现成的“规矩”可以减少团队在工具选型和工程化上的重复争论与投入。2. 核心架构与设计哲学解析2.1 模块化与“关注点分离”思想深入查看Sargentech-AI的代码仓库和文档其核心设计哲学非常鲜明模块化和关注点分离。它没有试图创造一个无所不包的“巨无霸”框架而是将AI应用拆解成几个清晰、独立的层次每个层次负责特定的职责。这种设计让代码结构一目了然也极大地提升了可测试性和可维护性。通常一个典型的AI应用会包含以下几个核心部分LLM调用与抽象层负责与不同的模型提供商如OpenAI、Anthropic、本地部署模型进行交互统一接口处理认证、重试、流式输出等底层细节。提示词Prompt管理如何组织、版本化、测试和优化那些“驱动”模型的文本指令。这是AI应用的核心逻辑所在但也是最容易变得混乱的部分。对话与状态管理对于多轮对话应用需要管理对话历史、用户上下文、会话状态等。状态管理不当会导致对话逻辑错乱或信息丢失。工具Tools与函数调用让LLM能够执行具体操作如查询数据库、调用API、进行计算的关键。需要定义工具、安全地暴露给模型并处理执行结果。业务逻辑编排将以上组件组合起来实现具体的应用流程例如一个客服机器人、一个代码生成助手或一个数据分析管道。部署与运维如何将开发好的应用打包成服务如REST API、WebSocket服务并配置监控、日志、扩缩容等。Sargentech-AI的架构正是围绕这些关注点进行组织的。它为每个部分提供了明确的“位置”和“接口”。例如提示词可能被集中存放在一个prompts/目录下使用模板语言如Jinja2编写便于参数化和复用。工具函数会被定义在tools/目录中并通过装饰器或配置文件声明其元数据名称、描述、参数schema框架会自动将其封装并注入到LLM的上下文中。这种强制性的结构分离虽然一开始可能让人觉得有些约束但长期来看是保证项目在增长过程中不失控的关键。2.2 配置驱动与“约定优于配置”另一个重要的设计理念是配置驱动和约定优于配置。框架鼓励开发者将可变的参数——如模型类型、API密钥、温度参数、超时设置——从代码中剥离出来放入配置文件如YAML、JSON或环境变量中。这样做的好处显而易见不同环境开发、测试、生产可以使用不同的配置而无需修改代码敏感信息如API密钥不会硬编码在源码里安全性更高调整参数进行A/B测试也变得非常容易。“约定优于配置”则体现在项目结构的默认设定上。框架通常会预设好目录结构、命名规范、入口文件的位置等。只要遵循这些约定很多功能如自动加载工具、注册路由就能“零配置”生效。这减少了开发者需要做的决策降低了入门门槛。当然框架也保留了足够的灵活性允许开发者在必要时覆盖这些默认约定以满足特殊需求。注意采用“约定优于配置”的框架时初期务必花时间理解其默认约定。盲目修改目录结构或命名可能会导致框架的自动发现机制失效反而需要编写更多的配置代码来“纠正”得不偿失。最好的方式是先遵循约定快速搭建一个可运行的原型再根据实际需求进行定制。2.3 对生产环境的原生支持与许多实验性质的AI项目不同Sargentech-AI从设计之初就考虑到了生产部署的需求。这体现在几个方面健康检查与就绪探针集成了标准的健康检查端点如/health方便容器编排平台如Kubernetes判断服务状态。可观测性很可能内置或易于集成日志、指标Metrics和分布式追踪Tracing功能。能够记录每一次LLM调用的耗时、Token使用量、费用估算以及工具调用的成功与否这对于监控应用性能、优化成本和排查问题至关重要。错误处理与重试机制提供了健壮的异常处理层对于网络波动、API限流等临时性故障内置了可配置的重试和回退策略。部署友好项目结构易于容器化Docker并且可能提供了与常见云平台或服务器less环境集成的示例或工具。这种生产就绪的特性使得从原型验证到线上服务的跨越变得更加平滑减少了后期工程化改造的巨大成本。3. 核心组件深度拆解与实操3.1 提示词工程与管理实践在Sargentech-AI框架中提示词不再是一段段散落在代码各处的字符串而是被当作一等公民来管理。我们来看看它是如何实现的。1. 结构化存储与模板化框架通常会定义一个专门的目录比如app/prompts/里面按功能分类存放提示词文件。这些文件可能使用.j2、.txt或.yaml后缀。更重要的是它支持模板引擎。假设我们有一个客服场景的提示词原始版本可能是你是一个专业的客服助手。用户的问题是{{user_question}}。请根据以下知识库内容回答{{knowledge_base}}。回答要求专业、简洁。在Sargentech-AI中这个提示词会被保存为app/prompts/customer_service.j2。在代码中调用时我们只需传入上下文变量from sargentech_ai.prompt_manager import PromptManager prompt_manager PromptManager() prompt_template prompt_manager.get_template(customer_service) filled_prompt prompt_template.render( user_question我的订单为什么还没发货, knowledge_base标准物流时间为3-5个工作日您的订单于昨日下单目前处于打包状态。 )这种方式的好处是版本控制提示词的修改可以通过Git进行追踪和对比。A/B测试可以轻松创建customer_service_v2.j2在代码中动态选择不同版本的提示词进行效果对比。参数化清晰地将静态指令和动态变量分离避免在代码中进行复杂的字符串拼接。2. 提示词链与组合复杂的应用往往需要多个提示词协作。例如一个查询流程可能包含“查询理解”、“信息检索”、“答案生成”三个步骤每个步骤对应一个提示词。Sargentech-AI可能提供了构建这种“提示词链”的机制允许你将多个模板串联起来前一个模板的输出可以作为后一个模板的输入部分形成清晰的工作流。3. 实操心得提示词的版本与测试为提示词编写“单元测试”可以创建简单的测试脚本用固定的输入和预期的输出格式来验证提示词的有效性。虽然LLM的输出具有不确定性但可以测试其是否包含关键信息、是否符合指定格式如JSON。使用语义化版本对提示词文件进行重命名时如task_summarization_v1.1.0.j2并在变更日志中记录修改内容和原因例如“v1.1.0增加了输出格式的严格指令以减少模型自由发挥”。集中管理系统指令将模型的身份设定、行为规范等通用指令抽离成基础模板base_system_prompt.j2其他业务提示词通过继承或引用的方式组合它避免重复和 inconsistency。3.2 工具Tools与函数调用的规范化集成让LLM调用外部工具是增强其能力的关键。Sargentech-AI框架极大简化了这一过程。1. 工具的定义与注册在框架中你通常只需要用装饰器来定义一个普通的Python函数框架就会自动将其转化为LLM可识别的工具。from sargentech_ai.tools import tool tool def get_weather(city: str, date: str) - str: 获取指定城市在指定日期的天气预报。 Args: city: 城市名称例如“北京”。 date: 日期格式为YYYY-MM-DD。 Returns: 天气预报的文本描述。 # 这里实现实际的天气API调用逻辑 # ... return f{city}在{date}的天气是晴气温20-25度。 tool def query_order_status(order_id: str) - dict: 根据订单ID查询订单状态。 Args: order_id: 订单的唯一标识符。 Returns: 包含订单状态的字典例如 {{status: shipped, estimated_delivery: 2023-10-27}}。 # 调用内部订单系统API # ... return {status: shipped, estimated_delivery: 2023-10-27}框架的tool装饰器会解析函数的文档字符串Docstring和类型注解自动生成符合OpenAI Function Calling或类似规范的JSON Schema。这个Schema会告诉LLM这个工具叫什么、需要什么参数、每个参数是什么类型。2. 工具的自动发现与绑定在应用启动时框架会自动扫描某个目录如app/tools/下所有被tool装饰的函数并将它们注册到一个全局的工具列表中。当你创建一个AI助手Agent时你可以简单地指定“使用所有已注册的工具”或者按需选择一部分工具绑定到这个助手上。from sargentech_ai.agent import Agent # 创建一个助手并自动绑定所有已发现的工具 agent Agent( modelgpt-4, toolsall, # 框架会自动注入工具列表 system_prompt你是一个有帮助的助手可以查询天气和订单状态。 ) # 或者选择性地绑定工具 from app.tools.weather import get_weather from app.tools.order import query_order_status agent Agent( modelgpt-4, tools[get_weather, query_order_status], # 手动指定工具列表 system_prompt你是一个有帮助的助手可以查询天气和订单状态。 )3. 安全性与执行隔离这是框架处理得非常关键的一点。当LLM决定调用一个工具时框架不会直接执行原始函数。它会解析LLM返回的工具调用请求。进行参数验证检查参数类型、格式是否符合Schema。在安全上下文中执行工具函数可能在一个具有特定权限限制的执行器Executor中运行防止其对系统造成意外影响例如限制文件读写、网络访问。处理结果并返回给LLM将工具执行的结果或错误信息格式化重新放入对话上下文供LLM生成最终回复。这种机制将“决策”由LLM做出和“执行”由框架安全地控制分离开是构建可靠AI应用的基础。3.3 智能体Agent与工作流编排Sargentech-AI的核心抽象之一很可能是“智能体”Agent。一个智能体是一个具备特定目标、拥有记忆和工具使用能力的LLM实例。框架提供了高级API来创建和运行智能体。1. 基础智能体创建from sargentech_ai.agent import Agent from sargentech_ai.memory import ConversationBufferMemory # 创建一个带有对话记忆的智能体 memory ConversationBufferMemory() agent Agent( modelgpt-4, tools[get_weather, query_order_status], memorymemory, system_prompt你是客服助手小萨。, ) # 运行智能体 response agent.run(用户我订单12345的货到哪了) print(response) # 助手会自动调用query_order_status工具并生成回复。2. 多智能体协作与工作流对于复杂任务可能需要多个智能体分工协作。框架可能提供了定义工作流Workflow或管道Pipeline的能力。例如一个内容创作工作流可能包含“头脑风暴智能体”、“大纲生成智能体”、“内容撰写智能体”和“校对智能体”。# 可能的一种工作流配置示例 (假设框架支持YAML配置) workflow: name: content_creation steps: - agent: brainstormer input: {{user_topic}} output_to: outline - agent: outliner input: {{brainstormer.output}} output_to: writer - agent: writer input: {{outliner.output}} output_to: proofreader - agent: proofreader input: {{writer.output}} output: final_content在代码中你可以像运行一个函数一样运行这个工作流final_content workflow.run(user_topic如何学习Python编程)这种声明式的工作流定义使得复杂的多步AI任务变得清晰、可维护且易于复用。3. 记忆管理智能体的记忆是其连贯性的保证。Sargentech-AI可能提供了多种记忆后端ConversationBufferMemory简单地在内存中保存完整的对话历史。ConversationSummaryMemory随着对话进行自动总结之前的对话内容以节省Token并聚焦关键信息。VectorStoreMemory将对话片段转换为向量存入向量数据库如Chroma、Pinecone。当需要回忆时通过语义搜索检索相关历史片段。这对于长上下文和知识密集型应用非常有效。框架会帮你处理记忆的存储、加载和与提示词的集成你只需要根据场景选择合适的记忆类型。4. 项目初始化、开发与部署全流程4.1 环境搭建与项目初始化假设Sargentech-AI提供了类似CLI工具来初始化项目整个过程会非常顺畅。# 1. 安装框架CLI工具假设通过pip pip install sargentech-ai-cli # 2. 初始化一个新项目 sargentech-ai init my-ai-assistant # 3. 进入项目目录 cd my-ai-assistant # 4. 查看生成的项目结构 tree . # 预期会看到类似如下的结构 # . # ├── app # │ ├── __init__.py # │ ├── main.py # 应用主入口 # │ ├── agents/ # 智能体定义 # │ ├── tools/ # 工具函数 # │ ├── prompts/ # 提示词模板 # │ ├── workflows/ # 工作流定义 # │ └── config.py # 配置加载 # ├── tests/ # 测试目录 # ├── requirements.txt # Python依赖 # ├── .env.example # 环境变量示例 # ├── docker-compose.yml # Docker编排文件 # └── README.md接下来你需要配置环境变量。复制.env.example为.env并填入你的API密钥等敏感信息。cp .env.example .env # 编辑 .env 文件填入 OPENAI_API_KEY 等然后安装依赖pip install -r requirements.txt现在你可以运行示例应用来验证环境python app/main.py如果一切顺利你应该能看到一个简单的AI服务启动起来并监听某个端口如8000。4.2 开发你的第一个AI功能一个天气查询助手让我们从头开始在初始化好的项目中添加一个简单的天气查询助手。1. 创建工具在app/tools/目录下新建一个文件weather.py# app/tools/weather.py import os import requests from sargentech_ai.tools import tool # 这里我们使用一个模拟的天气API实际项目中请替换为真实的API WEATHER_API_URL https://api.weatherapi.com/v1/current.json WEATHER_API_KEY os.getenv(WEATHER_API_KEY) # 从环境变量读取密钥 tool def get_current_weather(location: str) - str: 获取指定城市的当前天气情况。 Args: location: 城市名称例如“London”或“北京”。 Returns: 当前天气的简要描述字符串。如果查询失败返回错误信息。 if not WEATHER_API_KEY: return 天气服务未配置API密钥。 try: params { key: WEATHER_API_KEY, q: location, aqi: no } response requests.get(WEATHER_API_URL, paramsparams, timeout10) response.raise_for_status() data response.json() city data[location][name] condition data[current][condition][text] temp_c data[current][temp_c] humidity data[current][humidity] return f{city}当前天气{condition}气温{temp_c}摄氏度湿度{humidity}%。 except requests.exceptions.RequestException as e: return f查询天气时出错{str(e)} except KeyError: return 无法解析天气API的返回数据。2. 创建提示词在app/prompts/目录下新建文件weather_assistant.j2你是一个友好的天气助手。你的名字叫“小天”。 你的任务是帮助用户查询他们关心城市的当前天气。 请根据工具返回的天气信息用清晰、友好且带有一点趣味性的语言回答用户。 如果工具返回错误信息请向用户礼貌地说明情况并建议他们稍后再试或检查城市名称。 当前对话历史 {{ history }} 用户问题{{ input }} 请开始你的回答3. 创建智能体在app/agents/目录下新建文件weather_agent.py# app/agents/weather_agent.py from sargentech_ai.agent import Agent from sargentech_ai.memory import ConversationBufferMemory from app.tools.weather import get_current_weather from app.prompts import load_prompt class WeatherAgent: def __init__(self, model: str gpt-3.5-turbo): self.memory ConversationBufferMemory() self.prompt_template load_prompt(weather_assistant) self.agent Agent( modelmodel, tools[get_current_weather], memoryself.memory, # system_prompt 可以通过prompt模板动态生成 system_promptself._get_system_prompt(), ) def _get_system_prompt(self): # 这里可以组合一些静态的系统指令 return 你是一个专注于天气查询的助手。必须使用提供的工具来获取实时天气数据严禁编造信息。 def chat(self, user_input: str) - str: # 渲染完整的提示词包含历史记录和当前输入 full_prompt self.prompt_template.render( historyself.memory.load_memory_variables({})[history], inputuser_input ) # 运行智能体。框架会处理工具调用、记忆更新等所有细节。 response self.agent.run(full_prompt) return response4. 集成到主应用修改app/main.py添加一个API端点# app/main.py (部分代码) from fastapi import FastAPI, HTTPException # 假设框架基于FastAPI from app.agents.weather_agent import WeatherAgent app FastAPI(titleMy AI Assistant) weather_agent WeatherAgent() app.post(/api/weather/chat) async def weather_chat(request: dict): 用户与天气助手对话。 请求体: {message: 用户消息} user_message request.get(message) if not user_message: raise HTTPException(status_code400, detailMessage is required) try: response weather_agent.chat(user_message) return {response: response} except Exception as e: raise HTTPException(status_code500, detailfInternal server error: {str(e)})现在启动应用后你就可以通过向http://localhost:8000/api/weather/chat发送POST请求来和你的天气助手对话了。4.3 配置管理与生产部署1. 多环境配置框架的配置通常通过app/config.py或类似文件加载支持根据环境变量如ENVIRONMENTproduction加载不同的配置文件。# app/config.py import os from pydantic_settings import BaseSettings class Settings(BaseSettings): # 基础配置 environment: str os.getenv(ENVIRONMENT, development) log_level: str INFO # AI模型配置 openai_api_key: str os.getenv(OPENAI_API_KEY) default_model: str gpt-3.5-turbo # 工具相关配置 weather_api_key: str os.getenv(WEATHER_API_KEY) # 服务器配置 host: str 0.0.0.0 port: int 8000 class Config: env_file .env # 根据环境加载不同配置的逻辑可以在这里实现 settings Settings()2. Docker化部署项目根目录的Dockerfile和docker-compose.yml使得部署变得简单。# Dockerfile FROM python:3.11-slim WORKDIR /app # 复制依赖文件并安装 COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt # 复制应用代码 COPY app/ ./app/ COPY .env . # 注意生产环境通常通过 secrets 管理环境变量而非直接复制 .env 文件 # 暴露端口 EXPOSE 8000 # 启动命令 CMD [uvicorn, app.main:app, --host, 0.0.0.0, --port, 8000]使用Docker Compose可以方便地定义服务依赖比如如果需要连接数据库或Redis作为记忆存储# docker-compose.yml version: 3.8 services: ai-assistant: build: . ports: - 8000:8000 environment: - ENVIRONMENTproduction - OPENAI_API_KEY${OPENAI_API_KEY} - WEATHER_API_KEY${WEATHER_API_KEY} # 如果使用Redis记忆后端 depends_on: - redis restart: unless-stopped redis: image: redis:7-alpine ports: - 6379:6379 volumes: - redis_data:/data volumes: redis_data:3. 监控与日志生产部署后监控至关重要。框架可能集成了OpenTelemetry等标准或者至少提供了结构化的日志输出。你需要确保日志聚合将应用日志收集到ELK Stack、Loki或云服务商的日志服务中。指标收集监控API调用延迟、Token消耗、工具调用成功率、错误率等关键指标。可以使用Prometheus Grafana的组合。健康检查确保配置了/health端点并被你的负载均衡器或K8s探针正确使用。5. 常见问题、性能优化与避坑指南5.1 开发与调试阶段常见问题1. 工具函数未被识别或调用症状智能体在应该调用工具时没有调用或者报错说工具不存在。排查步骤检查装饰器确保工具函数正确使用了tool装饰器或框架规定的其他装饰器。检查导入确保定义了工具的模块被正确导入。在框架的入口文件或某个初始化脚本中可能需要显式导入工具模块例如import app.tools.weather以便框架的自动发现机制能扫描到它。有些框架通过扫描目录自动加载需要确认工具文件所在的目录在扫描路径内。检查函数签名和文档LLM依赖函数的文档字符串和类型注解来理解工具。确保文档字符串清晰描述了工具的功能和参数并且参数有明确的类型提示如str,int,List[str]。查看日志启用框架的调试日志查看启动时是否成功注册了工具。2. 提示词渲染错误或变量未定义症状应用报模板渲染错误或者生成的提示词中{{variable}}没有被替换。排查步骤检查模板语法确保使用的是框架支持的模板引擎语法如Jinja2。常见的错误是用了错误的括号或过滤器。检查传入的上下文变量在调用template.render()时确保传入的字典包含了模板中引用的所有变量名。变量名拼写需完全一致。检查模板文件路径和加载使用框架提供的load_prompt函数时确认传入的名称与模板文件名不含后缀匹配且文件位于正确的prompts/目录下。3. 智能体陷入循环或输出无关内容症状AI助手反复说同一句话或者回答与工具和指令完全无关的内容。解决方案强化系统指令在system_prompt中更明确地规定助手的角色、职责和限制。例如“你必须使用提供的工具来回答问题如果工具无法提供信息请明确告知用户你不知道切勿编造信息。”调整温度Temperature参数降低温度值如从0.7降到0.2可以减少输出的随机性使其更专注于遵循指令。检查记忆如果使用了ConversationBufferMemory过长的历史可能会干扰当前指令。考虑使用ConversationSummaryMemory或增加一个“清理记忆”的机制。设计更具体的工具描述工具的函数名和文档字符串要极其清晰、具体避免歧义让LLM能准确理解何时该调用它。5.2 性能优化与成本控制1. 减少Token消耗Token消耗直接关联成本与响应速度。优化提示词删除提示词中不必要的废话使用更简洁的指令。对系统指令进行压缩实验在保证效果的前提下力求最短。使用更高效的记忆方式对于长对话避免使用ConversationBufferMemory存储全部历史。优先使用ConversationSummaryMemory或VectorStoreMemory它们只传递摘要或相关片段能显著减少上下文长度。选择合适模型在非关键或简单任务上使用更小、更快的模型如gpt-3.5-turbo而非gpt-4。可以在配置中根据任务路由到不同模型。实现缓存层对于相同或相似的查询例如过去一小时内对同一城市的天气查询可以将LLM的回复或工具调用结果缓存起来使用Redis或内存缓存直接返回缓存结果避免重复调用。2. 提升响应速度并行工具调用如果智能体需要调用多个彼此独立的工具查看框架是否支持并行调用。如果支持可以显著减少等待时间。流式输出对于文本生成类任务确保启用流式响应Streaming让用户能尽快看到首个Token提升体验。异步处理确保你的工具函数和框架调用是异步的使用async/await避免阻塞主线程尤其是在I/O密集型的工具操作如网络请求、数据库查询中。3. 设置合理的超时与重试网络和API调用总是不稳定的。为LLM调用设置超时在框架配置中为向模型提供商发起的请求设置一个合理的超时时间如30秒避免因网络问题导致请求长时间挂起。为工具调用设置超时每个工具函数也应有个体化的超时设置防止某个缓慢的工具拖垮整个请求。配置指数退避重试对于可重试的错误如网络超时、API速率限制429错误配置重试逻辑并采用指数退避策略避免加重对方服务器负担。5.3 生产环境稳定性保障1. 实施速率限制为你的AI服务API添加速率限制防止被恶意用户或错误循环刷爆导致高昂的API费用和服务不可用。可以在API网关层面如Nginx或应用层使用像slowapi这样的库实现。2. 全面的错误处理与降级优雅降级当核心LLM服务或关键工具不可用时应用应有一个降级方案。例如返回一个预定义的友好错误消息或者切换到一个备份的、能力较弱的模型。用户友好的错误信息不要将后端详细的异常信息直接暴露给最终用户。记录详细的错误日志供排查但给用户返回通用、友好的提示。事务与状态回滚对于涉及多步骤、多工具调用的复杂工作流要考虑部分失败的情况。框架最好能支持某种形式的事务语义或者你需要自己设计补偿机制在失败时清理或回滚已执行的操作。3. 安全考量输入验证与清理对所有用户输入进行严格的验证和清理防止提示词注入攻击。避免将未经处理的用户输入直接拼接到提示词模板中。工具执行沙箱对于执行高风险操作的工具如文件操作、系统命令确保它们在受限制的沙箱环境中运行。访问控制如果你的AI服务提供不同的能力给不同用户需要在应用层实现认证和授权控制哪些用户可以访问哪些工具或工作流。4. 测试策略AI应用的测试比传统软件更复杂因为输出具有不确定性。单元测试工具函数像测试普通函数一样测试你的工具确保其逻辑正确。集成测试智能体针对固定的输入测试智能体的整体输出。由于LLM输出的非确定性可以测试输出的“关键元素”是否存在例如对于天气查询回复中应包含城市名和温度或者使用语义相似度来判断。端到端E2E测试工作流模拟真实用户场景测试完整的工作流。可以使用“金标准”答案进行对比或设置可接受的输出范围。持续监控与评估在生产环境持续收集用户反馈和交互数据定期评估智能体的表现并以此作为优化提示词和流程的依据。