Chat /RAG / Agent选型指南：场景对照表、Checklist、Python骨架

很多团队做大模型项目会陷入“伪进度”：会议上讨论 RAG/Agent 很热闹，但上线后发现要么没必要、要么维护成本爆炸。
问题通常不在“模型强不强”，而在一开始形态选错：该用 Chat 的场景硬上 Agent，该用 RAG 的场景只靠 Prompt 硬编。

这篇文章给你 3 个交付物：

• 一张 Chat / RAG / Agent 选型对照表
• 一份 落地 Checklist（需求→数据→评测→成本→安全）
• 三段 最小 Python 骨架（方便你快速开工）

1）先给结论：什么时候选 Chat / RAG / Agent

• 只需要“回答得像个专家”：先用 Chat（成本最低、迭代最快）
• 需要“基于你的资料回答，且要可追溯”：用 RAG（把答案建立在可检索的证据上）
• 需要“完成动作/跑流程/调用系统”：用 Agent（LLM 负责规划 + 工具负责执行）

经验法则：能不用 Agent 就别用 Agent。
Agent 的收益来自“自动化流程”，代价来自“失败模式爆炸 + 可观测/权限/回退”。

1.1 一个更稳的判别法：证据 × 动作（四象限）

很多争论，其实是把“证据”和“动作”混在一起了。你可以用两条线把需求切开：

• 证据维度：答案是否必须来自一份“可检索、可追溯”的资料？（例如制度、产品手册、合同条款）
• 动作维度：答案是否必须触发一个“可执行的动作”？（例如创建工单、查库存、发通知、生成报表）

把它画成一个四象限，选型会很清晰：

            需要动作（调用工具/跑流程）
                    ↑
                    │  Agent（强流程）：
                    │  工单/自动化/跨系统编排
    需要证据         │
（可追溯引用）       │  RAG + Agent（最重）：
      →──────────────┼──────────────→
                    │  既要引用资料，又要执行动作
                    │
                    │  Chat（最轻）：
                    │  写作/总结/解释/建议
                    │
                    └────────────────────→
                         不需要动作

实操建议：如果你一开始不确定，就先做 Chat PoC；
当你明确“必须引用资料”再上 RAG；当你明确“必须执行动作”再上 Agent。

---

2）一张表讲清楚：选型对照表（收藏用）

形态	目标	最适合的场景	不适合的场景	依赖	常见失败模式	上线复杂度
Chat	生成/解释/总结/问答	写作、总结、代码解释、头脑风暴、轻量客服	强依赖“公司内部知识”、需要引用证据、需要执行动作	几乎无	幻觉、上下文丢失、口径不一致	低
RAG	基于资料回答 + 可追溯	知识库问答、制度/合同/产品文档、售后 SOP	数据质量差/更新混乱但期望“准确”	文档→分块→向量化→检索→重排	检索不到/检索错、分块不合理、提示拼接污染	中
Agent	规划 + 多步执行	工单处理、数据拉取分析、自动化运营、跨系统流程	没有明确动作/工具、只需要给建议	工具接口、权限、日志、回退	工具误用、越权、循环、超时、状态丢失	高

2.1 三个典型场景示例（照着套）

把“抽象名词”换成“真实需求”，你会更容易选：

1. 场景 A：销售/客服需要更快写话术、总结沟通要点

   • 目标：更快产出内容
   • 证据：不要求引用内部制度原文
   • 动作：不需要调用系统
   • ✅ 推荐：Chat

2. 场景 B：员工问“退款规则是什么？XX 情况算不算违约？”

   • 目标：答案必须一致、最好能引用条款
   • 证据：必须来自制度/合同/FAQ 文档
   • 动作：不需要下单/开票/创建工单
   • ✅ 推荐：RAG（答案“基于资料”，并尽量引用出处）

3. 场景 C：用户投诉来了，要“自动建工单→拉取用户信息→生成处理建议→通知负责人”

   • 目标：完成流程，减少人工操作
   • 证据：可能需要查知识库/历史工单（可选 RAG）
   • 动作：必须调用工单系统、IM、CRM 等工具
   • ✅ 推荐：Agent（必要时叠加 RAG 做证据检索）

2.2 三类形态的最小架构图（理解“复杂度来自哪里”）

[Chat]
User -> Prompt -> LLM -> Answer

[RAG]
User -> Query -> (Embedding) -> Vector Search -> (Rerank) -> Context -> LLM -> Answer(+Citations)

[Agent]
User -> Planner LLM -> Tool Calls -> Tool Results -> Planner LLM -> ... -> Final Answer/Action
                      (需要：权限/日志/回退/停止条件)

---

3）落地 Checklist（从“能跑”到“能上线”）

3.1 需求（先把边界写清楚）

