Perplexity AI：AI Agent 的一个真实用例

看完概念和框架，值得看一个真实产品：把搜索做成 agent 是什么样的。

这个产品形态的 agent 循环

理解问题 → 决定搜什么 → 搜（工具调用）
   → 读回来的东西（观察）→ 够不够答？
      不够 → 换个关键词再搜（回到上一步）
      够了 → 写答案，并标注每句话的来源

「不够就再搜一次」这一步是它 agent 的地方 —— 搜几次、搜什么，是模型每一轮决定的。

最难的一格是 grounding

这类产品真正的工程难点不是让它会搜，是让它说得出每句话是从哪儿来的。

原因是模型有一个很稳定的倾向：它会顺着语感把话说完整，即使材料里没这么写。

我在自己的项目里量过一次同类问题：让模型从产品文档生成内容，它产出的断言里引用了 12 条界面文案，回头去文档里查只有 4 条查得到。剩下的都是编的 —— 看起来无比合理的那种编造。

对搜索产品来说，这类编造是致命的，因为产品的全部价值就建立在「它引用了真实来源」上。

怎么治：external anchoring

这个垂类的综述给了明确方向：幻觉控制做得好的系统，无一例外都引入了外部锚点机制 —— 每条产出必须能指回一个来源。

落到实现上有三条：

产出的 schema 里必须有来源字段，而且它要被校验，不是被信任
校验的对象是原始材料，不是上一步的产物 —— 否则上一步脑补的东西会被当成事实引用
查不到来源的内容，宁可不输出

第三条最反直觉也最重要：少说一句，比说一句查不到出处的话，代价小得多。

引用不等于理解对了

这一条要说清楚，因为它常被混淆。

模型可以正确引用一段材料，然后得出错误的结论。 出处解决的是编造，不解决推理错误。

所以「每句话都有引用」不等于「答案是对的」。它只是把错误的种类从「凭空捏造」缩小到「引用了但理解错了」—— 这是很大的进步，但不是终点。

这类产品的评测很难

值得提一下，因为它解释了为什么这个方向进展看起来慢。

有基准专门测「让 agent 自己拆出要点再去核对」这类任务，十个模型没有一个 F1 超过 30%。而且失败方式分成两派：要么误报率约 70%，要么召回低于 25% —— 没有一个能同时做到准和全。

这两种坏法在产品上后果完全不同：乱报的那派会先被骂然后被弃用；漏报的那派会安静地活很久，直到某次出事。而它们在总分上可能差不多。

所以只看一个总分是不够的，得知道它滑向哪一边。

从这类产品能学到的三件事

一、agent 的价值在「多轮」，不在「一轮更强」。 搜一次答不上来就换个词再搜 —— 这个能力是单次调用给不了的。

二、产品的信任建立在可核对上，不在流畅上。 答案写得漂亮但没法核对，用户第一次发现错误之后就不会再信。

三、要有一条「我不知道」的出路。 一个永远给得出答案的系统，一定在某些时候是编的。

边界与代价

这一篇是从外部观察一个产品形态，不是内部实现的还原。 我没有它们的架构文档，上面的循环是按公开行为和通用模式推的。

搜索类 agent 的成本结构很特殊： 每多搜一轮就多一次外部调用加一次模型调用，而用户对延迟的容忍度很低。所以这类产品的「多搜几轮」在工程上是被严格限制的 —— 不是它不想搜，是搜不起。

引用做得好也挡不住一类问题：来源本身是错的。 引用了一个不靠谱的网页，格式上完全合规，内容还是错的。**grounding 保证的是可追溯，不是正确。**这条边界在验证器那一篇也成立。

外部锚点这件事我自己实测过一次，数字挺刺眼：让模型从一份产品文档里抽约束，它写出 12 条，我逐条回文档里查，只有 4 条查得到，剩下 8 条是它顺着经验补的 —— 而那 8 条听起来比查得到的那 4 条还专业。后来我把「每条必须逐字抄一句原文当依据」做成拒收门，第一版又太严，通过率直接掉到 0%，因为它连合理的推导都不许写。我的经验是这道门要卡在「引号里的原话必须能在原材料里找到」，而不是「所有内容都得有出处」 —— 前者可执行，后者会把系统卡死。