Agent 能力优化与效果评估：从可观测性到自动化评测

写在前面

Artificial Intelligence Agent，人工智能智能体（Agent）具有非确定性。同一个问题在模型、提示词、上下文或工具状态发生变化后，可能得到不同的规划路径和答案。传统软件测试主要判断输入经过确定性程序后是否得到预期输出，Agent 评估还要判断它是否选择了正确路径、是否调用了合适工具、参数是否正确、依据是否可靠，以及这些过程是否满足延迟、成本和安全约束。

因此，Agent 优化不能从修改提示词开始。首先要定义什么是正确，其次记录系统真实执行了什么，再用可重复的测试判断改动是否有效。这个项目以混合式财富管理投顾 Agent 为对象，完成四个环节：

文章先说明完整评估闭环，再拆解投顾 Agent 的评估对象，之后分别介绍追踪、测试集、评估器和自动化执行，最后给出当前实现暴露的问题和下一步优化方案。

一、Agent 优化的核心是建立闭环

图 1：Agent 评估从业务目标开始，以回归测试结束。只有通过同一测试集比较修改前后的结果，优化才具有可验证性（图由AI辅助绘制）。

LangSmith 官方将评估分为离线评估和在线评估。离线评估在发布前使用带参考输出的数据集进行基准测试和回归测试；在线评估面向生产 Trace，持续监控没有标准答案的真实请求。线上失败样本再进入离线数据集，构成持续改进闭环。

这个闭环包含四类对象。

业务目标决定系统应当优化什么。投顾 Agent 的首要目标不是回答更长，而是路由正确、事实有依据、建议符合客户风险偏好，并且不越过投资建议的安全边界。

测试集把目标转化为可重复输入。测试集需要覆盖常见任务、复杂任务、边界条件和高风险输入，不能只收集系统已经能够正确回答的问题。

评估器把正确转化为分数。结构、关键词、工具参数等确定性条件使用代码判断；相关性、完整性和个性化程度等语义条件可以使用 Large Language Model as a Judge，大语言模型裁判（LLM-as-a-Judge）；高风险样本仍需人工抽检。

回归测试判断修改是否有效。提示词、模型、路由和工具发生变化后，应在同一数据集上重新执行，并同时比较质量、延迟、Token 和成本。单次运行成功只能说明案例可用，不能说明系统已经稳定。

二、评估对象：混合式财富管理投顾 Agent

项目中的投顾助手采用混合式架构。协调层先将问题分为紧急型、信息型或分析型，再选择反应式或深思熟虑式处理路径。

反应式路径处理上证指数、账户配置和金融概念等简单查询。它强调响应速度，必要时调用行情或账户工具。深思熟虑式路径处理经济衰退应对、退休规划和教育金计划等复杂问题，依次完成数据收集、风险分析、配置建议和最终回答。

图 2：同一个 Agent 包含路由、工具、分析和回答多个评估对象，最终答案评分不能替代中间过程评估（图由AI辅助绘制）。

2.1 为什么不能只评估最终回答

最终回答正确，不代表执行过程正确。系统可能选错路径，但依靠模型常识碰巧给出合理答案；也可能工具参数错误，却从预训练知识中补全结果。相反，最终回答出现问题，也无法直接判断错误来自路由、数据、工具还是生成阶段。

混合式投顾 Agent 至少需要五层指标。

这套分层方式使指标能够定位问题。路由准确率下降时应检查协调层提示词或分类模型；工具参数错误时应修改工具模式和参数约束；答案冗长但事实正确时，只需要调整生成阶段，不应改动前面的数据链路。

2.2 当前案例的边界

项目使用两组示例客户画像，包含风险承受能力、投资期限、财务目标和资产配置。上证指数工具返回模拟行情，部分市场数据也来自预设内容。因此，当前实现用于验证架构、追踪和评估方法，不能将生成的投资建议视为真实投顾结论。

这个边界本身也应进入评估规则。模型不能把模拟数据描述为实时数据，不能在缺少持仓明细时推断科技股占比，也不能为缺少依据的收益率给出确定承诺。

三、LangSmith：先看清 Agent 做了什么

LangSmith 将一次完整调用记录为 Trace，并将模型调用、解析器、工具和图节点记录为子 Run。标签和元数据可以进一步标记客户、风险类型、提示词版本和实验版本。官方文档将 Trace 定义为一次操作的完整步骤序列，Run 则是其中的单次执行单元。

项目通过 RunnableConfig 将业务上下文附加到每次 LangGraph 执行。

config = RunnableConfig(
    run_name=f"wealth-advisor-{customer_id}",
    tags=[
        "wealth-advisor",
        "hybrid-agent",
        f"customer-{customer_id}",
        customer_profile["risk_tolerance"],
    ],
    metadata={
        "customer_id": customer_id,
        "processing_version": "v1",
        "query_length": len(user_query),
    },
)

