布吉岛 Agent

Appearance

12.4.3 什么时候问题已经不是“检索增强生成”，而是“任务规划 + 工具调用 + 检索”？ ​

先给结论：当问题需要“做动作”，而不仅仅是“给答案”，它就不再是 RAG 问题，而是任务型问题。此时检索只是证据来源，真正的主流程是规划与执行。

任务型问题的典型信号 ​

只要出现其中两类，就应该考虑进入“任务规划 + 工具调用”：

  • 需要多步操作（先查、再算、再写入）
  • 需要外部工具或系统（数据库、API、文件、执行器）
  • 需要状态变化（创建、更新、提交、预约）
  • 结果必须可验证（对账、核验、复核）

这些信号说明：问题不是“回答”，而是“行动”。

RAG 在任务型问题中的角色 ​

RAG 在这类问题中的定位是：

  • 提供证据
  • 支持决策
  • 约束行动

它不负责“执行动作”，也不负责“规划流程”。这两件事必须交给 Agent 或外部流程控制。

一个可落地的任务型流程 ​

你可以用下面这个结构来组织流程：

  1. 任务拆解：把问题拆成可执行步骤
  2. 证据获取：需要事实时调用检索
  3. 工具执行：对外部系统完成操作
  4. 结果核验：验证执行是否符合证据
  5. 输出交付：生成可读的结果与依据

最小伪代码示意：

python
def task_pipeline(task):
    steps = plan(task)
    for step in steps:
        if step.need_evidence:
            evidence = retrieve(step.query)
        result = execute_tool(step, evidence)
        verify(result, evidence)
    return summarize_results(steps)

流程的重点是“可控”，不是“复杂”。

什么时候仍然可以只用 RAG ​

如果问题只是“解释概念、总结文档、回答事实”，RAG 仍然足够：

  • 不涉及外部系统
  • 不需要多步操作
  • 不需要状态改变

一旦超出这些边界，就该进入任务型流程。

常见误区 ​

误区一：加了工具就叫 Agent ​

工具调用不是 Agent 的本质。Agent 的本质是“有规划、有流程、有终止条件”。

误区二：任务型问题也能靠单次 RAG 解决 ​

任务型问题需要执行与验证，单次检索生成只能给出建议，无法保证结果。

误区三：RAG 可以替代工具调用 ​

RAG 只能提供证据，无法产生状态变化。把工具调用交给 RAG，只会让系统变成“会说但不会做”。

自检清单 ​

  • 问题是否需要多步行动？
  • 是否必须调用外部系统或工具？
  • 结果是否需要被验证或提交？

一句话总结 ​

当问题需要“行动”而不是“回答”，你需要的是“任务规划 + 工具调用 + 检索”，而不是单纯的 RAG。