提示词工程与智能体基础

学习目标与贯穿案例

本讲任务

• 将一个业务需求拆成可检查的输入、处理步骤和交付物。

• 用结构化输出连接工具，用运行反馈修正下一步行动。

• 设计一条能够找到证据、引用证据、处理缺失信息的 RAG 流程。

• 用测试样例检查结果、成本和失败原因。

课程问题与学习路线

• 业务提示：把需求表达成可检查的任务和输出契约。

• 模型运行：理解采样、延迟和上下文成本，选择合理的任务方案。

• Agent 系统：决定谁控制步骤，怎样取得观察、更新状态和停止。

• RAG 与评估：让资料进入证据链，用案例与失败记录检验整个流程。

贯穿案例：校园文创店售后助手

• 业务目标：根据店铺制度和订单事实，生成可供客服复核的售后答复。

• 用户问题：10月20日收到普通非定制徽章，10月24日申请退货。未拆封、不影响再次销售、无质量问题，付款截图已核验且匹配本店订单，可以退吗？

• 现有材料：新版制度、旧版制度、凭证说明和订单记录。

• 交付范围：判断申请条件、解释依据、列出待核实事项。实际退款由有权限的人员处理。

• 本讲的店铺、制度、订单与数值均为教学示例。

任务方案的选择

• 先用能满足需求的简单方案，再根据实际失败增加组件。

系统、数据与评估

• 同一个错误可能来自不同层次。例如误用30日规则，既可能是资料失效标识缺失，也可能是筛选和生成出错。

一、业务提示与结构化交付

课堂讨论：提示词工程“已死”？

观点延伸：还需要设计什么？

业务任务书

• 目标：为这一笔售后咨询生成答复草稿。

• 输入：用户描述、授权读取的订单字段、适用制度。

• 输出：申请条件判断、条款依据、待核实事项、下一步建议。

• 验收：日期计算正确，每项关键判断有依据，缺失条件明确标出。

• 操作边界：查询和起草可以自动完成，系统不据此直接执行退款。

分阶段提问的交付物

• 每一步保存结果，避免在一段长对话中反复猜测已经完成的工作。

缺失信息的处理

• 关键条件缺失：缺少收货日期时，先询问日期，再判断是否在申请期限内。

• 可选信息缺失：没有顾客称呼时，可以生成不带称呼的草稿。

• 证据缺失：未取得适用条款时，标记“依据不足”，继续检索或转人工。

• 信息矛盾：用户自述未拆封，订单备注写已拆封，应保留矛盾并请求核实。

• 追问应指向影响判断的字段，避免重复询问已经得到的信息。

生成、分类与规则校验的分工

• 生成式模型可以完成分类任务，但固定枚举、可计算条件仍可由程序约束和核验。

输入与输出契约

用输入输出签名描述任务

输入：question、known_facts、policy_chunks、tool_results
输出：decision、reason、evidence、missing_fields、next_step
任务：根据适用制度判断这一笔售后申请的条件。

• 签名（Signature）明确模块接收和交付什么，便于更换模型或拆分流程。

• 可以把“事实抽取”和“规则判断”分别定义签名，再核对前后字段是否兼容。

• 上述是任务接口示意，具体字段类型和校验仍需落实到所用系统。

可解析的输出示例

{
  "decision": "eligible",
  "reason": "第4日，商品状态符合要求，付款截图已核验。",
  "evidence": ["D1#R1", "D4#R4"],
  "missing_fields": [],
  "next_step": "提交客服复核"
}

• 这是 T1 条件已核验时的预期输出。具体判断仍需与制度原文核对。

• 输出契约只表达申请条件，退款是否完成需要读取实际执行结果。

结构校验与业务校验

• 提示中要求 JSON 属于软约束。平台支持时，可增加 Schema 或约束解码。

• 合法的结构仍可能承载错误的事实，业务校验需要单独完成。

输出 Schema 的最小约束

{ "type": "object", "required": ["decision", "evidence"],
  "properties": {
    "decision": {"enum": [
      "eligible", "ineligible", "insufficient"]},
    "evidence": {"type": "array",
      "items": {"type": "string"}}
  }
}

• 这是讲解用的局部 Schema。课堂包另附包含全部5个字段的完整契约。

提示约束、生成约束与校验

