《AI Agents with MCP》拆解大纲(定稿:已按审阅意见改过)
这一份是动笔前的节级大纲,一节一行,每行「进来时以为 → 出去时知道」。 两头是同一件事的节已经删掉或改写。定稿后正文的节序与这里一致。
审阅意见落到了哪里(逐条)
| 审阅提的问题 | 改在哪 |
|---|---|
| 第 05 章走查算不出来(计算器只有加减乘除) | 走查换成「12 乘以 30」——multiply_two_numbers(a=12, b=30) → 360,一次服务器、两次模型 |
| 第 06 章只走资源、不走提示;资源模板插断走查 | 走查改成一条链:挑提示 → 填参数 → 取回两条消息 → 把资源正文追加进第一条 → 发给模型。资源模板挪到走查之后(§7) |
| 第 05 章提前用掉「资源」「嵌入资源」 | §4 只讲文字/图片/音频三类,那两种块整个挪到第 06 章 §6 补讲;§4 里连「资源」两个字都不出现 |
| 第 01 章 §3 与 §4 重复 | §3 只留循环机制,「由谁决定」整句删掉;§4 独占判定,并写成一次改判 |
| 第 02 章 §1 与第 01 章 §4 重复 | §1 与原 §2 合并,直接从「40 行 Python 翻成 Go」的写死流程开讲 |
| 第 08 章分页被标成主走查第 4 步 | 分页与变更订阅摘出来合成一处另起走查;主走查改成四步(通知、进度、日志、断线) |
| 第 11 章没兑现第 08 章的变更订阅与日志 | 加「第六级:订阅改成客户端登记一条长回话」;日志弃用进 §11「只能当历史读」那一栏,并在第 08 章 §7 先埋一句 |
| 第 10 章 §5/§6 是同一条机制的两面 | 重新切分:§5 只讲客户端一侧「不能转手」,§6 改成服务器一侧「收到一张令牌要验哪几样」,落到主走查上 |
| 第 10 章 §2/§3 预设 .env 与环境变量 | 环境变量整件事前移到第 04 章 §2(启动一台本机服务器要交三样东西);.env 也在那里一句话带过 |
| 第 04 章实际 8 个新词 | 丢掉「服务器推送(SSE)」这个名字;并且不引入「传输层」,正文一律说「线路」,英文对照放总纲的对照表 |
| 第 10 章实际 9 个新词 | 环境变量移走、动态注册降级成大白话(不给名字)、补上「授权码」 |
| 第 02 章 4 个名额花在工作流模式上 | §4 正文只讲提示词链,另外四种降成一张表(名字 + 一句「它治什么病」),表不算正文引入 |
| 原书两处「你可能根本不需要自己写客户端」没人接 | 第 09 章新增 §4「或者根本不自己写」;资源过滤并进 §2;Best Practices 空节写进第 09 章边界 |
| 第 11 章走查没指名道姓 | 借第 04、05 章那台计算器:同一条 multiply_two_numbers(a=12, b=30),左右逐字段对照 |
复审意见落到了哪里(第二轮,逐条)
| 复审提的问题 | 改在哪 |
|---|---|
| 19 个承重名字被留在词表外「另计」,配额是假 的 | 全部加进 scripts/book-jargon.mjs;重数之后七章超标,见下面「怎么压回去的」 |
| 第 11 章 8 个新词 | 拆成 11 + 12 两章(前四级 / 后两级 + 结账单) |
| 第 03 章的协议、接口、三个角色、一对一都不在主走查上 | 主走查改成一条贯穿三节的线:同一个「读文件」工具 → §2 算账 → §3 摆到接口上(三格具体值)→ §5 真接一次(七步,每步带程序名与状态) |
| 第 07 章 §4 根目录不在主走查上 | 第 0 步同时报上根目录,第 2 步按根目录读到一个具体文件;§4 新增「主走查续」,拿三条具体路径演示越界没人拦 |
| 第 10 章交叉引用指错章(上一章 §4) | 改成「本章第 4 节」 |
| 第 09 章「两条判断」下面挂着三行表 | 改成三条,§9 可带走第 7 条也补全成三条 |
第 06 章把 size 讲成行数 | 改成字节,并补一条 ② 类脚注引规范原话;图说的参照物换成同一口径 |
| 总纲兑现表漏记四处、指错一节、一处没兑现 | 补上四行、01 §2 改指 05 §3;第 08 章那半句「理由和另外两样同一个」删掉(规范只给了迁移路径,没给理由),并在第 12 章照实写明 |
| 04:128 一段里 JSON 与 JSON-RPC 同时首次出现 | 拆成两段,JSON 先单独讲一段并拿它说两件事 |
| 05:122 一段里「字符串」与「内容块」同时首次出现 | 「字符串」提到 §2 讲参数类型的地方 |
| 04 §2 走查起点没声明编的数值 | 表前加了一条引用块声明 --debug 与 CALC_PRECISION 是编的 |
| 09:161 词元换算率、05:143 base64 三分之一,没标来源 | 各加一条「补充(不在书里,来自通用知识)」脚注,并把换算过程写出来让读者能自己核 |
| 07 章两处「这样能力」少量词 | 都改成「这一样能力」 |
| 09:164 上下文窗口的定义句是五项顿号串 | 定义句缩短,五样东西改成分点 |
| 10:288「九成」没依据 | 改成「§3 那张表里五样只有一样是它真正要的」 |
| 总纲把词元说成「字」 | 改成「比用户那句话长七千多倍」,绝对数与口径留给第 09 章 |
新词配额账(每章第一次出现的承重词)
这是复审之后重新数出来的实际值,口径按标准:
node scripts/book-jargon.mjs ai-agents-with-mcp --list,只数 book-jargon 词表里的承重词,
按第一次出现的位置归章。
复审改掉的一件大事: 上一版这张表下面挂了一串「不在词表里、但本书当承重词引入的名字」 声明「另计」——那是绕过检查,不是达标。 标准只准人名、机构、论文名另计, 而那 19 个里没有一个是;其中「问路方法」「多轮往返请求」「结果保鲜期」「扩展机制」 还各自占着一节的标题。它们已经全部加进
scripts/book-jargon.mjs的词表, 加完重数,有七章超配额,按下面「怎么压回去的」逐章压回 7 个以内。
| 位置 | 第一次出现的承重词 | 个数 |
|---|---|---|
| 总纲 | 模型、大语言模型、模型上下文协议、MCP、智能体、参数、URI | 7 |
| 01 | 生成式、工具调用、记忆、动作—反馈循环 | 4 |
| 02 | 工作流、智能体式工作流、提示词、提示词链、确定性 | 5 |
| 03 | 协议、接口、语言服务器协议、宿主应用、客户端、服务器、MxN 问题 | 7 |
| 04 | 标准输入输出、子程序、环境变量、JSON、JSON-RPC、会话、Streamable HTTP | 7 |
| 05 | 原语、JSON Schema、字符串、内容块、字节、base64、结构化返回 | 7 |
| 06 | 资源、提示、内容类型、字段、嵌入资源、资源链接、资源模板 | 7 |
| 07 | 采样、人在回路、根目录、征询、回调、弃用 | 6 |
| 08 | 通知、日志、日志级别、断线续传、分页、游标、订阅 | 7 |
| 09 | 会话组、词元、上下文窗口、阈值、缓存、检索、沙箱 | 7 |
| 10 | 版本库、OAuth、令牌、请求来源校验、令牌透传、混淆代理、授权码 | 7 |
| 11 | 多副本部署、无状态、请求元数据、元数据、问路方法、多轮往返请求 | 6 |
| 12 | 结果保鲜期、扩展机制 | 2 |
最差的一章是 7 个,没有超配额的章。总纲同样是 7。
怎么压回去的(一章一条,标准只准两条路:拆章,或把外围概念整章移出)
| 章 | 加词后是几个 | 压回去的办法 |
|---|---|---|
| 03 | 8 | 不再把 GPT 当承重词引入——它只是举例时的一个产品名,正文改说「OpenAI 的那一系列模型」 |
| 04 | 8 | 「初始化握手」这个名字整个不要了,全章只用大白话「打招呼」(章标题本来就是它);官方名 initialize 收进总纲的对照表。顺带治好了「同一个概念两个名字」 |
| 05 | 8 | 「输入模式」这个名字不要了,它本来就是表里那一行「参数表」的第二个名字;inputSchema 与 JSON Schema 照旧讲透。另把「字段」让给第 06 章、把「字节」接过来(base64 要用它算账) |
| 06 | 8 | 「资源地址」这个名字不要了,全章只说「地址」并当场讲清它是什么;URI 收进总纲对照表 |
| 08 | 10 | 去掉三个名字: 「Markdown」(走查里纯属点缀,改说「说明文档」)、「变更订阅」(它是「订阅」的第二个名字)、「进度标识」(改说「一个标识(progressToken)」) |
| 09 | 9 | 去掉两个名字: 「渐进式工具发现」与「程序化工具调用」——全章本来就一直在用「按需查找」和「让模型写脚本」,官方英文名收进总纲对照表 |
| 10 | 9 | 去掉两个名字: 「访问令牌」(简称「令牌」是全章一直在用的那个)、「令牌的收件人」(改说「它是发给谁用的」那一格) |
| 11 | 9 | 拆章。 原第 11 章 13 节、32 KB,是全书最长的一章;按「同一条理由推了几级 」切成两章:新 11 讲前四级(状态、打招呼、问路、服务器发问),新 12 讲后两级(断线、订阅)+ 零碎改动 + 扩展 + 全书结账单 |
一条都没有靠砍解释来压: 上面「名字不要了」的每一处,解释、走查、台阶全部原样留着, 去掉的只是一张多余的生面孔——那正是标准四种解释法里排第一条的「换成大白话,不引入这个词」。
总纲 index.md
六节:30 秒导读 → 这是谁在什么时候写的 → 全书一条主线 → 章节地图 → 覆盖什么/不覆盖什么(含中英对照表) → 我们的判断 → 兑现表。
01 什么是「智能体」:一个会自己动手的模型
主走查:「帮我给这个文件写单元测试」——三圈,每圈手里拿到什么。(圈数与内容是我们为演示编的,书里那张图写着 Figure coming soon。)
| 节 | 进来时以为 → 出去时知道 |
|---|---|
| 1 | 以为智能体是「更聪明、答得更长的聊天机器人」→ 知道差别不在聪明,在于它能不能改变外面的东西、并且看到改完之后的结果 |
| 2 | 以为模型能自己读文件、跑命令 → 知道模型的输出只有文字,任何真实动作都得由外面一段程序代劳,那段程序就叫工具 |
| 3 | 以为模型一次就把活干完了 → 能复述那一圈:写下要调哪个工具 → 外面跑完把结果塞回去 → 再写下一步(只讲机制,不提「谁决定」) |
| 4 | 以为「§1 学到的能动手就是智能体」够了 → 知道真正的分水岭是下一步由模型挑还是由代码挑,并知道本书为什么必须先钉死 Anthropic 那条定义 |
| 5 | 以为业界对「智能体」已有共识 → 知道这是一条被广泛引用但并非唯一的定义,也知道它如果错会错在哪 |
| 6 | 以为读完就掌握了书里这一章 → 知道这一章有四节只有标题、正文写着稍后补充,后面凡是补上的都会当场标明不是书里的 |
02 智能体,还是写死的流程?
主走查:「把这 40 行 Python 翻成 Go」——同一个输入,先走写死的流程,再交给智能体。
| 节 | 进来时以为 → 出去时知道 |
|---|---|
| 1 | 知道「代码挑」这条路存在,但不知道它长什么样 → 能指出这条路上每个判断点分别由谁做(主走查上半) |
| 2 | 以为这是随手写的 if-else → 知道它有固定形状、有名字(提示词链),属于「智能体式工作流」这一类 |
| 3 | 以为智能体版只是把判断语句换成模型 → 知道那张路线图被整个撤掉了 |
| 4 | 以为「写死的流程」只有一种形状 → 拿到一张表:另外四种各治什么病(表,不展开) |
| 5 | 以 为智能体更先进所以该优先选 → 知道选择标准是「这条路你事先知不知道」,以及为什么线上跑着的系统里写死的流程反而更多 |
| 6 | 以为两者泾渭分明 → 知道真实系统通常外层写死、内层放开,并知道这条判断如果错会错在哪 |
03 MCP 要解决的那件事:30 个连接件变成 13 个
**主走查:**3 个模型 × 10 个工具,30 → 13,重复的 17 段在哪。
| 节 | 进来时以为 → 出去时知道 |
|---|---|
| 1 | 以为把工具接给模型写一次就到处能用 → 知道没有共同接口之前,接法跟着模型走,换个模型要重写一遍 |
| 2 | 以为「MxN 问题」是一句形容词 → 能自己算这道题,并知道重复的 17 段正是 bug 最爱藏的地方(主走查) |
| 3 | 以为协议是一份大家自觉遵守的文档约定 → 知道它规定的是消息长什么样、一问一答按什么规矩来 |
| 4 | 以为 MCP 是凭空设计的 → 知道它照搬了语言服务器协议的思路,那边当年解决的是形状一样的一道题 |
| 5 | 以为「客户端/服务器」就是浏览器和网站那一套 → 能指出宿主、客户端、服务器各自在哪、谁装在谁里面,并知道「一个客户端只对一台服务器」这条硬规矩 |
| 6 | 以为这一章全部来自原书 → 知道原书专门讲协议的那一章标着「不可用」,协议部分取自官方规范,每一处该去哪儿核 |
04 接上一台服务器:两种线路和一次打招呼
**主走查:**从敲下 python calculator_server.py --debug 到客户端确认「连上了」,中间来回三条报文。
| 节 | 进来时以为 → 出去时知道 |
|---|---|
| 1 | 以为连服务器就是连一个网址 → 知道有两条线路,选哪条取决于服务器在不在本机 |
| 2 | 以为服务器总是别人先开好、你去连 → 知道本机线路下服务器是客户端自己拉起来的一个子程序,启动它要交三样东西:命令、参数、环境变量(主走查第 1 步) |
| 3 | 以为远程线路就是普通网页请求 → 知道它只有一个地址,服务器既可一次答完,也可开一条长连接慢慢吐,后一种是可选的 |
| 4 | 以为报文很复杂、得先学一套新语法 → 能认出一条请求由方法名和参数组成、一条回复靠同一个编号带回结果,并知道这套格式比 MCP 老得多 |
| 5 | 以为连上就能直接调工具 → 能复述那三条报文各说了什么,并知道不打招呼就调工具会被拒(主走查第 2 步) |
| 6 | 以为关连接就是关端口、杀进程 → 知道一次连接叠了两层(子程序 + 会话),必须按相反顺序拆 |
| 7 | 以为打招呼是地基不会变 → 知道 2026 年的规范已取消它,理由要等到第 11 章才讲得清 |
05 工具:怎么找到它、怎么调它、怎么把结果送回模型
**主走查:**用户问「12 乘以 30 是多少」→ 列出四个工具 → 模型写下 multiply_two_numbers(a=12, b=30) → 服务器回 360 → 第二次调模型说出「360」。两次模型、一次服务器。
| 节 | 进来时以为 → 出去时知道 |
|---|---|
| 1 | 以为每一类东西都得单独学一套调法 → 知道三类东西共用同一个套路:先要清单、再挑一个用 |
| 2 | 以为一个工具就是一个函数名 → 能说出一条工具描述里有哪几样,尤其是那份说明参数的表格(主走查第 1 步) |
| 3 | 以为模型直接把工具跑了 → 知道模型只是写下「我要调 X、参数是 Y」然后停下,真正去跑的是宿主程序(主走查第 2 步) |
| 4 | 以为工具返回一个字符串 → 知道返回的是一串块,客户端要挨个认领(只讲文字/图片/音频,另两种留到第 06 章)(主走查第 3 步) |
| 5 | 以为工具跑完就直接打给用户 → 能复述第二次调模型必须带上哪三条消息,少哪一条会怎样(主走查第 4 步) |
| 6 | 以为工具给了模型就一定会用 → 知道那个开关有四挡,而且它是模型厂商的、不是 MCP 的 |
| 7 | 以为工具结果只能是给人看的文字 → 知道新规范让工具可以额外交一份按约定格式写好的数据 |
| 8 | 以为工具越多智能体越强 → 知道数量上去之后选择准确率会掉,这笔账在第 09 章还 |
06 另外两类:资源送数据,提示送话术
**主走查:**用户输入 prompt: debug_script script_name deploy_script → 客户端把 deploy_script 填进参数 → 取回两条现成消息 → 再把 deploy_script 这份资源的正文作为一块追加进第一条消息 → 发给模型。
| 节 | 进来时以为 → 出去时知道 |
|---|---|
| 1 | 以为服务器要送数据也得包成一个工具 → 知道资源是专门送只读数据的一类,以及为什么要和工具分开 |
| 2 | 以为「提示」就是用户输入的那句话 → 知道它是服务器提供的可复用话术,由用户挑、由客户端填空(主走查第 1 步) |
| 3 | 以为资源靠名字取用、列清单就拿到了内容 → 知道清单里只有地址和说明,正文要拿着地址再取一次(主走查第 2 步) |
| 4 | 以为读资源就是读回一段文本 → 知道要先判断文字还是二进制,二进制还要看类型(主走查第 3 步) |
| 5 | 以为把资源当成一条新消息发过去就行 → 知道要追加进同一条消息的块列表里,另开一条会让模型误解谁在说话(主走查第 4 步) |
| 6 | 还欠着第 05 章那两种认不出的块 → 认出「嵌入资源」和「资源链接」,并知道它们各自什么时候用 |
| 7 | 以为资源清单是死 的 → 知道服务器还能给带占位的地址样板,由客户端把变量填进去 |
| 8 | 以为三类东西可以随便挑一类实现同一个需求 → 知道设计上工具归模型挑、资源归应用挑、提示归用户挑,以及这条归属被打破会出什么问题 |
| 9 | 以为资源的用法已经定型 → 知道作者自己写明这一类还没被探索完,并见到一个把资源当缓存用的实际项目 |
07 反过来:客户端能给服务器什么
**主走查:**一台订机票服务器要从 3 个航班里挑一个,它自己没有模型,于是回头找客户端借——中间卡一道人工确认。(这台服务器和那 3 个航班是我们为演示编的。)
| 节 | 进来时以为 → 出去时知道 |
|---|---|
| 1 | 以为 MCP 是单向的 → 知道方向可以反过来,而且开放之前必须先声明,不声明服务器根本不会来问 |
| 2 | 以为服务器要用模型就自己接一个 → 能复述这一借的四步,并知道账单记在客户端头上(主走查) |
| 3 | 以为人工确认放哪都行 → 知道必须拦在请求发给模型之前,晚一步账单已经产生 |
| 4 | 以为根目录是一道权限限制 → 知道它只是一条建议,真正的把关发生在用户挑服务器那一刻 |
| 5 | 以为服务器缺一条信息就只能报错退出 → 知道后来加了「征询」,并知道要密码要密钥必须走另一条不经过客户端的路 |
| 6 | 以为每样能力都要单独学一套实现方式 → 知道它们的形状是同一个:写个函数、按规定的参数长相、建会话时挂上去 |
| 7 | 以为这几样是协议里的稳定部分 → 知道其中两样已被标记为将要移除,而服务器来问客户端的方式被整个换掉,理由在第 11 章 |
08 连接不是一根干净的管子
**主走查:**一次「把仓库里 214 个 Markdown 转成 PDF」的调用跑了 3 分钟——这 3 分钟里客户端陆续收到了什么,中途断线会发生什么。(214 与 3 分钟是我们为演示编的。) **另起一处走查:**一连上就要清单,服务器只给前 60 个工具 + 一个记号;不接着取就漏掉后面 120 个;连着的时候服务器又通知「清单变了」。
| 节 | 进来时以为 → 出去时知道 |
|---|---|
| 1 | 以为调用就是发一条、收一条 → 知道一件跑得久的活会带出四个额外问题,协议对每个都给了办法 |
| 2 | 以为所有消息都得一来一回 → 知道还有一类只管发、不等回复,进度和日志都靠它送(主走查第 1 步) |
| 3 | 以为进度条是应用自己估着画的 → 能复述进度怎么带回来,并知道这个数代表什么由服务器说了算(主走查第 2 步) |
| 4 | 以为服务器的日志只能在它那台机器上看 → 知道客户端可以挂个函数接住,级别用的是一套现成的八级标准(主走查第 3 步) |
| 5 | 以为线断了只能整个重来 → 能复述当时的续传办法,并意识到它要求服务器一直记着自己 发过什么(主走查第 4 步) |
| 6 | 以为列清单一次就全拿回来了、清单连上后就固定 → 知道清单可能分页、也可能中途变,两种应对各自的代价(另起走查) |
| 7 | 以为通知在 SDK 里能直接用 → 知道作者当时明写 Python SDK 没提供这个口子;并先埋一句:日志这条路后来被标记为将要移除(第 11 章) |
09 当你连的不是一台服务器而是五台
**主走查:**一个宿主连 5 台服务器、共 180 个工具——全部塞进模型要花多少,换成按需查找之后花多少。(5 台与 180 个是我们为演示编的;十几万对两千这个量级出自官方文档。)
| 节 | 进来时以为 → 出去时知道 |
|---|---|
| 1 | 以为连五台就得自己管五份连接 → 知道 SDK 提供了会话组,并知道它换来的方便与失去的自由 |
| 2 | 以为工具名是全局唯一的 → 知道唯一性只在单台服务器内成立,聚合多台必须自己改名;也知道该由谁决定把哪些工具交给模型 |
| 3 | 以为用了 MCP 就自动支持所有模型 → 知道中间还差一层翻译,并知道把它写成一个能自己转格式的类好在哪 |
| 4 | 以为自己写客户端是唯一的路 → 知道两家厂商都提供了直连,以及作者给的三条代价 |
| 5 | 以为把所有工具都摊给模型是理所当然的 → 能说出一个数量级,并知道该拿什么比例当切换阈值(主走查 第 1 步) |
| 6 | 以为省上下文只能靠删工具 → 能复述三层取法,并知道这正是第 05 章那笔账的还法(主走查第 2 步) |
| 7 | 以为每次工具调用都必须经过模型一个来回 → 知道还有一条路:模型写脚本、在隔离环境里串着跑完 |
| 8 | 以为按需查找是纯赚的 → 知道它把「挑工具」从模型手里挪给了检索;并知道书里最后那节 Best Practices 只有标题 |
10 三种被坑法:密钥、请求来源、以及借出去的凭证
**主走查:**一台远程 MCP 服务器要替你读 Google 日历——你手里那张凭证能不能直接给它,不能的话该走哪条路。
| 节 | 进来时以为 → 出去时知道 |
|---|---|
| 1 | 以为安全是写完功能之后再补的一节 → 知道原书在五个不同位置各留了一句警告,合起来正好覆盖三类风险 |
| 2 | 以为把密钥挪进 .env 文件就安全了 → 知道风险在提交那一下,以及一旦提交第一件要做的事不是删文件 |
| 3 | 以为把系统环境变量一股脑传过去最省事 → 知道这会把无关的凭证一起送出门,以及该只挑哪几个传 |
| 4 | 以为远程服务器加个密码校验就够了 → 知道至少要做两件事,漏掉第二件会被浏览器里一个陌生网页当枪使 |
| 5 | 以为把用户的凭证交给服务器最省事 → 知道这条路被规范明令禁止,并能复述正确形状(主走查) |
| 6 | 以为令牌就是一把通用钥匙 → 能说出服务器收到一张令牌要验哪几样,第一样是「收件人是不是我」(主走查续) |
| 7 | 以为用户点过一次同意就万事大吉 → 能复述混淆代理这个坑的形状:同意被浏览器记住,攻击者换个身份再来一次 |
| 8 | 以为照着书里那个 auth 参数填上就能对接 → 知道现在的规范用的是哪一套,以及旧的登记办法已被标记为将要移除 |
11 协议自己变了形 — 三样地基件是怎么塌的
**主走查:**同一条 multiply_two_numbers(a=12, b=30) 请求,左边按书里那套(先三条打招呼报文、再一条带编号的请求),右边按 2026-07-28 那套(没有打招呼、请求自带版本与能耐、结果多一个 resultType),逐字段对照。
| 节 | 进来时以为 → 出去时知道 |
|---|---|
| 1 | 以为书里的写法只是版本略旧 → 知道最新规范把三样地基件都拆掉了,同时知道旧写法仍作为「旧的那一代」被继续支持 |
| 2 | 以为协议改动是为了设计得更优雅 → 知道压力来自远程服务器必须多开几份来扛量 |
| 3 | 以为连接状态只是个编号、存哪儿都行 → 知道它意味着「服务器记得你上次说过什么」,多开几份之后这件事没法保证 |
| 4 | 以为打招呼和连接状态是两件独立的事 → 知道打招呼的产物本来就存在那份状态里,状态没了它只能跟着每个请求重报(主走查) |
| 5 | 以为取消打招呼之后只能盲试 → 知道新增了一个服务器必须实现的问路方法,而且客户端可以不问 |
| 6 | 以为服务器要问用户就直接朝客户端发一条请求 → 能复述新形状:先答「我还缺这几样」,客户端补齐后换个新编号整条重发 |
| 7 | 以为「可带走的」到这里就完了 → 知道同一条理由还剩两级没推,而且知道它们是哪两级 |
12 塌下来的其余部分 — 断线、订阅,以及这本书还剩什么
新增的一章(复审时从原第 11 章拆出来的:那一章 13 节、32 KB,新词也超配额)。
**主走查:**第 08 章那次「214 份文档转 PDF、跑到第 180 个断了」的调用,换到新规矩下再跑一遍—— 断了怎么办(§2)→ 不想白跑改走哪条路(§2 末、§5)→ 重连之后必须补做什么(§3)→ 要不要重取清单(§4)。 (走查里的具体数值全部是我们为演示编的;哪些被删、哪些必须重做,全部出自规范。)
| 节 | 进来时以为 → 出去时知道 |
|---|---|
| 1 | 以为第 11 章已经把话说完了 → 知道还剩两样也建在「服务器记得你」上面,并拿到这一章的走查路线 |
| 2 | 以为 断线续传是必备功能 → 知道它依赖服务器记着自己发过什么,与「不记着你」正面冲突,于是被删了;也知道那条「任务」出路要付什么前提 |
| 3 | 以为订阅不受影响 → 知道服务器主动推的那条路被换成了「客户端登记一条长回话」,而且重连之后必须重新登记 |
| 4 | 以为改动只有上面这几条大的 → 知道还删了几个小方法、给清单结果加了保鲜期,并能说出它们同出一因 |
| 5 | 以为协议会一直往核心里加功能 → 知道后来的做法是把非核心的东西拆成可选扩展、各自单独排版本 |
| 6 | 以为地基换了这本书就作废了 → 知道哪几部分仍然成立、哪几部分只能当历史读(日志也在这一栏),也知道弃用的理由规范根本没给 |