result = wealth_advisor_app.invoke(initial_state, config=config)

这些字段不参与模型推理，但可以按客户类型、版本和查询特征筛选失败样本。实际工程中还应记录 model_version、prompt_version、tool_version 和运行环境，否则不同实验之间无法准确归因。

图 3：LangSmith 展示协调层、模型、解析器、反应式节点和响应节点，并保留每一步的 Prompt、输入、输出、标签与延迟。

图中的简单行情查询被路由为 emergency 和 reactive。这说明协调层完成了预期分类，但 Trace 还暴露了性能问题：协调阶段耗时约 2.63 秒，反应式阶段约 4.67 秒，端到端约 8.36 秒。对一个强调快速响应的简单查询，这个延迟仍然偏高。

图 4：瀑布图显示协调层和反应式路径中的模型调用串行执行，可以据此定位主要延迟来源。

从瀑布图可以得到三个直接结论。第一，协调层本身需要一次模型调用；第二，反应式路径又包含两次模型调用；第三，这些调用基本串行，延迟会累积。后续优化应优先减少简单查询的模型调用次数，例如将高频明确意图交给规则或轻量分类器，缓存稳定路由结果，或者让工具结果直接通过模板生成回答。优化后仍需在同一测试集上比较路由准确率，不能只追求速度。

Trace 还能直接加入 Dataset。线上出现的错误请求、长尾问题和人工修正结果可以转成回归样本，这比单独编写理想化问题更接近真实使用分布。

四、测试集：把业务要求写成可执行样本

当前测试集包含 8 个样本：3 个反应式查询、3 个深思熟虑式查询和 2 个边界输入。

测试数据中的期望输出不必写成唯一标准答案，更适合保存结构化约束。

TEST_CASES = [
    {
        "inputs": {
            "user_query": "今天上证指数的表现如何？",
            "customer_id": "customer1",
        },
        "expected_outputs": {
            "processing_mode": "reactive",
            "should_contain": ["上证指数", "点位", "涨跌"],
        },
    },
    {
        "inputs": {
            "user_query": "请为我设计一个10年期教育金计划。",
            "customer_id": "customer1",
        },
        "expected_outputs": {
            "processing_mode": "deliberative",
            "should_contain": ["教育金", "10年", "投资计划", "风险"],
        },
    },
]

processing_mode 是确定性标签，适合精确匹配；should_contain 只检查最小信息集合，不限制模型使用完全相同的句子。这种设计比整段文本精确匹配更适合生成式系统。

4.1 当前测试集还缺少什么

8 个样本足以跑通评估流程，但不足以证明系统稳定。正式评估应至少扩展四类数据。

同一意图还应使用不同表达方式，避免测试集只验证关键词。每次测试至少重复数次，以观察非确定性带来的均值和方差。测试集应划分开发集与保留集，防止提示词不断针对公开样本调优后产生过拟合。

五、评估器：确定性规则优先，模型裁判补充

5.1 处理模式评估器

协调层输出只有 reactive 和 deliberative 两个候选值，最可靠的方法是直接与参考标签比较。

class ProcessingModeEvaluator(RunEvaluator):
    def evaluate_run(self, run, example, **kwargs):
        expected = example.outputs.get("processing_mode")
        actual = run.outputs.get("processing_mode")

        return {
            "key": "processing_mode",
            "score": float(actual == expected),
            "comment": f"expected={expected}, actual={actual}",
        }

这种评估不需要模型，结果可重复、成本低，也容易解释。工具名称、参数模式、JavaScript Object Notation，JavaScript 对象表示法（JSON）结构、必填字段和风险提示等同样应优先使用确定性规则。

5.2 回答完整性评估器

项目使用期望关键词的覆盖率衡量最小信息完整性：

[ \text{Completeness} = \frac{\left|K_{\text{expected}} \cap K_{\text{response}}\right|} {\left|K_{\text{expected}}\right|} ]

expected = example.outputs.get("should_contain", [])
response = run.outputs.get("final_response", "")

found = [word for word in expected if word.lower() in response.lower()]
score = len(found) / len(expected)

这个指标容易执行，但只能判断关键词是否出现，不能判断语义是否正确。例如回答包含风险和建议两个词，不等于建议真的符合客户画像。因此，它适合作为最低完整性检查，不应替代事实正确性和业务适配评估。

5.3 OpenEvals 的通用与业务评估器

OpenEvals 是 LangChain 团队维护的评估器库，提供可复用的评估提示和 LLM-as-a-Judge 构造函数。它可以与 LangSmith 集成，也可以作为独立评估逻辑使用。官方仓库同时指出，Agent 轨迹的专用评估可进一步使用 AgentEvals。

项目为投顾 Agent 组合了 7 个评估器。

