Agent 跑完了，不等于任务完成了

从一次舆情分析实践，到我的六个可靠性检查点

第三批采集结束后，Agent 没有生成报告。

程序没有报错，MCP 也正常返回了数据。只是经过清洗和筛选，有效记录还没达到我设定的门槛。工作流停下来问我：要不要继续采集？

我选择继续。又跑了几个批次，正式报告才生成。这次测试的是数阔和八爪鱼的品牌舆情。

如果只看自动化程度，这次停顿似乎降低了效率。Agent 没有一口气跑到底，还把决定交回给人。但回头看，它恰恰完成了这套工作流里最重要的一件事：在证据不足时，没有把“已经执行”写成“已经完成”。

自动执行和完成任务，是两套标准

现在谈 Agent，常见展示方式是一条很长的任务链：理解需求、调用工具、处理数据、生成报告，再把结果发送出去。链路越长，画面越像一个能独立工作的系统。

但真实业务并不只问“它调用了多少工具”，还会继续追问：

• 它执行的是不是正确任务？
• 输入不完整时有没有继续猜？
• 数据够不够支撑结论？
• 某一步失败后，最终状态有没有被误报为成功？
• 生成的结果能不能回到原始证据？
• 换一个主题、模型或运行环境，结果还能不能保持？

这些问题讨论的是系统可靠性。它和模型单次回答得好不好有关，却不是一回事。

结合自己的项目，我现在更愿意这样定义“可靠完成”：在明确的输入、范围和权限下，Agent 要么交付一个满足验收条件、可以复核的结果；要么准确说明当前处于什么状态、缺少什么，以及下一步需要谁确认。

一份报告不是唯一的成功状态。“需要补充输入”“证据不足”“等待授权”和“执行失败”，只要表达准确，也可能是本轮任务应该交付的结果。

我用六个检查点判断 Agent 是否可靠

舆情分析的案例让我逐渐整理出六个检查点。这不是行业统一标准，只是我目前设计和测试 Skill 时使用的一套工作框架。

模型只承担其中一部分。规则、工具、状态记录和人工确认共同决定了最后的可靠性。方案还预留了查询记录和排除原因，但这部分尚未经过真实运行核对。

证据门槛还要考虑等待成本

我使用的 MCP 数据连接器每次返回数量有限。单批太少，覆盖不足；一次拉取太多，等待时间又会明显变长。因此，我把单批设为 50 条，默认先执行三批。

三批最多得到 150 条原始结果。标准化、去重和语义筛选后，真正有效的数据通常更少。

正式报告需要同时满足三个条件：至少 100 条有效记录、5 个来源域名和 2 种来源类型。这是一条工程交付线，用来拦住样本太少、来源过于集中的报告。它不是统计学结论，也不能代表全网覆盖。

八爪鱼品牌舆情在默认三批后没有达标。工作流没有无限续跑，而是提示当前缺口。我确认继续后，它又执行了多个批次，最终达到门槛并生成报告。

这个确认点同时控制两种风险：一边是证据不足却强行给结论，另一边是为了追求更多数据，让任务运行时间不断延长。可靠性不仅是结果质量，也包含成本、延迟和用户是否仍愿意继续。

多轮采集后才达标，也不能直接推出品牌全网声量较小。时间窗口、检索词、连接器覆盖、公开网页状态和“八爪鱼”这个词的语义歧义，都会影响结果。系统看到的是本次检索范围，不是市场全貌。

LLM 改善了相关性，也留下了误删盲区

关键词只能找到候选数据。页面即使命中品牌词，也未必真的围绕目标对象，更未必能够支撑当前分析问题。因此，我在采集之后增加了 LLM 语义筛选。

我检查过最终保留的数据，它们与设定主题基本相关。这只能部分回答“留下来的准不准”，也就是精确率问题。

还有一个召回率问题：真正相关的内容，有没有被误删？

这一点我还没有验证。我没有对被排除的数据做过真实抽查，也就无法确认里面是否有应该保留的内容。方案中预留了 Excluded 表，按设计应记录排除内容和原因，但我还没有核对它在真实运行中是否完整写入。