• 输入是什么（文本/文件/截图/表格）？
• 输出是什么（自然语言/结构化 JSON/可执行动作）？
• 失败能不能接受（错一次损失多大）？
• 需要不需要“可追溯证据”（需要就倾向 RAG）？
• 需要不需要“执行动作”（需要就倾向 Agent）？
• 是否需要“可解释/可审计”（例如：答案引用来源、动作有日志）？
• 是否存在“高风险动作”（高风险动作必须有人审/二次确认）？

3.2 数据（RAG 必做）

• 文档来源与版本（谁维护、多久更新）
• 分块策略（chunk size、overlap）
• 检索质量评估（Top-k、召回率、重排）
• 证据引用格式（答案里明确引用来源）
• 文档更新策略（增量更新/全量重建/过期清理）
• “不可用资料”处理（缺失/冲突/过期时的拒答/提示）

3.3 评测（没有评测就没有迭代）

• 代表性问题集（至少 30–100 条）
• 评价维度（正确性、覆盖率、可读性、引用质量）
• 线上指标（失败率、平均延迟、成本）
• 关键业务场景设“金标准”（哪些问题必须 100% 正确）
• 为 RAG 单独评测“检索质量”（检索到对的文档/段落，生成才可能对）

3.4 成本与稳定性（上线必看）

• 超时与重试策略（尤其是 Agent）
• 限流与并发（防止爆账单/打爆下游）
• 缓存策略（固定提示词/重复问答）
• 降级策略（模型不可用时：切换模型/只返回检索结果/转人工）
• 关键链路可观测（请求日志、耗时分布、错误码、重试次数）

3.5 安全（Agent 必做）

• 工具权限最小化（只给必要权限）
• 关键动作二次确认（删库/转账/发通知）
• 审计日志（谁触发、做了什么、结果如何）
• 工具输入校验（白名单/正则/范围检查）
• 防提示注入（把“用户输入”和“系统指令”隔离，工具参数不让模型随便拼）

3.6 最小评测方案（按形态）

你不需要一上来就做复杂评测，先做“最小可用”的版本：

• Chat：30 条代表性任务（写作/总结/解释/拆解），人工打分 + 记录失败原因（幻觉/跑题/格式错）
• RAG：
  1. 先评检索：Top-k 里是否能命中正确资料（命中率）
  2. 再评生成：答案是否引用了正确片段、是否“只基于资料”
• Agent：
  1. 任务成功率（端到端完成）
  2. 工具调用正确率（参数是否正确）
  3. 失败可恢复率（重试/回退后是否能继续）

---

4）最小 Python 骨架（可直接复制改造）

说明：这里用“OpenAI 兼容”的写法做示例。你需要填：api_key、base_url、model（以你所用服务的文档为准，例如 https://147ai.com）。

4.1 Chat：最小可用（建议先封装一个调用函数）

from openai import OpenAI

client = OpenAI(
    api_key="YOUR_API_KEY",
    base_url="YOUR_BASE_URL",  # 例如 https://xxx/v1
)

def llm(messages):
    resp = client.chat.completions.create(
        model="YOUR_MODEL_NAME",
        messages=messages,
    )
    return resp.choices[0].message.content

print(llm([
    {"role": "system", "content": "你是一个严谨的技术助手。"},
    {"role": "user", "content": "把下面这段需求拆成任务清单，并给验收标准：..."},
]))

4.2 RAG：最小链路（更贴近真实工程的骨架）

RAG 最关键的不是“把资料拼进去”，而是这三件事：

1. 检索要准（先命中文档/段落）
2. 上下文要干净（别把无关内容塞进去污染模型）
3. 答案要可追溯（至少返回引用片段/来源标识）

def retrieve(query: str) -> list[str]:
    # 1) 把 query 向量化
    # 2) 去向量库 top-k 检索
    # 3) （可选）重排
    return ["doc_chunk_1", "doc_chunk_2"]

def rag_answer(query: str) -> str:
    context = "\n\n".join(retrieve(query))
    prompt = f"""你是企业知识助手。
请只基于<资料>回答；如果资料不足，请回答“资料不足”。
<资料>
{context}
</资料>
问题：{query}
"""
    return llm([{"role": "user", "content": prompt}])

4.3 Agent：最小循环（把“护栏”写进代码里）

Agent 不是“更聪明的 Chat”，它更像一个会犯错的“实习生流程机器人”。
最小护栏建议固定三个：最大步数、超时、关键动作确认。

tools = {
    "search_kb": lambda q: "...",
    "create_ticket": lambda title, detail: "...",
}

def run_agent(task: str):
    # 1) LLM 规划
    # 2) 需要工具时调用工具
    # 3) 把工具结果回填给 LLM
    # 4) 直到完成或触发停止条件（最大步数/超时/人工确认）
    pass

提醒：Agent 一旦上线，日志与审计非常关键。建议至少记录：每一步的输入输出、调用了哪个工具、参数是什么、结果是什么、耗时多少。

---

5）最后提醒：别把“形态”当信仰

• 你不确定时，先用 Chat 做 PoC
• 一旦发现“必须基于资料回答”，再加 RAG
• 一旦发现“必须执行动作”，再上 Agent