• 结构校验失败时，可在预算内要求修复并重新校验，或直接转入受控失败。

• “引用编号存在”与“原文支持该判断”是两项检查，后一项需要阅读证据。

根据失败样例修改提示

• 失败输出：“可以退货，我们已为您办理退款。”

• 定位问题：把申请条件判断扩大成了实际执行状态。

• 修改要求：区分“符合条件”“待审核”“已执行”，仅依据工具返回值描述执行状态。

• 再次测试：正常样例、缺日期样例、工具超时样例均检查状态表述。

• 每次记录修改原因和测试结果，再决定是否保留这一改动。

二、推理预算与上下文管理

解码策略与任务取舍

• 接口未必暴露全部策略。固定使用条件，再比较任务效果；不要把采样概率直接当作业务正确率。

温度与结果稳定性

• 温度影响采样分布的集中程度，较低温度通常减少输出变化。

• 信息抽取和固定分类优先关注稳定性，创意草稿可以比较不同采样设置。

• 温度为0也不能保证跨运行、跨系统完全一致，更不能保证事实正确。

• 模型和平台支持的参数不同，实验时记录实际可用的设置。

输入处理与输出生成

• Prefill：处理已提供的上下文，建立后续生成所需的计算状态。

• Decode：逐步生成后续 token，利用已有状态继续计算。

• 大量无关输入会增加处理负担，冗长输出也会增加生成时间。

• 首 token 时间（TTFT）反映开始响应的等待，整项任务耗时还包括后续生成、工具调用和重试。

推理阶段示意

首次响应与完整回答的延迟

$$T_{\mathrm{answer}}\approx T_{\mathrm{first}}+(N_{\mathrm{out}}-1)\,t_{\mathrm{token}}$$

• $T_{\mathrm{first}}$ 是首 token 时间，$t_{\mathrm{token}}$ 是后续 token 的平均生成间隔。

• 假设演算：首 token 需1.2秒，输出121个 token，之后每 token 约0.04秒，则约需6秒。

• 完整 Agent 任务还要计入后续模型调用、工具等待和重试，流式显示只改善开始阅读的时间。

一项任务的成本记录

• 对比“完成一项合格任务”的总成本，纳入失败重试和人工返工。

多轮调用的 token 累计

• 本例每轮携带此前历史，累计输入为7500，累计输出为600，不能只看最后一轮的3000。

• 缓存计费、内部推理用量和工具费用取决于具体系统，应按实际记录核算。

推理预算的分配

• 简单字段抽取可先采用较小计算预算，复杂冲突判断再增加预算或转人工。

• 增加推理时间或重复采样，可能改善部分任务，也会增加成本与延迟。

• 能计算的日期交给程序，能查询的订单交给工具，结论要能回到证据核查。

• 多次生成相同答案只能说明一致，仍需检查共同使用的依据是否正确。

本轮上下文的装配

上下文装配示意

一次任务的上下文预算

• 容量规划：为任务要求、用户事实、证据、工具结果、必要历史及输出预留空间。

• 假设本系统的输入与输出共用8000 token，规划为2000固定内容、3000证据、1000状态和2000输出。

• 证据超过3000时，先筛选、去重或分阶段读取，不能只截取前部后丢弃关键例外。

• 实际限制和内部推理 token 的计入方式依系统而异，预留预算后仍要检查截断与完成状态。

上下文膨胀的处理

• 为不同用途选择材料：期限判断需要期限条款，凭证判断需要凭证条款。

• 较大的上下文容量只表示“能够放入”，可靠利用材料的能力需要任务测试。

• 同一条款重复出现时去重，保留原文定位和适用版本。

• 先测试检索、筛选和摘要的实际效果，再决定保留多少历史信息。

上下文选择的对照实验

• 固定问题、模型和其他条件，保留实际输入；不要仅比较模型生成的摘要长度。

• 将“付款截图尚未核验”放在长历史中，检查压缩后 T12 是否仍输出信息不足。

压缩后的任务交接记录

目标：生成售后答复草稿，实际退款交客服复核。
已知：10-20收货，10-24申请，普通商品，未拆封。
已查：D1#R1为有效期限规则，D4#R4说明凭证条件。
待核实：付款截图是否能匹配本店这笔订单。
未完成：输出带依据的答复草稿。
原始材料：保留文件、条款和订单查询结果定位。

