第 12 章　一个会聊天的 AI，为什么还需要资料和工具

先把“AI完成了”拆成可以检查的职责

这项任务至少包含六个不同责任：

人说明目标、课程和允许使用的材料
        ↓
检索系统找到可能相关的原文
        ↓
模型依据原文整理候选清单
        ↓
人确认日期、冲突和最终内容
        ↓
应用检查参数与权限，调用日历工具
        ↓
工具返回结果，人查看现实状态

这条链不是唯一架构，却能防止一句“AI做了”掩盖角色差别。模型生成“创建日历事项”这几个字，不会让日历发生变化；检索系统找到了某段文字，也没有证明它仍然有效；工具返回成功代码，还需要确认写入的是正确账户和正确时间。

系统设计应先确定任务在哪些位置需要事实、权限、执行和验收，再判断模型适合承担哪一段。模型只是其中一个部件。

资料准备链：RAG运行以前，文件先变成可检索材料

大语言模型不能只凭参数保证掌握这门课最新、完整、获授权的安排。为了让回答接触外部资料，可以使用检索增强生成（Retrieval-Augmented Generation，RAG）↗：先从资料集合中找出与问题相关的内容，再把这些内容送入模型的当前上下文，由模型据此形成回答。[1]

“给AI一个资料柜”适合建立直觉，却省略了资料进入检索系统以前的准备工作。

第一步是确定资料范围。课程大纲、实验指导书和正式通知可以进入；成绩、学生名单、私人聊天和未获授权课件不应顺手混入。范围不清时，后续检索越方便，数据与权利风险越大。

第二步是整理和切分。系统通常不会每次把所有文件完整塞给模型，而会把材料分成较小片段，并保存标题、发布日期、章节、课程名称等元数据。切得太大，检索结果会携带大量无关内容；切得太小，定义与条件可能被拆开。

第三步是建立可检索表示。传统检索可以根据关键词匹配，现代 RAG 也常把文本片段转换为向量表示，再寻找与问题在表示空间中较接近的片段。向量检索擅长发现措辞不同但语义相近的内容，却可能把“看起来相关”误当成“足以回答”。向量数据库只是保存和查找这些表示的一类工程工具，不是新的知识来源。

第四步是版本与权限。若“实验课安排”同时存在旧通知和新通知，系统至少要保留日期、发布者和替代关系。没有版本信息的高相似度片段，可能把过期内容排在最前面。

RAG的质量在用户提问以前就已经被资料选择、切分、表示和元数据设计限制。很多所谓“模型回答错误”，根因其实在检索链的更早位置。

把这段准备工作压成一条链，大致是：

登记获准使用的原始文件
  → 保存课程、发布者、日期、版本和替代关系
  → 按语义与版面切分，并保留回到原文的位置
  → 建立关键词或向量索引
  → 用测试问题检查能否找回关键片段
  → 文件更新时重建受影响部分

这条链通常在资料加入或更新时运行，不是每位学生每问一次都把全部文件重新处理一遍。准备阶段若没有留下版本与权限，查询阶段再聪明也无法凭空补回。

每次查询链：一个问题怎样取回片段并形成回答

学生问“下周实验课准备什么”时，系统先把问题转成检索请求。它可以加入课程标识、日期范围和材料权限，再从索引中取回若干候选片段。有的系统还会重新排序，优先选择更匹配、更可靠或更新的材料。

下面把教学情境里的两份通知写成可追查记录；编号、日期和分数均为构造示例，不对应真实课程：

问题经过课程编号和“下周”日期范围改写后，检索器可能给D-03示意相似度0.87，给D-07示意相似度0.84。这个数只表示特定检索器中的匹配程度，不是正确概率。若系统只按相似度取第一名，就会把旧通知交给模型；若保留了替代关系，排序或后处理才有机会把D-07置于有效位置。

一次查询运行链可以写成：

用户问题与权限
  → 加入课程和日期条件
  → 召回D-03、D-07等候选片段
  → 根据版本、来源和任务重新排序
  → 把问题、片段及引用要求送入模型
  → 生成带出处的候选清单
  → 人确认冲突与最终日期

