系列第七篇。上一篇讲怎么让用户看见进展，这一篇讲怎么让你自己看见系统好不好。

0. 先看一个让人抓瞎的场面

你的 Agent 上线了。老板问：

“最近效果怎么样？用户满意吗？哪里答得不好？”

你打开后台，只看到一堆日志，翻半天翻不出来。你只能说：“好像还行……吧。”

老板再问：

“昨天有个用户说答错了，你知道是哪一步错了吗？”

你说：“我复现一下看看。”然后复现了三小时，没复现出来。

问题不在你不努力，在于系统“看不见自己”。

生活类比：你开车，仪表盘坏了。油快没了你不知道，水温过高你不知道，发动机故障灯不亮你也不知道。车还能开，但哪天抛锚了你完全不知道为什么。

这一篇讲的就是：给 Agent 装仪表盘——多模型怎么选、日志和埋点怎么埋、效果怎么评测、bad case 怎么回流。装好了，系统好不好你一眼能看见。

1. 先把五个词讲清楚

1.1 多模型路由（Model Routing）

一句话：不同任务用不同的模型，好钢用在刀刃上。

生活例子：你出门，近的地方骑共享单车，远的地方坐地铁，搬家才叫货车。不是所有事都叫货车，也不是所有事都骑车。

在 Agent 里：简单任务（意图识别、参数抽取）用小模型，快且便宜；复杂任务（长文本总结、复杂推理）用大模型，慢但准；模型超时了切备用模型。

1.2 可观测性（Observability）

一句话：系统运行时，你能看到它每一步在干什么、花了多久、哪里出的错。

生活例子：汽车的仪表盘。油量、速度、水温、故障灯。没有仪表盘，车坏了你只能猜。

在 Agent 里：每个节点花多久、调了哪个工具、模型返回了什么、哪一步报错了，全都有记录，能按会话回溯。

1.3 埋点（Instrumentation）

一句话：在代码里预先插一些“记录点”，系统跑的时候自动把关键数据记下来。

生活例子：你在家里每个房间装一个温度计，不用每天去问“现在几度”，温度计自动显示。埋点就是这些温度计。

在 Agent 里：在意图识别节点前后各记一个时间戳，就知道这一步花了多久；在工具调用处记下“调了什么、返回什么、成功还是失败”。

1.4 RAGAS

一句话：一套给 RAG（检索增强生成）系统打分的评测指标集，主要看三件事：答得忠不忠实、答得相关不相关、检索得准不准。

生活例子：老师批作文，看三点——有没有胡编（忠实）、有没有跑题（相关）、引用材料对不对（检索准）。RAGAS 就是这套“批作文标准”。

三个核心指标：

faithfulness（忠实度）：回答有没有胡编，是不是基于检索到的材料；

answer relevancy（答案相关性）：回答有没有跑题，是不是用户问的；

context precision（上下文精确率）：检索出来的材料，有多少是真正有用的。

1.5 bad case 回流（Bad Case Feedback Loop）

一句话：把线上答错的案例收集起来，分析原因，改进系统，再测一遍，形成闭环。

生活例子：你考试做错题，把错题抄到错题本上，分析为什么错，下次不再错。错题本 + 复盘就是 bad case 回流。

在 Agent 里：线上答错的会话打标 → 分析是模型问题、检索问题还是工具问题 → 改 Prompt/改检索/改工具 → 加入评测集回归 → 上线验证。

一句话总结：多模型路由是“按活选人”，可观测是“装仪表盘”，埋点是“装温度计”，RAGAS 是“批作文标准”，bad case 回流是“错题本”。五个词合起来，就是“让系统看得见自己、能自己变好”。

2. 多模型路由：别拿大炮打蚊子

2.1 为什么需要多模型

原因一：成本和速度差很多

大模型准，但慢且贵；小模型快且便宜，但复杂任务搞不定。全用大模型，成本扛不住；全用小模型，效果上不去。

生活例子：你送快递，同城骑电动车，跨省发物流，国际走空运。不是所有包裹都值得空运。

原因二：不能把鸡蛋放一个篮子

只用一个模型，它挂了整个系统就挂了。多模型互为备份，一个超时切另一个。

生活例子：家里停水，你还有个桶装水备用。不是等停水了才现挖井。

2.2 怎么分级路由

按任务难度分三级：

def 选模型(任务类型):    if 任务类型 in ["意图识别", "参数抽取"]:        return 小模型    elif 任务类型 in ["知识问答", "总结"]:        return 中等模型    else:        return 大模型

class 统一模型接口:    def 调用(self, 指令, 输入): ...小模型 = 统一模型接口(配置="本地Ollama")大模型 = 统一模型接口(配置="云端GLM")

生活例子：你家所有电器都走标准插座，换电器不用改电路。统一接口就是 Agent 的“标准插座”。

2.3 超时切换：主模型挂了怎么办

try:    结果 = 主模型.调用(输入, 超时=3秒)except 超时:    结果 = 备用模型.调用(输入, 超时=5秒)

原则：主模型超时切备用，备用也超时走规则兜底。不让用户等一个已经挂了的模型。

