Agentic AI（四）实用技巧：评估、误差分析与组件优化

一、先做出原型，再谈评估

1.1 别空想几周，先做个能跑的

构建 Agentic 系统最难的地方在于，你没法提前知道它在哪些输入上会工作得很好、在哪些输入上会翻车，也就不知道力气该往哪儿使。所以常见的建议是：先做一个快而糙的原型，跑一遍，看它在哪里表现不如意，再集中精力改进。反过来，坐在那里推演几周该怎么做，通常是更差的选择。

关键前提是：这个原型要安全、负责任地做，不能泄漏数据，在这个底线上越快越好。有了原型，你才能盯着真实输出，把有限的时间花在真正薄弱的环节上。

1.2 端到端评估

评估（evals）的目的不是给系统打分，而是量化你觉得值得担心的地方。它长什么样，取决于你的应用怎么犯错，看三个例子。

1.2.1 发票信息抽取

第一个例子是发票处理：提取四个必填字段（收款方、收款方地址、应付金额、到期日），写进数据库。跑了一批发票后发现，模型经常把"开票日期"和"到期日"搞混——而业务关心的正是到期日，好按时付款。

于是你需要一个评估来量化到期日抽取的准确率。做法是找 10~20 张发票，人工写下每张的正确到期日，作为逐例正确答案（ground truth）。为了让代码能比对，让 LLM 始终把日期输出成 年-月-日 的标准格式，然后用正则把日期抠出来，跟人工标注比对。

1# 用标准格式约束输出，方便程序提取唯一关心的那个日期2pattern = r"\d{4}-\d{2}-\d{2}"

1# 逐例比对：抽取结果 == 人工标注的正确答案则计对2if extracted_date == ground_truth_date:3    num_correct += 1

有了这 20 个样例，你改 prompt、换算法，都能立刻看到"到期日准确率"这个指标往上走。

1.2.2 营销文案编写

第二个例子是给 Instagram 写商品文案的营销助手。业务要求每条文案最多 10 个词。跑批后发现文字读起来还行，但经常超长：太阳镜 17 词、咖啡机正常、蓝衬衫 14 词、搅拌机 11 词——模型对长度约束的执行不稳定。

这里要评估的是输出字数。建一个 10~20 条的测试集，跑完用代码数单词数，再跟 10 词上限比。注意：每条样例都按“不超过 10 词”判定，不用逐例比对正确答案。

1# 数出模型输出词数2word_count = len(text.split())3 4# 只要没超过 10 词就算对5if word_count <= 10:6    num_correct += 1

1.2.3 研究型 Agent：为每个主题列要点，交给 LLM 打分

第三个例子是研究型 Agent。让它写一篇关于黑洞科学最新突破的文章，一个被大量报道的重磅发现它只字未提；换成"调研西雅图租房还是买房"，答得不错；到了"收获水果的机器人"，又把一家领军公司落下了。它的毛病是偶尔漏掉一个人类专家一定会写的关键点。

这就没法用正则去数了，因为关键点的说法五花八门。做法是：为每个主题列出 3~5 条标准讨论点，然后用 LLM 当裁判，让LLM数一数文章里提到了几条。LLM返回一个带分数和解释的 JSON。

1{2  "score": 3,3  "count": 3,4  "total": 5,5  "explanation": "文章涵盖了事件视界、引力波探测和最新望远镜观测，但未提及射电阵列的新数据。"6}

1.3 评估标准

把上面这些评估放到一张二维图上，能看清它们的本质差别。横轴是用什么方式评估输出：用代码算，是客观评估；让 LLM 当裁判，是主观评估。

四个象限正好对应上面四个例子：

这套评估还有个名字叫端到端评估（end-to-end evals），因为一端是用户查询/提示词，另一端是最终输出，衡量的是整个系统的表现。

1.4 设计端到端评估的几条建议

