前几章里，我们设计了持有工具、使用记忆、多体分担的智能体。到这里，许多开发者会撞上一堵墙："做是做出来了，可它到底有没有真正好好运作，我不知道"。智能体是概率地运作的，同样的指令，每次也不会一模一样地跑。正因如此，"度量的机制（评估）"与"可视化的机制（可观测性）"，成了投入实务的生命线。本章要打下这样的地基：用数字抓住质量、复现失败、持续转起改进。
目标是"不靠直觉，靠量出来的数字把智能体做好"
为什么评估最重要
普通程序，给同样的输入就返回同样的结果。可智能体的中心坐着 LLM，它的输出是概率性的。同样的指令，选的工具、步骤、措辞每次都会微微不同。也就是说，这次跑通了，绝不保证下次也跑通。
这里藏着智能体开发独有的坑。演示时跑得漂亮，可真实用户稍微换个问法就崩了——这并不稀奇。原因很简单，"跑通了≠正确"。也许只是碰巧撞对了，10 次里说不定错 3 次。想知道究竟，只能去数。
💡 量不出来的东西，改不动。 "感觉好像变好了"不叫改进。改了提示词，成功率是升了还是降了。加了一个工具，是不是白白更慢·更贵了。能用数字比较，才第一次判断得出变更是前进还是后退。评估不是"做完之后的作业"，而是开发的地基。
还有一点要紧的，是评估别往后拖。一开始不需要完美的评估底座。但若按"先做，跑通了再考虑评估"来推进，评估多半会一直做不出来。哪怕小，也要从做出第一个智能体的那一刻起就开始量——这看着绕，其实是最快的路。评估的全貌可看《AI 智能体评估实践指南》，究竟指什么则从《什么是智能体评估（evals）》入门。
评估什么 ― 成果与轨迹
一说"评估"，多数人只会想到最终答案对不对。那的确是出发点，但对智能体只这一项不够。因为智能体"中途做了什么"极其重要。就算到达了正确答案，要是白白调用了 10 次工具、浪费了时间和成本，实务里就没法用。反过来，答案惜败错了，但中途的判断是对的——这种情况也有。
于是，我们把评估的对象分成4 个侧面来想。把这 4 个记在脑中，"不知道该测什么"的迷茫就会消失。
是否达成了给定的目的。答案准不准、是否满足要求。最基本的指标。
用了哪些工具、以什么顺序、为何调用。过程是否合理，有无绕路或多余步骤。
是否用对了工具、传对了参数。有没有调用不存在的工具、或对失败置之不理。
一次执行消耗的令牌量·费用·耗时。是否与质量相称。
📊 测"轨迹"是智能体评估的关键。 普通 AI 输出的评估是"对答案"，而智能体评估看的是"答案＋到达答案的过程"。过程脏乱的智能体，条件稍变就轻易崩掉。反之过程有条理的，即便偏一点也能扳回来。正因为看过程，才找得到改进的线索。
评估的 5 种手法
"那到底怎么测"——这里是实务的核心。评估手法有若干种，各有擅长与不擅长。别只靠一种，按要测的对象组合使用，才是定式。把代表性的 5 种，连同长处短处逐个看。
把事先备好的"正解"与智能体的输出对照，度量是否一致。适合分类·抽取·计算这类答案唯一的任务。
长处：明快、易自动化、不飘。
短处：对"正解不唯一"的自由撰写难以使用。
"是否含必需词""是否为合法的 JSON 格式""有无禁用词"等，按既定条件机械地判定。
长处：高速·低成本，擅长格式与安全条件的检查。
短处："意思对不对"这类模糊的质量测不了。
把评分标准交给另一个 LLM，让它评判输出的好坏。摘要的质量、回答的贴心度等正解不唯一的任务都能测。
长处：能大批量自动评估自由撰写与主观质量。
短处：评分者自身会飘·会偏。需要把标准写明，并人工抽检。
把代表性任务汇成测试集，每次变更都整套跑一遍。守住"昨天还通过的，别被今天的改动弄坏了"的机制。
长处：能早期发现变更导致的劣化（回退）。
短处：测试集的整备与维护费功夫。
发布后，持续观测真实用户的执行。汇集成功率·成本·延迟的走势，以及用户评价（👍／👎），追踪现实的性能。
长处：能发现只有真实环境才暴露的问题与意料外的用法。
短处：事后性。问题"发生后"才知道。须与事前评估并用。
⚠️ 组合使用是基本。 格式与安全条件用规则式，答案确定的用正解比对，自由撰写用LLM-as-judge，每次变更用回归测试，发布后用本番监控。别想用一种手法包办全部。用又便宜又快的手法（①②）筛掉大部分，昂贵的手法（③）只用在需要的地方，就能压住成本又保住精度。更详细的可参考《什么是 LLM 评估》。
评估数据（测试集）的做法
无论用哪种手法，作地基的都是"测什么的素材"＝评估数据（测试集）。它说白了，就是"对这样的输入，希望得到这样的结果"这类代表性任务的集合。这里一贫弱，再气派的评估手法也靠不住。反过来，只要有好的测试集，评估就成功了八成。
做法很简单，按下面的顺序推进。与其追求完美，不如先小小地开始、再养大，这是铁则。
把智能体实际可能收到的委托，连同典型·边界·易失败的例子一起收集。
写下每个任务"希望变成怎样"。正解、应满足的条件、评分标准，都可以。
起初 10〜20 条就够。比起数量，优先映照现场实态的"质"。
把本番里发现的失败例逐条加进测试集。用得越多越聪明的资产。
✅ 别小看"才 10 条"。 你也许觉得"样本太少没意义"。但精心挑的 10 条，远比漫无目的攒的 1000 条管用。先把真正让你头疼的 10 个代表性情形做到可测，光这一点，就能让你当场判断提示词或工具的改动是往好还是往坏。测试集不是做一次就完，而是每发现一次失败就加一条来养大，是活物一般的资产。
可观测性 ― 把运行可视化
如果说评估是"度量好坏"，那可观测性（observability）就是让"为何会那样"变得可追。评估里就算查出"成功率下降了"，要是看不到其中发生了什么，就无从修起。智能体在内部转多个步骤，从外看往往是"喂进输入，中间出了点事，冒出结果"的黑盒。把它打开、让里面可见，就是可观测性。
支撑可观测性的要素，大体有 3 个。
把一次执行从头到尾贯通记录。"输入→思考→工具调用→结果→下一步判断"这一连串流程，按时间顺序整段可追。
在每一步里，发了什么提示词、用什么参数调用工具、返回了什么。令牌消耗与耗时也留在这里。
对出问题的执行，能用同样的输入·同样的状态再走一遍。能复现，才谈得上定位原因、验证修正。
这些也可以手动往日志里补写，但实务中一般用追踪工具（tracing）。追踪工具会自动捕捉智能体的每一步，做成时间序的树，清晰可视化。"在哪一步耗了时""在哪里工具调用失败了""在哪个判断上偏了方向"，都能一目了然。
📊 追踪是"调试的眼睛"。 上例中，④处工具调用失败，⑤处智能体自己扳了回来。只看结果是"成功"，但看追踪就能看到"容易弄错列号"这个弱点。这份察觉，接向下一次改进。可观测性的思路，在《什么是 AI 可观测性（observability）》里有体系化的讲解。
转起改进的循环
到此为止的工具组——评估与测试集，以及可观测性——各自单用也有用，但真正的价值出在把它们当成一条循环转起来的时候。智能体开发不是"做一次就完工"，而是靠度量·找弱点·修正·再度量的循环，一点点变好的营生。
对测试集跑评估，把成功率·成本·延迟用数字给出来。
读失败执行的追踪，查明在哪·为何出了错。
提示词·工具说明·步骤·分工等，改动命中原因的那一处。
用同一测试集重评，确认既定改进是否出现、别处有没有变糟。
这条循环里有一个重要诀窍：一次尽量只改一处。若提示词、工具、步骤同时改，就算成功率上去了，也搞不清"是哪个改动起了作用"。正因逐个改·逐个量，变更与结果的因果才连得上，经验才积累得下来。虽不起眼，但这正是"稀里糊涂的改进"与"确凿的改进"的分水岭。
✅ 循环要转得快、转得小。 与其一次砸下大改，不如把小变更飞快地反复转，结果反而更快变好。有 10 条测试集，改完就能立刻测。这种"改→立测"的节奏一旦上身，智能体开发就从碰运气的猜谜，变成稳步前进的工程活。
- 智能体是概率性的，"跑通了≠正确"。不量就改不了。
- 评估对象有 4 个侧面 ― 最终成果·中途轨迹·工具调用·成本与延迟。尤以"轨迹"为智能体评估的关键。
- 手法有 5 种 ― 正解比对·规则式·LLM-as-judge·回归测试·本番监控，按对象组合。
- 评估数据从少量代表任务起步。精心的 10 条胜过漫然的 1000 条。加失败来养大。
- 可观测性靠执行追踪·每步日志·失败复现。用追踪工具把运行可视化。
- 改进是度量→发现弱点→修正→再度量的循环。变更逐个来，转得小、转得快。
能度量质量、让运行可见之后，接下来是"如何防止失控·误操作·滥用"。上一章第 4 章《多智能体设计》里增添的自主性，要学着安全地驾驭它。我们前往下一章第 6 章《护栏与安全》。