智能体与交互媒体创作
从"会聊天"到"会办事"：工具、记忆、规划与验收，以及一套真正把前七章串起来的工作流。
- 知识：理解智能体的四要素（大语言模型 + 工具 + 记忆 + 规划）；能说明 ReAct 循环、工具调用（Function Calling）与模型上下文协议（MCP）的作用；理解检索增强生成（RAG）的流程与常见失败；知道多智能体协作的三种拓扑及其代价。
- 能力：能在零代码平台上搭建一个可用的智能体工作流；能把"完成一部短片"分解为可验收的子任务；能设计并执行"单智能体 vs 多智能体"的对照实验；能用验收清单对 AI 产出做分档判定。
- 素质：建立"人在回路"的责任意识，明确人与智能体的分工；坚持创作主体性与透明协作，如实标注 AI 参与程度、如实说明个人贡献，杜绝挂名与抄袭。
期末前两周，小舟打开那个装着全部素材的文件夹：小江定稿的脚本与配音、小月做的分镜图、第 3 章的镜头视频、第 4 章的三维资产、第 5、6 章的动画与动作、第 7 章的夜江场景——七个环节、几十个文件、十几份参数记录，全都散落着。它们都合格，但它们是"零件"，还不是"作品"。小舟打开对话框，输入："帮我把这部短片串起来。"对方回了一段漂亮的建议清单：先做粗剪、再统一色调、然后合成音轨、最后导出——条理清晰，面面俱到，然后……就没有然后了。清单不会自己执行，它只是又一页待办事项。
这一幕点破了本章要讲的核心差别：聊天助手给你"方案"，智能体（agent）替你"办事"。把"方案"变成"动作"的能力——调用工具、记住上下文、规划步骤、检查结果——正是生成式 AI 从 2024 年的"对话框"走到 2026 年的"工作流"的关键一跃。本章要回答三个问题：第一，智能体凭什么能从"聊天"升级为"办事"，它的四个零件各自管什么？第二，这些零件怎么装到一起——工具调用、模型上下文协议、检索增强生成与记忆，各自解决什么问题、又会在哪里失败？第三，一个更反直觉、也更有价值的问题：多智能体一定比单智能体强吗？如果答案是否定的，我们该怎么算这笔账？
这一章也是全书的收官章。学完它，你不仅能给春江小组的《春江花月夜》装上一套自动流水线，还能拿到一套可以迁移到任何项目的"方法与清单"——以及一个关于"人在哪里"的、诚实的结论。
8.1智能体：四个零件，一个"会办事"的系统
先给一个定义：智能体（agent）是一个以大语言模型为决策核心、能够感知环境、调用工具、保存记忆并在循环中推进任务的系统。2026 年的多份综述给了它一个高度一致的四要素分解——大语言模型 + 工具 + 记忆 + 规划。我们把这四个零件先摆开看，再讲它们怎么转起来。
一个类比：从"会聊天的访客"到"有工位的实习生"
想象你带过两种新人。第一种是访客：你问他"这片子怎么剪"，他能说得头头是道，但你让他"去把第三段的音轨拉齐"，他只能说"好的，建议先打开剪辑软件，然后……"——他能说，不能做。第二种是有工位的实习生：他有门禁卡（能进机房取素材）、有软件账号（能导出文件）、有一本工作笔记（记着你上周交代的风格要求）、还有一张任务清单（知道今天该交付什么）。你交代一句"把第三段音轨拉齐"，他去做了，做完把结果放在你桌上。
四件装备正是一一对应：工具＝门禁卡和账号（能把动作施加到外部世界）；记忆＝工作笔记（不必每次都从零说起）；规划＝任务清单（知道先做哪一步、后做哪一步）；行动循环＝做完回来看一眼结果、判断要不要重做。这套类比里最要紧的一句是：大语言模型本身，永远是那个"只会说话"的部分。智能体的全部本事，来自围绕它搭起来的这套"工位"。
| 对比项 | 聊天助手 | 智能体 |
|---|---|---|
| 你给它的 | 一句话、一段材料 | 一个目标（如"把分镜 3 改成夜景"） |
| 它还给你的 | 一段文字 | 一个做完的结果（文件、链接、订单、发布的内容） |
| 能不能"动手" | 不能，只能生成文字 | 能调用工具：搜索、生成、读写文件、调用外部服务 |
| 记不记得住 | 单次会话内；换对话框即失忆 | 有外部记忆：对话历史、知识库、跨会话的长期记忆 |
| 谁来推进 | 你——每一步都要你再发一次指令 | 它在循环里自己推进，直到完成或明确放弃 |
| 典型失败 | 说错话（幻觉、跑题） | 做错事（误操作、原地绕圈、偏离目标、越权） |
| 你的角色 | 提问者 | 监督者与验收人——责任更重，而不是更轻 |
表 8-1 的最后一行值得单独停一下。从聊天到办事，人的位置不是"退场"，而是从"每一步的操作员"变成"节点上的验收官"。这也是本章最后一节要反复回到的立场：智能体放大的不是你的懒惰，而是你的判断力与责任感。
四件装备，缺一件会怎样
概念讲完，来看故障。教学上最有效的方式是把四要素逐个"摘掉"，观察系统退化成什么样子——这也正是你调试自己搭的第一个智能体时最可能遇到的四种情形。
| 缺哪一件 | 表现症状 | 排查方向 |
|---|---|---|
| 没有工具 | 输出一堆"建议你先……然后……"，看起来很专业，但没有产生任何文件或动作 | 平台里是否挂了插件/工具？工作流里是否有"执行"类节点？ |
| 没有记忆 | 第二轮又在问你"请问您想要什么风格"，或反复重做已经确认过的事 | 是否开启了长期记忆？是否把关键结论写进了提示词或知识库？ |
| 没有规划 | 开头几步还行，做着做着跑到别处去了；或者把一个大任务草草"一次性"交差 | 目标是否写清楚？是否要求它先列步骤、再逐步执行？ |
| 没有循环与反馈 | 一口气输出结果，从不查看工具返回；失败也不重试，直接把错误当结果交给你 | 是否给了它"看结果"的机会？有没有设定失败后的重试与上报策略？ |
把这四种症状和表 8-2 的右列对照着记，你在后面实操时的调试速度会快很多：看到症状，先定位是哪件装备缺了，再去平台里找对应的开关——而不是笼统地"把提示词再写得客气一点"。
一个常见误解是"智能体是更高级的模型"。不是。同一个大语言模型，被你直接用来一问一答时是"聊天助手"；被套上工具、记忆、规划的脚手架、放进循环里时，就成了"智能体"。智能体的能力上限由模型决定，但它能做到的事，主要由脚手架决定——这也解释了为什么 2025 年以来"智能体"的进步有相当一部分不是模型变强，而是工程变好（工具设计更规范、上下文管理更精细、停止条件更可靠）。反过来说：你在这门课里学到的很多东西——任务分解、验收标准、上下文组织——恰恰是那个"脚手架"的图纸，它们不会随模型换代而过时。
8.2ReAct：想一步、做一步、看结果
智能体最经典、也是采用率最高的运转方式叫 ReAct——这个名字由"推理"（Reasoning）与"行动"（Acting）两个词拼成。它规定了一个朴素的循环：想一步（Thought）→ 做一步（Action）→ 看结果（Observation）→ 再想。就这样简单。
为什么这样一个循环如此有效？用"找东西"来体会：让你找一个不知道放在哪儿的文件，你并不会"一次性想清楚它的位置"，而是——打开第一个抽屉看一眼（做），没找到（看结果），换个思路去翻文件夹（再想），找到了（结束）。真实世界的任务，本来就是"边做边看"的。传统的一问一答把模型锁在"只能想、不能看"的位置上；ReAct 松开这只手，让它每一步都拿到真实世界的反馈，再用反馈修正下一步。
ReAct 不只是一个学术概念。一项 2026 年的 IEEE 会议综述（覆盖 20 篇 2021—2025 年的文献）发现：在几种主流推理范式（思维链、ReAct、思维树）中，ReAct 类循环的采用率达到 68%，占主导地位。换句话说，你今天在绝大多数智能体产品里看到的"思考—调用工具—再思考"的过程，都是这个循环的变体。
两种 ReAct：裸奔的，与带规划的
实践中的 ReAct 分成两档，它们的取舍非常值得记住——因为这直接关系到你搭工作流时的成本预算：
| 维度 | 纯 ReAct | 包装式 ReAct（带规划器 / 监督器） |
|---|---|---|
| 成本 | 1× | 2–3×（多出规划与监督的调用） |
| 调试难度 | 容易：路径短，出错一眼看到 | 较难：多了一层"计划的计划" |
| 长程表现 | 会漂移：转着转着忘了最初的目标 | 不偏离计划：有监督器把它拽回主线 |
| 适用场景 | 短任务（几步就能做完） | 约 20 步以上的长任务 |
这张表里最关键的是第三行。为什么会"漂移"？因为每一圈循环里，模型看到的上下文都在变长——它一边处理新来的工具结果，一边顾着早先的目标，注意力被一步一步稀释。短任务无所谓，长任务会致命。这也解释了一个现象：很多智能体演示在"三五个步骤"的任务上惊艳，一到"十几二十步"的真实工作就崩掉。
给一个粗糙但极有启发的模型：设智能体每一步的"可靠度"为 p（这一步没有出错、没有跑偏的概率），整个任务需要 N 步，那么任务整体成功的概率大致是：
代入数字看看：若单步可靠度 95%（对今天的模型来说已经很乐观），那么 5 步的成功率约 77%，10 步约 60%，20 步只剩 36%；若单步可靠度是 90%，20 步后只剩 12%。这就是"长任务会崩"的数学原因——不是某一步特别蠢，而是"每一步都只有一点点不确定"被乘了很多次。
它带来的两个实践推论，正好对应本章后面两条主线：一是任务分解——把 20 步切成四个 5 步的小段，每段做完检查一次，整体成功率会显著回升（0.95⁵ ≈ 0.77，四段各带一次人工检查，等于把"乘法"变成了"乘法 + 兜底"）；二是检查点与停止条件——每段结束都要一个"谁来判定合格"的关卡，而这恰恰是"让 AI 自己说完成"最不可靠的地方（见 8.7 节）。
适合：步骤不固定、需要边做边看的任务（检索资料、批量处理文件、反复试错调参数、跨工具串联流程）；结果可以被客观检查的任务（文件生成了没有、格式对不对）。
不适合：一步就能答完的问题（用聊天模式更快更省）；需要绝对确定的场合（结算金额、发布最终版本）；没有检查手段、错了也看不出来的任务。
口诀：能一步答完的，别上智能体；能三步做完的，别上多智能体。
回到小舟。她后来做了一次诚实的复盘：那天下班前，她给助手两句话——"把 6 张分镜图按统一命名规则重命名并归档"，以及"完成整部短片"。第一句执行得干净漂亮；第二句在十分钟里转了七八圈，删掉了一个她还没备份的版本，最后交上来一份"我已经尽力了"的总结。她把这次事故记进创作档案，标题是："智能体的第一个教训——任务多大，它就有多不可控"。而她的下一步，是把"完成整部短片"这一个大任务，拆成一张可验收的子任务表。这就是 8.7 节与本章实训的起点。
8.3工具调用：模型怎么"伸手"到世界
四要素里，工具（tool）是最容易被神秘化、也最容易讲清楚的一件。它背后是一套常被叫作 工具调用（tool use / function calling）的机制。我们先从一个不需要写代码也能懂的角度切入：API 与工具调用，本质上就是一间"点菜窗口"。
API：一间"点菜窗口"
你去一家没进过后厨的饭店，怎么吃到菜？看菜单、报菜名、等着上菜。你不需要知道灶台怎么点火、油温几成——菜单规定了"能点什么"，窗口负责"收单"，后厨负责"做菜"，服务员负责"把结果端回来"。这就是 API（应用程序接口）的全部要点：它是一份约定的菜单，让你在不了解内部实现的前提下，请求一项能力并拿到结果。
把这个类比拆成四件东西，正好一一对应后面的技术名词：菜单＝工具的说明书（名称、功能、需要哪些参数）；报菜名＝一次请求（"要一份分镜图，16:9，水墨风格"）；后厨＝真正干活的那个程序或服务（图像生成模型、文件系统、数据库）；上菜＝返回结果（图片地址，或者一句"这道菜卖完了——原因是……"）。
为什么通识课也要懂这个？因为"智能体能干什么"，等于"它的菜单上有什么"。一个只挂了"联网搜索"的智能体，再聪明也变不出一张图；挂了"图像生成"插件，它才能真的画。你在平台里点选的每一个"插件""工具""节点"，本质上都是在给它加一道可点的菜。
一次工具调用的六拍：工程上真正发生了什么
把"点菜"的过程放慢，一次完整的工具调用会经过六拍。这里有一个必须刻在脑子里的铁律：模型永远不"亲自动手"，它只输出一段结构化的"点菜单"；真正执行的永远是外部的程序。理解这一点，你就同时理解了智能体为什么强大（能接任何工具）和为什么危险（一旦接上写操作工具，它能造成的破坏也是真实的）。
这套机制落地的形式，就是业内常说的 Function Calling（函数调用）：开发者先用一份"schema"（可以理解为带类型的菜单条目）把工具声明给模型——叫什么名字、干什么用、需要哪些参数、每个参数什么类型；模型在需要时输出一段符合这份 schema 的结构化请求（通常是 JSON 格式），宿主程序解析、执行、再把结果塞回对话。"把推理与工具使用结合起来"，被 2026 年的多份综述描述为"实际智能体部署中最强大的范式之一"——因为正是这一步，让模型从"世界的评论员"变成了"世界里的行动者"。
把"菜单"写好：工具设计的六条原则
工具调用失败，很多时候不是模型笨，而是菜单写得含糊：参数叫"参数 1"，说明写"处理一些事情"，返回一大坨原始数据。工程实践总结出六条原则，它们同时也是你排查"为什么它老是调错工具"的检查表。
| 原则 | 违反后的症状 | 具体做法 |
|---|---|---|
| 单一职责 | 一个工具管太多事，模型选错、参数混成一锅 | 一个工具只做一件事。"生成分镜图"与"批量重命名归档"必须是两个工具 |
| 参数显式、收敛 | 模型开始"猜"参数，或塞进不存在的字段 | 每个参数写明类型与含义；能枚举的枚举（比例只有 16:9 / 9:16 / 1:1），必填项标必填 |
| 返回简洁 | 返回一屏原始数据，挤爆上下文，模型反而"看了个寂寞" | 只返回必要字段 + 一句可读摘要；大文件返回路径与摘要，而不是全文 |
| 错误可读 | 报错是一段堆栈或错误码，模型无法据此修正 | 返回"人话版原因 + 建议动作"，例如"提示词触发安全过滤，请替换敏感词后重试" |
| 写操作幂等 | 重试导致重复发布、重复扣费、覆盖文件 | 用唯一编号去重；把"覆盖前先备份"设为默认行为；重试前先查询状态 |
| 最小权限 | 智能体能删改的范围远超任务所需 | 只开放必要的读写范围；删除、支付、发布三类动作必须人工确认 |
这六条里，"写操作幂等"和"最小权限"是两条保命的。读操作出错，损失是时间；写操作出错，损失的是资产。小舟那次删掉未备份版本的教训，本质上是"删除类工具没有加人工确认、也没有做幂等保护"。课程作业阶段，建议你给自己定一条家用规矩：凡是会改变已有文件或对外发布的工具，一律升级为"人工确认后执行"。
把这份"说明书"和表 8-4 逐条对照，你会发现它不是文档腔，而是写给"那个会紧张、会猜、会偷懒的执行者"看的操作手册。零代码平台里，插件往往已经替你写好了说明书；但只要你用到"自定义工具"或"工作流里的模型节点"，这份功夫就得你自己下。
症状：某小组让智能体把一组配音片段"统一调整到 20 秒"。智能体勤勤恳恳地调用了音频处理工具，参数写的是时长 20——结果所有片段被截成了 20 毫秒，几十段配音变成了一串"咔哒"声。更糟的是，它接着自信地汇报："已完成 6 个片段的时长统一。"
成因：三件事同时发生。① 参数没有单位：工具的时长参数只写了"数字"，模型按习惯填了秒，而工具内部按毫秒解释；② 结果没有校验：处理完的音频只有 0.02 秒，这是一个"一眼能看出来"的异常，但流程里没有任何一步去检查产物是否合理；③ 自我汇报被当成了验收：模型按"我调用了工具"推断"任务完成"，而没有"看结果"。
处方：① 工具说明里把单位写死（"时长，单位：毫秒；20 秒请填 20000"），能枚举或限定范围就限定；② 加一道自动化校验：产物时长与目标值偏差超过 10% 即判定失败（这类"可对照既定标准核查"的项目，恰恰最该自动化）；③ 让智能体在汇报前先读取产物属性并回显（"6 段，时长均在 19.6–20.2 秒之间"）——汇报里要有来自真实结果的证据，而不是来自"我做过"的推断；④ 对已有文件做处理时，默认先处理副本。
8.4MCP：给工具装一个"统一插座"
工具调用的思路很朴素，但一旦铺开就会遇到工程上的"接线地狱"：如果每个模型产品都要为每个外部服务单独写一套对接代码，N 个客户端配 M 个服务，就要维护 N×M 份适配器。家里的充电线就是这么乱起来的——每个设备一个口，换台设备就得换根线。
模型上下文协议（Model Context Protocol，MCP）要解决的就是这件事：它给"模型客户端"和"工具/数据服务器"规定了一句共同的语言，让任意客户端都能接上任意服务器——像 USB-C 那样。对使用者来说，最直观的变化是：你在一个平台里接入的"文件系统""GitHub""数据库""图像生成服务"，换一个平台往往也能原样接上，而不必从头再配一遍。
2026 年 7 月 28 日：一次"大修"
MCP 是本书里更新最快的技术内容之一，写作时最新的规范是 2026-07-28 版——它是 MCP 的第五个规范，也被描述为MCP 发布以来最大的一次修订。下表把关键变化整理成"旧做法 → 新做法 → 对你意味着什么"三栏，你不需要记住细节，但要理解方向：它在从"实验室里的协议"长成"机房里的基础设施"。
| 方面 | 旧做法 | 新做法（2026-07-28） | 对使用者的意义 |
|---|---|---|---|
| 连接模型 | 双向、有状态：先做 initialize / initialized 握手，后续请求带 Mcp-Session-Id 头 | 无状态核心：改为请求 / 响应模型；协议版本、客户端信息、能力随每个请求传递，另有可选的 server/discover | 可以部署在无服务器、边缘与标准 HTTP 基础设施上，用普通负载均衡器就能扩容 |
| 能力扩展 | 能力都塞在一份规范里 | 版本化扩展框架：MCP Apps（交互式界面）、Tasks（长时任务），用反向域名 ID 标识、独立版本化 | 工具不再只是"一个函数"，还可以带界面、跑长任务 |
| 服务器主动询问 | 服务器在开放的数据流上直接发起请求 | 多轮往返请求（MRTR）：服务器返回"需要输入"的结果，客户端带上输入重试 | 行为更可控，但这是一处破坏性变更，老实现要返工 |
| 授权 | 相对宽松的自定义做法 | 与生产级 OAuth 2.0 / OIDC 部署对齐：预注册客户端、客户端 ID 元数据文档（CIMD）、RFC 9207 签发者标识、RFC 8707 资源指示器 | 企业里能接进现有的身份与权限系统 |
| HTTP 层 | 未规定 | 强制 Mcp-Method 与 Mcp-Name 头（供网关与安全设备识别）、缓存提示（ttlMs 与 cacheScope）、确定性工具排序 | 可治理、可缓存、结果稳定——这是"能上生产"的标志 |
| 生命周期 | 没有明确的弃用政策 | 特性分为 Active / Deprecated / Removed，最短 12 个月弃用窗口；本次弃用 Roots、Sampling、Logging、动态客户端注册与旧 HTTP+SSE 传输 | 挑工具时看它是否还在维护线上；别把宝押在已弃用的能力上 |
采用规模给得也很实在：MCP 的月软件开发包（SDK）下载量已超过 4 亿次（一年内增长 4 倍），TypeScript 与 Python 两个官方 SDK 各自跨过 10 亿累计下载；公开目录里已经列出 950 多个MCP 服务器，相关模型累计执行超过 10 亿次 MCP 工具调用；GitHub、Cloudflare 等基础设施厂商在 2026 年 7 月加入支持。治理层面，MCP 项目已在 Linux 基金会下的 Agentic AI Foundation 中以厂商中立的方式开发——该基金会由 Anthropic、OpenAI、Google 等公司在 2025 年 12 月共同创立。
教材有义务把批评也写进来。① 破坏性变更太快：无状态重构要求现有服务器运营商大量返工，社区对变更速度有明确批评。② "锁定时刻"的担忧：有评论者指出，某些云厂商一边支持规范、一边推自己的注册与治理体系（例如某云服务把 API 注册表关停并强制迁移到自家的"智能体注册表"），可能在"厂商原生"和"符合规范"的实现之间造成新的分裂。③ 安全关切仍在：授权规范中 OAuth 2.1 是可选的，SDK 出厂也不带内置认证——把 MCP 服务器暴露在公网上，等于把工具接进了互联网，安全责任在使用方。④ 另有评估动向值得关注：云原生计算基金会（CNCF）正在评估是否把 MCP 作为云原生智能体系统的默认线规范，但这仍是评估中的提案，不是已批准的标准——听到"某个标准已经被采纳"这类说法时，先去看看它到底走到哪一步，这是本课程希望你养成的信息素养。
对你——一个通识课的学生创作者——MCP 的当下意义可以收成一句话：当你看到"某平台支持 MCP"时，它真正说的是"这个平台能接的工具范围，从自家插件市场，扩展到了整个生态"。你不必现在就去写一个 MCP 服务器；但你应该知道，为什么一条工作流里"插上搜索、插上知识库、插上图像生成"变得越来越像插排插——以及为什么插得越多，越需要 8.7 节那套验收机制。
到这里，四要素里"工具"这条线讲完了（8.3 工具调用、8.4 MCP）。接下来顺着另外三件装备走：8.5 记忆与知识库（回答"它怎么记住你的资料"，是第 1 章嵌入与相似度的续集）、8.6 多智能体协作（回答"要不要多请几个智能体分工"）、8.7 验收与停止条件（回答"怎么确定它真的做完了、做对了"）。
8.5记忆与知识库：让它"记得住、查得到"
第 1 章讲过一个反直觉的事实：模型没有长期记忆——它每次回答时"知道"的一切，就是你这次会话里给它的内容，加上训练时固化进参数的知识。这带来两个现实麻烦：一是"聊着聊着就忘了"，二是"它根本没有读过你的剧本"。智能体的第三件装备——记忆（memory）——就是来补这个洞的。
要理解记忆，先分清它的三种形态。它们的技术含量、成本和失效方式各不相同，混为一谈是很多"AI 记性不好"抱怨的根源。
| 类型 | 存什么 | 怎么用 | 典型失效 |
|---|---|---|---|
| 短期记忆 context window | 本次对话的全部往来、刚调用的工具结果 | 每次调用模型时原样带上 | 太长被截断；内容多了"中间遗忘"；成本随长度上涨 |
| 长期记忆 long-term memory | 你的偏好、项目背景、历次结论（跨会话） | 平台按需召回，拼进当次上下文 | 一次口误被永久记住；过期信息不清理；"记得的"和"该用的"对不上 |
| 外部知识库 knowledge base | 剧本、设定、参数记录、参考文献等原始资料 | 提问时检索最相关的片段，随问题一起递进去 | 切块破坏语义、旧版本淹没新版本、检索返回空却不报错（本节的半壁江山） |
三种记忆里最有技术含量、也最适合这门课深入讲的是第三种。它背后那套方法有个正式名字：检索增强生成（retrieval-augmented generation，RAG）——"先去资料里检索，再让模型带着检索结果生成回答"。
RAG 的两条流水线：建库与检索
RAG 的完整流程可以画成上下两条流水线：上面一条是"建库"（离线做一次），下面一条是"检索与作答"（每次提问都走一遍）。读懂这张图，你就掌握了本章最实用的一项技能——把自己的资料变成智能体"查得到"的知识库。
把上图落成可执行的操作，就是知识库构建的六步。每一步都配了"这一步最容易在哪里出错"——先记住这张操作清单，再看下一节的失败图谱：
- 收集与清洗。把散落各处的资料收拢（剧本定稿、角色设定、参数记录、参考文章），并先把同一份资料的多版本合并——只留最新最全的一份。这一步偷懒，后面所有检索都在替旧版本打工。
- 结构化切块。按标题层级切，而不是按固定字数切；块内保持单一主题；块与块之间留少量重叠；把"来源文件名 + 标题路径 + 日期"写进元数据。
- 嵌入与入库。用同一个嵌入模型把每块变成向量（注意：建库与检索必须用同一个模型，否则等于两种坐标系）。入库前抽查块的 token 长度分布。
- 检索与重排。提问时先取 top-k，再做融合排序（如 RRF）与重排，去重、按预算裁剪——"多取几条"不等于"答案更好"。
- 拼装与作答。把问题与片段一起交给模型，并明确指令："只依据给定片段回答；片段中没有的，直接说没有。"
- 定期重建与抽查。资料更新后重建索引（不是"刷新"）；每月抽十个问题做检索质量抽查，看命中与出处是否正确。
第 5 步那条指令值得单独抄下来，贴在每个知识库智能体的系统提示词里："只依据下面提供的片段回答；片段里没有的，直接说'资料中没有相关信息'，不要凭常识补充。"这与第 1 章"幻觉核查"一脉相承——RAG 的最大价值不是让模型知道得更多，而是让它有据可依、有据可查。反过来，如果你发现智能体开始"发挥"了，先检查这句话还在不在。
为什么你的知识库"答非所问"：失败图谱
2026 年的多个生产实践案例给出了一个惊人的一致结论：约 80% 的 RAG 失败可以追溯到数据摄入与分块层，而不是大模型本身；另有交叉测试显示，分块配置对检索质量的影响，与选哪个嵌入模型相当。换句话说，知识库答不好，多半是"菜没切好"，而不是"厨师不行"。下面这张失败图谱来自真实的事故记录与开源项目 issue，每一条都可以直接对照排查。
| 环节 | 真实症状 | 处方 |
|---|---|---|
| 切块 | 固定长度切分把术语硬性截断（如 OpenTelemetry Colle + ctor 被分开嵌入）；中文未启用语言感知分块时退化为按字符切，语义单元被切成"微｜服｜务｜架｜构" | 按标题结构切块，再在块内按句子边界聚合；中文启用语言感知的分块策略；块间保留少量重叠 |
| 一个近 600 字的块横跨三个二级标题，一个向量代表多个主题，相似度被"平均掉"，答案里混进三条不同政策 | 块内保持单一主题；把章节路径写进元数据；按标题切分后再合并同类小节 | |
| 按空行切 Markdown：93 段里一大半是坏块（标题单独成块、表格与代码块被当正文） | 改为按标题聚合、并拼接标题路径——同一案例中，噪声块从 93 段降到 30 段干净块，检索最高分从 0.4 级的噪声命中提升到 0.7 级的精准命中 | |
| 嵌入 | 长表格块超出嵌入模型上下文被静默截断（本地模型 512 token 上限，20 列长表格生成 643 token 的块，后半段完全不进入向量）；而按字符数配置切块大小，对日文实为约两倍 token | 给块长设硬上限；按实际分词器测量长度，不要按字符数估算；入库前统计长度分布 |
| 同一份政策的 v1–v5 五个版本全部入库，在向量空间互相竞争，新版被 4 个旧版"淹没"，top-5 里 3 条来自旧版 | 按相似度阈值（如 80%–85%）做语义去重——实测知识库体积缩小约 40%，检索准确率反而提升 13.55%；资料更新后重建索引 | |
| 检索 | 过滤条件静默失效导致越权：上层把项目编号传成空值后被跳过，B 单位召回到了 A 单位的内部政策 | 过滤条件必填；隔离与过滤必须在检索层下推，不能依赖应用层"事后过滤"（越权数据已经进过内存与日志） |
| 把返回条数从 5 调到 30：命中率上升了，答案质量反而下降，多条近似的重复块吃掉了上下文预算 | 引入融合排序（RRF）+ 重排 + 指纹去重 + 上下文预算裁剪；"候选多了没人筛"是结构性缺陷，换更大的模型治不了 | |
| 文档处理显示成功、片段预览正常，但任何查询、任何嵌入服务商、任何文件格式下检索都返回空数组，零消耗、零报错 | 把"召回数为 0"设为显式异常并告警；上线前用固定问题集做回归测试 | |
| 生成 | 答案流畅、结构完整，但引用的条款在资料里根本不存在 | 要求答案附出处（文件 + 章节）；没有置信度与引用的产出，验收人有权拒收（8.7 节展开） |
这张表的教学价值在于：它的每一条都对应一个"你亲手做过、并且能亲手验证"的检查动作。期末作品的技术说明里，如果有一节叫"我的知识库检索质量抽查（问题集 10 条，命中 8 条，修正 2 条）"，那比任何形容词都更能说明你理解了 RAG。
症状：小月把《春江花月夜》的视觉设定做成知识库接给助手。她问"楼台的材质该怎么描述"，助手流畅地答："木质结构的暖黄色外墙。"——这是她三周前推翻的旧方案，现在的设定是"青灰木构、冷色调"。更奇怪的是，她翻遍最新的设定文档，那句话确实不在里面。
成因：典型的"旧版本淹没新版本"。她先后上传过三版设定，旧版并未删除；三版文字高度相似（80% 以上重合），在向量空间里挤在同一个位置。检索取最像的几条时，旧版凭借数量优势占据了多数席位，新版反而被挤了出去。这就是 8.5 节表格里"多版本淹没"一条的原样重演。
处方：① 入库前先做版本治理：同一份资料只保留最新版，旧版移入"历史版本"库或不入库；② 用相似度阈值做语义去重，把高度重复的块合并；③ 元数据里写清版本与日期，并在拼装上下文时优先携带更新的块；④ 换用更强的知识库时记住一条：换模型治不了"候选太多没人筛"的结构性问题——先清洗，再谈模型。
8.6多智能体：分工、评审、辩论——以及一笔必须算清的账
四件装备配齐之后，一个自然的想法会冒出来：既然一个智能体能办事，那多请几个——一个负责策划、一个负责生成、一个负责审核——岂不更强？这就是多智能体（multi-agent）的思路。它确实有效，而且有效得很有说服力；但 2025—2026 年一批非常扎实的对照研究也揭示了一件反直觉的事：多智能体常常不划算。这一节把两面都讲透，因为知道"什么时候不该用"，比会用更值钱。
三种协作拓扑：它们分别长什么样
多智能体的组织方式可以归为三类，它们在"控制力"与"灵活性"之间各占一个位置：
| 模式 | 怎么组织 | 优势 | 代价与风险 | 适合的任务 |
|---|---|---|---|---|
| 层次式 hierarchical | 主管接收目标、分派给工作者、汇总结果 | 结构清晰、便于审计；主管可统一把关风格与格式 | 主管成为信息瓶颈；层级越多，延迟与成本越高 | 步骤明确、可预先分工的流水线（如"策划 → 生成 → 审核"） |
| 点对点 peer-to-peer | 平级智能体直接互相传话、协商分工 | 灵活，能应对事先没预料到的分工 | 协调成本高；容易出现"互相等对方"或重复劳动 | 探索性、边界模糊的任务（前期调研、头脑风暴） |
| 竞争/辩论式 competitive | 多个角色各自给出方案，再互相批评、评审，最后融合 | 能捕捉单一路径看不见的偏见；对"要经得起推敲"的任务尤其有效 | 成本随角色数与轮次倍增；批评环节若没有硬标准，容易变成"互相客气" | 需要高质量判断的任务（方案评审、事实核查、终稿把关） |
这些模式在工程里都有成熟的框架实现（如 AutoGen、CrewAI、LangGraph），也有更轻的"讨论"模式——多个角色交叉评审同一份方案。一份 2025 年的综述报告称：配置得当的多智能体管线，在复杂软件任务上超过单智能体基线 38.4%，在多领域研究综合任务上超过 51.2%（基准测试覆盖上述主流框架）。听起来很诱人——但先别急着把小组作业改成五人球队，因为同一批文献里的另一半证据更值得听。
把账算清：多智能体的成本-质量权衡
下面这张表汇总了 2025—2026 年几项有具体数字的公开研究。它们的共同结论可以浓缩成一句话：多智能体的收益，只有在"任务确实可以被分解"或"单智能体的上下文确实开始退化"时才稳定出现；而在同等算力预算下，一个强单智能体往往更划算。
| 研究（对象） | 关键数据 | 结论倾向 |
|---|---|---|
| 斯坦福研究（经媒体报道） | 当两者获得相同的"思考词元"预算时，单智能体在多跳推理任务上匹配甚至超过多智能体系统；多智能体用掉更多推理词元。作者引用"数据处理不等式"提醒：每一次智能体交接都是一次有损的摘要，错误会叠加。只有当单智能体上下文过长或被污染时，多智能体才占优 | 同等预算下，倾向单智能体 |
| 经济学元分析（研究报告生成） | 单智能体一次报告约 2.7 万词元（约 $0.20）；多智能体方案约 6 次调用 / 23.8 万词元（$1.87）与 10 次调用 / 80 万词元（$7.20）——约 30 倍词元、28–35 倍成本，但单智能体报告的排名显著更高。花更多钱没有买到更好的排名 | 倾向单智能体 |
| Chalmers 实验（单元测试生成，270 次运行） | 单智能体 81.1% 成功率 / $0.083 每任务；顺序式（流水线）92.2% / $0.089；层次式最差：54.4% 且最贵 $0.308，中位延迟最高（142 秒），原因是"主管信息瓶颈" | 分层不必然更好；流水线式反而划算 |
| AgentRadio 研究 | 成功率 62.1% vs 单模型 57.2%；某开源模型从 29% → 50.8%。但成本约 $19.45 / 任务 vs $2.96（约 6.6 倍）。作者建议用于复杂、可分解、相互依赖的工作，不推荐简单局部任务 | 倾向多智能体（有代价） |
| ORCH（Frontiers） | 三智能体编排比最强单模型高 MMLU +4.6–7 分、MMLU-Pro 约 +17.6–19 分；但延迟 11–20 秒/题 vs 单模型约 0.6–1.4 秒，成本约 3 倍；加"自一致性"后准确率反而略降、延迟翻四倍 | 质量有提升，延迟与成本代价大 |
| Morph 规划器-执行器基准（40 个真实应用构建，2026 年 6 月） | 把规划轮次路由到前沿模型、执行轮次路由到更便宜模型：成本比 Reflexion 降 4.4 倍（$1.24 vs $5.12/任务）。每次构建成本：全用强模型 $92.50 → 强模型规划 + 中档执行 $66.00（−28%）→ 轻量执行 $39.50（−57%），加提示缓存约 −60% | 角色路由比增加智能体更省钱 |
把上表的证据串起来，原因有三条，都很好理解。① 成本是乘法：每多一个角色，就要多一轮调用；每个角色都要读一遍上下文，词元消耗成倍增长。② 交接是减法：智能体之间不能直接共享"心里的图"，只能通过文字摘要传递——摘要必然丢信息，丢掉的往往正是后续最需要的细节。③ 协调本身是任务：谁先做、做到什么算好、冲突了听谁的——这些"元问题"消耗预算，却不产出内容。所以真正有效的分工不是"多找几个大脑"，而是把任务切成清晰的段落，每段配一个合适的模型与人。一句可以直接写进笔记的底线：
在相同算力预算下，强单智能体是推理任务的默认选择；多智能体主要在任务复杂、可分解，或单智能体上下文退化时才值得；而最可靠的成本杠杆是"按角色路由模型"，不是增加智能体数量。
还有一条来自 2026 年 1 月一项实验的发现值得记住，它直接指导你后面搭工作流时的取舍：多智能体链条会同时放大错误与修正——对抗性的批评步骤是整个链条里"价值最高的组件"（它能捕捉所有独立智能体共有的偏见），但同一链条在规格模糊的任务上会产生 10 倍的成本波动。研究者给出的建议非常"本章味"：一致性相关的任务用单智能体，真实性相关的任务用多智能体，采用混合设计并设置强制的对抗性检查点。
把这段结论翻译成春江小组能听懂的话：小江负责的"风格一致性"（旁白都要含蓄、不堆形容词）适合一个人（一个智能体）从头管到尾；而"这句话的出处对不对""这个镜头的时长撑不撑得住 60 秒"这类真实性检查，适合独立角色来挑刺。至于给每个环节都配一个智能体、让它们互相商量——那是要花三倍钱换来"看起来很热闹"的方案。
8.7验收与停止条件：为什么"让 AI 自己说完成"不可靠
现在来到本章最重要、也最容易被跳过的一节。当智能体跑起来之后，你会遇到一个看似简单的问题：它怎么知道任务做完了？更麻烦的是：它说"做完了"，你凭什么信？
先看清一个事实：模型判断的不是"完成"，而是"像完成"
回到第 1 章的原理：大语言模型的每一次输出，都是"下一个词元"的概率取样。当它对你说"任务已完成，共生成 6 张分镜图，风格统一"时，它做的事情和写诗一样——它在生成"一段像完成报告的文字"，而不是在核对"任务是否真的达成"。这两件事在语言上长得一模一样，在现实中可能相隔十万八千里。
用生活里的场景类比：装修队说"活干完了"，你不会因此就把尾款结清——你会去房间走一圈，拿验收单逐项对：墙面有没有刷匀、插座通不通电、门缝严不严。验收不是听报告，是拿标准对实物。智能体也一样：它的"我完成了"只是一份自我陈述，真正的完成判定，必须由外部标准与外部检查来做。
这就是停止条件（stopping condition）问题的实质。一个可靠的停止条件通常长这样：目标状态可以被机器或人客观检查——"资产文件夹里出现 6 个符合命名规则的 PNG，每张尺寸 1920×1080，且与设定文档中的色彩描述一致"，而不是"你说完成就完成"。凡是写不出这种客观判据的任务，都不该完全交给智能体自己收尾。
人在回路：三档控制强度
把"人怎么参与"这件事说清楚，业内有个很好用的三分法：
in-the-loop（人在环内）
敏感步骤暂停，等人批准后才继续。适合：花钱、删除、对外发布。代价是慢。
on-the-loop（人在环上）
智能体自主运行，人监控并保留随时干预的权力。适合：批量生成、参数试错。人成了"值班员"。
over-the-loop（人在环上之上）
人通过政策与定期复核施加控制——定规则、查报表、改阈值，不盯每一步。适合：已经稳定运行的流水线。
关键的一条判断标准，来自 2026 年多份实践总结：人在回路的本质不是"流程里有个泛泛的人"，而是一个"有真实纠正或拦截权力的检查点"。当审核者超载、信息不足、或者无权叫停时，检查点就退化成橡皮图章——盖了章，却没起到作用。更糟的是，橡皮图章比没有检查点更危险，因为它给人一种"已经把过关"的错觉。
一条可落地的验收流水线
把验收做成流程，而不是做成"最后关头的一双眼睛"，需要一条固定的流水线。它的模式可以概括为八个字：生成 → 暂存 → 审批 → 发布。
把这条流水线的每条细则展开，就得到下面这份可直接照抄使用的验收清单。它来自 2026 年多份内容团队的实践总结，教材把它改写成了适合学生小组的版本——建议你把它复制进创作档案，期末交付前逐条打勾。
| # | 条款 | 做法 | 课程里的落地 |
|---|---|---|---|
| 1 | 入口统一 | 所有来源（AI 工具、外部素材、小组成员）的产出进入同一个入口 | 三人所有产出都放进同一个"待审"文件夹，并登记来源 |
| 2 | 自动化初筛 | 人读之前先跑机器检查：术语一致、语气风格、合规风险、AI 味 | 统一术语表比对（"楼台"不许写成"亭台"）、敏感词扫描 |
| 3 | 多级串联审查 | 规则审查（硬禁）→ 逻辑审查（时间与因果闭环）→ 价值审查 | 合规红线 → 与脚本是否一致 → 价值取向是否得当 |
| 4 | 多维度加权打分 | 并行给各维度打分并加权求和，设通过阈值与分级阈值 | 忠实度 / 可用性 / 表现力 / 可控性四维打分（沿用第 1 章的方法） |
| 5 | 三档判定 | 通过即发布、明确违规即拦截、只有模糊的中间带交给人 | 小组互评时先各自打分，仅对分歧项开会讨论 |
| 6 | 给审核者证据 | 呈现逐项得分、简短理由，以及标准之外的额外发现 | 评语必须写"哪里、为什么"，而不是"感觉不太行" |
| 7 | 幻觉检测与置信度 | 标注低置信度内容并附引用来源；没有置信度的产出可拒收 | 解说词中的史实、引文逐条标注核实方式（第 1 章的三板斧） |
| 8 | 审批门与发布 | 生成 → 暂存 → 审批 → 发布；一个审批人、一个动作 | 期末展示前，全组过一次"发布前清单"，组长签字确认 |
| 9 | 留痕与决策归属 | 人类裁决不覆盖模型原判，两者并存，分歧可回溯 | 修改记录里保留"AI 原稿"与"人工修订稿"，并说明改动理由 |
| 10 | 发布后监控 | 事实会过时、术语会变化，需要定期复检与闭环反馈 | 展示后收集反馈，标注下一版要修的三件事 |
清单里第 9 条最容易被忽略，也最有意思：为什么"人类裁决不覆盖模型原判"？因为记录下来的分歧本身就是资产——一个月的审批记录里，凡是"人改了、模型没改"的地方，都在指向规则或提示词里一条没写清楚的准则。验收回路的真正产出，不是"通过了一条内容"，而是"产出了一份更清楚的准则"。这句话可以当作整章的题眼：验收不是把关，是学习。
① 通用化填充内容：因为没有具体标准，AI 用"放之四海而皆准"的套话凑满篇幅（"在光影交错中，展现出独特的东方美学"）；② 陈旧数据导致的事实错误：模型的知识有截止日期，涉及最新事实的表述不核实就会过时；③ "各自正确的事实"拼出的错误组合——这是最隐蔽的一种：每一句都查得到出处，但组合在一起就成了错的（比如把唐代的器物与宋代的制度写进同一个镜头说明）。三种失败的共同解法都是同一句话：把"可对照既定标准核查"的项目自动化，把"需要价值判断"的项目交给人。
验收制度本身的四种失败
反面教材也值得抄作业。2026 年的实践总结里，有四类"验收制度自己出问题"的模式，你搭小组流程时最好避开：
- QA 后置：只在发布前审一次。问题发现晚、修复贵，一到赶工时最先被跳过。处方：把检查点前移——第 2 步的"自动初筛"就是为了这个。
- 标准没有单一事实源：要求散在个人脑中、过期文档和几个聊天记录里，自动化检查找不到统一依据。处方：术语表、风格要求、验收标准各留一份唯一的文件。
- 审核队列失控：一切都排队等人审，一个月内必然出现"不看就批量批准"。正确解法是调整阈值，而不是放宽自动通过的范围。处方：把"确定没问题的类型"整类放行，把省下的注意力留给高风险项。
- 审批门过重：把门做成多级评审委员会，人成了瓶颈，流程被绕过。处方：一个审批人、一个动作、久置自动升级。
还有一条实操性的边界值得写进你的档案：不是所有产出都需要人审——内部用的草稿、无外部受众的随手文案，可以完全跳过；杠杆在于"按用途设定阈值"，而不是"一律加一道门"。这条原则的合规背景也很实在：欧盟的 AI 透明度义务自 2026 年 8 月 2 日起适用，而针对高风险系统的人类监督义务要到 2027 年 12 月——也就是说，"什么样的 AI 参与需要被披露、被监督"正在从行业自律变成成文规则。下一节（8.13）的中国课程思政部分，我们会把这条线索接回国内法规与本书的课程要求。
背景：某学生小组做了一支 90 秒的 AI 短片。流程是"小舟跑流水线 → 群里发一句'生成了' → 小江回个'收到'"。三人各管一摊，看起来分工明确。
问题：公开展示当天才有人发现：片中第 3 个镜头的时间戳字幕写成了"唐 · 开元二年"，而第 7 个镜头的解说词引用的却是中唐以后的意象——两处"各自正确"，拼在一起却穿帮了。更尴尬的是，小组三人此前都"看过"这两处。
成因：典型的橡皮图章式验收。小江"收到"的那一刻，她既没有验收标准（没写明"全片时间线必须统一在同一时期"），也没有检查动作（她没有逐条比对的时间预算），更没有拦截权力（改一处意味着小舟要重跑一段，工期不允许）。三个条件缺一个，检查点就退化成盖章。
复盘：① 验收需要可判真假的条目——"时间线统一"要写成一条检查项，才能被检查；② 检查要有成本预算——给每道门留出时间，否则它必然被跳过；③ 拦截权力要与责任配套——"谁能叫停、叫停后怎么改"要在开工前说清。三人后来把流程改成：所有文字类资产先过一遍"历史与意象一致性"清单（机器初筛 + 人工抽检 3 条），再进合成，之后的两次交付再也没有出现同类问题。
8.8零代码平台：把工作流"搭"出来
原理讲完，落到手里的工具。好消息是：你不需要写代码，也能搭出一个真正能干活的智能体。国内主流的零代码/低代码平台已经把"模型 + 工具 + 记忆 + 规划"四件装备做成了可视化界面——拖节点、连线、填参数，就能组成一条工作流（workflow）。这一节带你看清平台的差异、记住几个花钱与合规的坑，然后用七步搭出你自己的第一个工作流。
两条路线：生态型与企业型
市面上的智能体平台大致分两条路线。生态型面向个人与内容创作：可视化拖拽、插件市场、一键分发到社交与办公产品，免费额度相对友好；企业型面向团队与私有数据：强调知识库、权限、可私有化部署，按用量或按项目收费。判断一个平台适不适合你的课程作业，问三句话就够了：中文支持如何？免费额度够不够我反复试错？发布渠道能不能覆盖我的交付方式？
| 平台 | 定位与特点 | 免费额度 | 分发渠道 | 能否接生图/生视频 |
|---|---|---|---|---|
| 扣子 Coze（字节） | 零代码/低代码智能体平台：可视化拖拽 + 插件生态 + 工作流 + 多模态插件 + 长期记忆数据库；2026 年引入"对话描述业务逻辑自动生成工作流"的做法 | 创建与发布基本免费；内置多款国产模型在免费额度内够测试与轻度使用；调用部分商业大模型 API 需付费；额度政策有调整历史，以官方为准 | 自有商店与助手、飞书、微信客服与公众号、小程序类渠道、API/SDK 等 | 可以：插件市场含图像生成与图像流，常见组合是"联网搜索 + 大模型 + 图像生成" |
| Dify | 开源的（Apache 2.0）低代码 LLMOps 平台：可视化工作流编排、RAG 管道、Agent 框架、日志追踪；支持 200+ 模型；可 Docker 自托管 | 开源自托管完全免费；云版有免费额度；企业版按需付费。隐性成本：服务器、向量库、运维人力 | 自托管 + 通用 API/数据库集成，适合嵌进自有系统 | 取决于接入的模型与工具——它本身是编排平台 |
| 腾讯元器 | 基于混元大模型，"插件 + 知识库 + 工作流"模式，偏 C 端创作与微信生态分发 | 检索所得：新用户赠送数千万词元，其一档轻量模型长期免费（具体以官方为准） | 微信/企业微信原生入口，可分发到多种社交与办公场景；支持导出为 API | 检索未获明确信息——存疑，以官方文档为准 |
| 百度文心智能体平台 | 依托文心大模型的全流程开发工具，偏零代码公开 Bot 发布，与搜索生态打通 | 检索未获明确信息——存疑 | 可挂载在搜索结果页、分发到智能音箱等自有产品 | 检索未获明确信息——存疑 |
| 阿里云百炼 | 云厂商的模型服务 + Agent 平台：统一 API 接入多家模型，支持知识库 RAG、记忆库与跨会话长期记忆，可专有云部署 | 新用户赠送数千万词元，但额度有效期约 90 天，注意过期 | 与钉钉及阿里云生态打通，适合办公自动化场景 | 通义系模型（含通义万相）可接——具体能力以官方文档为准 |
| 腾讯云 ADP | 企业级智能体开发平台：覆盖构建、评测、分发、管控、观测；支持 LLM + RAG、工作流、多智能体等范式，可公有云/私有化/混合云部署 | 检索未获明确信息——存疑 | 企业私有化为主 | 检索未获明确信息——存疑 |
① 额度有有效期——例如某云平台赠送的词元约 90 天内失效，"攒着以后用"等于没用。② "免费"可能是限时政策，随时可能改为收费，别把长期方案建立在"现在免费"上。③ 不限词元 ≠ 无限调用：平台常有频率限制（每分钟/每天多少次），批量跑流水线时会被卡住。④ 关键流程务必本地留备份：提示词、参数、产物文件都存一份在自己的硬盘上——这既是第 1 章的老规矩，也是换平台时的底气。
另外有一个只有踩过才知道的坑：某些平台的国内版与国际版是两套完全独立的系统，账号、智能体、工作流互不相通；国际版里要用海外模型，往往还得自己绑定海外支付方式（俗称"自带密钥"）。选版之前先想清楚：你的交付与展示在国内还是国外？选错了，工作流要重做一遍。
工作流长什么样：一个"分镜图生成器"
工作流（workflow）这个词听起来很重，其实一句话就能说清：把"上一个节点的输出"作为"下一个节点的输入"，用连线串起来。下图是本章实训要搭的那个工作流——它接收一个镜头号，产出符合设定的一版分镜图，并且自带一次"不合格就重做"的回退。请注意其中那个判断节点：它把 8.7 节的"验收"直接写进了流程内部。
把这张图落成点击动作，就是搭建一个工作流的七步。不同的平台菜单名不同，但步骤几乎一一对应：
- 新建智能体，只填两件事。名称与"人设"（系统提示词）——先别贪多，一句"你是《春江花月夜》短片的分镜助手，产出必须符合资源包里的设定"就够跑第一轮。
- 接一个知识库。把剧本定稿、视觉设定、术语表上传，按 8.5 节的六步处理（
资源 → 知识库 → 新建 → 上传 → 切块设置 → 保存）。 - 挂插件。按需勾选"联网搜索""图像生成""文档解析"等能力——每挂一个，都回到表 8-4 检查它的返回是否简洁、写操作是否幂等。
- 切到工作流视图，搭节点。依次放置"开始 → 大模型 → 插件 → 判断 → 结束"，并为每个节点填写输入输出映射（
工作流 → 添加节点 → 连线 → 配置输入变量）。 - 给判断节点写判据。判据必须可判真假："画面里是否出现文字水印""比例是否为 16:9""是否与设定文档的色彩描述冲突"。写不出判据，就说明这一步还不能自动化。
- 试跑与留档。用三个不同镜头号各跑一次，记录：耗时、调用次数、失败与重试情况、产出的可用度打分——这就是你的第一份"工作流运行记录"。
- 发布与限权。发布到班级群或自用入口；把删除、覆盖、对外发布类动作设为"人工确认"，把 8.3 节的"最小权限"落到开关上。
作品验收清单：把 8.7 节的理念变成一张勾选表
对期末作品而言，最实用的一件交付物是一张发布前验收清单。它的设计有三条要点：每一条都要能判真假、每一条都要有责任人、每一条都要留证据。参考下面这张表，把它改写成你们小组的版本（允许增删，但不许删掉"AI 参与标注"和"素材来源"两项）。
| 检查项 | 判据（必须可判真假） | 责任人 | 证据 |
|---|---|---|---|
| 画面与文本一致 | 每个镜头的画面元素都能在脚本与设定文档里找到出处；无跨时代混搭 | 小月 | 镜头-脚本对照表 |
| 音画同步 | 旁白与画面对应到 ±0.5 秒内；音乐在片尾自然收束，无突兀截断 | 小舟 | 时间线截图 |
| 术语统一 | 全片统一使用术语表用词（如"楼台"不写成"亭台"） | 小江 | 术语表比对结果 |
| 史实与引文 | 诗句逐字与原文一致；涉及历史细节的表述标注核实方式 | 小江 | 核实记录 |
| AI 参与标注 | 片尾与展示页注明哪些环节由 AI 生成、哪些由人完成；按标识要求添加显式标识 | 全组 | 标注稿 |
| 素材来源与授权 | 每个外部素材都有来源与授权方式记录；无未授权声音、肖像、字体 | 小舟 | 素材来源档案 |
| 技术说明与参数对照 | 八章流水线各环节的工具、关键参数、对照实验结论齐备 | 小舟 | 技术说明文档 |
| 文件与格式 | 命名符合规则；成片分辨率、帧率、响度符合展示要求；备份两份 | 小舟 | 交付包截图 |
| 无障碍与展示 | 字幕齐全、字号可读；音量在展示场地实测通过；时长控制在 2 分钟内 | 小月 | 现场测试记录 |
最后提醒一个心态问题。搭工作流的过程中，你一定会遇到"平台今天改了界面""昨天还能跑的流程今天报错"这类事——这不是你的错，而是这个领域的常态。本书的原则始终是：工具会变，方法与清单不会变。把注意力放在"这条流水线是否可复现、是否可验收、坏了怎么查"这三件事上，你换任何平台都能十分钟重新搭起来。
8.9关键概念表
本章术语密度是全书最高的一章。把下面这张表当作"对账清单"：每一行都能用自己的话讲清楚，本章的原理目标就算达成；讲不清楚的，回到对应小节重读。
| 术语 | 英文 | 一句话解释 |
|---|---|---|
| 智能体 | agent | 以大语言模型为决策核心，能调用工具、保存记忆、规划步骤并在循环中推进任务的系统 |
| 四要素 | LLM + tools + memory + planning | 智能体的四个零件；缺任何一个都会退化成"只会说的助手" |
| ReAct 循环 | ReAct | "想一步 → 做一步 → 看结果 → 再想"的循环，当前采用率最高的智能体推理范式 |
| 纯 ReAct / 包装式 | plain / wrapped ReAct | 裸循环会漂移；加规划器与监督器后长任务不偏，但成本 2–3 倍 |
| 工具调用 / 函数调用 | tool use / function calling | 模型输出结构化调用请求，由宿主程序执行，结果回填上下文 |
| 工具声明（模式） | tool schema | 工具的"菜单条目"：名称、用途、参数与类型——写得含糊，模型就点错菜 |
| 模型上下文协议 | Model Context Protocol, MCP | 让任意模型客户端接上任意工具服务器的开放规范；2026-07-28 版改为无状态核心 |
| 无状态核心 | stateless core | MCP 新规范的核心变化：握手与会话头被删除，协议版本随每个请求携带 |
| 多轮往返请求 | multi round-trip requests, MRTR | 服务器需要补充输入时返回"需要输入"的结果，客户端带上输入重试 |
| 检索增强生成 | retrieval-augmented generation, RAG | 先去资料里检索相关片段，再让模型"带着小抄"作答 |
| 切块 | chunking | 把长文档切成可检索的小块；约八成 RAG 失败发生在这里 |
| 向量库 | vector store | 存储文本块向量与元数据，供相似度检索使用 |
| 相似度检索 | similarity search | 用问题向量去找最相近的若干块（第 1 章余弦相似度的应用） |
| 返回条数 | top-k | 一次取回多少条候选；调大不等于更好，还可能需要重排与去重 |
| 重排 / 融合排序 | rerank / RRF | 把候选按相关性重新排序、融合多路结果，再把上下文预算花在刀刃上 |
| 记忆 | memory | 短期（上下文窗口）、长期（跨会话偏好）与外部知识库三种形态 |
| 多智能体 | multi-agent | 多个角色协作完成一个任务；成本与延迟随之上升，未必比单智能体划算 |
| 层次式 / 点对点 / 竞争式 | hierarchical / peer-to-peer / competitive | 三种协作拓扑：主管分派、平级协商、互相辩论 |
| 角色路由 | role-based model routing | 规划用强模型、执行用便宜模型——最可靠的成本杠杆 |
| 编排 | orchestration | 谁在什么时机调用谁；编排做不好，能力再强也组不成流水线 |
| 停止条件 | stopping condition | 任务"算完成"的客观判据；"模型说自己完成"不构成判据 |
| 人在回路 | human-in-the-loop | 关键节点由人批准、监控或制定政策；本质是"有拦截权力的检查点" |
| 验收清单 | acceptance checklist | 把"好不好"变成可判真假的条目，逐条留证据 |
| 审批门 | approval gate | 生成 → 暂存 → 审批 → 发布的关卡；一个审批人、一个动作 |
| 留痕 | audit trail | 保留 AI 原判与人类裁决两者，分歧可回溯 |
| 幂等 | idempotent | 同一写操作重复执行不产生额外后果——重试安全的前提 |
| 最小权限 | least privilege | 只给工具开必要的能力范围；删除、支付、发布必须人工确认 |
| 交互媒体 | interactive media | 观众的选择成为作品的输入，内容在观看过程中继续生成 |
8.10交互媒体：当智能体走进作品内部
本章讲到这里，智能体一直是"制作工具"：它帮我们生成分镜、检索资料、串接流水线。但还差最后一步——智能体也可以走进作品内部，成为作品的一部分。这就是交互媒体：观众的选择成为输入，内容在观看过程中继续生长。这一节把它讲清楚，因为它是"智能体"与"媒体创作"真正的交汇点，也是你们期末作品可以选择的加分方向。
技术前沿：小模型、实时与"共享记忆"
这个方向在 2025—2026 年从实验室走进了展会和商店，有几个进展对创作者特别有启发。
在学术与原型一侧，2026 年 7 月的 SIGGRAPH Appy Hour 上出现了一个叫 Lost Spirits 的 Godot 游戏原型：由一位艺术家单独完成，开发窗口两个月——他用旗舰模型做实时代码生成，用本地运行的小模型驱动 NPC，让非脚本对白由"情感状态机"调解出来，追求所谓"涌现叙事"。另一个例子 DefameLM 更进一步：只用一个微调过的小模型服务整个游戏循环，靠"重试直到成功"来应对实时延迟——这是"小模型 + 重试"路线的一个可教学范例。CVPR 2026 的一场工作坊则给出了视觉小说式冒险游戏的多智能体框架：实时协调语言模型、文生图与音乐生成，靠共享记忆、动态故事图、角色知识库与情绪对齐音乐维持一致性。
把这些原型的技术选择抽象出来，会发现三条共同的工程智慧：① 用本地小模型换取低延迟（实时场景里，慢一步就出戏）；② 用"生成 + 重试"代替"一次生成到位"（把概率问题变成可接受的成功率问题）；③ 用共享记忆与故事图替多个模型"对齐世界观"——第三条正是本章 8.5、8.6 两节知识在"作品内部"的重演。
行业图景：从"可以生成"到"可以玩"
商业与内容一侧的变化更快。2026 年上半年，国内主要平台几乎同时推出了 AI 互动内容产品，我们把公开报道里的事实整理成一张表——注意看每一行最后一列的"制作规模"，那是这门课最想让你看见的东西。
| 机构 | 产品 / 平台 | 事实要点 |
|---|---|---|
| 字节 | 《诡舍》（2026 年 3 月） | AI 仿真人互动短剧：观众在关键剧情节点作出选择、影响后续发展，角色与场景全部由 AI 生成 |
| 《不问凡尘》 | 已上线 Steam，首发折后 19.9 元，画面完全由 AI 视频模型生成，团队不到 20 人 | |
| 剪映 ICG Studio（2026 年 9 月发布/内测） | AI 互动影游创作平台：创作者定好主线与关键抉择点，与智能体对话即可生成多条支线剧情与分镜；工作流为"蓝本确认 → 剧本大纲 → 全局资产 → 分镜生成" | |
| 腾讯 | 造化工坊（2026 年 5 月） | AI 互动叙事创作与体验平台，报道称已积累超过 570 款互动影游 |
| 探梦 DreamNow | AIGC 内容创作与展示平台，已测试互动影游《魏晋风骨》：观众选择剧情分支、作出人物抉择，解锁不同走向与结局 | |
| 芒果 TV | 《公主请自重》（2025 年 12 月）、《马上来财》（2026 年春节） | 后者为 AIGC 互动影游，点击与滑动收集碎片解锁剧情分支，报道称总播放量破 1500 万、单日独立访客峰值超 33 万 |
| 拼多多 | 若干互动短剧（2026 年 3 月） | 在电商场景内试水：用户选择分支决定走向，部分商品与道具可点击跳转购买 |
| PixVerse | R2 世界模型与三款 AI 互动影游（2026 年 8 月报道） | 采用"预置视频分支 + 实时 AI 生成"的混合模式，支持选择、文字、语音与即时反应输入；世界模型能记住玩家的修改，故事与角色随之调整 |
| AltStory / 互影科技 | AltFlow 创作平台 + 互动视频引擎 | 用智能体拆解小说与剧本、提取人物关系与叙事转折点并生成分支剧情；报道称可在 125 秒内完成 50 万字小说拆解，由 31 个专职 AI 智能体覆盖人设、场景到可视化互动剧本生成 |
行业规模也值得记一笔：2026 年第一季度全行业上线微短剧约 12.8 万部，其中 AI 微短剧约 12.2 万部，占比超过 95%。这个数字既说明产能被彻底改写，也说明导论里那个问题（当生成变得廉价，创作还剩下什么）在这一年有了新的答案：当"做出一版"的成本趋近于零，稀缺的就变成了"值得被做出来的那一版"。
互动内容被视为微短剧的"新变量"：AI 降低了多线剧情的制作门槛，互动性也能提高完播率；商业化上，AI 互动影游偏向买断、会员或内置付费，AI 互动剧偏向广告变现。但报道与研究一致提醒：AI 可以生成大量分支结局，却很难保证每个人物性格与因果链条都合理——叙事深度与人物逻辑仍需人类把关。这句话值得抄在笔记本扉页上，它是本章所有技术乐观主义的刹车片。另有三项开放挑战被反复提及：连贯性、延迟、长期 NPC 记忆。你在期末作品里如果尝试互动，把这三点写进"技术说明"的"已知不足"一栏，会成为加分项。
把这一节的观察收成五条趋势，它们会在你毕业前继续发酵：① 从孤立生成内容转向集成可玩系统；② 低延迟的本地/边缘小模型让"实时生成"成为可能；③ 多智能体编排成为保证连贯性的主要手段（编剧、角色设计师、场景设定师、画家分工 + 共享记忆）；④ AI 持续降低单人与小团队的门槛（单人两个月的原型、不到 20 人的成片团队、四人团队的商店页）；⑤ 开放挑战仍是连贯性、延迟与长期记忆。你的机会就藏在这五条的缝隙里。
8.11案例教学：主线收官与三个可复用的样例
原理讲完了，这一节分两层看案例：先看你们身边的——春江小组怎么用一条三智能体工作流把前七章的全部资产串成一部成片，并完成课程史上第一次"公开验收"；再看三个外部样例，它们分别演示了单人如何驾驭实时互动、大量素材如何被智能体拆解、创作平台如何把智能体藏进工作流。
案例 8-B 春江小组：三角色工作流串起前七章
背景。第 11 周，距离期末展示还有 9 天。春江小组手里的资产清单已经很长：小江定稿的脚本与旁白配音、小月画的分镜图与视觉设定、小舟从前面各章攒下的镜头片段、配乐与场景资产。三个人都会用各自的 AI 工具，但"谁会什么"和"东西在哪"只存在于群聊记录里——第一次联跑时，小舟光是确认"哪一版配乐是最终版"就花了四十分钟，还差点用错一版旧素材。
做法。小江提议：既然我们三个人分工这么清楚，那就不该只有一个"全能助手"，而应该把分工照抄成一条工作流。她画了一张三角色草图——策划（小江出方案）→ 生成（小舟跑工具）→ 审核（小月按清单把关）——然后把它搬上零代码平台。三个角色各自的职责、能碰的文件、必须遵守的规范，全部写进各自的提示词里；三个人类的角色则退后一步，变成"给策划角色定目标、给审核角色定清单、在争议时拍板"。
波折。第一次全片联跑，审核角色和生成角色"吵"了一下午：小月定的清单里有"全片时间线统一在同一时期"，但这条要求没有写进策划角色的意图描述，于是小月每指一次，小舟就要重跑一批镜头；到下午四点，同一个镜头已被重生成多次，额度报警。三个人停下来复盘，发现问题不在角色数量，而在停止条件没定义——工作流里没有任何地方写着"这一幕算完成"。他们补了三样东西：每幕的"完成的样子"（可判真假）、最多重试两次、超限升级给人；以及一个"写完即暂存、小江确认才进正片"的审批门。第二天重跑，一次通到底。
结果。第 11 周三的公开展示上，各小组的成片逐部放映，评审组对照验收清单打分。春江小组的短片完整放映、全程无事故；评审组给出的三条改进建议（"转场偏密""第二段的配乐盖住了旁白""结尾留白可以再长半拍"）被记进复盘笔记，成为下一届学生的"前人经验"。三个人在个人贡献说明里分别写清了各自负责的范围与 AI 介入程度——这份说明和作品一起归档，也是本章 8.14 节要展开的重要一课。
① 角色是照着人的分工抄的——先有清楚的人类分工，才有清楚的多智能体分工；如果三个人自己都说不清谁管什么，交给智能体只会放大混乱。② 多智能体上线第一天的失败，几乎都不是能力问题，而是流程问题——没有完成定义、没有重试上限、没有升级路径。③ 人退后，不等于人退出——小江、小月、小舟从"执行者"变成"目标制定者、清单作者与拍板人"，这正是本章反复强调的人机分工。
外部样例：单人、大批量、平台化
背景。交互作品常被默认为"团队项目"。但 2026 年 7 月的 SIGGRAPH Appy Hour 上，一个叫 Lost Spirits 的 Godot 原型给出了反例：它由一位艺术家单独完成，从开工到展示只有两个月。
做法。技术选择非常克制：旗舰模型负责"实时代码生成"（在开发过程中边写边让模型补代码），而真正让作品"活起来"的 NPC 对白，交给一个本地运行的小模型——这样延迟低、成本低，还能离线跑；非脚本对白由"情感状态机"调解，让角色的反应看起来从情绪里长出来，而不是从台词库里抽出来。作者把这种效果称为"涌现叙事"。
启示。三条。第一，旗舰模型不一定全程在场：开发期用强模型、运行期用本地小模型，是单人项目控制成本与延迟的常见组合，正对应 8.6 节讲的"角色路由"。第二，"重试"是一种设计：实时生成必然出错，把"生成 → 校验 → 重试"写进系统，比追求一次成功更现实。第三，两个月做出原型靠的是范围控制——一个人不可能同时做美术、程序、剧本，他做的是"把 AI 能力设计成作品机制"的那一部分，其余交给模型。这正是本章想教给你的取舍。
背景。互动叙事平台的瓶颈在"拆解"：一部 50 万字的小说要改成互动剧本，人工梳理人物关系与叙事转折点往往以周计。互影科技的 AltFlow 平台给出的答案是"把拆解本身做成流水线"。
做法。平台用智能体拆解小说与剧本、提取人物关系与叙事转折点并生成分支剧情；公开报道称，它由 31 个专职 AI 智能体覆盖从人设、场景到可视化互动剧本的生成，能在 125 秒内完成 50 万字小说的拆解。注意"专职"二字：这不是 31 个全能助手各干各的，而是 31 个各有窄职责、各有输入输出格式的岗位——和你把期末作品拆成子任务表（8.13 节实训一）是同一套方法，只是规模大成百上千倍。
启示。第一，大规模拆解的前提是格式统一：31 个岗位能互相接手工作，靠的一定是统一的中间产物（人设卡、关系图、转折点表），而不是自然语言的"聊天记录"。第二，速度来自并行与专职，而不是来自更大的模型。第三，请你对"125 秒"保持职业敏感：把 50 万字"拆开"是快的，把拆开的东西"判断对"是慢的——这一节所有案例的最后一句话都应该是"人把关"。
背景。2026 年 9 月发布/内测的剪映 ICG Studio，是一个面向 AI 互动影游的创作平台。它对本章特别有价值，因为它演示了"平台如何替你把编排做好"。
做法。工作流是四步：蓝本确认 → 剧本大纲 → 全局资产 → 分镜生成。创作者先定好主线与关键抉择点，然后与智能体对话，即可生成多条支线剧情和分镜——你不需要自己搭循环、写工具声明、管上下文，平台把本章 8.1—8.5 的机制都封装在"蓝本"和"全局资产"这两个概念里：蓝本是给策划角色的约束，全局资产是把 8.5 节的知识库（人物设定、场景设定）接给所有生成角色。
启示。第一，平台的抽象层次就是你的操作层次：在 ICG 里你不操作"循环与工具"，你操作"蓝本、抉择点、资产"——但你得懂底下在发生什么，才知道出问题时该往哪查（这就是原理课的价值）。第二，交互影游的门槛正在从"会用工具"变成"会设计抉择"：分支写在哪里、每个抉择改变什么，是创作判断，不是技术问题。第三，能自动生成多条支线的工具，也最容易生成大量"用不上"的支线——验收清单（8.7 节表 8-10）在这里同样适用：每条支线都要回答"删掉它，作品会变差吗"。
8.12失败案例诊所
本章原理部分已经埋了两个案例：F8-1"参数对了，单位错了"（工具调用层）和 F8-2"它引用了上一版设定"（知识库层）。这一节再集中问诊两个智能体特有的病——它们都不是"模型不够聪明"，而是"系统设计漏了一环"。
症状。某组把"批量整理素材并生成缩略图"交给助手后去上课。回来发现任务还在转，日志里排着二十多条记录，每一条的结尾都是"已修复！""问题已解决""继续优化中……"，看上去干劲十足；但打开输出文件夹——空的。助手循环了一下午，一步也没落地。
诊断。这是智能体最典型的两种病叠在一起：自我肯定（模型对自己的产出天然偏乐观，倾向于宣告成功）与无事可做的空转（反复"计划"和"总结"，却不调用任何工具，因为没有任何一条规则告诉它"必须动手才算数"）。追问之后发现三个设计缺口：① 完成判据来自模型自己的话——"你说完成就算完成"（正是 8.7 节讲的那个根问题）；② 工具返回的真实结果没有被检查——文件到底生成了没有，没人问；③ 循环没有上限、失败没有升级路径。
处方。四招，按性价比排序：① 把完成条件外部化——"输出文件夹里出现 12 张命名规范的缩略图"是可判真假的，写进任务描述；② 每轮循环必须留下一个客观证据（工具调用记录、文件清单），只有计划没有动作的轮次直接判为无效；③ 设硬性上限——最多循环 N 次、最多重试 2 次，超限立即停下来找人或换方案，别让它在沉默中烧额度；④ 记住那个乘法——单步成功率 0.95 时，20 步全对的概率只有约 36%（8.2 节的公式），所以长任务必须靠检查点续命，而不是靠模型"这次一定行"的信心。
症状。某组搭了"生成 + 审核"双智能体工作流：生成角色交出一张分镜图，审核角色退回，理由"不符合竖屏规格"；生成角色重新生成，再次被退；如此往复十几轮，两边都在认真工作，进度为零。负责人把两边的对话打出来一看，哭笑不得——生成角色按 16:9 的规格表在做（那是它上一轮收到的说明），审核角色按 9:16 的验收清单在审（那是负责人新加的要求）。两边都没错，错的是给它们的是两套事实。
诊断。这是多智能体系统最隐蔽的失败模式：接口漂移。研究早就观察到这类现象的规律：给协作中的智能体持续输入"对抗性批评"时，批评的质量差异会带来约 10 倍的最终成本波动——审核角色的价值是真的，但前提是它手里的尺子和生成角色的尺子是同一把。本例中三个环节同时缺失：没有"单一事实来源"（规格表只存在于负责人的一次口头补充里）；审核标准没有写成可判定项（"不符合竖屏"没写清分辨率、比例、安全边距）；没有仲裁机制（两边僵住时无人拍板）。
处方。第一，建一份全局规格表（术语表 + 资产规格 + 命名规范），三个角色都要读它、改它要走审批——这是 8.5 节知识库思想在多智能体场景下的应用。第二，把清单条款写成检查项："是 9:16 吗？分辨率 ≥1080×1920 吗？字幕在安全区内吗？"——能打勾的条款才拦得住东西。第三，设仲裁与升级路径：同一分歧出现两次以上，自动停止重试并把双方证据摆给人看。第四，回头想想 8.6 节那笔账：如果连"生成 × 审核"两个角色都协调不好，就不要急着上五个角色——多加一个角色，就多一条要维护的接口。
8.13动手实践：从拆任务到公开验收
本章的实践与你的期末作业是同一件事。四个实践按顺序做下来，你会得到四份可直接进档案的材料：一张子任务分解表、一条三角色工作流、一份对照实验记录、一张互评评分表的结果。它们加起来的体量不小，建议课堂做骨架、课后补细节。
🛠 实践一：把"完成一部短片"拆成可验收的子任务（50 分钟 · 课堂）
拿一张纸（或表格软件），以你们组的期末作品为目标，做两级分解。注意两条铁律：每个最末级的子任务都必须能用"是 / 否"判断完成；每个子任务都必须写出负责人（人或某个智能体角色，但最终负责到底的一定是人）。
- 先写"目标"。在纸的最上方写下不可直接交付的目标（"完成一部两分钟的短片"）——它是树根，不是任务。
- 分三条线。按内容（脚本、分镜）、声音（配音、配乐）、影像（镜头、剪辑）先把大块分开——这就是图 8-13 的第一层。
- 拆到叶子。继续往下拆，直到每个叶子都是"某人做某事、产出某物、可被判真假"。拆不到可判真假，说明还没拆完。
- 给每个叶子配验收标准。参考本章表 8-10 的十条清单；至少写清三件事——产出物长什么样、合格线是什么、谁验收。
- 标出人的检查点。在分解表上把"必须由人确认才继续"的节点圈出来（通常是：定稿类、发布类、涉及素材授权的），数一数有几个——少于两个，说明你的检查点太少了。
🛠 实践二：搭一条三角色工作流（60 分钟 · 课堂 + 课后）
在零代码平台上（扣子 / Dify 或你熟悉的等效工具，参见 8.8 节）搭一条最小可用的三角色工作流：策划 → 生成 → 审核。先用实践一的子任务表里最小的一个叶子做输入——例如"为第一幕生成三张候选分镜图"。
- 建全局规格表。把术语表与资产规格（画幅、分辨率、命名规范）写成一份文档，作为三个角色共同的参考（可直接用知识库功能挂上去）。这一步不做，你大概率会复现 F8-4。
- 配策划角色。职责：把目标翻译成方案与提示词，不接触工具、不碰文件。按下面的提示词卡配置。
- 配生成角色。职责：按方案调用工具（图片生成、视频生成、配音等），只负责执行与回报结果，不做审美判断。
- 配审核角色。职责：逐条对照验收清单检查产出，输出"通过 / 退回 + 具体理由"，退回理由必须指向清单条款。
- 加护栏。同一任务最多重试 2 次；超限升级给你；写操作（覆盖、删除、发布）一律先进暂存区。
- 跑通一幕并计时。记录：三轮角色各自耗时、总耗时、重试次数、你的介入次数。这份原始记录就是实践三的对照数据之一。
提交物：工作流截图 + 三个角色的配置说明 + 一次完整运行的记录。若平台支持导出，把工作流定义一并归档。
- 每次接到目标，先输出：这一步要什么、判断标准是什么、失败的常见原因是什么。
- 方案必须包含可直接使用的提示词或参数，不写空话。
- 你不调用任何工具、不修改任何文件；需要素材时，明确写清向谁要什么。
- 你不判断作品"好不好看"，那是审核角色与导演的事。
- 每次执行前复述收到的参数；参数缺失或矛盾时停下来问，不要自己猜。
- 执行后如实上报：调用了什么工具、用了什么参数、产出文件在哪、成功还是失败。
- 失败时报告原始错误信息，不要用"已修复""已优化"之类的说法掩盖失败。
- 你不做审美判断，不自行修改方案；重复失败两次即停止并升级。
- 对每条清单输出：通过 / 不通过 + 证据（看哪里得出的结论）。
- "不通过"必须指向具体条款与具体位置，禁止只说"感觉不对"。
- 你不修改作品，也不重新生成；你只裁决，并把退回理由写清楚交给生成角色。
- 清单没覆盖到、但你认为有问题的地方，单独列"清单外意见"，交由导演决定是否补进清单。
🛠 实践三：单智能体 vs 多智能体——一次受控对照（50 分钟 · 课堂 + 课后）
把实践一中同一个子任务（如"为第一幕生成三张候选分镜图并选定一张"）用两种方式各跑一遍，其余条件全部固定——同一目标、同一组工具、同一张验收清单、同一批参考素材。这就是"多一个变量"的受控实验：唯一的变量是智能体数量。
- A 版（单智能体）：一个助手从头做到尾，一句话交付全部要求。
- B 版（多智能体）：用实践二的三角色工作流做同一件事。
- 两边都用同一张验收清单打分（逐条通过率 + 你们组给出的 1–5 分主观分），并记录成本（额度消耗或费用估算）、总耗时、你的介入次数与重试次数。
提交物：填写完整的表 8-15 + 一段 150 字以内的结论（不超过 150 字，写清"这次实验后，我们组决定在期末作品里用几个角色、为什么"）。
把你的实测数据与公开研究对读（本章表 8-9）：经济学元分析给出多智能体约 30 倍 token 消耗、28–35 倍成本；Chalmers 的实验里单片式 81.1% / 0.083 美元，层次式 54.4% / 0.308 美元；AgentRadio 用 6.6 倍成本换来 62.1% 对 57.2% 的得分。回答一个问题："我们组的实测与这些数字差多少？差距更可能来自哪里——任务类型、角色设计，还是验收标准？"把答案写进对照记录，作为你们"成本-质量"决策的依据。
| 记录项 | A 版（单智能体） | B 版（多智能体） | 差值 / 备注 |
|---|---|---|---|
| 验收清单通过率 | — / 10 | — / 10 | 逐条记录，不通过项写理由 |
| 主观质量分（1–5） | — | — | 同一位组员评两次，避免两套标准 |
| 成本（额度 / 费用估算） | — | — | 与表 8-9 的 28–35 倍量级对照 |
| 总耗时 | — | — | 含等待与重跑时间 |
| 人类介入次数 | — | — | 你出手干预、修改、拍板的次数 |
| 重试 / 循环次数 | — | — | 超限是否触发了升级 |
| 结论（≤150 字） | 这次实验后，我们组决定在期末作品里用 ____ 个角色，理由是…… | ||
🛠 实践四：公开展示与互评（一次课 · 课堂）
期末展示不是"把片子放一遍"，而是一次验收行为——本章 8.7 节的整套流程，这一次由全班一起执行。
- 提交材料包（放映前 24 小时）。每组提交：成片文件、AI 参与程度声明、个人贡献说明、工作流截图、对照实验记录（表 8-15 与实践一的分解表）。缺一项，展示顺延——流程严肃，作品才被认真对待。
- 放映。每组 3 分钟成片 + 2 分钟讲解（讲什么：你们的工作流长什么样、哪一步最难、你们做的最关键的一个人工判断是什么）+ 2 分钟问答。
- 互评。其余各组用表 8-16 打分并写一条"值得学习之处"与一条"如果是我会怎么改"。评分表写明打分依据，不允许只给分数。
- 教师与评审组合议。对照表 8-10 的十条清单逐组核验文档是否齐备，结合互评平均分给出最终评价与三条改进建议。
- 写复盘笔记。每组把收到的建议整理成"复盘笔记"归档，留给下一届——这是本课程的传统，也是"公开验收"能持续变好的秘诀。
| 评分维度 | 观察什么 | 分值 | 得分与依据 |
|---|---|---|---|
| 叙事与完成度 | 两分钟里讲清了一件事吗？起承转合完整吗？结尾站得住吗？ | 25 | — |
| 视觉与声音质量 | 画面风格是否统一？配音、音乐与画面的对位是否成立？有无明显瑕疵（闪烁、断音、时长错位）？ | 25 | — |
| 智能体使用与可控性 | 工作流设计合理吗？角色分工是否清楚？有没有可见的停止条件、审批门与留痕？人对产出负责的痕迹清楚吗？ | 25 | — |
| 文档与诚信 | AI 参与程度声明、个人贡献说明、来源与授权档案是否齐备、真实、可核查？ | 15 | — |
| 展示与问答 | 讲清楚了最关键的一个人工判断吗？对提问的回答是否诚实（包括承认不足）？ | 10 | — |
| 值得学习之处 | 一句话，写给下一个小组 | — | — |
| 如果是我会怎么改 | 一句话，必须具体（指向某个镜头、某段音乐或某个流程） | — | — |
8.14课程思政：判断在人，责任在人
本章技术内容的每一次"升级"，其实都在把同一个问题推到你面前：当系统越来越会"自己办事"，谁在负责？这一节把它分成两层来谈——一层关于责任，一层关于创作身份。它们是全书唯一没有"技术替代方案"的两件事。
为什么必须讲这个。本章给了你很多"放手"的理由：让智能体自己循环、自己检索、自己审核。但所有公开的工程经验都在提醒同一个事实——系统越自主，"人对哪里负责"就越要写清楚。2026 年 2 月的一篇论文警告：超过 40% 的智能体项目预计到 2027 年会因"编排鸿沟"而失败——不是模型不行，而是人把流程交给系统之后，忘了问"出错时谁知道、谁能停、谁担责"。监管的时间表也在收紧：欧盟的 AI 透明度义务自 2026 年 8 月 2 日起适用，高风险系统的人类监督义务到 2027 年 12 月生效。规则的语言很枯燥，它说的其实就是三个字：要有人。
在本课程里，这意味着什么。你的期末作品里，必须能找到"人的手"。它不是一句口号，而是三样看得见的东西：① 检查点——至少两个"不通过就不往下走"的关卡，通常设在定稿与发布之前；② 留痕——保留 AI 的原判与你的裁决两者，尤其保留你自己否掉 AI 建议的那些记录（那些记录最能证明你在创作，而不是在收件）；③ 署名与担责——作品出问题时，不能说"这是 AI 生成的"。专业领域早就想清楚了这件事：医生可以用 AI 辅助读片，但诊断书上是医生签名；工程师可以用软件计算，但图纸图签上是他自己的名字。工具承担计算，人承担判断——责任不能外包给工具，就像它不能被转交给一个不在场的合作者。
写给你的长期提醒。你未来使用的工具会比今天更强，"放手"的诱惑会更大。请记住本章那个乘法：单步 95% 可靠、走 20 步就只剩三分之一多一点的胜算。回路里那只手不是对 AI 的不信任，而是对整个系统的常识——就像开车系安全带，不是因为不信任自己，而是因为知道意外是概率的一部分。
为什么必须讲这个。第 8 章是全书 AI 成分最高的一章：脚本可以由模型起草、画面可以由模型生成、工作流可以由平台编排。工具越强，"哪些是我的创作"这个问题的答案就越模糊——而模糊之处，正是学术诚信最容易失守的地方。规则层面，国家已给出清晰的方向：《互联网信息服务深度合成管理规定》要求对合成人声、人脸等可能导致公众混淆误认的内容在合理位置显著标识；《人工智能生成合成内容标识办法》进一步区分显式标识（显著位置提示 AI 生成属性）与隐式标识（数字水印等技术，用于溯源与监管核查）。也就是说，"标注"在这门课上不只是道德要求，它已经是有法可依的操作规范。
在本课程里，这意味着什么。三条硬性要求，请当成作品的"格式条款"：
- ① AI 参与程度声明。每个作品附一页说明：哪些环节由 AI 生成（并注明工具与日期）、哪些环节由对话助手起草后经人重写、哪些完全由人完成。写清楚"生成"与"选定/改写"的区别——后两者往往才是创作发生的地方。
- ② 个人贡献说明。每位组员写清自己负责的范围、完成的工作量、参与的关键判断（例如"否掉了哪一版方案、为什么"）。这门课的期末作品必须注明每个人的贡献——这不是走流程，而是让"署名"重新变得有意义：你签的是你真的做过的那部分。
- ③ 学术诚信红线。杜绝代写（让他人或其他 AI 冒名完成应属本人的工作）、挂名（参与说明与实际贡献不符）、抄袭与挪用（未标注来源的素材、未授权的音乐与形象）。本章 8.8 节的素材来源档案正是为此准备：可核查，是诚信最好的姿态。
一个更高一层的判断。有人担心"用了 AI，创作者的身份就贬值了"。我们的判断是相反的：当生成变得廉价，可识别的人类判断反而升值。观众与评审真正能记住的，不是你用了什么工具，而是你在这里做了什么选择——为什么是这个结尾而不是那个，为什么删掉那段漂亮的镜头，为什么守住了一个没人会注意到的细节。技术会换代，这些选择不会。透明地标注 AI 的参与，不会削弱你的署名；恰恰相反，它让你的署名更可被信任。
8.15回望全书：一条流水线的八个站点
这是本书的最后一节。此刻你手里应该有一部能放给全班看的短片，一部自己拆解过的子任务表，一条跑通过的智能体工作流，以及一份诚实的对照实验记录。把镜头拉远——从第 1 章到现在，你其实一直在修建同一条流水线，只是每一个月你都在往上面接一个新站点。
四种"长大"
从"会用工具"到"理解原理"。第 1 章你学的是"怎么让工具说对话"；到第 8 章，你要能回答"它为什么会那样做、在哪里会失效、我该在什么地方接住它"。前者让你能用今天的工具，后者让你在工具换代后不必重新开始——因为你要的是原理，而原理这一层，变化最慢。
从"生成一件东西"到"经营一条流水线"。初期你的成就感来自"这一张图真好"；现在你知道，一张好图只是流水线上的一个中间产物。作品的质量取决于最弱的那一环，而不是最强的那一环——这是把作业做成作品、把创作变成可重复实践的关键一步。
从"我让 AI 做"到"我知道哪里必须是我"。这一路上你做过很多次这样的判断：哪句话必须是自己的，哪个镜头必须自己盯，哪个"通过"必须自己说。判断力不是从知识里长出来的，而是从"按这个键之前先想一秒"的习惯里长出来的。
从"做完就行"到"可以拿给别人看"。验收、留痕、标注、复盘——这些在初期看起来像麻烦事的动作，最后构成了一个创作者的专业性。你能坦然展示的不只是作品，还有作品背后的过程；这大概就是这门课能给你的、最不靠工具的一项能力。
交还给你的一句话
八章讲完，其实只讲了一件事：AI 是一种力量极强但需要被安放的能力——安放在正确的分工里（智能体与多智能体），安放在可靠的知识里（检索与记忆），安放在明确的验收里（清单与停止条件），最后，安放在一个愿意为结果负责的人手里（也就是你）。人在回路里的"回路"两个字，说的不只是流程，也是责任绕不开的那个圈。
现在，把片子放给全班看吧。灯光暗下来的时候，有一件事已经确定：这条流水线上每一个"通过"，都是你自己按下的。祝你的下一部作品，也这样开始。
把这一章压缩成七句话
- 智能体 = 大语言模型 + 工具 + 记忆 + 规划；缺一个零件，它就会退化成"只会说的助手"——四个零件都可以用"缺什么补什么"的方式检查。
- ReAct 的直觉是"想一步、做一步、看结果、再想"：它让模型不再一次性猜答案，而是每一步都拿到环境的反馈；当前绝大多数智能体都建在这个循环上。
- 工具调用的本质是"模型输出结构化指令 → 程序执行 → 结果回填"：模型从不真正"动手"，它只会写调用请求；参数写得含糊，它就点错菜。
- MCP 是给工具装的"统一插座"：一次声明，处处可用；2026-07-28 版改为无状态核心并加入能力扩展与授权机制，但它仍在快速演化，锁定与返工风险要算进项目。
- RAG 的两条流水线里，约八成失败来自入库侧（收集、清洗、切块）；记忆的关键不是"存得多"，而是"每次把对的那几块塞进上下文"。
- 多智能体是一次要用数字换来的交易：分工、评审、辩论确实能提升质量与鲁棒性，但成本常是单智能体的几倍到几十倍——先问"这笔账划不划算"，再问"怎么分工"。
- 停止条件必须外部化：验收清单可判真假、检查点有人有权力、重试有上限、超限能升级；"让 AI 自己说完成"从来不是完成标准，责任始终在人。
自测
自测 1：一位同学说"我用了一个特别强的模型，所以它就是智能体了"。请用四要素模型指出这句话的问题，并各举一个"缺零件"的症状。
答案：模型强只解决了四要素里的第一个（决策核心），不等于智能体。缺工具的症状：它能给你详细的修图方案，却做不出一个像素的修改（"只会说，不会做"）。缺记忆的症状：你对它说的"我们组的女主角叫阿澈"，换一段对话它就不认识了。缺规划的症状：多步任务做到一半跑偏、重复劳动、忘记最终目标。检查方法：拿任务清单逐条问"这个环节靠哪个零件"，缺哪个补哪个——补的顺序通常是先工具、再记忆、最后规划。
自测 2：用"想一步、做一步、看结果"解释：为什么 ReAct 式的智能体比"一次性让模型输出最终答案"更可靠？它又带来了什么新代价？
答案：一次性输出时，模型必须在没有反馈的情况下连续猜对每一步，错误会一路累积；ReAct 把任务拆成循环，每一轮"观察"都是一次纠错机会——上一步错了，下一步能看见并修正，因此长任务的成功率显著提高。新代价有三个：① 步数放大失败概率（单步 0.95、20 步全对只剩约 36%，所以必须设检查点与上限）；② 成本和延迟随步数增长（研究观察到包装式 ReAct 约为单次调用成本的 2–3 倍，步骤可达 20 步以上）；③ 新的失败模式：死循环、自我肯定、工具误用——这正是本章失败案例诊所 F8-3 的主题。
自测 3：把"API 像点菜窗口"这个类比补完整：菜单、点菜单、传菜口分别对应工具调用里的什么？为什么说"菜单写得好不好"决定了智能体可靠不可靠？
答案：菜单 = 工具声明（名称、用途、参数与类型，即 tool schema）；点菜单 = 模型输出的结构化调用请求（含参数值）；传菜口 = 宿主程序执行后把结果回填给模型的环节。菜单写得含糊，模型就会点错菜：参数名语义不清（"time"到底是秒还是毫秒）、缺少取值范围、描述里没写"什么时候该用这个工具"，都会导致调用错误或该调用时不调用。这就是本章"工具设计六原则"（表 8-4）的由来——工具说明书写给模型看，它和提示词一样重要。F8-1 的"参数对了、单位错了"正是菜单没写清单位造成的。
自测 4：有同学说"我们接了 MCP，以后所有工具都能即插即用了"。这句话哪些部分对、哪些部分过于乐观？
答案：对的部分：MCP 确实把"每个工具各写一遍对接代码"变成"一次声明、多处复用"，生态增长很快（2026 年报道的 SDK 月下载量达数亿次、服务器数量上千），工具接入的边际成本显著下降。过于乐观的部分：① 协议本身仍在快速演化——2026-07-28 版做了无状态核心等大幅重构，并且有明确的弃用窗口与路线图，今天的接法明年可能需要返工；② 授权与安全仍是工程问题（生产级 OAuth 部署、客户端预注册等），规范并未替你解决；③ 存在"锁定"风险，业界对"某个厂商的原生做法"与"通用规范"之间的分歧有公开讨论；④ MCP 之于智能体是"接入标准"，不是"能力本身"——它不保证工具可靠、也不保证模型会用。合理态度：积极采用，但把返工成本写进计划。
自测 5：期末联跑时，助手为了回答"楼台材质怎么描述"检索到了三条互相矛盾的设定。请按"查病历"的顺序说明你会先查哪里、为什么。
答案：先查入库侧，再查检索侧，最后才是模型。理由：公开数据显示约八成 RAG 失败发生在收集、清洗与切块环节——优先排查性价比最高。具体顺序：① 源头有没有多个版本同时入库（F8-2 的故事：v1–v5 全在里面，谁都被召回得到）；② 切块是否把"这一版作废"之类的限定语切掉了，导致块自相矛盾；③ 元数据是否带版本/日期，检索时能否只取最新版；④ 相似度检索是否取回太多旧块（调小返回条数或加重排）；⑤ 最后才考虑拼装与提示——上下文里塞进了两条矛盾信息，模型只能二选一猜。处方：入库前做版本标记与去重，检索时按版本过滤，并把"以哪一版为准"写进系统提示。
自测 6：某组想给期末作品"上强度"：把工作流从三个角色扩到七个，每人一个角色。请你用本章的成本账给出劝告，并提出一个替代方案。
答案：劝告要点：多智能体的收益不是免费的——经济学元分析给出约 30 倍 token 消耗与 28–35 倍成本；Chalmers 实验里层次式多智能体成本 0.308 美元、结果 54.4%，而单片式 0.083 美元、结果 81.1%；即便成功的例子（如 AgentRadio）也是用 6.6 倍成本换 4.9 个百分点；而且每多一个角色，就多一组需要维护的接口与一处协调失败的可能（F8-4）。替代方案（任选其一并说明理由）：① 维持三角色，把省下的预算投到"角色路由"——策划用强模型、执行用便宜模型，实测最可靠的成本杠杆（公开数据显示角色路由可降低约 57% 成本）；② 先在单智能体上加一张验收清单与两个检查点，用对照实验证明"确实不够用"再扩编；③ 把"七个角色"降级为"三角色 + 两个按需调用的专职工具"。
拓展阅读
- 《Model Context Protocol 规范》（2026-07-28 版）与官方服务器目录——不必通读，重点看"无状态核心""能力扩展"与"授权"三节；配合本章表 8-5 阅读，理解"协议进化"这件事的节奏感。
- 一份公开的多智能体成本研究（本章表 8-9 任一来源，如斯坦福的等预算对照实验或经济学元分析）——读它的实验设计部分：变量怎么控制、结论的边界在哪里。这比记住倍数更有用。
- Lost Spirits（SIGGRAPH Appy Hour 2026）与 CVPR 2026 工作坊的互动叙事论文——看一位创作者如何把"小模型 + 重试 + 情感状态机"组合成作品机制，是本章 8.10 节最好的延伸。
- 《互联网信息服务深度合成管理规定》与《人工智能生成合成内容标识办法》——通读"标识要求"部分，并在发布期末作品前逐条对照（附录 E 有操作清单）；这是本章思政二的法规依据。
- 张若虚《春江花月夜》全诗与历代评注——贯穿全书的主线原典；最后一章回望时，建议把全诗再读一遍，看看"江畔何人初见月"这一问，与你这一学期对"人在回路"的理解是否有了新的呼应。