1. 从模型到系统为什么评测与Agent是LLM落地的分水岭如果你最近在折腾大语言模型大概率会经历这样一个过程一开始你兴奋地跑通了某个开源模型的Demo或者接入了某个API惊叹于它流畅的对话能力。接着你开始尝试让它帮你写代码、分析文档、总结会议纪要效果时好时坏。然后你可能会遇到一些头疼的问题为什么同一个问题换种问法答案就天差地别为什么让它处理长文档时中间的信息总是被忽略为什么一个简单的多步骤任务比如“查一下天气如果下雨就提醒我带伞并生成一份出行建议”它总是执行得磕磕绊绊甚至直接“摆烂”这时你面对的就不再是一个单纯的“语言模型”而是一个需要被集成到真实工作流中的“系统组件”。这个跨越正是“评测”和“Agent”这两个概念要解决的核心问题。模型本身只是一个拥有强大文本生成能力的“大脑”而要让这个大脑在复杂、动态的真实世界里可靠地工作我们需要为它建立一套“体检标准”评测和“手脚与感知器官”Agent。过去几个月我深度参与了几个将LLM嵌入到生产系统的项目从最初的盲目乐观到后来的谨慎务实踩的坑不少。最大的体会是只关注模型本身的参数大小和跑分高低就像只关注发动机的马力而不考虑整车的操控性、安全性和油耗一样是远远不够的。一个在学术数据集上刷出高分的模型可能在你的业务场景里表现得一塌糊涂。而一个能力中等但足够稳定、可预测、可操控的模型通过合理的系统化设计Agent其最终表现往往能碾压一个不可控的“天才”模型。这篇笔记我就结合自己的实践拆解一下“评测”和“Agent”如何共同作用把LLM从一个黑盒模型变成一个可信赖的系统基石。我们会避开那些空泛的概念直接深入到评测到底要测什么、怎么测才有效Agent框架的核心设计模式是什么在实际开发中有哪些反直觉的细节决定了成败2. 超越跑分构建面向真实场景的LLM评测体系当我们谈论LLM评测时很多人第一反应是MMLU、GSM8K、HumanEval这些著名的学术基准。这些基准很重要它们提供了模型在通用知识、数学推理、代码能力上的横向对比标尺。但是如果你直接拿着这些分数去选型用于你特定业务的模型很可能会“踩雷”。因为这些基准测试的往往是模型的“原始智力”而非其在特定上下文、特定约束下的“工作能力”。2.1 评测维度的重新定义从“能力”到“可用性”一个面向生产系统的LLM评测至少需要涵盖以下四个维度我称之为“可用性四象限”任务完成度与准确性这是最核心的。但需要细化不能只问“回答得对不对”。例如指令遵循模型是否严格遵循了你的指令你让它“用JSON格式输出”它是否真的输出了严格可解析的JSON而不是在JSON外面包了一段解释文字事实一致性在涉及外部知识或给定上下文时模型是否会产生“幻觉”编造信息例如在基于一份产品文档进行问答时它给出的功能点是否都真实存在于文档中逻辑连贯性在多轮对话或复杂推理中模型的回答是否自洽前后有没有矛盾稳定性与可靠性这是系统集成的生命线。输出格式稳定性同样的输入多次请求下输出的格式如JSON的键名、列表的标记方式是否保持一致这对于后端解析至关重要。性能边界探测模型的“能力边界”在哪里输入超过多少token后性能会急剧下降面对模糊、有歧义或恶意的输入时是会拒绝回答、胡言乱语还是能得体地处理抗干扰能力在提示词中加入一些无关的“噪音”指令模型是否会被带偏安全与合规性这直接关系到项目能否上线。内容安全过滤模型是否会生成有害、偏见、或不符合法律法规的内容这需要设计专门的测试用例集例如OWASP Top 10 for LLM就列出了十大安全风险包括提示词注入、训练数据投毒、敏感信息泄露等。数据隐私在流式传输或处理过程中用户输入的数据是否可能以意外的方式被保留或泄露成本与延迟这是商业化的现实考量。Token效率完成相同质量的任务哪个模型消耗的Token更少这直接关联到API调用成本或自部署的推理开销。响应时间在平均负载和峰值负载下端到端的响应延迟是多少是否满足用户体验要求2.2 评测方法自动化、场景化、持续化手动测试几个例子是远远不够的。一个有效的评测体系必须是自动化、可重复的。构建评测集这是最耗时但也最核心的一步。你需要从真实业务场景中抽象出成百上千个测试用例。每个用例应包括输入提示词、期望的输出或输出需满足的规则、上下文如果有。例如一个电商客服场景的用例可能是输入“我上周买的手机屏幕碎了能保修吗”上下文提供保修政策文档期望模型应能引用文档中的具体条款如是否属于意外损坏来回答并引导用户提供订单号。设计评分函数如何判断模型输出是否合格对于格式固定的任务如信息提取可以用精确匹配或正则表达式。对于开放性问题则需要更复杂的方法基于规则的校验检查输出中是否包含关键词、是否遵循了指定的结构。使用“裁判员”模型用另一个通常更强的LLM根据评分标准如相关性、完整性、无害性对输出进行打分。这种方法成本高但灵活性强。人工复核对于关键用例或自动评分存疑的结果必须保留人工抽查的通道。搭建评测流水线将评测集、评分函数、模型调用封装成一个自动化流程。每当你更新模型版本、调整提示词模板、或修改Agent逻辑时都能快速运行一遍评测得到一份量化报告。工具上可以基于pytest自定义插件搭建也可以使用像ragas、DeepEval这类专门针对LLM应用评估的框架。实操心得不要追求一次性构建完美的评测集。采用“迭代”方式先覆盖最重要的20%的核心场景在开发过程中不断收集失败案例和边缘案例将其补充进评测集。一个不断生长的、源自真实问题的评测集比一个庞大但脱离场景的评测集有价值得多。2.3 一个实战案例知识库问答系统的评测假设我们要为一个内部技术文档搭建一个RAG检索增强生成问答系统。我们的评测设计可能是这样的评测集来源从历史客服工单、技术论坛提问中提炼出500个典型问题。为每个问题标注标准答案或答案要点。评测指标检索相关度系统检索出的文档片段与问题相关的有多少可用“裁判员”模型或人工标定答案准确性最终生成的答案与标准答案在事实层面的一致性。采用“裁判员”模型打分辅以人工复核引用质量答案中声称引用的来源是否真实存在于检索出的片段中且引用是否正确自动化检查拒绝能力对于文档中不存在答案的问题我们也会故意构造一些系统是否能得体地拒绝回答而不是胡编乱造运行与对比用这套评测集去测试不同的嵌入模型、不同的检索策略、不同的重排序模型、以及不同的LLM生成器。你会发现有时候换一个更便宜的LLM但搭配一个更好的检索策略整体效果可能比直接用最顶级的LLM还要好成本却低得多。通过这样系统化的评测你才能从“感觉这个模型挺聪明”过渡到“我们的系统在95%的核心用例上能达到4.5分满分5分的准确率且单次查询成本控制在X元以下”。这才是工程化的语言。3. Agent架构解析为LLM装配“思考-行动”的循环如果说评测是给LLM做“体检”和“定岗”那么Agent就是为它设计“工作流程”和“操作手册”。一个Agent本质上是一个能够感知环境、进行决策、执行动作以实现目标的自主系统。对于LLM驱动的Agent其核心模式可以抽象为下图所示的循环注此处用文字描述架构替代Mermaid图表一个典型的LLM Agent核心循环包含四个部分规划LLM作为“大脑”分析用户目标将其分解为一系列可执行的子任务或步骤。工具调用LLM根据当前步骤决定调用哪个外部工具如搜索API、计算器、代码执行器、数据库查询。行动执行系统实际执行被调用的工具获取结果如搜索返回的网页摘要、代码执行后的输出。观察与迭代将工具执行的结果作为新的观察反馈给LLM。LLM据此评估任务完成情况决定是进入下一步还是需要调整计划抑或最终给出答案。这个循环的关键在于LLM被限制在“规划”和“决策”层而具体的、确定性的操作如计算、查询、写文件交给专门的工具去完成。这既发挥了LLM强大的理解和推理能力又规避了其不擅长精确计算和事实查询的弱点。3.1 核心组件设计要点工具Tools的设计这是Agent能力的扩展边界。设计工具时要遵循“原子化”和“描述清晰”原则。原子化一个工具只做一件事并且做好。例如search_web(query)工具就只负责返回搜索结果不要让它同时做结果摘要。摘要可以由LLM在拿到结果后自己完成或者设计另一个summarize_text(text)工具。描述清晰给每个工具编写清晰、无歧义的描述包括功能、输入参数名称、类型、含义、输出格式。这个描述会被拼接到给LLM的提示词中LLM靠这个来决定是否以及如何调用它。例如weather_tool Tool( nameget_current_weather, description获取指定城市的当前天气情况。, args_schemaWeatherInput, # 一个Pydantic模型定义了city: str参数 funcfetch_weather )安全性工具能访问哪些资源执行代码的工具必须在沙箱中运行访问数据库的工具必须有严格的权限控制和查询审查。规划与记忆Planning Memory这是Agent智能度的体现。任务分解对于复杂任务LLM需要能制定计划。简单的做法是让LLM直接输出一个步骤列表。更高级的做法是使用“思维树”或“思维图”等结构允许探索不同的执行路径。记忆Agent需要记住对话历史、之前的工具执行结果。记忆的实现方式多样对话历史最简单的把之前的几轮问答直接拼接到上下文里。摘要记忆当对话很长时让LLM定期对历史进行摘要只保留关键信息以节省Token并聚焦重点。向量记忆将历史信息编码成向量存入向量数据库需要时通过语义检索召回相关记忆。这适合需要长期、大量记忆的场景。执行引擎Execution Engine负责调度整个循环。它需要处理工具调用解析解析LLM的输出识别出它想要调用哪个工具以及参数是什么。通常要求LLM以特定格式如JSON输出调用指令。错误处理工具调用失败如网络超时、API限流时引擎需要捕获异常并将错误信息格式化后反馈给LLM让它决定重试或调整策略。循环控制设置最大迭代次数、超时时间防止Agent陷入死循环。3.2 主流框架对比与选型思考目前市面上有很多优秀的Agent框架如LangChain、LangGraph、LlamaIndex、AutoGen等。选择时不必追求最火的那个而要看哪个最贴合你的需求。LangChain生态最丰富工具链最全抽象层次高。但正因为抽象高有时候感觉“黑盒”程度也高自定义复杂逻辑时可能需要深入其内部。适合快速原型验证和构建标准化的复杂链。LangGraph基于状态图StateGraph来定义Agent的工作流可视化程度高对于有明确状态转移的复杂流程如客服、审批建模非常直观。它和LangChain同源可以无缝集成。LlamaIndex在RAG检索增强生成领域非常专注和强大其Agent能力也主要围绕检索和知识库交互展开。如果你的Agent核心是与文档深度交互LlamaIndex可能是更直接的选择。AutoGen由微软推出特色在于支持多Agent协作对话。你可以定义不同角色程序员、测试员、产品经理的Agent让它们通过对话共同完成任务。适合需要模拟团队协作的场景。踩坑实录在早期项目中我们曾试图用LangChain“一把梭”解决所有问题。后来发现对于某些极其定制化的执行逻辑比如需要严格顺序执行且中间状态复杂的业务流程直接用LangGraph构建状态机或者甚至用FastAPIPydantic自己写一个轻量级的调度引擎代码反而更清晰、更易调试。框架是工具而不是枷锁。从最简单的while循环和if判断开始理解Agent的本质再根据需要引入框架是更稳妥的路径。4. 实战构建一个能执行多步骤任务的桌面助手Agent让我们抛开概念动手设计一个简单的桌面文件管理助手Agent。它的目标是理解用户用自然语言描述的复杂文件操作任务并安全地执行。核心需求用户可以说“把我桌面‘项目报告’文件夹里所有上个月修改过的.docx文件找出来并把它们的文件名和修改日期整理成一个CSV表格放到‘汇总’文件夹里”。Agent需要理解时间范围、文件类型、筛选条件、最终输出格式和路径并调用一系列系统工具完成。4.1 系统设计工具集定义list_files(directory_path: str, extension: str None) - List[Dict]列出目录下文件返回包含文件名、路径、修改时间等信息的列表。filter_files_by_date(file_list: List[Dict], start_date: str, end_date: str) - List[Dict]根据修改时间过滤文件列表。create_csv(data: List[Dict], columns: List[str], save_path: str) - bool将数据列表创建为CSV文件。move_file(source_path: str, target_directory: str) - bool移动文件本例中可能不需要但作为示例工具。Agent核心循环实现伪代码逻辑# 提示词模板包含工具描述和输出格式要求 SYSTEM_PROMPT 你是一个文件管理助手。你可以使用以下工具 - list_files: 列出目录文件。参数directory_path(目录路径), extension(扩展名可选)。 - filter_files_by_date: 按日期过滤文件列表。参数file_list(文件列表), start_date(开始日期YYYY-MM-DD), end_date(结束日期YYYY-MM-DD)。 - create_csv: 创建CSV文件。参数data(数据列表), columns(列名列表), save_path(保存路径)。 请严格按以下JSON格式回应 1. 思考下一步该做什么。 2. 如果需要调用工具输出{action: call_tool, tool_name: xxx, arguments: {...}} 3. 如果任务完成输出最终答案{action: final_answer, answer: 任务完成CSV文件已保存在xxx} def agent_loop(user_request: str, max_steps10): conversation_history [{role: system, content: SYSTEM_PROMPT}] conversation_history.append({role: user, content: user_request}) for step in range(max_steps): # 1. LLM规划与决策 llm_response call_llm_api(conversation_history) # 解析LLM的响应期望是JSON try: decision json.loads(llm_response) except: # 处理LLM输出不规范的情况 decision {action: error, reason: Invalid JSON format} # 2. 执行动作 if decision[action] call_tool: tool_name decision[tool_name] args decision[arguments] # 安全检查验证参数防止路径遍历等攻击 if not validate_tool_args(tool_name, args): result Error: Invalid arguments. else: # 实际调用工具函数 result call_tool_function(tool_name, args) # 将结果加入历史供LLM观察 conversation_history.append({role: user, content: f[Tool Result] {tool_name} returned: {result}}) elif decision[action] final_answer: return decision[answer] elif decision[action] error: # 处理错误可以反馈给LLM让其重试 conversation_history.append({role: user, content: fYour last response was invalid. Please adhere to the JSON format. Error: {decision.get(reason)}}) else: # 未知动作 conversation_history.append({role: user, content: Unknown action specified. Please use call_tool or final_answer.}) # 防止历史过长可在此处进行摘要或截断 if len(conversation_history) 20: conversation_history summarize_history(conversation_history) return Error: Max steps reached without completing the task.安全与边界处理路径安全所有涉及文件路径的参数必须进行规范化并检查是否在允许的目录范围内如限制在用户家目录下防止路径遍历攻击。工具权限create_csv、move_file这类写操作工具在执行前可以增加一个确认环节或者只允许在特定沙箱目录内操作。LLM输出解析必须做好异常处理。LLM可能不会每次都输出完美JSON需要有降级策略比如用正则表达式二次提取或者返回错误要求其重试。4.2 调试与评测这个Agent如何知道这个Agent好不好用我们回到第2部分的评测思想。构建测试集设计20-30个不同复杂度的文件操作指令从简单的“列出桌面所有PDF”到复杂的多条件筛选和格式转换。定义成功标准任务成功最终是否生成了正确的CSV文件在正确的位置步骤效率它用了多少步工具调用次数完成任务步骤是否合理例如它是否先list_files再filter_by_date而不是反过来安全性当用户提出危险指令如“删除所有文件”时它是否拒绝执行或要求确认自动化测试编写脚本自动运行这些测试用例记录成功率和平均步骤数。通过修改提示词、调整工具描述、甚至更换底层LLM观察这些指标的变化。通过这个简单的例子你可以清晰地看到评测让我们能量化Agent的能力而Agent架构让我们能将LLM的“意图”转化为安全、可靠的系统操作。两者结合才是LLM从演示玩具走向生产系统的关键。5. 避坑指南Agent开发中的常见陷阱与应对策略在实际开发中理想化的循环常常会遇到各种意外。以下是我总结的几个高频“坑点”及应对思路。5.1 陷阱一LLM的“规划短路”与“工具滥用”现象Agent要么过于“懒惰”用户让做多步任务它却直接说“我做不到因为我没有X工具”其实它可以通过组合现有工具完成要么过于“奔放”在不该调用工具的时候乱调用或者反复调用同一个工具陷入循环。根因分析提示词不清晰没有在系统提示词中明确要求LLM进行任务分解或者工具描述不够精确导致LLM不理解工具的能力边界。缺乏“反思”机制Agent执行一步后没有对结果进行有效性评估就盲目进行下一步。解决方案强化规划指令在提示词中明确加入分步思考的指令例如“请逐步思考这个问题。首先你需要达成什么目标其次达成这个目标需要哪些步骤每一步可以使用什么工具”引入“验证”步骤在关键的工具调用后让LLM对结果进行简单验证。例如调用list_files后让LLM判断“返回的文件列表是否符合我的时间筛选条件如果不符合我可能需要先获取所有文件再过滤或者调整过滤参数。”设置循环检测在执行引擎中记录最近几次的工具调用。如果发现完全相同的调用在短时间内重复出现可以中断循环并将“你似乎陷入了循环”的观察反馈给LLM强制其改变策略。5.2 陷阱二上下文窗口限制与记忆丢失现象在处理长对话或多步骤任务时Agent“忘记”了之前说过的话或执行过的操作导致行为不一致或重复提问。根因分析LLM的上下文窗口有限如4K、8K、128K Token当对话历史和工具执行结果累积超过这个限制时最早的信息就会被丢弃。解决方案选择性记忆不是所有历史都需要保留。可以设计规则只保留最重要的部分最新的几轮对话、工具调用的关键结果摘要、以及用户设定的核心目标。动态摘要在历史长度达到阈值时主动调用LLM对之前的对话进行摘要用一段简短的文本替代大段历史。例如“用户想整理项目报告。我们已经完成了1. 列出了‘项目报告’文件夹的所有文件。2. 筛选出了其中修改时间在2023-10-01之后的文件。”然后将这个摘要和最新的对话一起送入上下文。外部记忆体对于需要长期、大量记忆的场景如个性化助手可以将历史信息向量化后存入向量数据库。当需要相关记忆时通过语义检索召回最相关的几条。这相当于为Agent配备了一个“外部硬盘”。5.3 陷阱三工具执行的脆弱性与错误处理现象工具调用因为网络超时、API限流、输入参数格式错误、权限不足等原因失败导致整个Agent流程崩溃。根因分析将LLM视为“万能大脑”期望它能处理所有底层异常但LLM本质上并不理解网络、系统权限这些概念。解决方案工具层封装与降级每个工具函数内部要做好完善的异常捕获和日志记录。返回给Agent的不是原始的异常堆栈而是结构化的、LLM能理解的错误信息。例如网络超时返回“工具X暂时不可用请稍后重试或尝试替代方案Y”而不是ConnectTimeoutError。Agent层的重试与备选策略在执行引擎中对于可重试的错误如网络抖动可以自动重试几次。对于不可恢复的错误将清晰的错误描述反馈给LLM并提示它“你可以尝试使用另一个工具Z来完成类似功能或者向用户请求更多信息”。超时与熔断为每个工具调用和整个Agent循环设置超时时间。如果某个工具长时间无响应或频繁失败可以暂时将其“熔断”避免拖垮整个系统。5.4 陷阱四提示词工程的“黑魔法”与可维护性现象为了提升Agent在某个任务上的表现不断在提示词中加入各种“咒语”如“一步一步思考”、“确保准确性”导致提示词变得冗长、矛盾且难以维护。稍微修改业务逻辑整个提示词就可能失效。根因分析将提示词当作一个整体“魔法字符串”来调试缺乏结构化和模块化。解决方案模板化与变量注入将提示词拆分为多个模块系统角色定义、工具描述列表、任务格式说明、当前上下文/记忆。使用模板引擎如Jinja2来动态组装将变量如当前日期、用户信息、会话历史注入到合适的位置。版本控制与A/B测试像管理代码一样管理提示词使用Git进行版本控制。建立评测流水线可以方便地对不同版本的提示词进行A/B测试用数据评测集得分而不是感觉来决定哪个更好。少样本示例对于复杂或容易出错的步骤在提示词中提供1-2个清晰的“少样本示例”Few-shot Examples。这比用自然语言描述规则往往更有效。例如在要求LLM输出特定JSON格式时直接给一个完整的输入输出对。开发一个健壮的Agent系统是一个在“赋予LLM灵活性”和“施加系统约束力”之间不断寻找平衡的过程。评测体系是你的导航仪告诉你平衡点在哪里而扎实的工程实现良好的错误处理、可维护的代码结构则是你的安全绳确保系统不会在探索中崩溃。这个过程没有银弹需要的是对LLM能力与局限的深刻理解以及严谨的软件工程实践。 LLM评测与Agent架构：从模型到生产系统的工程实践
1. 从模型到系统为什么评测与Agent是LLM落地的分水岭如果你最近在折腾大语言模型大概率会经历这样一个过程一开始你兴奋地跑通了某个开源模型的Demo或者接入了某个API惊叹于它流畅的对话能力。接着你开始尝试让它帮你写代码、分析文档、总结会议纪要效果时好时坏。然后你可能会遇到一些头疼的问题为什么同一个问题换种问法答案就天差地别为什么让它处理长文档时中间的信息总是被忽略为什么一个简单的多步骤任务比如“查一下天气如果下雨就提醒我带伞并生成一份出行建议”它总是执行得磕磕绊绊甚至直接“摆烂”这时你面对的就不再是一个单纯的“语言模型”而是一个需要被集成到真实工作流中的“系统组件”。这个跨越正是“评测”和“Agent”这两个概念要解决的核心问题。模型本身只是一个拥有强大文本生成能力的“大脑”而要让这个大脑在复杂、动态的真实世界里可靠地工作我们需要为它建立一套“体检标准”评测和“手脚与感知器官”Agent。过去几个月我深度参与了几个将LLM嵌入到生产系统的项目从最初的盲目乐观到后来的谨慎务实踩的坑不少。最大的体会是只关注模型本身的参数大小和跑分高低就像只关注发动机的马力而不考虑整车的操控性、安全性和油耗一样是远远不够的。一个在学术数据集上刷出高分的模型可能在你的业务场景里表现得一塌糊涂。而一个能力中等但足够稳定、可预测、可操控的模型通过合理的系统化设计Agent其最终表现往往能碾压一个不可控的“天才”模型。这篇笔记我就结合自己的实践拆解一下“评测”和“Agent”如何共同作用把LLM从一个黑盒模型变成一个可信赖的系统基石。我们会避开那些空泛的概念直接深入到评测到底要测什么、怎么测才有效Agent框架的核心设计模式是什么在实际开发中有哪些反直觉的细节决定了成败2. 超越跑分构建面向真实场景的LLM评测体系当我们谈论LLM评测时很多人第一反应是MMLU、GSM8K、HumanEval这些著名的学术基准。这些基准很重要它们提供了模型在通用知识、数学推理、代码能力上的横向对比标尺。但是如果你直接拿着这些分数去选型用于你特定业务的模型很可能会“踩雷”。因为这些基准测试的往往是模型的“原始智力”而非其在特定上下文、特定约束下的“工作能力”。2.1 评测维度的重新定义从“能力”到“可用性”一个面向生产系统的LLM评测至少需要涵盖以下四个维度我称之为“可用性四象限”任务完成度与准确性这是最核心的。但需要细化不能只问“回答得对不对”。例如指令遵循模型是否严格遵循了你的指令你让它“用JSON格式输出”它是否真的输出了严格可解析的JSON而不是在JSON外面包了一段解释文字事实一致性在涉及外部知识或给定上下文时模型是否会产生“幻觉”编造信息例如在基于一份产品文档进行问答时它给出的功能点是否都真实存在于文档中逻辑连贯性在多轮对话或复杂推理中模型的回答是否自洽前后有没有矛盾稳定性与可靠性这是系统集成的生命线。输出格式稳定性同样的输入多次请求下输出的格式如JSON的键名、列表的标记方式是否保持一致这对于后端解析至关重要。性能边界探测模型的“能力边界”在哪里输入超过多少token后性能会急剧下降面对模糊、有歧义或恶意的输入时是会拒绝回答、胡言乱语还是能得体地处理抗干扰能力在提示词中加入一些无关的“噪音”指令模型是否会被带偏安全与合规性这直接关系到项目能否上线。内容安全过滤模型是否会生成有害、偏见、或不符合法律法规的内容这需要设计专门的测试用例集例如OWASP Top 10 for LLM就列出了十大安全风险包括提示词注入、训练数据投毒、敏感信息泄露等。数据隐私在流式传输或处理过程中用户输入的数据是否可能以意外的方式被保留或泄露成本与延迟这是商业化的现实考量。Token效率完成相同质量的任务哪个模型消耗的Token更少这直接关联到API调用成本或自部署的推理开销。响应时间在平均负载和峰值负载下端到端的响应延迟是多少是否满足用户体验要求2.2 评测方法自动化、场景化、持续化手动测试几个例子是远远不够的。一个有效的评测体系必须是自动化、可重复的。构建评测集这是最耗时但也最核心的一步。你需要从真实业务场景中抽象出成百上千个测试用例。每个用例应包括输入提示词、期望的输出或输出需满足的规则、上下文如果有。例如一个电商客服场景的用例可能是输入“我上周买的手机屏幕碎了能保修吗”上下文提供保修政策文档期望模型应能引用文档中的具体条款如是否属于意外损坏来回答并引导用户提供订单号。设计评分函数如何判断模型输出是否合格对于格式固定的任务如信息提取可以用精确匹配或正则表达式。对于开放性问题则需要更复杂的方法基于规则的校验检查输出中是否包含关键词、是否遵循了指定的结构。使用“裁判员”模型用另一个通常更强的LLM根据评分标准如相关性、完整性、无害性对输出进行打分。这种方法成本高但灵活性强。人工复核对于关键用例或自动评分存疑的结果必须保留人工抽查的通道。搭建评测流水线将评测集、评分函数、模型调用封装成一个自动化流程。每当你更新模型版本、调整提示词模板、或修改Agent逻辑时都能快速运行一遍评测得到一份量化报告。工具上可以基于pytest自定义插件搭建也可以使用像ragas、DeepEval这类专门针对LLM应用评估的框架。实操心得不要追求一次性构建完美的评测集。采用“迭代”方式先覆盖最重要的20%的核心场景在开发过程中不断收集失败案例和边缘案例将其补充进评测集。一个不断生长的、源自真实问题的评测集比一个庞大但脱离场景的评测集有价值得多。2.3 一个实战案例知识库问答系统的评测假设我们要为一个内部技术文档搭建一个RAG检索增强生成问答系统。我们的评测设计可能是这样的评测集来源从历史客服工单、技术论坛提问中提炼出500个典型问题。为每个问题标注标准答案或答案要点。评测指标检索相关度系统检索出的文档片段与问题相关的有多少可用“裁判员”模型或人工标定答案准确性最终生成的答案与标准答案在事实层面的一致性。采用“裁判员”模型打分辅以人工复核引用质量答案中声称引用的来源是否真实存在于检索出的片段中且引用是否正确自动化检查拒绝能力对于文档中不存在答案的问题我们也会故意构造一些系统是否能得体地拒绝回答而不是胡编乱造运行与对比用这套评测集去测试不同的嵌入模型、不同的检索策略、不同的重排序模型、以及不同的LLM生成器。你会发现有时候换一个更便宜的LLM但搭配一个更好的检索策略整体效果可能比直接用最顶级的LLM还要好成本却低得多。通过这样系统化的评测你才能从“感觉这个模型挺聪明”过渡到“我们的系统在95%的核心用例上能达到4.5分满分5分的准确率且单次查询成本控制在X元以下”。这才是工程化的语言。3. Agent架构解析为LLM装配“思考-行动”的循环如果说评测是给LLM做“体检”和“定岗”那么Agent就是为它设计“工作流程”和“操作手册”。一个Agent本质上是一个能够感知环境、进行决策、执行动作以实现目标的自主系统。对于LLM驱动的Agent其核心模式可以抽象为下图所示的循环注此处用文字描述架构替代Mermaid图表一个典型的LLM Agent核心循环包含四个部分规划LLM作为“大脑”分析用户目标将其分解为一系列可执行的子任务或步骤。工具调用LLM根据当前步骤决定调用哪个外部工具如搜索API、计算器、代码执行器、数据库查询。行动执行系统实际执行被调用的工具获取结果如搜索返回的网页摘要、代码执行后的输出。观察与迭代将工具执行的结果作为新的观察反馈给LLM。LLM据此评估任务完成情况决定是进入下一步还是需要调整计划抑或最终给出答案。这个循环的关键在于LLM被限制在“规划”和“决策”层而具体的、确定性的操作如计算、查询、写文件交给专门的工具去完成。这既发挥了LLM强大的理解和推理能力又规避了其不擅长精确计算和事实查询的弱点。3.1 核心组件设计要点工具Tools的设计这是Agent能力的扩展边界。设计工具时要遵循“原子化”和“描述清晰”原则。原子化一个工具只做一件事并且做好。例如search_web(query)工具就只负责返回搜索结果不要让它同时做结果摘要。摘要可以由LLM在拿到结果后自己完成或者设计另一个summarize_text(text)工具。描述清晰给每个工具编写清晰、无歧义的描述包括功能、输入参数名称、类型、含义、输出格式。这个描述会被拼接到给LLM的提示词中LLM靠这个来决定是否以及如何调用它。例如weather_tool Tool( nameget_current_weather, description获取指定城市的当前天气情况。, args_schemaWeatherInput, # 一个Pydantic模型定义了city: str参数 funcfetch_weather )安全性工具能访问哪些资源执行代码的工具必须在沙箱中运行访问数据库的工具必须有严格的权限控制和查询审查。规划与记忆Planning Memory这是Agent智能度的体现。任务分解对于复杂任务LLM需要能制定计划。简单的做法是让LLM直接输出一个步骤列表。更高级的做法是使用“思维树”或“思维图”等结构允许探索不同的执行路径。记忆Agent需要记住对话历史、之前的工具执行结果。记忆的实现方式多样对话历史最简单的把之前的几轮问答直接拼接到上下文里。摘要记忆当对话很长时让LLM定期对历史进行摘要只保留关键信息以节省Token并聚焦重点。向量记忆将历史信息编码成向量存入向量数据库需要时通过语义检索召回相关记忆。这适合需要长期、大量记忆的场景。执行引擎Execution Engine负责调度整个循环。它需要处理工具调用解析解析LLM的输出识别出它想要调用哪个工具以及参数是什么。通常要求LLM以特定格式如JSON输出调用指令。错误处理工具调用失败如网络超时、API限流时引擎需要捕获异常并将错误信息格式化后反馈给LLM让它决定重试或调整策略。循环控制设置最大迭代次数、超时时间防止Agent陷入死循环。3.2 主流框架对比与选型思考目前市面上有很多优秀的Agent框架如LangChain、LangGraph、LlamaIndex、AutoGen等。选择时不必追求最火的那个而要看哪个最贴合你的需求。LangChain生态最丰富工具链最全抽象层次高。但正因为抽象高有时候感觉“黑盒”程度也高自定义复杂逻辑时可能需要深入其内部。适合快速原型验证和构建标准化的复杂链。LangGraph基于状态图StateGraph来定义Agent的工作流可视化程度高对于有明确状态转移的复杂流程如客服、审批建模非常直观。它和LangChain同源可以无缝集成。LlamaIndex在RAG检索增强生成领域非常专注和强大其Agent能力也主要围绕检索和知识库交互展开。如果你的Agent核心是与文档深度交互LlamaIndex可能是更直接的选择。AutoGen由微软推出特色在于支持多Agent协作对话。你可以定义不同角色程序员、测试员、产品经理的Agent让它们通过对话共同完成任务。适合需要模拟团队协作的场景。踩坑实录在早期项目中我们曾试图用LangChain“一把梭”解决所有问题。后来发现对于某些极其定制化的执行逻辑比如需要严格顺序执行且中间状态复杂的业务流程直接用LangGraph构建状态机或者甚至用FastAPIPydantic自己写一个轻量级的调度引擎代码反而更清晰、更易调试。框架是工具而不是枷锁。从最简单的while循环和if判断开始理解Agent的本质再根据需要引入框架是更稳妥的路径。4. 实战构建一个能执行多步骤任务的桌面助手Agent让我们抛开概念动手设计一个简单的桌面文件管理助手Agent。它的目标是理解用户用自然语言描述的复杂文件操作任务并安全地执行。核心需求用户可以说“把我桌面‘项目报告’文件夹里所有上个月修改过的.docx文件找出来并把它们的文件名和修改日期整理成一个CSV表格放到‘汇总’文件夹里”。Agent需要理解时间范围、文件类型、筛选条件、最终输出格式和路径并调用一系列系统工具完成。4.1 系统设计工具集定义list_files(directory_path: str, extension: str None) - List[Dict]列出目录下文件返回包含文件名、路径、修改时间等信息的列表。filter_files_by_date(file_list: List[Dict], start_date: str, end_date: str) - List[Dict]根据修改时间过滤文件列表。create_csv(data: List[Dict], columns: List[str], save_path: str) - bool将数据列表创建为CSV文件。move_file(source_path: str, target_directory: str) - bool移动文件本例中可能不需要但作为示例工具。Agent核心循环实现伪代码逻辑# 提示词模板包含工具描述和输出格式要求 SYSTEM_PROMPT 你是一个文件管理助手。你可以使用以下工具 - list_files: 列出目录文件。参数directory_path(目录路径), extension(扩展名可选)。 - filter_files_by_date: 按日期过滤文件列表。参数file_list(文件列表), start_date(开始日期YYYY-MM-DD), end_date(结束日期YYYY-MM-DD)。 - create_csv: 创建CSV文件。参数data(数据列表), columns(列名列表), save_path(保存路径)。 请严格按以下JSON格式回应 1. 思考下一步该做什么。 2. 如果需要调用工具输出{action: call_tool, tool_name: xxx, arguments: {...}} 3. 如果任务完成输出最终答案{action: final_answer, answer: 任务完成CSV文件已保存在xxx} def agent_loop(user_request: str, max_steps10): conversation_history [{role: system, content: SYSTEM_PROMPT}] conversation_history.append({role: user, content: user_request}) for step in range(max_steps): # 1. LLM规划与决策 llm_response call_llm_api(conversation_history) # 解析LLM的响应期望是JSON try: decision json.loads(llm_response) except: # 处理LLM输出不规范的情况 decision {action: error, reason: Invalid JSON format} # 2. 执行动作 if decision[action] call_tool: tool_name decision[tool_name] args decision[arguments] # 安全检查验证参数防止路径遍历等攻击 if not validate_tool_args(tool_name, args): result Error: Invalid arguments. else: # 实际调用工具函数 result call_tool_function(tool_name, args) # 将结果加入历史供LLM观察 conversation_history.append({role: user, content: f[Tool Result] {tool_name} returned: {result}}) elif decision[action] final_answer: return decision[answer] elif decision[action] error: # 处理错误可以反馈给LLM让其重试 conversation_history.append({role: user, content: fYour last response was invalid. Please adhere to the JSON format. Error: {decision.get(reason)}}) else: # 未知动作 conversation_history.append({role: user, content: Unknown action specified. Please use call_tool or final_answer.}) # 防止历史过长可在此处进行摘要或截断 if len(conversation_history) 20: conversation_history summarize_history(conversation_history) return Error: Max steps reached without completing the task.安全与边界处理路径安全所有涉及文件路径的参数必须进行规范化并检查是否在允许的目录范围内如限制在用户家目录下防止路径遍历攻击。工具权限create_csv、move_file这类写操作工具在执行前可以增加一个确认环节或者只允许在特定沙箱目录内操作。LLM输出解析必须做好异常处理。LLM可能不会每次都输出完美JSON需要有降级策略比如用正则表达式二次提取或者返回错误要求其重试。4.2 调试与评测这个Agent如何知道这个Agent好不好用我们回到第2部分的评测思想。构建测试集设计20-30个不同复杂度的文件操作指令从简单的“列出桌面所有PDF”到复杂的多条件筛选和格式转换。定义成功标准任务成功最终是否生成了正确的CSV文件在正确的位置步骤效率它用了多少步工具调用次数完成任务步骤是否合理例如它是否先list_files再filter_by_date而不是反过来安全性当用户提出危险指令如“删除所有文件”时它是否拒绝执行或要求确认自动化测试编写脚本自动运行这些测试用例记录成功率和平均步骤数。通过修改提示词、调整工具描述、甚至更换底层LLM观察这些指标的变化。通过这个简单的例子你可以清晰地看到评测让我们能量化Agent的能力而Agent架构让我们能将LLM的“意图”转化为安全、可靠的系统操作。两者结合才是LLM从演示玩具走向生产系统的关键。5. 避坑指南Agent开发中的常见陷阱与应对策略在实际开发中理想化的循环常常会遇到各种意外。以下是我总结的几个高频“坑点”及应对思路。5.1 陷阱一LLM的“规划短路”与“工具滥用”现象Agent要么过于“懒惰”用户让做多步任务它却直接说“我做不到因为我没有X工具”其实它可以通过组合现有工具完成要么过于“奔放”在不该调用工具的时候乱调用或者反复调用同一个工具陷入循环。根因分析提示词不清晰没有在系统提示词中明确要求LLM进行任务分解或者工具描述不够精确导致LLM不理解工具的能力边界。缺乏“反思”机制Agent执行一步后没有对结果进行有效性评估就盲目进行下一步。解决方案强化规划指令在提示词中明确加入分步思考的指令例如“请逐步思考这个问题。首先你需要达成什么目标其次达成这个目标需要哪些步骤每一步可以使用什么工具”引入“验证”步骤在关键的工具调用后让LLM对结果进行简单验证。例如调用list_files后让LLM判断“返回的文件列表是否符合我的时间筛选条件如果不符合我可能需要先获取所有文件再过滤或者调整过滤参数。”设置循环检测在执行引擎中记录最近几次的工具调用。如果发现完全相同的调用在短时间内重复出现可以中断循环并将“你似乎陷入了循环”的观察反馈给LLM强制其改变策略。5.2 陷阱二上下文窗口限制与记忆丢失现象在处理长对话或多步骤任务时Agent“忘记”了之前说过的话或执行过的操作导致行为不一致或重复提问。根因分析LLM的上下文窗口有限如4K、8K、128K Token当对话历史和工具执行结果累积超过这个限制时最早的信息就会被丢弃。解决方案选择性记忆不是所有历史都需要保留。可以设计规则只保留最重要的部分最新的几轮对话、工具调用的关键结果摘要、以及用户设定的核心目标。动态摘要在历史长度达到阈值时主动调用LLM对之前的对话进行摘要用一段简短的文本替代大段历史。例如“用户想整理项目报告。我们已经完成了1. 列出了‘项目报告’文件夹的所有文件。2. 筛选出了其中修改时间在2023-10-01之后的文件。”然后将这个摘要和最新的对话一起送入上下文。外部记忆体对于需要长期、大量记忆的场景如个性化助手可以将历史信息向量化后存入向量数据库。当需要相关记忆时通过语义检索召回最相关的几条。这相当于为Agent配备了一个“外部硬盘”。5.3 陷阱三工具执行的脆弱性与错误处理现象工具调用因为网络超时、API限流、输入参数格式错误、权限不足等原因失败导致整个Agent流程崩溃。根因分析将LLM视为“万能大脑”期望它能处理所有底层异常但LLM本质上并不理解网络、系统权限这些概念。解决方案工具层封装与降级每个工具函数内部要做好完善的异常捕获和日志记录。返回给Agent的不是原始的异常堆栈而是结构化的、LLM能理解的错误信息。例如网络超时返回“工具X暂时不可用请稍后重试或尝试替代方案Y”而不是ConnectTimeoutError。Agent层的重试与备选策略在执行引擎中对于可重试的错误如网络抖动可以自动重试几次。对于不可恢复的错误将清晰的错误描述反馈给LLM并提示它“你可以尝试使用另一个工具Z来完成类似功能或者向用户请求更多信息”。超时与熔断为每个工具调用和整个Agent循环设置超时时间。如果某个工具长时间无响应或频繁失败可以暂时将其“熔断”避免拖垮整个系统。5.4 陷阱四提示词工程的“黑魔法”与可维护性现象为了提升Agent在某个任务上的表现不断在提示词中加入各种“咒语”如“一步一步思考”、“确保准确性”导致提示词变得冗长、矛盾且难以维护。稍微修改业务逻辑整个提示词就可能失效。根因分析将提示词当作一个整体“魔法字符串”来调试缺乏结构化和模块化。解决方案模板化与变量注入将提示词拆分为多个模块系统角色定义、工具描述列表、任务格式说明、当前上下文/记忆。使用模板引擎如Jinja2来动态组装将变量如当前日期、用户信息、会话历史注入到合适的位置。版本控制与A/B测试像管理代码一样管理提示词使用Git进行版本控制。建立评测流水线可以方便地对不同版本的提示词进行A/B测试用数据评测集得分而不是感觉来决定哪个更好。少样本示例对于复杂或容易出错的步骤在提示词中提供1-2个清晰的“少样本示例”Few-shot Examples。这比用自然语言描述规则往往更有效。例如在要求LLM输出特定JSON格式时直接给一个完整的输入输出对。开发一个健壮的Agent系统是一个在“赋予LLM灵活性”和“施加系统约束力”之间不断寻找平衡的过程。评测体系是你的导航仪告诉你平衡点在哪里而扎实的工程实现良好的错误处理、可维护的代码结构则是你的安全绳确保系统不会在探索中崩溃。这个过程没有银弹需要的是对LLM能力与局限的深刻理解以及严谨的软件工程实践。