evaluators = [
    create_llm_as_judge(
        prompt=ANSWER_RELEVANCE_PROMPT,
        feedback_key="relevance",
        judge=eval_llm,
        continuous=True,
    ),
    create_llm_as_judge(
        prompt=PROCESSING_MODE_PROMPT,
        feedback_key="processing_mode",
        judge=eval_llm,
        continuous=True,
    ),
    create_llm_as_judge(
        prompt=RESPONSE_COMPLETENESS_PROMPT,
        feedback_key="response_completeness",
        judge=eval_llm,
        continuous=True,
    ),
]

对于路由这种离散标签，前面的代码规则比 LLM-as-a-Judge 更合适。模型裁判只有在参考输出结构复杂、表达存在合理变体，或者需要评价帮助性和风险匹配等语义条件时才有明显价值。

5.4 单指标样例暴露了什么

项目对 OpenEvals 的评估提示进行了独立样例测试。部分结果符合预期：

这些分数可以证明评估器能够区分明显的正例、弱例和反例，但还不能证明它适用于真实投顾数据。更重要的是，幻觉测试出现了一个反例：上下文只说明 Python 是高级编程语言，回答补充了 1991 年和作者信息，评估器仍给出 1.0。补充信息可能符合模型常识，却没有得到当前上下文支持。

这个结果说明幻觉、事实错误和无依据扩展不是同一概念。高风险系统应分别检查：

如果将四类问题都压缩到一个幻觉分数中，评估器很容易漏报。投顾场景应优先要求事实可追溯，并对关键数字和产品信息使用确定性校验。

六、自动化执行与 Prompt Ops

Prompt Operations，提示词运维（Prompt Ops）的核心不是在控制台中手动比较两段回答，而是将提示词版本、测试集和实验结果关联起来。项目通过 LangSmith 的 evaluate() 执行批量实验。

def predict(inputs):
    result = run_wealth_advisor(
        user_query=inputs["user_query"],
        customer_id=inputs.get("customer_id", "customer1"),
    )

    return {
        "final_response": result["final_response"],
        "processing_mode": result["processing_mode"],
        "query_type": result["query_type"],
    }


results = evaluate(
    predict,
    data="wealth-advisor-test-dataset",
    evaluators=[
        ProcessingModeEvaluator(),
        ResponseCompletenessEvaluator(),
    ],
    experiment_prefix="router-v2",
    max_concurrency=1,
)

一次实验应绑定明确版本，例如：

metadata = {
    "model": "qwen-plus",
    "prompt_version": "coordination-v3",
    "tool_version": "market-data-v2",
    "dataset_version": "wealth-advisor-2026-07",
}

改动前后的实验使用同一数据集和评估器，比较路由准确率、完整性、相关性、延迟、Token 和错误率。只有当关键指标达到门槛且没有高风险样本回归时，新版本才可以替换基线。

LangSmith 官方支持代码规则、LLM-as-a-Judge、人工评价和成对比较。离线实验还可以将输入、参考输出、评估得分、延迟和 Token 放在同一视图中比较。[^1] 对于输出差异难以绝对打分的场景，成对比较通常比要求裁判直接给出精确小数更稳定。

七、DeepEval：把评估接入测试流程

DeepEval 更接近传统测试框架。它通过测试用例、指标、阈值和断言组织评估，适合接入 Continuous Integration/Continuous Delivery，持续集成/持续交付（CI/CD）。官方文档区分端到端评估和组件级评估：前者判断整个应用是否完成任务，后者基于 Trace 评估工具、规划器和检索器等内部组件。[^4]

项目为投顾助手设置三个指标：

metrics = [
    AnswerRelevancyMetric(
        threshold=0.6,
        model="gpt-4o-mini",
        include_reason=True,
    ),
    HallucinationMetric(
        threshold=0.5,
        model="gpt-4o-mini",
        include_reason=True,
    ),
    GEval(
        name="RiskConsideration",
        criteria="投资建议是否考虑客户风险承受能力和投资偏好",
        evaluation_params=[
            LLMTestCaseParams.INPUT,
            LLMTestCaseParams.ACTUAL_OUTPUT,
        ],
        threshold=0.5,
        model="gpt-4o-mini",
    ),
]

Answer Relevancy，答案相关性用于判断是否切题；Hallucination，幻觉指标用于检查输出与上下文的冲突；G-Eval 是基于自然语言标准构造自定义语义评估的方法。风险偏好匹配是投顾领域指标，通用评估库无法自动知道什么是合格的个性化建议，因此必须单独定义。

DeepEval 与 LangSmith 不是简单替代关系。DeepEval 适合在本地和 CI/CD 中执行质量门槛，LangSmith 更适合追踪、数据集管理、实验比较和在线监控。OpenEvals 主要提供评估器实现，LangSmith 提供运行和分析平台。工程选择应看现有技术栈，而不是同时引入所有工具。

