一个多跳问题让我返工：RAG 还是 Agent？

m0_74824877

422人浏览 · 2026-07-14 14:34:30

m0_74824877 · 2026-07-14 14:34:30 发布

用一次提审前的返工，讲清聊天、RAG、Workflow 和 Agent 各自负责什么

26年6月，Nameo 已经准备提审了。

我又导入了几份有关联的资料，顺手问了一个问题：先从资料里确认当前阶段，再查这个阶段对应的规则，判断能不能进入下一阶段。

系统很快给了答案，也引用了资料 A。问题是，它只找到了 A。

规则在资料 B 里。B 没找，判断自然也站不住。

我第一反应是查 chunk：是不是切碎了，或者切得太大？接着又看混合检索，怀疑 BM25、向量召回和重排的权重没调好。两个多小时倒不至于，来回检查一圈以后，我才确认第一跳其实能工作。系统缺的是拿着 A 里的线索继续找 B。

后来刷短视频，正好听到“多跳”两个字。我当时的反应很直接：

我去，这不就是我忘掉的那一步吗？

上一篇《HarmonyOS 多端实战：把手机 UI 搬上大屏后，我翻车了》讲的是 Nameo 的多端外壳。这篇往里走一层，聊聊智能问答该怎样分工。

第一跳没坏，继续拧 TopK 也找不到 B

这个问题的实际结构可以抽象成：

用户问题
  ↓
找到资料 A：最新进度
  ↓
从 A 里提取阶段名或条件编号
  ↓
形成第二个检索问题
  ↓
找到资料 B：项目规则
  ↓
组合 A + B，检查证据是否够用

我说的“关联”，是 A 里存在定位 B 所需的阶段名、条件编号或业务实体。没有读到 A，第二个问题甚至问不出来。

所以，提高第一跳的 TopK 只能让系统多拿几份相似材料。系统没有“证据不够时继续查”的机制，再多拿几个 A 也不会自动变出 B。

在这里插入图片描述

为方便说明，问题写成：

根据最新进度确认项目当前处于哪个阶段，再找到该阶段对应的准入规则，判断能否进入下一阶段；如果满足，生成一条后续待办草稿。

这句话里其实有三件事：找资料、按规则判断、准备一个可能写入系统的动作。它们不该全塞进一次模型调用。

先把聊天和 RAG 分开

普通聊天模型能解释、总结和改写，但它不知道项目昨天更新了什么，也看不到当前账号有权访问的资料。

如果答案依赖私有文件、实时数据或必须给出来源，纯聊天就不够。它可以组织语言，事实得从别处来。

RAG 的基础链路是：

问题 → 检索 → 相关资料 → 上下文 → 回答 → 来源

在这个案例里，RAG 至少要找回最新进度和对应规则，最终判断也得确实使用这两份证据。

这里很容易验错。检索结果里出现了 A 和 B，不代表回答器使用了 A 和 B。B 可能在上下文组装时被截掉，回答模板也可能只消费第一条结果。检索命中与答案综合要分开测。

Nameo 只对允许扩展的跨资料问题启动第二跳，而且最多两跳。第一跳证据不足时，从 A 提取桥接实体，再重写第二个查询。整个过程受证据覆盖、时间预算、开关和失败回退限制。

简化后的代码大概是：

const first = retrieve(question)

if (!shouldExpand(question, first)) {
  return answer(first)
}

const bridge = extractBridge(first)
const second = retrieve(buildNextQuery(question, bridge))

return enoughEvidence(first, second)
  ? answerWithBoth(first, second)
  : answerInsufficientEvidence(first, second)

第二跳没找到可靠证据时，系统可以说明已找到什么、还缺什么，不能继续下“已经达标”这种结论。

多跳验收也不能只看最后一句答得像不像。我会把它拆开：

第一跳是否找到了 A，A 里有没有可用的桥接实体；
第二个查询是否真的由桥接实体和原问题共同生成；
第二跳是否命中 B，B 是否在当前用户的权限范围内；
回答是否同时使用 A 和 B，而不是只在末尾挂两个来源；
证据不够、第二跳超时或开关关闭时，系统是否按预期回退。

这样失败时才知道该调检索、查询重写、上下文组装，还是最终回答。只盯着最后答案评分，几条链路会一起藏在一个分数里。

步骤固定，就用 Workflow

如果每次都按下面的顺序处理：

检索最新进度
  → 提取当前阶段
  → 检索对应规则
  → 校验必需条件
  → 生成待办草稿
  → 等待人工确认

这更适合 Workflow。路径由代码预先定义，失败停在哪、重试几次、每步输入输出什么，都能提前写清楚。

它的局限也直白：遇到没有设计过的分支，就没有路。但对材料检查、审批、批量导入这类稳定流程，可预测通常比“模型临场发挥”更重要。

Agent 负责选路，不能顺便获得越权资格

当用户表达很多样，系统需要根据状态在知识检索、待办查询、会议工具或写入草稿之间选择，才轮到 Agent 路由。

Nameo 当前采用的是受控单轮路由，可以简化成：

用户输入
  ↓
意图分类
  ├─ 普通聊天/知识问题 → 检索上下文 → 回答
  ├─ 待办查询 → 查询工具 → 回答
  ├─ 写入请求 → 生成确认草稿 → 等用户确认
  └─ 其他受控意图 → 对应查询或工具路径

这次分流由意图分类完成，工具返回后流程结束。

写操作还要再拆。只读查询、生成写入草稿、真正提交是三个步骤。确认卡先保存待提交参数；用户点击确认后，业务链路才执行落库。

高风险动作至少要带上权限、参数校验、幂等键和人工确认。否则模型路由对了，业务仍可能因为网络重试创建两条记录；用户取消以后，也可能有一条请求已经偷偷发出。

在这里插入图片描述

放在一起看，四种方案的差别是责任：

方案	私有资料	路径	真实动作	主要风险
普通聊天	默认没有	对话内生成	通常没有	把常识说成当前事实
RAG	可以	检索策略内	通常没有	漏召回、错召回、证据未组合
Workflow	可嵌入 RAG	预先固定	可以	流程外情况无节点可走
Agent	可调用 RAG	有界动态	可调用工具	误路由、越权、循环和成本失控