生活例子：导航主路线堵死，自动切备选路线；备选也堵，提示“请手动选择”。

一句话总结：多模型路由按任务难度分级，统一接口换模型不改代码，超时自动切备用，不让用户等死。

3. 可观测性：给 Agent 装仪表盘

3.1 要记录什么

一个 Agent 请求，至少要记五类信息：

会话 ID：这次请求属于哪个用户、哪次对话；

每步耗时：意图识别多久、参数收集多久、工具调用多久、模型生成多久；

工具调用详情：调了哪个工具、传了什么参数、返回什么、成功还是失败；

模型调用详情：用了哪个模型、输入多少 token、输出多少 token、耗时多少；

最终结果：成功、失败、转人工、兜底，分别是什么原因。

生活例子：医院的病历。谁看的、什么症状、做了什么检查、结果是什么、开了什么药，全记下来。下次复诊一翻就知道。

3.2 怎么埋点

原则一：在节点边界埋

每个节点开始和结束各记一个时间戳，差值就是节点耗时。

def 带埋点的节点(节点函数):    def 包装(state):        开始 = 现在()        结果 = 节点函数(state)        记录埋点(会话ID=state["会话ID"], 节点名=节点函数.__name__, 耗时=现在()-开始)        return 结果    return 包装

原则二：在工具层统一埋

所有工具调用都走工具层，工具层统一记“调了什么、传了什么、返回什么、耗时多少、成功失败”。不用每个节点自己记。

原则三：记录要能串起来

所有记录都带上同一个会话 ID，出问题时按会话 ID 一查，整条链路全出来。

生活例子：快递单号。你用一个单号，能查到揽件、运输、派送、签收全流程。会话 ID 就是 Agent 的“快递单号”。

3.3 线上问题怎么回溯

用户说“昨天答错了”，你按会话 ID 查：

会话ID: abc12314:23:01 意图识别 完成，耗时1.2s，结果：开证明14:23:02 参数收集 完成，耗时0.8s，结果：{类型:在职, 用途:null}14:23:03 追问用户 完成，耗时0.1s，问题：请问用途？14:23:15 用户回复：旅游签14:23:16 参数收集 完成，耗时0.7s，结果：{用途:旅游签}14:23:17 调工具 失败，耗时3.5s，错误：接口超时14:23:18 调工具 重试 失败，耗时3.4s，错误：接口超时14:23:19 兜底节点 完成，转人工

一眼看出：错在工具接口超时，不是模型问题。不用复现三小时。

一句话总结：可观测性就是“记全五类信息、节点边界埋点、会话 ID 串起来”，出问题一查就知道错在哪。

4. 评测：怎么知道效果好不好

4.1 为什么不能只看“感觉”

“感觉还行”不是评测。感觉是主观的、不可比的、不能回归的。今天改了 Prompt，感觉变好了，但可能只是你心情好。

生活例子：你说“我今天跑得挺快”，但到底多快？没有秒表，你永远不知道是进步了还是退步了。

4.2 建评测集：一批有标准答案的题

做法：收集一批真实问法，人工标注“正确答案/正确工具/正确检索结果”，形成评测集。

[  {"问题": "开一张在职证明旅游签用", "期望意图": "开证明", "期望证明类型": "在职证明", "期望用途": "旅游签"},  {"问题": "班车几点", "期望意图": "查班车", "期望工具": "查班车"},  ...]

规模：不用一开始就几千条，200 条真实问法就能看出问题。关键是覆盖高频场景和边界情况。

生活例子：模拟考。不用把题库全做完，做一套有代表性的卷子，就能看出你哪块弱。

4.3 用 RAGAS 评 RAG：三个指标讲透

faithfulness（忠实度）：回答有没有胡编？

检查方法：把回答拆成一句句，看每句能不能在检索到的材料里找到依据。找不到依据的句子越多，忠实度越低。

生活例子：老师问你“这篇文章说了什么”，你答的内容必须能在文章里找到，不能自己编。

answer relevancy（答案相关性）：回答有没有跑题？

检查方法：把回答反推成几个问题，看这些问题和用户原问题像不像。越像，相关性越高。

生活例子：题目问“李白是谁”，你答“李白是诗人，写过《静夜思》”，相关；你答“唐朝有很多诗人”，跑题。

context precision（上下文精确率）：检索出来的材料，有多少真正有用？

检查方法：看检索结果里，相关材料排得靠不靠前。靠前的相关材料越多，精确率越高。

生活例子：你查资料，前三条就是你要的，精确率高；翻了十页才找到一条有用的，精确率低。

怎么用：改检索策略前后各跑一遍评测集，看三个指标升了还是降了。升了说明改对了，降了说明改坏了。

4.4 评测要自动化、可回归

做法：把评测集跑成脚本，每次改完代码/ Prompt 自动跑一遍，出报告。

评测报告：- 意图识别准确率：92%（上次 90%，↑2%）- 检索 Top3 命中率：91%（上次 89%，↑2%）- faithfulness：0.87（上次 0.85，↑0.02）- answer relevancy：0.82（上次 0.84，↓0.02）← 注意，这块退步了