八、Qwen-Agent 与 Langfuse：框架外的可观测性

为了验证非 LangChain 技术栈，项目还将同一个投顾助手改为 Qwen-Agent，并使用 Langfuse 追踪。Qwen-Agent 通过系统提示描述反应式与深思熟虑式行为，注册行情查询工具，再由 Assistant 处理对话和工具调用。

图 5：面对科技股占比问题，系统返回已有资产大类配置，同时明确指出缺少股票明细，避免将科技偏好误写成实际持仓比例。

这个结果体现了评估中容易被忽略的一点：没有给出具体数字不一定是能力不足。在数据不完整时，明确说明无法确定并请求补充持仓明细，比生成一个看似完整的比例更可靠。完整性指标必须与事实依据共同解释，不能单独鼓励模型填满所有字段。

Langfuse 通过 @observe 记录一次 gui_query 调用，并在 Span 中写入客户标识、风险类型、查询长度、输入和输出。Langfuse 官方将评估与可观测 Trace 关联，使分数能够按模型、版本、用户和时间聚合。[^5]

@observe(name="gui_query", as_type="generation")
def traced_run():
    langfuse.update_current_span(
        input=user_query,
        model="qwen-turbo-latest",
        metadata={
            "customer_id": customer_id,
            "risk_tolerance": customer_profile["risk_tolerance"],
        },
    )

    responses = list(Assistant.run(agent, messages))

    langfuse.update_current_span(
        output=extract_final_response(responses),
    )
    return responses

图 6：Langfuse 保存调用参数、模型输出、Token 和返回状态，为 Qwen-Agent 提供框架外追踪能力。

当前封装主要记录外层生成调用。若要定位工具选择和路由问题，还应将协调判断、每次工具调用、工具结果和最终生成分别记录为子 Span。外层 Trace 告诉我们请求是否完成，细粒度 Span 才能说明失败发生在哪里。

九、从评估结果回到能力优化

评估的最终目的不是生成更多分数，而是确定下一次修改的位置。

9.1 优化协调层

当前简单查询需要先经过模型分类，再进入反应式路径。可以先统计路由混淆矩阵，找出最常误判的意图。高频且边界清晰的查询可以使用规则或轻量模型处理，低置信度样本再交给大模型。路由优化必须同时比较准确率与延迟，不能只减少调用次数。

9.2 优化工具层

工具应使用结构化参数模式，并返回数据来源、时间戳和错误状态。模拟行情替换为真实 Application Programming Interface，应用程序接口（API）后，需要增加超时、权限、限流和数据新鲜度指标。金融数字应由程序计算，模型负责解释，不能让模型直接推算账户事实。

9.3 优化生成层

简单查询应使用短模板，复杂建议才允许长回答。生成提示需要明确区分已知事实、推断和建议，并要求关键结论引用工具结果。对于缺少数据的问题，优先返回缺失字段和下一步操作，而不是补全未知信息。

9.4 校准模型裁判

LLM-as-a-Judge 不是标准答案。评估模型、提示词和温度变化都会影响分数。可靠流程应先准备人工标注的小型校准集，比较评估器与人工判断的一致性；对高风险指标使用确定性规则；对边界样本进行人工复核；保存裁判模型和评估提示版本。

同一个模型既生成答案又评价答案，还可能产生自我偏好。重要实验可以使用不同系列模型裁判，或者使用成对比较和多次投票降低单次波动。

十、当前结果与局限

当前项目已经完成以下验证：

本地材料没有保存完整 LangSmith 实验的汇总报表，因此不能据此宣称投顾 Agent 已达到某个整体准确率。OpenEvals 的独立样例也表明，单一幻觉评估器可能把未被上下文支持的信息判断为正确。当前结论应限定为评估基础设施和方法已经建立，评估器仍需用真实投顾样本校准。

此外，测试集规模较小，市场和持仓数据包含模拟内容，尚未覆盖工具故障、并发、提示注入、越权请求和多轮对话。下一阶段应接入真实但脱敏的数据源，扩充历史失败集，并将路由准确率、工具正确率、事实可追溯率、端到端延迟和单位请求成本设置为发布门槛。

小结

Agent 能力优化可以归纳为一条清晰主线：先定义正确行为，再记录完整执行过程，然后用分层指标评估，最后通过同一数据集验证修改是否有效。

LangSmith 和 Langfuse 解决发生了什么，OpenEvals 和 DeepEval 解决结果是否合格，业务规则与人工抽检负责校准模型裁判。对于混合式投顾 Agent，最关键的指标不是单一回答分数，而是路由、工具、事实依据、风险匹配和系统效率能否同时满足要求。

当失败样本能够自动进入数据集，每次修改都能形成可比较实验，Agent 开发才从凭感觉调提示词转变为可重复、可解释、可持续优化的工程过程。