取回的片段与问题、系统要求一起组成模型本轮输入。模型需要从材料中提取要求、合并重复项、标明出处，并避免把材料没有说过的常识补成课程规定。

在这个例子里，检索同时找到了周三旧通知和周四新通知。系统应把冲突呈现出来：两份材料的发布时间是什么，后一份是否明确替代前一份，仍缺谁的确认。让模型“综合判断一个最可能日期”会把证据缺口藏起来；发现不能继续的理由，本身就是有价值的结果。

RAG常见的失败可以落在不同层：

因此，“使用了RAG”只能说明系统增加了外部检索步骤，不能直接证明回答正确。它把部分错误从不可见变得可追查，前提是系统确实保留来源与过程。

工具调用把语言请求交给能够执行的程序

清单确认以后，学生要求加入日历。这一步会改变外部系统，需要工具调用（Tool Calling）↗。

一种常见实现是：应用先向模型提供可用工具的名称、参数结构和用途；模型根据对话生成结构化调用请求，例如工具名为“创建日历事项”，参数包含标题、开始时间、结束时间和提醒方式。真正执行工具的是周边应用，而不是模型。[2]

执行前，应用要完成普通软件同样需要的工作：验证日期格式，检查必填参数，确认账户和权限，限制工具可以访问的范围。用户确认也不能只剩一个笼统的“是否允许”；他应看见即将写入的时间、标题和提醒方式。

执行后，工具返回结果。返回“成功”只是程序层证据，用户还应能在日历中看到事项，必要时修改或撤销。若工具超时、权限失效或参数错误，系统应报告真实状态，不能让模型用一段流畅文字补成“已经完成”。

模型提出调用、应用批准并执行、工具返回结果、人确认现实状态，是四个不同事件。把这四步写清，才能讨论自动化是否可靠。

一条完整系统记录，应该让后来者看见什么

把上面的准备、查询和执行连起来，一次任务可以留下下面这份最小记录。字段仍是教学构造，真实产品会有不同名称，也不应无限保存个人数据。

如果记录只剩“AI已完成”，后来者无法判断错在资料、检索、生成、参数还是工具。反过来，记录越多也不一定越可靠；它只应覆盖追溯、纠错和恢复所需的最少信息。

工作流与Agent的分界，在于下一步由谁决定

若步骤完全固定：读取指定资料，生成清单，等待确认，写入日历，这可以是一条工作流。模型参与某一步，不会让整套流程自动变成Agent。

任务变成“根据实验进度安排本周准备工作”后，系统需要读取当前状态，判断还缺什么，选择下一项工具，根据结果调整计划。这时，它接近本书所说的Agent模式↗：系统围绕目标，让模型在限定范围内选择动作，接收外部反馈，再决定继续、改道或停止。ReAct 展示了“推理—行动—观察”交替的一种研究范式，但并非所有Agent的统一定义。[3]

Agent不是一种拥有责任的新主体，也不必然比普通工作流更先进。开放选择增加了适应性，也扩大了错误路径。只要系统可以自主选择下一步，就要同时回答：它能调用哪些工具，最多执行多少步，哪些动作必须经过确认，状态保存在哪里，失败怎样回退，谁能接管。

有时最好的设计仍是固定流程。课程日期确认、付款、提交作业和修改重要记录，都不应因为“Agent更智能”就移除明确确认点。

评价一套AI系统，要沿任务链逐段验收

评价模型常用语言质量、任务正确率或基准测试；评价完整系统还要增加别的证据。资料是否覆盖任务，检索能否找到关键片段，引用能否回到原文，工具是否执行正确，错误能否停止，用户能否理解和撤销，都是独立问题。

一个可检查的系统，不在“回答生成”处结束。课程原文提供事实，模型整理候选，应用验证参数和权限，工具改变外部状态，人查看结果并决定是否保留。任何一环没有证据，任务都只能停在相应位置。

LLM、RAG、Tool Calling和Agent只是路标。新工具不断变化，资料准备链、查询链、执行链和验收记录仍然可以帮助人看清系统究竟做到了哪一步。