• 快而糙的评估也够起步。 不少团队被"评估要花好几周"吓住，迟迟不动手。其实先放 10、15、20 个样例，写段代码或用 prompt 让模型当裁判，先拿到几个指标，配合人眼一起看输出就够用了；随着评估变复杂，再把信任逐渐从人眼转到指标上。
• 评估要跟着系统一起迭代。 你改了系统，人眼觉得明显更好，但评估分数没动——这往往是评估没抓住你的判断。这时候就该扩充样例集，或者换一种评估输出的方式，让它跟你觉得"哪个系统更好"对齐。
• 用"比专家差"来找方向。 很多 Agent 工作流是在自动化人类本来会做的任务。这类应用里，去找哪些地方比熟练人类干得差，往往就是最值得投入的方向。

二、误差分析：决定先修哪个组件

有了端到端评估，你只知道"整体有没有变好"，但不知道问题出在哪个组件。Agentic 系统组件众多，随便挑一个猛修几周，最后可能发现根本不是主要矛盾，误差分析就是用来解决这个局面的。

2.1 别靠直觉挑组件

还是研究 Agent。它漏关键点，几乎任何一个环节都可能是元凶：第一个 LLM 生成的搜索词不好，搜的方向就错；web 搜索本身不够好，把搜索结果列表交给 LLM 时没选中最值得抓的几篇；web 抓取失败；或抓回来之后，LLM 忽略了文档里的某些要点。靠直觉从这么多候选里挑一个，运气好一次中，运气不好就是几个月白干。

2.2 看 trace：每一步的中间输出

更靠谱的做法是观察每一步的中间输出。整条流程跑完后，把所有中间结果串起来，就是这次运行的 trace；其中某一步单独的输出，叫 span（这两个词来自可观测性领域）。读 trace 能让你对"哪个组件表现不佳"产生一个直观判断。

研究 Agent 的整条链路大致是这样：

以"黑洞科学最新进展"为例，一步步看：人类专家评价生成的搜索词，认为跟自己的做法接近，合理；但看 web 搜索返回的 URL，出现"小学生破解 30 年黑洞谜题（来源：AstroKid News）"这种不够严谨的页面，整体上返回了太多博客和大众媒体文章，科学论文不够，撑不起你要的研究报告质量。再到"选 5 个最佳来源"这一步，如果输入的全是非严谨文章，就不能怪它没选出好来源——给它同样一批输入，人工也只能这么选。

2.3 系统化统计错误

光有直观感觉还不够，值得更严谨一点：聚焦在系统做砸的那一批案例上（做对的先放一边），把每一步的表现记到一张表格里，统计每个组件出错的频率。这里的"错误"定义为：某一步的输出明显差于一个人类专家在相同输入下会给出的结果。

假设统计下来，"搜索词"让你不满意的概率是 5%，而"搜索结果"是 45%。那你就该仔细核对一下搜索词到底有没有问题——如果确认搜索词没问题、只是结果差，就该把注意力放到 web 搜索引擎上（比如调整参数，让它返回更相关、更高质量的结果），而不用去动链路里其他组件。

2.4 用错误频率 + 改进思路定优先级

误差分析最后给你的不是答案，而是优先级。两个维度一起看：某个组件出错频率高，而且你有明确的改进思路，那它就是最该优先做的；如果组件有问题但你毫无办法，那就不该排在前面。

这个技能之所以重要，是因为复杂系统里能做的事太多了，太容易挑一件埋头做几周、几月，最后发现对整体性能毫无帮助。

用误差分析把"该把时间花在哪"这个问题回答清楚，是高效开发 Agentic 工作流的关键能力。

三、两个误差分析实战

3.1 发票处理

发票老是抽错到期日。误差分析的目的是判断：是 PDF 转文本这一步把日期读错了（连人都看不清哪个是到期日），还是 LLM 拿到 PDF 转文本的输出后自己抽错了（比如把开票日期当成了到期日）。发票处理这条链路本身长这样：

找 10~100 张日期抽错的发票，逐张判断是哪一环的责任，记在表格里。统计后发现，LLM 数据抽取环节承担了更多错误，那么改进重点就应该是 LLM 抽取，而不是去调 PDF 转文本。否则很容易出现：花几周调 PDF 转文本，最后发现对系统整体性能几乎没有影响。

这些百分比加起来不一定等于 100%，因为不同组件的错误不是互斥的——同一张发票可能 PDF 转文本和 LLM 抽取都有问题。

3.2 客服邮件

