用一次提审前的返工讲清聊天、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 提取桥接实体再重写第二个查询。整个过程受证据覆盖、时间预算、开关和失败回退限制。简化后的代码大概是constfirstretrieve(question)if(!shouldExpand(question,first)){returnanswer(first)}constbridgeextractBridge(first)constsecondretrieve(buildNextQuery(question,bridge))returnenoughEvidence(first,second)?answerWithBoth(first,second):answerInsufficientEvidence(first,second)第二跳没找到可靠证据时系统可以说明已找到什么、还缺什么不能继续下“已经达标”这种结论。多跳验收也不能只看最后一句答得像不像。我会把它拆开第一跳是否找到了 AA 里有没有可用的桥接实体第二个查询是否真的由桥接实体和原问题共同生成第二跳是否命中 BB 是否在当前用户的权限范围内回答是否同时使用 A 和 B而不是只在末尾挂两个来源证据不够、第二跳超时或开关关闭时系统是否按预期回退。这样失败时才知道该调检索、查询重写、上下文组装还是最终回答。只盯着最后答案评分几条链路会一起藏在一个分数里。步骤固定就用 Workflow如果每次都按下面的顺序处理检索最新进度 → 提取当前阶段 → 检索对应规则 → 校验必需条件 → 生成待办草稿 → 等待人工确认这更适合 Workflow。路径由代码预先定义失败停在哪、重试几次、每步输入输出什么都能提前写清楚。它的局限也直白遇到没有设计过的分支就没有路。但对材料检查、审批、批量导入这类稳定流程可预测通常比“模型临场发挥”更重要。Agent 负责选路不能顺便获得越权资格当用户表达很多样系统需要根据状态在知识检索、待办查询、会议工具或写入草稿之间选择才轮到 Agent 路由。Nameo 当前采用的是受控单轮路由可以简化成用户输入 ↓ 意图分类 ├─ 普通聊天/知识问题 → 检索上下文 → 回答 ├─ 待办查询 → 查询工具 → 回答 ├─ 写入请求 → 生成确认草稿 → 等用户确认 └─ 其他受控意图 → 对应查询或工具路径这次分流由意图分类完成工具返回后流程结束。写操作还要再拆。只读查询、生成写入草稿、真正提交是三个步骤。确认卡先保存待提交参数用户点击确认后业务链路才执行落库。高风险动作至少要带上权限、参数校验、幂等键和人工确认。否则模型路由对了业务仍可能因为网络重试创建两条记录用户取消以后也可能有一条请求已经偷偷发出。放在一起看四种方案的差别是责任方案私有资料路径真实动作主要风险普通聊天默认没有对话内生成通常没有把常识说成当前事实RAG可以检索策略内通常没有漏召回、错召回、证据未组合Workflow可嵌入 RAG预先固定可以流程外情况无节点可走Agent可调用 RAG有界动态可调用工具误路由、越权、循环和成本失控一个知识库问答只用 RAG 很正常一个周报流程用 Workflow 也不比 Agent 低级。先看任务再看名字。别用聊天框和 loading 文案认 Agent我现在看到一个“AI 助手”页面先不看机器人头像而是看后端到底做了什么。常见的混淆有四种大模型外面套聊天框能多轮对话但没有外部知识和工具聊天框接知识库能根据资料回答这就是有价值的 RAG 应用每次固定调用同一个接口更接近 Tool Calling 或一段固定 Workflow页面显示“分析中、执行中”只说明前端写了 loading 状态。判断 Agent 更有用的三个问题是它会不会根据当前状态选路失败或预算耗尽时怎么停修改真实数据以前由谁授权和确认。也不用把门槛抬到“必须连续自主运行三天”。在业务系统里范围明确、随时能停的小自治往往更容易上线。我现在怎样做选型再遇到 AI 需求我按这个顺序问答案是否依赖私有、实时或必须追溯的知识如果是接 RAG 或受控数据查询。步骤是否稳定、能提前枚举如果是优先 Workflow。是否必须根据中间结果动态选择路径或工具如果是再考虑 Agent。会不会修改待办、订单等真实业务状态如果会补权限、幂等、确认和回滚。失败时能否说清停在哪一步说不清就先别交给真实用户。前三个问题决定能力怎么组合后两个问题决定它能不能进入真实业务。对本文这个案例RAG 找规则和进度固定 Workflow 做条件校验只有需要在多类路径之间选路时才让 Agent 参与。真正写入仍由用户确认后的业务链路完成。企业验收还要继续往下问Demo 答对一次远远不够。上线前至少要能回答最终答案用了哪些证据用户为什么能看到这些文件工具调用为什么被允许写操作在哪里确认网络重试会不会创建两条待办多跳检索的次数、时间和成本谁来限制修复失败案例后旧问题有没有回归RAG 要分别验证检索和回答Agent 还要验证路由、工具参数、状态变化与停止条件。涉及真实动作再加权限、确认、幂等和恢复。以“达标后生成待办草稿”为例至少会出现几种互相独立的失败检索阶段拿错版本的规则判断阶段漏掉一个必要条件路由阶段把“给我看看”识别成写入请求确认阶段重复提交落库成功但返回超时重试后又写一遍。这些问题不能靠一句“模型准确率不错”一起覆盖。每一段都要有自己的输入、输出、日志和停止条件。出了问题才能知道该由检索、模型、工具网关还是业务接口负责。这次返工留下的结论六月那次失败并不是模型不会说而是证据链停在了 A。聊天负责理解和表达RAG 负责找到外部证据Workflow 负责执行确定步骤Agent 负责在受控范围内选路。它们可以组合也可以只用其中一部分。短视频帮我找到了“多跳”这个名字。我后来补的是桥接线索、第二跳检索、证据覆盖、失败回退以及“检索命中”和“答案使用”两层验收。下一篇聊 Harness当聊天、检索和工具调用在我的电脑上都能跑怎样证明换个分支、再发布一次也没有把旧功能改坏。延伸阅读Microsoft LearnRetrieval-augmented generation (RAG) and indexesMicrosoft LearnBuild advanced retrieval-augmented generation systemsAnthropicBuilding effective agents