Agent 上线前怎么测？从 10—20 条真实案例建立评估集

Agent 给出一段像样的回复，并不代表任务已经正确完成。它可能查错日期、调用多余工具，或者口头宣布成功，却没有生成需要的文件。LangChain 在 2026 年 10 月 15 日发布的评估问答中，建议团队从真实运行记录开始，逐步建立自己的评估集。

先选一个需要验证的行为

官方建议，起步时可以针对一种行为准备 10—20 条案例。例如，订单助手是否保留用户最后确认的条件，资料助手的结论是否能对应引用，编程 Agent 是否完成指定修改。

这只是启动评估的规模建议，不代表几十条案例就能证明系统覆盖了所有情况。先用当前版本跑出基线，之后每发现一个有代表性的失败，就把它补进评估集，再比较修改后的表现。

让评分方法对应具体问题

能够明确判断的条件，可以优先用代码检查，例如金额是否超预算、文件是否存在、字段是否完整。解释质量或证据支持程度等较难写成规则的问题，可以使用模型评分，并通过人工抽样校准。

模型裁判也需要清楚的评分标准。“是否包含用户要求的三个字段”比泛泛要求“评一下回答质量”更容易复核。官方建议采用明确的通过条件或少量有定义的类别，减少随意打分带来的波动。

把工具轨迹和最终状态纳入检查

对会采取行动的 Agent，只看最终回复容易遗漏问题。可以继续检查它调用了哪些工具、参数是否正确，以及最后留下的文件、记录或代码是否符合要求。

多轮任务还需要检查完整会话。用户先提出要求、随后修改条件时，每一轮回答可能单独看都合理，但最终结果却沿用了旧条件。评估应覆盖这些修正是否真正进入执行结果。

上线前和上线后相互补充

离线评估适合在更换模型、提示词或工具后做回归；在线评估用于观察真实流量中的新问题。线上发现的失败，经过人工核实后，可以回到离线数据集中。

团队可以从一套小而清晰的案例开始，持续记录成功率、成本和耗时。这样，每次调整都有可比较的依据，也更容易判断改进是否在真实任务中成立。

如果失败集中在长对话中遗漏早期要求，可以进一步检查上下文管理与长期记忆策略，再用原有失败案例验证调整效果。