客服邮箱工作流里，LLM 读客户邮件，查出订单信息（写数据库查询），再起草一封给人复核的回复。能出错的地方有三个：LLM 写了错的查询（比如查了错误的表，数据库就没拉到正确数据）；数据库本身数据有问题（即便查询完全正确，库里也没有正确信息）；或者拿到了正确信息后，LLM 写的邮件本身不妥当（比如漏了订单细节、算错数、语气生硬）。

对若干封回复不佳的邮件做误差分析，统计下来发现：75% 的问题集中在 LLM 写查询这一环，数据库基本正确，邮件措辞问题约占 30%。于是优先级很清晰——先改善 LLM 写查询的方式，其次才是优化写邮件的提示词。

四、组件级评估

4.1 端到端评估的代价和噪声

端到端评估能衡量"整体好坏"，但它有两个毛病：贵——每换一次组件（比如换搜索引擎），都要把整个流程重跑一遍；有噪声——即使某个组件真变好了，其他组件的随机性也可能把这点提升淹没掉。所以想在某个组件上做大量小而快的实验时，端到端评估不合适。

4.2 单独给一个组件建评估

更好的办法是单独评估你正在改的那个组件。以 web 搜索为例：找一小批查询，让专家列出金标准网络资源（这些是搜这类问题真正该出现的权威来源），然后写代码计算搜索结果与这些金标准的重叠度。信息检索里有现成的指标（比如 F1）专门衡量这类列表重叠。

• 换搜索引擎（Google、Bing、DuckDuckGo……）
• 调整返回结果条数
• 调整搜索的日期范围

每做一次这种改动，都能立即看出 web 搜索这个组件的质量有没有上升，而不必每次都重跑整条端到端流程。

4.3 什么时候还要跑端到端？

组件级评估信号更干净、改动反馈更快，适合在调参阶段反复用；但收尾前一定要跑一次端到端评估，确认单独调好的组件，放到整个系统里确实拉升了整体性能。组件级评估也特别适合多团队并行：每个团队只守着各自的组件，各有一个清晰的指标去优化，不用被全系统的复杂度牵制。

五、定位到问题后，怎么改进组件

Agentic 流程里的组件大体分两类，改进手法完全不同。

5.1 非 LLM 组件：调超参，或直接换

非 LLM 组件包括 web 搜索、RAG（检索增强生成）里的文本检索、代码执行、单独训练的机器学习模型（语音识别、人物检测等）。这类组件常见两条路：

• 调超参。web 搜索可以调返回条数、日期范围；RAG 文本检索可以调相似度阈值、切块大小；人物检测可以调检测阈值——它会带来误报和漏报之间的权衡。
• 替换组件。组件可替换性往往很高，随便换不同厂商的搜索服务、不同的检索服务就能对比谁更好。

因为这类组件差异极大，改进手法高度依赖它具体在干什么，没有统一套路。

5.2 LLM 组件：从轻到重的四条路

LLM 组件的改进顺序，通常是从成本低的往成本高的试：

1. 改提示词：加更明确的指令，或用 few-shot 提示（在 prompt 里塞一对输入-期望输出的示例），帮模型更好地理解要什么。
2. 换一个模型：很多工具（比如 AI Suite）让换模型很容易，用评估挑一个对当前任务最有优势的。
3. 拆任务：当一个步骤里塞了一大堆指令、模型顾不过来时，把任务拆成更小的步骤，或用"生成 + 反思"两段式，让两三次调用分别做好。
4. 微调模型：成本最高，通常留到前面几条路都试过了、就差最后几个百分点时才用，而且多用在比较成熟的场合。

5.3 一个例子：用 PII 脱敏掂量"跟指令"的能力

在总结客服通话时，会在摘要里出现姓名、社保号、地址这类个人身份信息（PII）。如果这份数据要做下游统计分析，就得先把 PII 抠掉。

这条 prompt 要求"识别下面文字里的所有 PII，并返回脱敏后的文本"。拿它去考验不同的模型，能看出明显的能力分层：小模型通常擅长回答简单事实问题，但不擅长严格跟指令。比如一个 80 亿参数的小模型，会先把识别出的 PII 列一遍，再给脱敏文本，然后又返一个多余的列表，还漏了姓名、没脱净部分地址；而指令能力更强的模型，能老老实实把所有 PII 列全并替换干净。这就是为什么某些任务更适合能力强一点的模型。