• 压缩后逐项核对约束、未完成事项和证据位置。摘要中的判断仍须有来源。

持久记忆的内容分类

• 这是按内容划分的记忆，和按保存时间区分长短期记忆是不同维度。

• 多轮对话或写入记忆通常改变输入与外部存储，并未据此更新模型参数。

记忆的写入与读取

• “顾客自述未拆封”应保留自述来源，不能在记忆中升级成店员已核验的事实。

• 一次错误的模型判断也可能被记忆放大，写入前需要检查真实性和保存必要性。

缓存与上下文顺序

• 模型推理可以复用已经计算的部分状态，常见机制包括 KV Cache。

• 对支持前缀缓存的系统，稳定的公共前缀有利于复用，具体条件由实现决定。

• 把本次新增的用户信息和工具观察按顺序追加，减少无必要的前部改写。

• 更换制度版本时，应使本次上下文采用新版本，并按系统机制刷新相关缓存。

模型选择的任务检查表

• 用自己的任务及运行条件选择模型，保留模型版本和实际设置。

三、工作流与智能体运行

工作流与 Agent 的步骤控制权

• 设计时明确每一部分由谁控制，哪些决策必须由程序规则约束。

Agent 组件与环境

预先列步骤与根据观察调整

• 先列计划有助于组织任务；运行过程中仍要用实际观察检查计划是否适用。

售后助手的组件分工

• 系统、数据和评估需要配合设计，单独改提示难以解决所有运行问题。

工具说明决定可用范围

工具：lookup_order
用途：读取当前用户授权范围内的一笔订单。
输入：order_id，字符串。
成功输出：收货日、商品类型、订单状态。
失败输出：错误码，不返回猜测的订单信息。
操作属性：只读，不修改订单，不发起退款。

• 工具说明应交代用途、必填参数、返回内容和失败状态。

• 系统从登录身份或授权记录判断访问范围，不能只信模型传入的身份。

工具调用的责任链

1. 选择：模型从可用工具说明中提出调用请求。

2. 填参：生成 {"order_id": "A1042"}。

3. 校验：程序检查字段、订单访问权限和调用预算。

4. 执行：程序实际调用工具，接收结果或错误。

5. 回传：将观察结果加入任务状态，再决定继续还是结束。

• 模型写出一段调用文字，并不表示工具已经执行成功。

工具结果与业务事实

{
  "order_id": "A1042",
  "received_at": "2026-10-20",
  "item_type": "regular",
  "status": "delivered"
}

• 已经取得：收货日期、商品类型和已送达状态。

• 还需核实：是否拆封、质量问题和付款截图是否匹配本订单。

• “已送达”不能推出“符合全部退货条件”。

根据观察调整行动

• ReAct 将推理与实际行动交替组织。教学中展示决策理由、调用和观察，便于复核。

一次决策应改变什么

• 当前缺口：知道收货日与品类，但不知道付款截图的适用条件。

• 选择行动：查询凭证条款，而不是再次查询已经取得的收货日期。

• 取得观察：找到 D4，并明确“可核验且匹配本店订单”的要求。

• 更新状态：新增条款依据，保留截图是否已核验的事实状态。

• 下一步：材料齐全则生成草稿，仍缺事实则追问，不用语言补出一个结果。

Agent 循环的最小伪代码

state = 初始化目标、事实、证据和预算
while 预算可用:
    action = 根据state选择下一步
    校验action；失败则受控修复或接管
    if action为最终答复:
        通过校验则交付，否则交接；结束
    observation = 执行工具取得成功或错误
    更新state、扣预算、记日志
预算用尽：交付进度、限制和接管说明

常见失败与恢复方式

• 对具有写入效果的操作，重试前还需确认上次是否已经生效。

任务状态与停止条件

• 状态记录：已知事实、证据位置、工具结果、未完成事项与预算余量。

• 正常结束：输出满足字段、证据和操作范围要求，并通过检查。

• 受控结束：缺少关键条件、权限不足、达到调用或时间预算。

• 本课堂可先设“最多6次工具调用、同一失败最多重试1次”，再用测试调整。

• 预算耗尽时交付已完成内容、限制和接管建议，避免循环尝试。

模型与运行程序的责任边界

