当前位置：首页 > web >正文

Agent轻松通-P3：分析我们的Agent

web 2025/6/21 18:34:52

欢迎来到啾啾的博客🐱。
记录学习点滴。分享工作思考和实用技巧，偶尔也分享一些杂谈💬。
有很多很多不足的地方，欢迎评论交流，感谢您的阅读和评论😄。

1 引言

让我们结合前两篇的理论与实践，尝试系统性、结构化、全面地分析Agent。
因继续写下去单个文件太长了，本篇代码较上篇做了结构改动，代码放在https://github.com/tataCrayon/LLM-DEV-COOKBOOK仓库。

2 使用工具分析Agent：”日志“

我们之前通过verbose=True的日志，对Agent的行为进行了定性分析（Qualitative Analysis）。
但verbose=True的日志结构还是不够清晰。

LangChain提供了组件（回调机制），让我们可以捕获Agent的完整思考链。

from langchain.callbacks.base import BaseCallbackHandler
from langchain.schema import AgentAction, LLMResult
from typing import Any, Dict, Listclass IterationCounterCallback(BaseCallbackHandler):"""一个在每次Agent行动前打印轮次的回调处理器"""def __init__(self):self.iteration_count = 0def on_agent_action(self, action: AgentAction, **kwargs: Any) -> Any:self.iteration_count += 1print(f"\n--- 🤔 思考轮次: {self.iteration_count} ---")class AgentTraceCallback(BaseCallbackHandler):"""一个捕获并存储Agent与LLM之间完整交互记录的回调处理器"""def __init__(self):self.trace = ""def on_llm_start(self, serialized: Dict[str, Any], prompts: List[str], **kwargs: Any) -> Any:self.trace += f"\n--- PROMPT TO LLM ---\n{prompts[0]}\n"def on_llm_end(self, response: LLMResult, **kwargs: Any) -> Any:self.trace += f"--- RESPONSE FROM LLM ---\n{response.generations[0][0].text}\n"

这些记录以配置的方式，在agent_executor.invoke调用中传入

response = agent_executor.invoke({"input": question},# 回调列表可以包含多个回调处理器config={"callbacks": [iteration_counter, trace_collector]} 
)

IterationCounterCallback
IterationCounterCallback 并不是 LangChain 的标准内置回调类，而更可能是一个自定义的回调处理器，用于在 LangChain 的执行过程中跟踪迭代次数或特定事件。这种回调通常用于记录某些操作的执行次数，例如在链（Chain）或代理（Agent）执行过程中统计某些特定步骤的调用次数。
- 功能
  迭代计数：IterationCounterCallback 通常用于记录某些特定操作（如 LLM 调用、工具调用、代理循环等）的次数。
  监控和调试：通过计数，可以帮助开发者了解模型或代理在执行任务时的行为，例如循环次数、调用频率等。
  自定义逻辑：可以根据计数结果触发特定行为，例如在达到一定次数后停止执行或记录日志。
  还有AgentTraceCallback。

这里不做多过记录了，具体详情见LangChain API。

3 Agent分析调优

我们需要从“效率”、“准确性”、“鲁棒性”三个角度去调整优化我们的Agent。

效率
Q：Agent的ReAct循环是否偏离预期？
Q：步骤是否多余（需要合并）？
准确性
Q：Agent选择搜索的关键词是否有效？
Q：使用工具获取的内容是否真的回答了问题？
Q：最终的答案是否准确、全面？
鲁棒性
Q：如果其中一个工具调用失败了（比如网页无法访问），Agent要怎么处理？
Q：故障怎么恢复？

3.1 使用LLM自评LLM-as-a-Judge

人工评估在复杂场景往往效率低下，更适合的做法是训练一个LLM评委。

实现"LLM即评委"。
我们将创建一个新的函数，它的职责就是扮演“评委”的角色。它会接收我们捕获到的agent_trace，然后调用一个强大的LLM（我们继续使用DeepSeek），根据我们设定的标准来对这次运行进行打分和评价。

Prompt :“评委LLM”的评分标准