关键：改一处可能升一处、降一处。自动化回归能让你看见“副作用”，而不是上线后才发现。

生活例子：体检报告。不是只看一项指标，是看整张表，哪项升了哪项降了一目了然。

一句话总结：评测不能靠感觉，要建评测集、用 RAGAS 三个指标量化、自动化回归看升降。

5. bad case 回流：让系统自己变好

5.1 什么是闭环

线上答错 → 打标收集 → 分析原因 → 改进 → 加入评测集 → 回归验证 → 上线 → 继续收集

转一圈，系统变好一点。转很多圈，系统持续变好。这就是闭环。

生活例子：错题本。做错 → 抄下来 → 分析为什么错 → 针对性练习 → 下次考同类题不再错。转一圈，成绩好一点。

5.2 怎么分析 bad case

拿到一个 bad case，先分类，再定位：

原则：先定位是哪一环的问题，再改那一环。不要一看到答错就换模型，可能只是工具描述写错了。

生活例子：你数学题做错，先看是公式记错了、计算错了还是审题错了。不能一错就说“我太笨了，换脑子”。

5.3 改进后必须回归

改完不能直接上线，要跑评测集：

改的那类题，正确率升了吗？

其他类题，有没有被改坏？

两个都通过，才上线。只升不降，才算真改进。

生活例子：你练了一个月跑步，先测 100 米有没有变快，再测 1000 米有没有被拖慢。都好了，才算真进步。

一句话总结：bad case 回流是“收集→分类→定位→改那一环→回归→上线”的闭环，关键是“先定位再改、改完必回归”。

6. 效果与口径：数字要带定义

简历和公众号里放数字，一定要写清口径，否则读者没法判断含金量。

6.1 你简历里几个数字的口径

意图识别准确率约 92%：在 200 条标注评测集上，意图判断正确的比例；

专属知识检索 Top3 命中率从约 60% 提升到 90% 以上：在 200 条真实问法上，正确答案出现在检索结果前 3 条的比例；

长链路端到端成功率约 88%：从用户发起请求到拿到结果、中间不需要人工介入的会话比例；

新场景联调成本降低约 70%：对比“改核心+全量回归”和“加插件+单场景测试”的人日差；

人工介入量降低约 40%：事务类咨询中，原来需要人工处理、现在 Agent 自助完成的比例。

6.2 写数字的三个原则

带定义：这个数字是怎么算的、样本多大；

带对比：改之前多少、改之后多少；

带边界：在什么条件下成立，不夸大。

生活例子：你说“我减肥了 5 斤”，要补一句“一个月内、控制饮食的情况下”。不然别人以为你三天瘦 5 斤。

一句话总结：数字不带口径就是耍流氓。带定义、带对比、带边界，数字才有说服力。

7. 面试怎么答

Q：多个模型怎么选？

A：按任务难度分级路由。简单任务（意图识别、参数抽取）用小模型/本地模型，快且便宜；中等任务用中等模型；复杂推理用大模型。抽象统一接口，换模型只改配置不改业务代码。主模型超时切备用，备用也超时走规则兜底。

Q：可观测性怎么做？

A：记五类信息——会话 ID、每步耗时、工具调用详情、模型调用详情、最终结果。在节点边界和工具层统一埋点，所有记录带同一个会话 ID，出问题按会话 ID 一查，整条链路全出来。

Q：RAGAS 三个指标是什么？

A：faithfulness 看回答有没有胡编、是不是基于检索材料；answer relevancy 看回答有没有跑题；context precision 看检索出来的材料有多少真正有用。改检索策略前后各跑一遍评测集，看指标升降。

Q：bad case 怎么回流？

A：线上答错打标收集 → 分类定位是哪一环的问题（意图/抽取/工具/检索/生成）→ 改那一环 → 加入评测集回归 → 上线。关键是先定位再改，改完必回归，防止改一处坏一处。

Q：效果怎么量化？

A：建评测集（200 条真实问法起步），用准确率、Top3 命中率、端到端成功率、RAGAS 指标量化，自动化回归看升降。数字要带口径——怎么算的、样本多大、改前改后对比。

8. 检查清单：你的 Agent“看得见自己”吗？

□不同难度的任务用不同模型吗，还是全用一个？

□换模型要改业务代码吗？ 

□主模型超时了会自动切备用吗？

□每个节点耗时都记了吗？

□工具调用详情（参数、返回、成功失败）都记了吗？

□所有记录能用会话 ID 串起来吗？

□有评测集吗，还是只靠“感觉”？

□RAG 系统用 RAGAS 指标量化了吗？

□改完代码会自动跑回归吗？

□bad case 有收集、分类、定位、回归的闭环吗？

□对外说的数字都带口径吗？

中五条以下，你的 Agent 大概率“看不见自己”，出了问题只能抓瞎。

下一篇

这一篇讲了怎么让系统看得见自己、能自己变好。下一篇是第一季的收尾：

《指标口径与面试复盘：88% 成功率、70% 成本下降到底怎么算》

我会把整个系列的数字口径统一讲清，再整理一份企业级 Agent 高频面试题清单，帮你把八篇文章的内容串成面试答案。