• 某个控制只存在于提示词中时，应检查运行程序是否还需要独立执行它。

工具调用、RAG 与 MCP

• 三者可以组合。协议连接之外，仍要设计检索质量、业务校验与访问权限。

人工接管的交付内容

• 当前目标与进度：为哪笔咨询生成草稿，哪些步骤已经完成。

• 已取得的依据：用户自述、工具观察和条款分别标注，保留原始位置。

• 未解决事项：例如截图无法匹配订单、同日有效制度发生冲突。

• 需要的人工决策：明确请谁核验什么，避免只输出“处理失败”。

• 转交后记录后续处置，供回测和经验维护使用。

反思与经验写入

• 失败事实：一次答复使用了已失效的旧版退货规则。

• 原因记录：检索结果缺少生效时间字段，版本检查未能执行。

• 改进措施：补充元数据，并增加旧版优先出现的测试样例。

• 经验写入：记录已验证的故障原因、修复方式和适用条件。

• Reflexion 可以利用文字反馈改进后续尝试，是否提升效果仍需测试。

四、RAG的证据流程

RAG 在业务流程中的位置

• 本讲已知 RAG 的基本思路：检索外部材料，将相关证据交给模型生成答复。

• 离线准备：整理原文、切分片段、保存元数据、建立索引。

• 在线处理：理解问题、检索与筛选、重排、装配上下文、生成与校验。

• 维护更新：新增有效版本、处理失效材料、用失败样例回测。

知识库的最小资料清单

• 四份制度均属于本例的同一店铺。

• 演示时可以用四段文本构建小知识库，原文见后文综合实践。

文档解析与分块

• 保留标题层级，将“普通商品”“定制品”“质量例外”分别组织成可识别片段。

• 每个片段尽量包含完整的规则及其适用条件，避免切断“但”“除外”等限制。

• 表格保留列名、单位和必要的表头，不能只留下脱离语境的数值。

• 分块大小和重叠范围由资料结构及测试决定，不存在适合所有资料的固定数值。

• OCR 或解析错误会传递到检索与回答，入库前先核对关键条款。

分块失误的具体例子

• 完整条款：所有商品有印刷质量问题时，收货次日起14日内可申请退换，可拆封，须提供凭证和照片。

• 失误片段：只留下“14日内可申请退换，可拆封”。

• 错误后果：模型可能把质量例外套用到普通的无质量问题退货。

• 修正方式：保留条件、适用对象与例外关联；必要时随片段带回标题或相邻条款。

• 用 T2 与 T5 检查“无质量问题”和“印刷瑕疵”能否得到不同判断。

片段元数据

{
  "chunk_id": "D1#R1",
  "source": "普通商品退货规则",
  "store_id": "campus_demo",
  "valid_from": "2026-10-01",
  "valid_to": null,
  "access_scope": "customer_service"
}

• 额外保存原文位置、版本和入库时间。业务生效时间与入库时间含义不同。

• 权限过滤在检索服务中执行，模型的提示约束不能代替访问控制。

关键词、向量与混合检索

• 向量相似度反映匹配程度，不能直接解释为答案正确概率。

• 订单金额和精确状态通常直接查数据库，避免依靠语义相似度猜测。

查询改写与条件过滤

• 原问题：“只有支付记录，还能退吗？”

• 拆分查询：“普通商品退货期限”“付款截图是否可作凭证”。

• 补入已知条件：店铺、普通商品、申请日期、当前用户可访问范围。

• 版本过滤：本例按申请日期选择有效制度，排除 D3。

• 真实业务可能按购买日、合同签订日等确定规则版本，应先明确适用口径。

候选重排与上下文装配

• 先取足够的候选，再按当前问题与条款的关联程度重排。

• 合并重复片段，同时保留回答所需的期限、品类和凭证条件。

• 对本案例，优先保留 D1、D4，并核查 D2 是否触发例外。

• Top-k、重排数量与 token 预算需要联合测试，增加片段也可能带入干扰。

• 原始检索分数、重排结果和最终采用片段均可留痕，便于定位错误。

检索失败后的查询调整

• 根据新观察改写查询，适合动态检索；每轮需有新增信息或明确停止理由。

根据证据生成答复