EVALUATION_PROMPT_TEMPLATE = """**角色：** 你是一位经验丰富的AI Agent评审专家。**任务：** 请根据以下提供的“原始问题”、“Agent最终答案”和“Agent完整思考轨迹”，对该Agent的表现进行一次全面、客观的评估。**评估标准：**1.  **效率 (Efficiency):** Agent是否采取了最直接、最少的步骤来解决问题？是否存在冗余的工具调用或不必要的思考循环？2.  **准确性 (Accuracy):** Agent的最终答案是否准确、全面地回答了原始问题？3.  **忠实度 (Faithfulness):** 最终答案是否严格基于其“观察结果”（工具的输出）？是否存在编造或幻觉的成分？4.  **工具使用 (Tool Use):** Agent是否选择了正确的工具？传递给工具的参数是否合理？---**【待评估材料】****原始问题:**{question}**Agent最终答案:**{final_answer}**Agent完整思考轨迹:**---{agent_trace}---**【你的评估报告】**请在下方提供你的评估报告。请先给出一个总体得分（满分10分），然后分点阐述你的理由，并提出具体的改进建议。**总体得分:** [请在这里打分，例如：8/10]**详细评估与改进建议:**1.  **效率:** ...2.  **准确性:** ...3.  **忠实度:** ...4.  **工具使用:** ..."""

“评委”代码

from langchain_deepseek import ChatDeepSeek
from langchain.prompts import PromptTemplate
from langchain.schema.output_parser import StrOutputParser
from ..llms.llm_clients import create_deepseek_llm # 从我们的llm模块导入from ..configs.prompt_config import EVALUATION_PROMPT_TEMPLATEdef evaluate_agent_trace(question: str, agent_trace: str, final_answer: str):"""使用LLM作为评委，来评估Agent的执行轨迹和最终答案。"""print("\n--- 启动LLM评委进行评估 ---")# 1. 创建评估链 (Evaluation Chain)prompt = PromptTemplate.from_template(EVALUATION_PROMPT_TEMPLATE)llm = create_deepseek_llm() # 复用我们创建LLM的函数# 使用LCEL（LangChain Expression Language）来构建链# 这是一个简单的 "Prompt -> LLM -> String Output" 链evaluation_chain = prompt | llm | StrOutputParser()# 2. 运行评估链try:print("评委正在审阅材料并生成报告...")evaluation_report = evaluation_chain.invoke({"question": question,"agent_trace": agent_trace,"final_answer": final_answer})print("\n--- 评委报告生成完毕 ---")print(evaluation_report)except Exception as e:print(f"\n--- LLM评委在评估时发生错误 ---")print(e)

AI给出来的评估内容如下：

--- 评委报告生成完毕 ---
**总体得分:** 8.5/10  **详细评估与改进建议:**1.  **效率:**- **评分：8/10**- **理由：** Agent通过三次`search_tool`调用逐步获取信息，逻辑清晰，但首次搜索查询（"Java vs Python for building LLM applications..."）的输入参数 过于宽泛，导致返回结果包含冗余信息（如Vert.x与Asyncio的无关对比）。后续两次搜索（Python/Java框架）更精准，效率较高。- **改进建议：** 首次搜索可拆分为两个针对性查询（如分别搜索优劣势和框架），或直接使用更精确的关键词（如"LLM framework comparison Java Python 2024"）。2.  **准确性:**- **评分：9/10**- **理由：** 最终答案全面覆盖了两种语言的优劣势，且列出的框架（如LangChain、Spring AI）与搜索结果一致。但未明确提及Python的GIL（全局解释器锁）对 多线程的限制，这是Python性能劣势的关键细节。- **改进建议：** 补充Python的GIL问题，并对比Java的JVM优化对LLM推理的潜在优势。3.  **忠实度:**- **评分：9/10**- **理由：** 答案严格基于工具返回的观察结果，未发现编造内容。但未完全引用搜索中提到的"Konduit支持模型加载与调优"的具体功能描述，略显简略。       - **改进建议：** 引用工具返回的原文关键描述（如"Konduit允许加载GPT/BERT模型"）以增强可信度。4.  **工具使用:**- **评分：8/10**- **理由：** 工具选择合理（仅需搜索无需爬取），但首次搜索参数可优化。未尝试组合查询（如"Java LLM frameworks performance benchmarks"）以获取更深度的对比数据。- **改进建议：** 在对比优劣势时，可增加一次搜索查询（如"Python Java LLM latency memory usage"）补充量化指标。**其他建议：**
- 可增加对跨语言生态的说明（如Java通过Jython调用Python库的可行性），以体现更全面的视角。
- 最终答案中可补充框架的典型应用场景（如"Haystack适合RAG"已提及，但Spring AI的企业集成场景可细化）。