AI Agent 效果评测实战：搭完 Agent 才是噩梦的开始

上篇我写了怎么在 WebView 里跑 MCP Agent，调通了天气查询、邮件发送那一套。接下来老板过来问了一句话，把我整不会了——

“效果怎么样？”

我当时心想的观点是。能跑啊，你不是看到了吗，又一想，不对。他问的不是“能不能跑”，是“跑得好不好”。而我手里没有一丁点数据能回答这个问题。

你想想。你花了两周搭了个 Agent，上线了。接下来有人问你“它靠谱吗”，你只能凭感觉说“还行吧”——这不就是开盲盒吗？

反常识的是：写 Agent 只占四成功力，剩下六成全在搭评测。

再看翻车一。人工评测——跑了几次我自己先崩溃了

我一开始的想法特别朴素：设计十个八个任务，挨个跑一遍，看能不能完成。

任务还挺具体的：

• “查一下下周北京天气”
• “发邮件给张三说会议改期”
• “查文档里 API 密钥过期时间，接下来发邮件通知相关人”

看着挺像回事吧？第一轮就傻眼了，老实说，

同一个 prompt 跑了两次第一次成功。第二次 LLM 在 tool call 阶段选了完全不同的工具。同一个任务，两次结果不一样！不过，这直接暴露出结果不可复现的痛点。

更大的问题来了——这算完成了吗？

有些任务结果是模糊的。比如“发邮件给张三说会议改期”——Agent 调用了通讯录找到张三的邮箱。写了邮件正文，点了发送，但 SMTP 到底发成功没有？日志里显示返回，却不确定收件箱真的收到了吗？人工核验的话，每跑一次都要去翻一遍收件箱，耗时又容易出错。

测了七八个任务后我开始放水——“嗯这个大概成功了吧，下一个。” 这种样本量太小、自己都在糊弄自己的评测方式根本不可靠。

人工评测的致命伤：

• 不可复现；其实，
• 样本量不足；
• 评测过程容易主观偏差。

再看翻车二。让 LLM 自己判——它疯狂放水

人工不行，那就自动化吧。

我第一版自动化评测的逻辑特别天真：让 LLM 自己看工具调用日志，自己判定“这个任务完成没有”。结果呢，它啥都说“完成了”。

最离谱的一次——我故意让 SMTP 服务挂了再跑测试。Agent 调用了 send_email 工具，返回 { success: true }但邮件根本没发出去。接下来我让 LLM 评判，它只看日志说：“工具调用成功，邮件已发送”。这直接暴露出只看表面返回码、忽视真实执行结果的痛点。

解决思路：双判机制

• 规则校验层：不仅检查工具返回码，还要验证实际执行效果。 死逻辑但可靠，老实说，
• L​LM 评审层：把完整执行链路交给另一个更强的 LLM 判定。灵活但可能被误导，
• E​RROR 标记：If 两层结论不一致。则标黄让人工介入，实现互相兜底。不过，

This 双判方案虽然不是完美。但把 “瞎放水” 的问题解决了七八成，大幅降低"无法信任自动化评测"的风险。

再看翻车三，精心设计了 10 个测试用例。上线秒打脸

前两个坑爬出来后我花了一天时间设计了 10 条测试用例，覆盖常见场景。跑了一轮，全绿，其实，我当时那个得意啊——评测程序建好了Agent 效果稳了上线！

# 实际痛点爆炸 #

- 上线第一天第一个真实使用者的问题把 Agent 干懵了：

- 我的测试集全是单步任务，没有这种 “查 A 时顺带发现 B 有问题所以执行 C” 的多跳推理场景。测试集和真实场景之间出现巨大的 "gap",你不上线永远不知道。不过，

# 如何弥补 gap #

• 从真实对话里扒测试用例：上线前三天把所有使用者对话打日志。挑出有代表性的案例手动加入测试集。别靠脑洞设计，使用者教你的才是真实需求。
• 将单步任务、 多步推理、 条件分支分别统计成功率。不要只看整体成功率，哪块拉低整体，一眼就能看到并针对性调整。

从代码来看，评测框架主要就仨东西

1️⃣ 任务定义 → JSON 描述要测什么

const testCase = {
id的观点是。"case-001",description: "查下周北京天气",input: "下周北京天气怎么样？",expectedTools:,// 预期调用工具列表
expectedResult: /北京.*下周.*晴/。// 正则匹配输出内容
validation: "rule+llm" // 双判模式
};说起来，

2️⃣ 执行器 → 自动跑 Agent 并记录完整日志

async function runTest {
const result = await agent.run;return { ...result,testCase };}

3️⃣ 判定器 → 双判逻辑

async function judge {
const { testCase } = result;// Rule‑check：工具调用 & 实际执行校验
const rulePass = ruleCheck;// LLM‑review：让更强模型审阅完整链路
const llmPass = await llmJudge;if return "pass";if return "fail";// 两者结论不一致 → 标黄，需要人工复核
return "needs_review";}

* 实际实现里还会加入超时处理、重试策略、结果缓存等细节，这里只展示主要思路。

收尾的观点是，没有镜子。你都不知道自己长啥样

- 翻车三次后我深刻体会到，没有评测程序，你根本不知道改了一句 Prompt 是让 Agent 更好还是更差。自以为 “好像好一点”，其实往往是错觉。 只有跑一次完整评测，让数字说话才能客观判断。

• E​very iteration before change → run baseline.
• E​very change after → run same test set.
• If metric goes up → 确认提高；怎么说呢，若下降 → 回滚或继续调参。

- 看似麻烦。但养成习惯后只需几分钟，比起上线后被使用者骂、排查、再修再上线 的成本要划算太多。按理说，

---

You:

• 💬 Your team’s evaluation workflow?
​
• 😱 Crashed into any stranger bugs?
​
• 📝 Shoot your story in comments – I’m collecting material for next sequel.

.

---