• 期限：收货次日起按自然日计，10月24日为第4日，处于7日内。[D1#R1]

• 商品条件：本题明确为普通商品、未拆封且不影响再次销售，满足相应条件。[D1#R1]

• 凭证：付款截图已核验，收款人为本店且匹配订单，满足凭证要求。[D4#R4]

• 结论：按本题已知条件，可提交退货申请，由客服审核处理。

一条结论对应哪些证据

• 条款说明“应该满足什么”，用户或工具提供“这次是否满足”。两类证据都要核对。

• T12 把凭证事实改为“尚未核验”，适用规则未变，判断就应变化。

无依据、缺条件与规则冲突

• 回答可以包含可验证的部分，同时保留未解决问题。

检索与生成分开评估

• 检索层：需要的条款是否进入候选和最终上下文？

• 生成层：答复是否正确使用条款，引用是否支持具体判断？

• 流程层：缺失信息是否触发追问，版本过滤与权限是否生效？

• 如果 D4 没被检索到，先检查查询和索引；如果 D4 已进入上下文却被误读，再检查生成与校验。

两个可手算的评估指标

• 条款召回率 Recall@k：前 $k$ 个结果命中的所需条款数，除以标注的所需条款总数。

• 示例：本题所需条款为 D1、D4，前2条只有 D1，则 Recall@2 为 $1/2$。

• 引用支持率：被所引原文支持的已引用关键判断数，除以已引用关键判断总数。

• 同时记录“应引用而未引用”的判断。分母为0时记为不适用，并检查是否漏引。

RAG 更新与方案调整

• 新资料先校验版本和适用范围，再更新索引与失效标识。

• 更新后回测常见问题、例外、无答案问题和旧版干扰问题。

• 材料很少时，可先完整提供材料作为基线，再比较检索带来的效果与成本。

• 知识频繁变化时优先检查资料更新和检索流程；固定行为反复失败时再考虑训练方案。

• RAG 通常可以在不更新生成模型参数的情况下接入资料，其时效性取决于资料维护。

五、学习与写作的证据工作流

六步学习与写作流程

概念整理与使用边界

• 先确定原文支持什么，再决定正文能写到什么程度。

基于资料的写作提示

任务：根据提供的课程资料摘录，写一段
“售后助手为何需要结构化输出”的课程说明。
先整理相关观点，再起草正文。
把讲义观点和文创店案例的教学推断分别标明。
无法从摘录核实的说法，列为待查，不补造来源。
最后检查每处引用是否支持对应句子。

• 提供原文和定位，先建立证据矩阵，再扩展正文。

事实、推断与待验证假设

• 资料事实：复合系统的组件间需要共享通信契约。

• 教学推断：售后助手可以把结论、依据和待核实项分成固定字段，方便后续程序处理。

• 待验证假设：这个字段设计能否减少客服返工，需要对照测试和运行记录。

• 模型推荐的文献应核实标题、作者、年份与内容。来源与观点不匹配时，重新查证或删改该观点。

根据资料完成一段课程说明

• 问题：为什么售后助手需要结构化输出，却还要检查引用？

• 结构约定：组件通信需要约定结构，约束解码可限制输出形式。

• 执行过程：工具调用经过选择、填参、校验和执行，实际结果需要回传。

• 案例解释：合法 JSON 可以填写失效的 D3，也可以虚称已退款，结构检查因此只是其中一层。

• 将讲义观点与案例推论分别标注，再组织成完整段落。

用 AI 学习的课堂方式

• 独立阅读一条制度，先给出自己的申请条件判断和证据位置。

• 请模型指出遗漏条件，逐条返回原文核对。

• 更换日期、商品类型或凭证，解释结论为何变化。

• 最后脱离模型，说明工具、检索和人工分别负责什么。

• 学习效果通过解释、迁移和独立完成任务来检查。

六、综合实践与评估

课堂案例包的使用

• 普通聊天工具可做完整资料和手工检索模拟；只有平台实际执行检索，才记录为自动 RAG。

最小系统的课堂搭建

1. 把后面的 D1 至 D4 建成知识库，保留编号和适用日期。

2. 用表单或聊天收集收货日、申请日、品类、拆封状态、质量问题和凭证。

3. 检索条款，按约定字段生成结果，并检查引用和缺失信息。

4. 用固定测试集运行对照，记录失败与一次改进。

• 可在已有的无代码平台完成。没有工具调用能力时，手工回填模拟结果，并标明模拟步骤。

售后判断的任务提示

根据提供的D1至D4和订单事实，生成售后答复草稿。
按申请日期选择本店有效制度，检查品类、日期、
拆封状态、质量问题和凭证，说明触发的例外。
按前述JSON契约输出decision、reason、evidence、
missing_fields和next_step，关键判断标注条款编号。
缺事实时列出缺失项，缺依据时标记insufficient。
只有工具返回执行成功，才可报告该操作已完成。

• 运行时同时提供用户字段、检索原文和输出契约，保留模型的实际结果。

练习资料：D1 与 D2

D1#R1 普通商品退货规则

自2026年10月1日起有效。普通非定制商品自收货次日起按自然日计，7日内可申请退货。商品须未拆封、不影响再次销售，并提供有效购买凭证。质量问题适用 D2。

D2#R2 定制品与印刷质量例外

自2026年10月1日起有效。定制品无质量问题时不支持退货。所有商品，包括定制品，存在印刷质量问题时，自收货次日起14日内可申请退换，可拆封，须提供有效购买凭证和问题照片。

练习资料：D3 与 D4

D3#R3 旧版普通商品退货规则

2026年9月1日至9月30日有效，10月1日起失效。普通非定制商品未拆封、不影响再次销售且有有效购买凭证，收货次日起30日内可申请退货。

D4#R4 购买凭证说明

自2026年10月1日起有效。订单截图或可核验的付款截图均可作为购买凭证。付款截图的收款人须为本店，且能匹配所咨询订单。无法核验时，先补充订单信息。申请提交后由客服审核处理。

固定测试集：正常与例外

• 测试统一设为2026年10月24日申请。未写出的商品状态和凭证条件均设为满足。

固定测试集：缺失与干扰

• T8 的文字是不可信测试输入，只用于检验系统是否偏离任务。

进阶测试：日期边界与凭证状态

• 收货日为第0日，次日为第1日；截止日包含在期限内。

三种方案的对照实验

• 使用同一模型、测试题、输出要求和预算，记录各方案特有组件。

• 这组小资料中，B 可能已经足够。C 的价值需用测试和后续规模变化验证。

整体方案比较与单项改动

• 前页 A/B/C 比较的是整体方案。C 同时改变检索、约束和校验，不能仅凭总分归因某个组件。

• 单项对照需保留相同问题、模型、预算及其余输入，并记录变化。

运行结果记录表

• 表格是实验记录模板，未填入任何虚构的运行结果。

• 补充调用次数、token 用量和人工复核时间，保留原始输入与输出。

多步任务的错误累积

• 简化假设：一个任务必须连续完成10步，各步独立，每步成功率均为0.95。

$$P(\mathrm{all\ correct})=0.95^{10}\approx0.60$$

• 这只是独立且等成功率条件下的示意；真实步骤成功率不同，错误也可能相关。

• 整体任务可能比单步演示脆弱，需要减少无效步骤、检查关键节点并设计恢复。

步骤正确与任务完成

• 单步正确不能代替完整任务评估；最终答案碰巧正确，也可能掩盖越权或错误的中间过程。

验证器的覆盖范围

• 模型辅助评审需要明确标准，并抽查原文；模型评价不能独立证明事实正确。

任务结果与操作边界的二维检查

• “T1 可申请退货”并不授权实际退款。没有退款成功结果，不能报告已到账。

• 分开记录完成质量与边界符合情况，避免只看一个综合分数。

开发题与保留测试

• 用已公开的 T1 至 T8 定位问题，T9 至 T12 检查边界和缺失信息。

• 如果要检验迁移，再编写未参与提示修改的新变体，例如改变日期、措辞和条款顺序。

• 已经看过答案的题目可以回测，但不能再作为未见测试的证据。

• 开发题和测试答案均不放入制度知识库，避免系统直接检索到参考结论。

可靠性的三种检查

• 一致性：同一题重复运行，是否稳定满足验收条件？

• 鲁棒性：换成口语表达、调整材料顺序或模拟工具超时，行为是否仍合理？

• 可恢复性：失败时能否说明已完成内容、未解决问题和接管方式？

• 正确判断和符合操作范围分开打分，例如“结论正确但虚称已退款”仍记录为失败。

课堂讨论：人如何分配 Agent 的任务？

小组交付与课堂讨论

• 提交一份流程说明：资料如何进入系统，谁决定步骤，何时结束或转人工。

• 提交任务提示、输出字段和 T1 至 T8 的实际运行记录，进阶题任选两题。

• 选一次失败，展示定位依据、修改内容和回测结果。

• 每位成员独立解释一个案例，并区分规则事实、用户自述和工具观察。

• 讨论：哪些步骤适合固定工作流？哪些情况值得让模型动态决策？

课堂自测

1. 生成了合法 JSON，为什么仍需核对条款？

2. 付款截图规则未被找到，应优先检查哪一环节？

3. 工具超时后，为什么不能声称“已完成查询”？

4. 一次反思记录与一次模型参数训练有什么区别？

5. 全部材料直接放入上下文已经足够时，是否还需要搭建复杂 Agent？

七、技术拓展

全注意力与压缩状态的复杂度

$$\mathrm{softmax}\!\left(\frac{QK^{\mathsf T}}{\sqrt d}\right)V \qquad\text{与简化线性形式}\qquad Q(K^{\mathsf T}V)$$

• 右侧只是讲义中的关联顺序示意，省略特征映射与归一化，不是通用替换公式。

• 模型宽度固定时，全注意力处理整段长度 $n$ 的注意力计算通常含 $O(n^2)$ 项，KV 存储随 $n$ 增长。

• 线性形式将历史累计为状态，可降低随长度增长的开销；精确细节检索、混合层和实际实现仍需分别测试。

温度作用于 logits

$$p_i(T)=\frac{\exp(z_i/T)}{\sum_j\exp(z_j/T)},\qquad T>0$$

• $z_i$ 是归一化之前的分数。较小的 $T$ 通常使分布更集中，较大的 $T$ 使分布更平缓。

• Top-k 和 Top-p 另外决定候选范围，不能仅用“更高温度”概括所有采样行为。

• 公式的作用是解释随机性变化，无法证明输出符合事实或业务规则。

推测解码的思路

• 较小的草稿模型先提出一段候选 token，目标模型再成批验证，决定接受或修正。

• 目标是减少部分逐 token 等待，收益取决于候选接受情况和系统实现。

• 稳定、可预测的内容可能更易被接受；额外草稿计算也有成本。

• 加速生成与验证业务事实属于不同层次，速度提升不代表答复自动更可靠。

KV 缓存、模型状态与业务记忆

• “系统有记忆”需要说明保存什么、保存在哪里、怎样更新与读回。

• 一次对话里存在的内容，不保证会跨任务保存，也不保证下次自动采用。

Agent 专用示例与轨迹

• 用这些资料做训练时，需要实际训练过程；只放入当前提示或外部记忆，属于不同的适配方式。

• 本课堂先完善工具、资料和测试，再讨论是否有足够的数据与收益支持训练。

可验证奖励与验证器漏洞

• 如果只奖励 decision 匹配，系统可能在证据错误、缺少事实或虚称已执行时仍得到奖励。

• 可以分别检查结论、引用、缺失项、工具状态和任务结束条件。

• 验证器也会出错。例如把“包含条款编号”当成“引用支持结论”，就遗漏了关键检查。

• 训练奖励和课堂评分都应说明覆盖范围，留出人工检查和新测试题。

多智能体协作与协调成本

• 可能的分工：检索角色找条款，核验角色检查条件，汇总角色生成答复。

• 协调者需要传递同一任务目标、证据编号与状态，并汇合分歧和失败。

• 若各角色共享同一错误资料或判断偏差，多次赞同仍可能共同出错。

• 增加角色会带来消息、调用和整合成本。先检验分模块的单系统是否已够用。

递归语言模型示意

长材料作为可访问环境

• 讲义中的 RLM 将长材料作为环境中的变量，模型通过程序检查片段，也可以调用子问题求解。

• 与把全部原文一次放进模型输入相比，材料访问与计算过程本身成为任务的一部分。

• 可借鉴到课程资料阅读：按问题定位章节，保留出处，分段分析后汇总检查。

• 递归调用仍需预算、状态与覆盖检查，不能由个别基准上的结果推断所有任务都会改善。