要验证这一层，不能只看最终报告。更合适的办法是从不同排除原因中分层抽样，由人重新判断相关性，再检查误删情况。进一步还可以建立一小批人工标注数据，比较不同模型或规则的精确率与召回率。

这是我目前明确知道、但还没有完成的测试。把它写出来，比给筛选能力一个没有依据的“高准确率”更有意义。

任务路由错了，后面越自动越偏

数据进入分析前，还要先确定用户需要哪一类报告。

产品 VOC 关注功能体验、价格、痛点、购买决策和竞品选择。我用特斯拉 Model Y 跑过这条路径，并通过正式报告门槛。

事件与品牌声誉报告关注已确认事实、事件时间线、发酵阶段、各方诉求、品牌回应和风险变化。《功夫女足》的测试走的是这条路径，也生成了正式报告。

两类任务调用的可能是同一套采集工具，输出目标却完全不同。Model Y 的报告要解释用户为什么选择或放弃一款产品；事件报告要说明事情从哪里开始、在哪个节点扩散，以及不同说法分别有什么依据。

如果路由错了，Agent 仍然可以完成采集、分析和写作，只是整条自动化链都在回答错误的问题。这类失败往往比程序报错更难发现，因为每一步看起来都运行正常。

生成报告之后，可靠性还没有结束

在我实际检查过的报告里，关键结论旁保留了证据编号和原始链接，事件时间线会区分已确认事实、媒体转述和分析判断。

我核对了来源、证据链和时间线，之后又请一位做过同主题分析的人复核。对方认为，报告中的事件经过和整体证据链与实际情况基本一致，时间线也比较清楚。

这次复核提供了现实参照，但它不是专家认证，也推不出准确率。它只能说明被复核的这份报告没有在关键事实和事件脉络上明显跑偏。工具超时后的恢复、证据链覆盖、最终交付回执和同一任务的重复一致性，仍然需要分别测试。

τ-bench ↗提供了一个可借鉴的验证思路：用同一任务的多次运行观察 Agent 能否持续遵守规则。我的项目已经跑通过多个主题，也真实触发过续采分支，但还没有完成这种重复一致性评估。

这套可靠性逻辑可以跨场景复用

舆情分析只是一个例子。在其他 Skill 的设计中，我也沿用了类似的控制方式。

销售协作助手需要把客户原话、合理假设和未知信息分开。缺少预算、权限、量级或时间节点时，应该继续提问，不能为了给出完整画像而自行补齐。对外回复只生成草稿，是否发送仍由销售决定。

金融监管风险监测则更强调当前批次隔离、证据索引和适用性判断。采集到一条处罚记录，不代表目标企业已经发生同类违规；投递命令执行成功，也不应该直接等同于报告已经送达。这些目前更多体现为工作流与校验器设计，不能全部写成生产环境中的采用结果。

三个场景处理的业务不同，底层问题却相似：哪些信息是事实，哪些只是推断；什么条件允许继续，什么状态必须停；结果由谁确认，怎样留下可复核记录。

Agent 最终应该交付一个可信状态

自动化率很容易展示：调用了多少工具，减少了多少点击，流程能不能从头跑到尾。

可靠性更难，因为它要求设计者把失败也纳入系统。任务可能完成，也可能等待输入、证据不足、需要授权或执行失败。每个状态都要有进入条件、保留记录和下一步动作。

NIST AI RMF ↗强调可重复的测试、评估、验证与确认，也要求记录系统超出既定条件后的适用限制。我把这种测试和边界记录思路借用到 Agent 项目中，它比单次演示成功更接近真实交付。

所以我现在不只看 Agent 能不能把任务自动跑完。我更关心它能不能在边界内完成，在证据不足时停下，在失败时说清状态，并让最后的结果回到可核验的事实。

一个真正进入业务的 Agent，不需要每次都给出答案，但每次都应该交付一个可信的状态。