5.4 培养"哪个模型擅长什么"的直觉

选模型不是查个排行榜就能定的，要积累对不同模型擅长什么、能跟住什么类型指令的直觉。几条实用的做法：

• 多上手试：新模型一发布就拿各种 query 去试，闭源、开源的都试。
• 备一套个人评估：用自己的样例集反复问不同模型，校准它们在各类任务上的表现。
• 读别人的 prompt：网上有人公开自己的 prompt，很多开源包源码里也藏着作者写的 prompt，读多了对"怎么把指令表达清楚"很有帮助。
• 换模型做评估：在 Agentic 流程里换不同模型，结合 trace 或组件级/端到端评估，看谁更合适，顺带把速度、价格也摸清。

六、延迟与成本优化

6.1 先保质量，再谈成本和延迟

成本、延迟不是不重要，而是输出质量通常是最难啃的部分。先把它做对，再考虑快一点、便宜一点。一个很常见的情况是：系统上线后用户涨到成本变高，再回头把单用户成本压下来——这算"幸福的烦恼"。所以优先级一般是：先把输出质量做高，成本、延迟排后面。

6.2 计时与计费：先量化，再定位

真要优化，第一步是量化每一步的耗时与花销，知道资产在哪里。给研究 Agent 每个步骤计时，可能得到这样的时间线：

生成搜索词   7sweb 搜索     5s选最佳来源   3sweb 抓取    11s写最终文章  18s

一眼就能看出哪几步最耗时、最值得优化。成本同理：LLM 步骤按 token 计费，调 API 的工具按调用次数计费，计算步骤按服务器容量的成本计费。给每一步算清成本，就能看出哪些步骤根本不值得操心（占比太小），哪些是大头。

6.3 降延迟和降成本的具体手段

• 利用并行：独立的几步（比如多次 web 抓取）如果还没并行，可以考虑同时跑。
• 换更小/更快的模型：某一步很慢，试试能力略降但更快的模型，看是否仍然够用；或者换一个能在专用硬件上更快返回 token 的模型提供商。
• 按成本大头动手：算出每步成本后，优先替换那些单价最贵的组件或模型。

这类基准测量往往能带来很大的清晰度——它会直接告诉你某些组件在成本或延迟上"不构成主要因素"，别在它们身上浪费时间。

七、开发过程：构建与分析来回切换

把前面所有手段串起来，整个过程其实是两个动作的反复：构建（写代码改进系统）与分析（决定下一步该把构建的力气花在哪）。分析有时看起来不像在推进，但它跟构建同等重要。

随着系统成熟，分析的严谨度是逐渐升级的：

1. 先快速做一个端到端系统，直接看最终输出、读 trace，得到哪些组件可能要改的直觉。
2. 系统再成熟一些，建端到端评估，用十来二十个样例算整体指标。
3. 更进一步，做更系统的误差分析，统计每个组件导致低质量输出的频率，决定先修哪个。
4. 成熟到一定程度，再对单一组件建组件级评估，让改进更聚焦、反馈更快。

常见的问题是：经验不足的团队把大量时间放在构建、很少花时间在分析上。恰恰是分析决定了构建该往哪儿使劲。另外，追踪 trace、记录运行、计算成本的工具不少（很多 DeepLearning.AI 的短期课程合作方提供），能用；但因为 Agentic 工作流大多高度定制，最终往往还是需要自己针对业务建一批贴合问题的自定义评估。

结语

整套方法浓缩成一句话：别想太多，先做一个能跑的版本；用端到端评估量化它哪里不行；用误差分析定位是哪个组件在拖后腿；然后单独优化那个组件，并配一个组件级评估来验证每一步改进；质量稳定后再谈延迟和成本。 能做到其中一部分，就已经比绝大多数开发者成熟。既然 Agentic 工作流天生复杂，真正的差距不在写代码，而在如何用证据决定把时间花在哪。

本文由 AgentWorkFlow 生成