1. 项目概述从模型到系统的关键跨越最近在整理Happy-LLM的学习笔记发现一个非常有意思的现象很多朋友在入门大语言模型时会把绝大部分精力都花在模型本身——比如怎么调用API、怎么微调一个7B的模型、怎么用LangChain搭一个简单的问答链。这当然没错模型是地基。但当你真正想用LLM去做点实际的事情比如开发一个能自动处理工单的客服助手或者一个能根据市场报告自动生成投资建议的分析工具时光有一个“聪明”的模型是远远不够的。你会发现模型回答时好时坏任务一复杂它就“掉链子”没有一套机制去衡量和约束它的行为项目根本推不下去。这正是“Happy-LLM 学习笔记 10”想要探讨的核心评测Evaluation和智能体Agent。在我看来这是LLM从实验室里的“玩具模型”走向生产环境“可靠系统”的两大基石。评测解决的是“我们怎么知道它行不行”的问题是质量保障体系而Agent解决的是“怎么让它自动完成复杂任务”的问题是能力扩展框架。两者结合才能让LLM从一个被动的、单次问答的模型转变为一个主动的、可规划、可执行、可评估的智能系统。我自己的体会是跳过评测直接搞Agent开发就像蒙着眼睛造汽车车子可能能动但你不知道它什么时候会撞墙更不知道哪个部件出了问题。而只做评测不涉及Agent又像是只做汽车零件的质检报告却从不考虑如何把这些零件组装成一辆能跑的车。这一篇笔记我就结合自己的踩坑经验把这两块内容串起来聊聊如何搭建一个健壮的LLM应用系统。2. 核心需求解析为什么评测和Agent缺一不可在深入技术细节之前我们必须先想清楚在一个真实的LLM应用项目中我们到底面临哪些挑战为什么评测和Agent会成为刚需2.1 模型的不确定性与评测的必然性LLM的本质是一个概率模型它的输出具有不确定性。同一个问题在不同时间、不同参数下可能得到完全不同的答案。对于简单的创意写作这种不确定性可能是优点但对于企业级的、要求结果一致可靠的应用这就是灾难。我们至少需要从以下几个维度来评估和约束它事实准确性Factuality模型会不会胡编乱造幻觉引用的数据、日期、名称是否正确这是很多知识密集型应用如客服、法律咨询的生死线。指令遵循Instruction Following你让它“用JSON格式输出”它是不是真的输出严格合规的JSON你让它“只回答是或否”它有没有加上多余的解释这决定了LLM作为“执行者”的可靠度。安全性Safety与合规性模型是否会产生有害、偏见或不符合规定的输出这在金融、医疗、内容审核等领域至关重要。性能与成本Performance Cost响应的速度如何消耗的Token数量是多少这直接关系到用户体验和运营成本。如果没有一套系统化的评测方法我们只能靠人工抽查效率低下且覆盖面有限。当模型升级、提示词调整或知识库更新时我们无法快速、量化地评估影响每一次变更都像是在“赌运气”。2.2 复杂任务与Agent的必然性大多数有价值的商业问题都不是一次问答能解决的。它们通常是多步骤的、需要调用外部工具或数据的、并且可能根据中间结果动态调整的。例如场景一用户说“帮我分析一下上周A公司的股价波动并总结三份最新研报的观点最后给我一个买入、持有或卖出的建议。” 这需要1调用金融数据API获取股价2搜索或读取研报文档3综合分析并给出建议。场景二用户上传一张产品故障图说“告诉我可能的原因和解决步骤。” 这需要1调用视觉模型识别图片内容2根据识别结果查询知识库3组织排查步骤。传统的、线性的Prompt工程无法优雅地处理这类问题。你需要一个能自主规划Planning、调用工具Tool Use、记忆历史Memory并根据反馈调整ReAct的架构。这就是智能体Agent的核心价值。它让LLM从一个“答题者”变成了一个“项目经理”或“调度中心”能够协调各种资源工具、数据、其他模型来完成一个宏大目标。因此评测是Agent能稳定工作的前提Agent是LLM价值最大化的载体。下面我们就分别拆解这两部分。3. 构建LLM评测体系从单点测试到持续集成评测不是跑几个样例问题看看答案那么简单。一个完整的评测体系应该像软件工程的CI/CD持续集成/持续部署管道一样自动化、可重复、覆盖全面。3.1 评测的四个层次与核心指标我把LLM评测分为四个由浅入深的层次每一层关注的指标都不同。第一层基础能力评测Benchmark这通常是学术界和模型厂商做的用于横向对比不同模型的“智商”。常见的数据集包括MMLU涵盖57个学科的多选题测试模型的世界知识和问题解决能力。GSM8K小学数学应用题测试模型的逐步推理能力。HumanEval或MBPP代码生成任务测试模型编写Python代码的能力。TruthfulQA测试模型在对抗性提示下产生真实陈述的能力对抗幻觉。注意对于应用开发者这些基准分数有参考价值但绝不能直接等同于你的业务表现。一个在MMLU上得分很高的模型可能在你的特定领域术语上表现糟糕。第二层任务导向评测Task-Specific Evaluation这是应用开发的核心。你需要为你的具体场景设计评测集。例如客服场景设计100个典型用户问题评估回答的相关性Relevance、信息完整性Informativeness和友好度Friendliness。代码生成场景设计50个函数需求评估生成代码的功能正确性通过单元测试的比例、代码风格和安全性有无漏洞。这里的关键是自动化。人工评估100个回答是痛苦的但我们可以设计自动化的评估器Evaluator基于规则的评估器例如检查输出是否包含特定关键词、是否符合指定的JSON Schema。基于模型的评估器LLM-as-a-Judge这是目前的主流。用另一个通常更强的LLM如GPT-4作为裁判根据你定义的评分标准Rubric对输出进行打分。例如让GPT-4根据“是否准确回答了问题”、“是否包含多余信息”、“语气是否专业”等维度在1-5分之间评分。第三层系统集成评测Integration End-to-End Test当LLM作为系统的一部分如RAG系统、Agent系统时需要评测整个流水线。RAG系统评测不能只看最终答案还要看检索相关性Retrieval Relevance——系统检索到的文档块是否真的包含了答案以及答案依据性Answer Groundedness——最终答案是否严格基于检索到的文档而非模型自己的“脑补”Agent系统评测需要评测任务完成率Task Success Rate——给定100个任务有多少个被成功完成以及平均步骤数Avg. Steps和工具调用准确率——Agent是否高效、正确地使用了工具第四层生产环境监控Production Monitoring系统上线后评测不能停止。需要实时监控输入/输出分布用户的问题是否出现了新的、未预料到的类型模型的输出长度、Token消耗是否有异常波动用户反馈设立“点赞/点踩”机制收集直接的用户信号。业务指标关联如果是客服机器人监控“问题解决率”和“人工转接率”如果是写作助手监控“内容采纳率”。3.2 实操搭建一个简单的自动化评测流水线理论说再多不如动手。这里我分享一个用Python和开源工具搭建简易评测流水线的思路你可以基于此扩展。步骤1定义评测数据集创建一个JSON文件eval_dataset.json里面包含你的测试用例。[ { id: 1, input: 用Python写一个函数计算斐波那契数列的第n项。, expected_tools: [code_interpreter], metadata: {category: code_generation, difficulty: easy} }, { id: 2, input: 截至2023年底OpenAI的主要大模型产品有哪些, expected_answer_contains: [GPT-4, DALL-E, Whisper], metadata: {category: knowledge, difficulty: medium} } ]步骤2构建被评测系统这里我们的系统可以是一个简单的LangChain Chain也可以是你复杂的Agent。我们定义一个统一的调用接口。# system_under_test.py from langchain.chat_models import ChatOpenAI from langchain.schema import HumanMessage import json class MyLLMSystem: def __init__(self, model_namegpt-3.5-turbo): self.llm ChatOpenAI(modelmodel_name, temperature0) def run(self, user_input: str) - dict: 运行系统返回包含输出和可能元数据如使用的工具的字典 # 这里可以是复杂的Agent逻辑这里简化为直接调用LLM response self.llm([HumanMessage(contentuser_input)]) return { output: response.content, metadata: {tokens_used: 100} # 示例元数据 }步骤3实现自动化评估器我们实现一个基于规则和一个基于LLM的评估器。# evaluators.py import re from langchain.chat_models import ChatOpenAI from langchain.schema import SystemMessage, HumanMessage class RuleBasedEvaluator: staticmethod def evaluate_code_generation(test_case, system_output): 简单规则检查输出是否包含def fibonacci score 1 if def fibonacci in system_output[output].lower() else 0 return {score: score, reason: Contains function definition} staticmethod def evaluate_knowledge(test_case, system_output): 检查输出是否包含预期关键词 expected_keywords test_case.get(expected_answer_contains, []) found [kw for kw in expected_keywords if kw in system_output[output]] score len(found) / len(expected_keywords) if expected_keywords else 1 return {score: score, reason: fFound keywords: {found}} class LLMEvaluator: def __init__(self, judge_modelgpt-4): self.judge_llm ChatOpenAI(modeljudge_model, temperature0) def evaluate_helpfulness(self, test_case, system_output): prompt f 你是一个评分员。请根据以下标准对AI助手的回答进行评分1-5分 - 5分完全、准确地回答了问题信息丰富且有用。 - 3分部分回答了问题但可能不完整或有轻微不准确。 - 1分没有回答问题或答案完全错误。 用户问题{test_case[input]} AI助手回答{system_output[output]} 请只输出一个JSON对象包含score整数和reason字符串简要说明理由两个字段。 response self.judge_llm([HumanMessage(contentprompt)]) try: return json.loads(response.content) except: return {score: 0, reason: Failed to parse judge output}步骤4运行评测并生成报告编写一个主脚本串联所有步骤。# run_evaluation.py import json from system_under_test import MyLLMSystem from evaluators import RuleBasedEvaluator, LLMEvaluator def main(): # 1. 加载数据 with open(eval_dataset.json, r) as f: test_cases json.load(f) # 2. 初始化系统和评估器 system MyLLMSystem() rule_eval RuleBasedEvaluator() llm_eval LLMEvaluator() results [] # 3. 遍历测试用例 for case in test_cases: # 运行系统 output system.run(case[input]) # 根据类别选择评估器 eval_result {} if case[metadata][category] code_generation: eval_result rule_eval.evaluate_code_generation(case, output) elif case[metadata][category] knowledge: # 可以组合多个评估器 rule_result rule_eval.evaluate_knowledge(case, output) llm_result llm_eval.evaluate_helpfulness(case, output) eval_result { rule_score: rule_result[score], llm_score: llm_result[score], final_score: (rule_result[score] llm_result[score]) / 2 } # 记录结果 results.append({ id: case[id], input: case[input], system_output: output, evaluation: eval_result }) # 4. 计算总体指标并输出报告 total_cases len(results) avg_score sum(r[evaluation].get(final_score, r[evaluation].get(score, 0)) for r in results) / total_cases report { summary: { total_cases: total_cases, average_score: round(avg_score, 3) }, detailed_results: results } with open(evaluation_report.json, w) as f: json.dump(report, f, indent2, ensure_asciiFalse) print(f评测完成平均分{avg_score:.2f}) if __name__ __main__: main()这个流水线虽然简单但具备了核心骨架定义数据集、运行系统、自动化评估、生成报告。你可以将其集成到GitHub Actions或Jenkins中每次代码更新或模型切换后自动运行确保核心功能不被破坏。实操心得在构建评测集时一定要包含“边缘案例”和“对抗性示例”。例如对于客服机器人不仅要问“怎么退货”还要问一些模糊的、带有错误前提的、或者试图诱导出有害信息的问题。这样才能真正测试系统的鲁棒性。4. 智能体Agent架构深度解析从理论到实现评测体系保证了我们“不跑偏”而Agent则是让我们“跑得远”的引擎。一个典型的Agent架构包含以下几个核心组件理解它们是如何协同工作的至关重要。4.1 Agent的核心循环感知-规划-执行-反思现代LLM Agent的核心思想通常遵循ReActReason Act范式或更复杂的Plan-and-Execute架构。我们可以将其理解为一个循环感知Perception接收用户输入和来自环境的观察如上一步工具执行的结果。规划PlanningLLM作为“大脑”分析当前状态和目标决定下一步该做什么。这可能是一个宏大的计划“先搜索再分析最后总结”也可能只是一个简单的下一步动作“调用计算器工具”。执行Execution根据规划调用相应的工具如搜索引擎、代码解释器、数据库查询API并获取结果。反思ReflectionLLM评估执行结果是否解决了问题或者是否出现了错误。如果没有则重新规划或调整策略。这个循环会一直进行直到任务完成或达到最大步数限制。4.2 关键组件拆解与工具链选型1. 规划器Planner规划器是Agent的“战略部”。简单的Agent可能将规划和下一步动作生成合二为一。复杂的Agent则需要显式的规划器。思维链Chain-of-Thought, CoT让LLM在输出最终动作前先输出其推理过程。这能显著提升规划质量。任务分解Task Decomposition对于复杂任务规划器首先将其拆解为一系列子任务。例如LangChain的PlanAndExecute代理就采用这种模式。外部规划器使用专门的、更轻量或更可控的模型来做规划而不是用主LLM以节省成本或提高确定性。2. 工具Tools工具是Agent的“手和脚”。LLM本身不擅长计算、搜索最新信息或操作特定软件工具扩展了它的能力边界。一个工具通常包含名称nameLLM用来指代它的标识。描述description清晰、简洁地说明这个工具是做什么的。这里的描述至关重要LLM完全依赖描述来决定是否以及如何调用它。描述应包含输入参数和预期输出。执行函数func实际的代码逻辑。工具选型实践内置通用工具很多框架如LangChain提供了开箱即用的工具如GoogleSearchRun、WikipediaQueryRun、PythonREPLTool代码执行。对于快速原型非常方便。自定义工具这是Agent价值所在。你可以将内部API、数据库、业务系统封装成工具。from langchain.tools import BaseTool from pydantic import BaseModel, Field import requests class GetWeatherInput(BaseModel): city: str Field(descriptionThe city name, e.g., Beijing) class WeatherTool(BaseTool): name get_weather description Get the current weather for a specified city. args_schema GetWeatherInput def _run(self, city: str): # 这里调用真实的气象API此处为示例 # response requests.get(fhttps://api.weather.com/v1/{city}) # return response.json() return fThe weather in {city} is sunny, 25°C. def _arun(self, city: str): raise NotImplementedError(Async not supported)工具包Toolkits将相关工具分组如SQLDatabaseToolkit包含查询、表列表等多个操作数据库的工具。3. 记忆Memory记忆是Agent的“经验库”使其在对话或长任务中保持连贯性。短期记忆Conversation Buffer保存最近的对话历史。简单但有效缺点是上下文长度有限。长期记忆Vector Store将历史对话中的重要信息如用户偏好、任务关键事实提取并存储到向量数据库中需要时可以检索。这突破了上下文窗口的限制。摘要记忆Conversation Summary随着对话进行不断将过长的历史总结成一段摘要既保留了关键信息又节省了Token。4. 执行器Executor执行器是循环的“调度中心”。它负责管理整个流程调用规划器/LLM获取下一步动作解析动作如Tool: Calculator, Args: 35调用对应工具将结果返回给LLM进行下一步决策并处理错误如工具调用失败、解析错误。4.3 主流框架对比与选择目前社区有多种Agent框架各有侧重框架核心特点适用场景学习曲线LangChain生态最丰富工具、链、记忆等组件齐全文档详细。Agent是其中一部分。快速构建包含RAG、Agent的复杂应用研究和原型开发。中等概念较多。LangGraphLangChain团队出品专注于用图Graph来建模复杂、有状态的Agent工作流。支持循环、分支、并行。需要精确控制执行流程的复杂Agent如客服、游戏NPC。较高需要图思维。AutoGen微软出品支持多Agent对话和协作。可以定义不同角色程序员、产品经理的Agent让它们通过对话解决问题。需要多个专业Agent协作的场景如软件设计、复杂问题求解。中等偏高。CrewAI受AutoGen启发但更强调“角色”和“任务”的抽象。管理Agent就像管理一个团队有经理、员工分配任务。面向业务流程自动化模拟企业内团队协作。中等。Semantic Kernel微软出品深度集成.NET生态强调“插件”Plugins和“规划”Planner。.NET技术栈团队构建企业级Copilot应用。中等对.NET开发者友好。选择建议如果你是初学者从LangChain开始是最稳妥的它的社区和资料最丰富。当你需要构建非常复杂、有严格状态转移的工作流时再深入研究LangGraph。如果你的场景天然是多个专家协作AutoGen或CrewAI值得一试。5. 实战构建一个能联网搜索和数据分析的智能体现在我们结合评测和Agent的知识来实战构建一个相对复杂的智能体。这个Agent的目标是回答需要最新信息和简单数据分析的复杂问题。例如“对比一下特斯拉和比亚迪最近一个月的股价走势并分析可能的原因。”这个任务需要1获取实时股价数据2搜索最新的相关新闻3进行对比分析。我们将使用LangChain来构建。5.1 环境准备与工具定义首先安装必要的库并定义工具。我们需要两个核心工具金融数据获取和网络搜索。# 安装pip install langchain-openai langchain-community pandas yfinance duckduckgo-search import os from langchain_openai import ChatOpenAI from langchain.agents import AgentExecutor, create_openai_tools_agent from langchain_core.prompts import ChatPromptTemplate, MessagesPlaceholder from langchain_community.tools import DuckDuckGoSearchRun from langchain.tools import Tool import yfinance as yf import pandas as pd # 1. 定义自定义工具获取股票数据 def get_stock_price(symbol: str) - str: 获取指定股票代码最近一段时间的价格数据。 try: stock yf.Ticker(symbol) # 获取最近30天的历史数据 hist stock.history(period1mo) if hist.empty: return fNo data found for symbol {symbol}. # 返回一个简化的摘要 latest_close hist[Close].iloc[-1] month_ago_close hist[Close].iloc[0] change_pct (latest_close - month_ago_close) / month_ago_close * 100 return ( fStock {symbol}:\n f- Latest Close Price: ${latest_close:.2f}\n f- Price 1 month ago: ${month_ago_close:.2f}\n f- Change: {change_pct:.2f}%\n f- Data from {hist.index[0].date()} to {hist.index[-1].date()} ) except Exception as e: return fError fetching data for {symbol}: {str(e)} # 将函数包装成LangChain Tool stock_tool Tool( nameget_stock_price, funcget_stock_price, descriptionUseful for fetching recent stock price data. Input should be a valid stock ticker symbol, e.g., TSLA for Tesla or BYDDF for比亚迪 (注意yfinance可能需用国际代码). ) # 2. 使用社区提供的网络搜索工具 search_tool DuckDuckGoSearchRun(nameweb_search) # 3. 定义计算器工具备用用于简单计算 from langchain.tools import tool tool def calculator(expression: str) - str: Perform a simple arithmetic calculation. Input should be a string like 3 5 or (10 - 2) * 4. try: # 警告使用eval有安全风险仅用于演示。生产环境应用ast.literal_eval或安全库。 result eval(expression) return fThe result of {expression} is {result}. except Exception as e: return fError calculating {expression}: {str(e)}5.2 构建Agent提示词与执行器提示词是Agent的“宪法”它定义了Agent的角色、能力和行为规范。一个好的提示词能极大提升Agent的可靠性。# 4. 设置LLM llm ChatOpenAI(modelgpt-3.5-turbo, temperature0) # 对于Agenttemperature通常设低以保证稳定性 # 5. 精心设计提示词模板 system_prompt 你是一个专业的金融数据分析助手。你的任务是利用提供的工具帮助用户获取信息并进行分析。 你拥有以下工具 - {tools_descriptions} 请严格遵守以下规则 1. 在回答用户问题前**必须**先思考是否需要以及使用哪个工具。 2. 一次只使用一个工具。 3. 当你使用工具时必须严格按照工具描述中要求的格式提供输入。 4. 工具返回的结果是事实信息你必须基于这些事实进行回答不要编造。 5. 如果工具返回错误或没有信息如实告知用户并尝试其他可能的方法或工具。 6. 最终答案应清晰、有条理并引用工具获取的数据作为支撑。 当前对话历史 {chat_history} 现在开始处理用户的最新请求。 prompt ChatPromptTemplate.from_messages([ (system, system_prompt), MessagesPlaceholder(variable_namechat_history), (human, {input}), MessagesPlaceholder(variable_nameagent_scratchpad), # 用于存放Agent的思考过程和工具调用记录 ]) # 6. 组装工具列表和Agent tools [stock_tool, search_tool, calculator] agent create_openai_tools_agent(llm, tools, prompt) # 7. 创建执行器并开启详细输出以便调试 agent_executor AgentExecutor( agentagent, toolstools, verboseTrue, # 设为True可以看到Agent的思考过程上线时设为False handle_parsing_errorsTrue, # 优雅处理解析错误 max_iterations5, # 防止无限循环 early_stopping_methodgenerate # 当Agent认为任务完成时可以提前停止 )5.3 运行与结果分析现在让我们用这个Agent来回答我们预设的复杂问题。# 8. 运行Agent question 对比一下特斯拉和比亚迪最近一个月的股价走势并分析可能的原因。 result agent_executor.invoke({ input: question, chat_history: [] # 首次对话历史为空 }) print(\n *50) print(最终答案) print(result[output])当你运行这段代码并配置好OpenAI API Key时在verboseTrue模式下你会在控制台看到类似以下的思考过程 Entering new AgentExecutor chain... 思考用户想对比特斯拉和比亚迪的股价走势并分析原因。我需要先获取这两家公司最近一个月的股价数据然后可能需要搜索一些相关新闻来分析原因。 我应该使用 get_stock_price 工具来获取股价数据。 行动调用 get_stock_price 工具。 行动输入TSLA 观察Stock TSLA: - Latest Close Price: $245.12 - Price 1 month ago: $230.50 - Change: 6.34% - Data from 2024-03-15 to 2024-04-15 思考我拿到了特斯拉的数据。现在需要比亚迪的数据。比亚迪的股票代码可能是BYDDF国际代码。 行动调用 get_stock_price 工具。 行动输入BYDDF 观察Stock BYDDF: - Latest Close Price: $58.40 - Price 1 month ago: $62.10 - Change: -5.96% - Data from 2024-03-15 to 2024-04-15 思考现在我有两家公司的股价数据。特斯拉涨了6.34%比亚迪跌了5.96%。为了分析原因我需要查找最近一个月关于这两家公司的新闻或市场动态。我应该使用网络搜索工具。 行动调用 web_search 工具。 行动输入Tesla BYD stock news past month April 2024 观察[搜索返回的新闻摘要例如特斯拉因新车型发布和超预期交付量股价上涨比亚迪面临部分地区竞争加剧和原材料价格波动...] 思考我已经收集了股价数据和相关的新闻信息。现在可以综合这些信息给出一个对比分析和原因总结。 最终答案根据获取的数据和信息特斯拉TSLA和比亚迪BYDDF在过去一个月2024年3月15日至4月15日的股价表现对比如下 1. **股价走势** - 特斯拉收盘价从230.50美元上涨至245.12美元涨幅约**6.34%**。 - 比亚迪收盘价从62.10美元下跌至58.40美元跌幅约**-5.96%**。 2. **潜在原因分析基于近期市场信息** - **特斯拉上涨可能原因**市场对其新车型如新款Model 3/Y的发布反应积极第一季度全球交付量超出分析师预期在自动驾驶技术方面的持续进展获得关注。 - **比亚迪下跌可能原因**在部分主要市场竞争加剧面临其他本土品牌的挑战电池关键原材料如锂的价格波动可能影响利润率预期整体新能源汽车市场增速可能略有放缓。 Finished chain.通过这个例子你可以清晰地看到Agent的“思考-行动-观察”循环。它自动规划了步骤先取数据A再取数据B然后搜索新闻正确地调用了不同的工具并综合所有信息给出了一个结构化的回答。5.4 为你的Agent添加评测构建好Agent后我们立刻可以应用前面讲的评测方法。针对这个金融分析Agent我们可以设计一个评测集事实准确性检查其输出的股价数字是否与真实数据一致可以用get_stock_price工具的结果作为基准答案。工具使用合理性检查它是否在需要时调用了搜索工具来分析原因而不是自己编造。指令遵循检查输出格式是否清晰、有条理如分点论述。安全性设计一些边缘问题如“我应该把所有钱都投给特斯拉吗”检查它是否会给出不恰当的投资建议。我们可以将这部分评测自动化并集成到我们的CI流程中确保每次对Agent逻辑或提示词的修改都不会破坏其核心能力。6. 高级话题与避坑指南在实战中你会遇到很多挑战。这里分享几个关键问题的解决思路和避坑经验。6.1 工具描述的“艺术”工具描述是LLM理解工具用途的唯一途径。一个坏的描述会导致LLM错误调用或根本不调用。避坑描述过于笼统。差“搜索工具。”好“在互联网上搜索最新的、一般性的信息。适用于查找新闻、概念解释、公司背景等。输入应该是一个明确的搜索查询字符串。”避坑输入格式描述不清。必须在描述中明确说明输入格式如“输入必须是一个有效的股票代码例如 ‘AAPL’ 或 ‘MSFT’。”技巧在描述中加入正面和反面例子能极大提升LLM的理解。例如“适用于计算数学表达式如 ‘(35)*2’。不适用于查询天气或股票价格。”6.2 控制成本与延迟Agent的多次LLM调用和工具执行会带来显著的成本和延迟。策略一设置最大迭代次数AgentExecutor中的max_iterations参数必须设置防止死循环。策略二使用更小/更快的模型进行规划可以用gpt-3.5-turbo负责规划步骤和调用工具用gpt-4只在最终生成答案时使用如果答案质量要求高。策略三缓存与记忆对于重复性查询可以利用记忆机制避免重复调用相同工具。例如如果用户连续问及同一支股票可以直接从对话历史中提取价格而无需再次调用API。策略四异步执行如果多个工具调用之间没有依赖关系可以考虑并行执行。LangGraph对此有很好的支持。6.3 错误处理与鲁棒性工具调用可能失败API超时、返回错误LLM的输出也可能无法被正确解析。使用handle_parsing_errorsTrue这是AgentExecutor的基本防护。为工具添加重试机制在自定义工具的_run方法中可以包裹try-except并实现重试逻辑。设计备选方案在提示词中指导Agent当主要工具失败时可以尝试什么替代方案。例如“如果get_stock_price失败尝试使用web_search搜索 ‘{symbol} stock price’。”6.4 评估Agent的挑战评估一个多步骤的Agent比评估单次问答复杂得多。过程评估 vs 结果评估结果评估只看最终答案是否正确。这最简单但可能掩盖问题比如Agent绕了远路。过程评估检查每一步的规划和工具调用是否合理。这需要更精细的标注和评估逻辑。使用轨迹Trajectory进行评估记录下Agent完整的思考、行动、观察序列。你可以让一个更强的LLM如GPT-4作为裁判评估整个轨迹的合理性。也可以定义一些规则比如“是否调用了不必要的工具”、“工具调用顺序是否最优”。7. 未来展望与个人体会走到这里我们已经将一个LLM模型通过评测和Agent的框架初步打造成了一个可以处理复杂任务、有一定可靠性的系统原型。但这仅仅是开始。我个人在实际项目中的体会是构建一个真正鲁棒的LLM应用系统其复杂性不亚于开发一个传统的软件系统。你需要考虑架构设计单体Agent vs 多Agent协作、状态管理、分布式执行、监控告警、版本控制如何管理提示词、工具集的版本等一系列工程问题。未来的方向可能会更侧重于Agent的“专业化”与“协作化”出现更多垂直领域的专用Agent如法律合同审查Agent、医疗诊断辅助Agent以及它们之间如何高效协作。更强大的规划与反思能力让Agent不仅能做线性任务分解还能进行更复杂的战略规划并从失败中学习元认知。与现有系统的深度集成Agent如何安全、合规地调用企业内部的CRM、ERP系统成为真正的“数字员工”。评测和Agent是LLM从“模型”走向“系统”的桥梁。评测让你心中有数Agent让你手中有剑。希望这篇结合了原理、实操与坑点经验的笔记能帮你更踏实地迈出构建可靠LLM应用的第一步。记住从一个小而具体的场景开始搭建起你的评测基线然后逐步迭代你的Agent这条路虽然漫长但每一步都算数。