第 19 章 架构决策方法论

本章把散落在前面各章的判断收拢成五件能直接上手复用的东西，规格、映射表、双轴地图、失败模式审查和选型纪律；真有一份新需求摆到桌上，先动哪一样、按什么顺序动、哪一步该停下来质疑，任何单独一章都答不上来，机制人人会用，用得熟不熟只影响快慢，真正拉开差距的是先做什么后做什么、每一步凭什么这么定，资深架构师和熟练工程师的区别就在这里，比的是决策方法，不是 API 熟练度，这句话也是第七部分的立脚点。19.1 讲规格本体，需求里的含糊在这里一份份写成条款，规格的三档形态、冲刺契约和计划的尺寸都在这节立规矩；19.2 给出一条从需求到架构的路，白板先把需求拼成最小组件，映射表再把任务特征一行行问下去，架构档位就一格格显出来，每条判据都标着出处；19.3 摆两件对照，一件是开发者自己的双轴工作地图，五个工作位在图上各有各的位置，另一件拿工作流的形状去对照设计模式，把编排这一层的词汇分清楚，这件是搭着讲的对照，不计在五件里。19.4 把第 14 章引过的那份失败模式清单翻过来用，上线前逐条自查，十种失败方式按审查时机分三组，另补一套威胁建模，专管蓄意来打的那类风险；19.5 把第 17 章给框架选型算成本的那套办法挪到一切选型上用，时效风险、供应商锁定和迁移成本，三条纪律比任何具体结论都活得久；这一章五节，问的其实是同一件事，手感里的决策，怎么才能变成一道工序。

19.1 从需求到规格

一份需求文档放到面前，第一步做什么？一种做法是技术先行，先定模型选哪家、框架用哪个、编排怎么搭；另一种是先追问任务本身，这项任务到底缺什么、错得起吗、等得起吗。demo 阶段两种顺序看不出差别，进了生产才见分晓。技术优先的系统，常常是技术堆了一大堆，业务上的缺口还留在那儿没人管；任务优先的系统，每样技术都对着一个具体缺口，不多一样也不少一样。

先任务后技术，任务这一侧最要紧的产出是规格。规格写含糊了会出什么事？有人做过一个试验，把一段模糊的功能描述发给五个并行智能体，那段描述很简单，不过是给内部工具加一个报表接口。五个都交回了能编译、能跑、能通过测试的实现，却五花八门、各错各的，有换了鉴权方式的，有改了返回结构的，有把数据写进另一个库的，还有一个照着仓库里相似功能的模样，把规格没写的部分补了大半。

问题不在执行力，在规格。五个都能干、也都尽了力，结果却各走各路，原因就在描述含糊。规格里每一处含糊，“按惯例鉴权”“错误处理要妥当”“性能要好”，智能体都自己挑一条路走，不会主动说这里其实有个岔口。五个并行智能体，带回来的是五份各自补全的规格，需求原文只有一份，另外四份全凭各自补全。

规格装什么，现成有一份七类清单，目标、验收标准、不变量、集成边界、完成定义、前车之鉴和开放问题。篇幅另有纪律，整份控制在 500 到 1000 词之间；想写到 800 词以上，先查一条更硬的对照，规格不许比预期的改动长，长出的一截，多半是把实现细节错当成了需求。

验收标准这一栏里，有一条最见功夫，只要某条标准绕开真问题也能通过，智能体就会利用这个漏洞。“所有测试通过”就是这一类，测试写松了，通过不代表问题解决。规格的边界也在这里显出来，想做什么，规格写得进去；做得合不合品味、该不该做，规格写不进去。有个试验让人去研究竞品、起草改动，交上来的东西测试全绿、文字漂亮，读代码才看出那些功能本就不该做。规格挡不住这种错，该不该做的判断，外包不出去。

规格不是一种尺寸，任务有大有小，规格跟着分几档。最轻的一档对一件有边界的小事，一个智能体、跑一遍、合成一份改动就收工，写起来几段话就够，一段目标、三五条验收标准和一张要动哪些文件的短清单，再指一条相似实现的路。中间一档对多步的产品活，几份改动、可能几个智能体、可能跨好几天，上面那份七类清单和篇幅纪律，说的就是这一档。最重的一档对跨周到跨月的大事，一次迁移、一次平台级重构，规格实质是一份设计文档，写清问题是什么、终态长什么样、架构粗到什么程度、约束有哪几条、怎么分步推上去。这一档用得比任何一次运行都久，也就最容易漂，管理上要当成正式资产，进版本控制，写明谁拥有它，定个刷新节奏。智能体分不出手里这份规格是新的还是旧的，版本控制、主人和刷新节奏三个缺一个，它就照着一份过期文件埋头干。三种形态都放进仓库里智能体够得着的地方，改动记录里顺手引用；留在聊天记录里的规格，过几天谁也翻不出来。

规格定了不能直接放行，中间还该签一份冲刺契约。契约就是提前谈定的完成定义，写进文件而不是留在提示里，列的每一条都让外人能核查。不少编码智能体都带了计划模式，让智能体先把计划写成文件停在那儿，计划里重述验收标准、列出步骤和要动的文件、写明自己的假设和疑问；人读计划、纠正误读、补上它缺的上下文，批准了才开工。这道关分得开两种情况。计划把清楚的规格读偏了，是它读错，改读法就行；计划照着规格读对了、奔向的却是不想要的结果，那是规格本身要错了东西，执行得再漂亮也救不回来。契约一签，本轮就冻结。中途想改完成定义，那就等于重新谈一轮，不是把文件悄悄改一改就能了事；能悄悄挪动的完成定义，谁也不会把它当真。开工之前还有一步便宜的保险，让智能体先当这份规格的审稿人，照着这份规格干活，看哪里有歧义、哪些边界情况没盖住、哪些不变量没写明。它马上就要执行这份文档，挑规格的毛病往往比人事后挑还准。这一步我后来用成了习惯，人顺手放过去的歧义，模型读规格时往往当场就挑出来。开销这一头也得有数，一眼望得尽、又不碰公共接口的小任务，直接派发更划算，契约那套留给值得立契约的任务。

契约立了，计划本身还有尺寸问题。计划读着漂亮，不等于验证过，顺着读一遍、点点头就放行，那不算审。还有一道更隐蔽的陷阱，为了让计划有据，先派一个子智能体把代码库整个摸一遍，这一个动作就可能占用小半个窗口，等真要动手，余量已经不多。解决办法不是把前置的功夫砍掉，是改它的结构，把大计划切成一段段可验证的小阶段，每段小到能整个查完；一段查不过，下一段就不动工。趁窗口还有余量，把不确定性分批压掉，前置的功夫才花得值。

规格、契约和计划三份都立在开工之前，把需求里的含糊一份份换成了白纸黑字。

19.2 从需求到架构的映射

从规格到架构的形状，中间可以用一块白板过渡。先把“这是智能体应用还是普通服务”这个问题放到一边，只看应用由哪几类操作组成，归纳起来四类，收集信息、做决策、总结和生成输出。每类在板上画一个形状，按数据流向连线，拼出满足需求的最小组件数。拿收集信息说，查询的种类一多，比如一边问库存价格、一边问营业时间，就放两个收集组件，各管一种。

拼完之后再剪枝，剪枝的依据是模型调用本身的固有代价，时延高、端点会宕、响应时间不定、结果不确定、还按 token 计费。剪枝通常有两条路，互相不依赖的调用改成并行跑；能不调模型的环节换成规则或缓存。这样拼出来的自定义微架构，常比照抄现成的智能体模式更贴需求。第 9 章的最简可行架构原则，落到白板上就是这个动作。

拼板和剪枝里还藏着两个叫得出名字的动作。把跟这份需求无关的特征从板上删掉，这个动作叫抽象（abstraction），判断的依据是目的，不是数据有没有，不能因为手里恰好有数据就把一样东西塞进架构，也不能因为没数据就当它不存在。把没数据支撑的特征用理想形状顶上，这个动作叫理想化（idealization），查不到确切的分布，用一条形状对得上的曲线，照样能把机制跑通。板上每删一样、每抹平一样，都是有意识的取舍，取舍的理由写得下来，这份架构才经得起评审会上的追问。

先看任务还是先看技术，这个次序可以练成方法。全书的机制章各立各的判据，散着放只能靠记忆临时调取；收拢到一处，就是一张能反复用的表。它跟前面的白板法也分好了工，白板拼组件形状，这张表定架构档位，动手的次序是先白板、后映射。这张表怎么搭？先把架构该停在哪一档问清楚，这是最核心的一层判断；再看还有哪些变量会推翻这个判断。

架构停在哪一档，出处是第 9 章的四级阶梯加三问。任务靠生成文本就能办完，停在最底下的直连模型；要到文本之外做事，回路得挂上工具，进到单智能体；解法写得成固定流程、控制权留在开发者手里，用工作流；路径要靠探索才浮现，这才谈得上自主多智能体。四级自下往上，靠三问一级一级往上逼，而且每回都先问最低一级为什么不行。

工作流与自主多智能体这两档还能再细分一层，用的是第 10 章那条控制权的线。这条线从档位的第二级往上接，工作流四式与自主三式在这条线上各占一段；控制权要放多少，就在这条线上挑一个点。

架构档位之外，还有三件事得单独定下来，知识与记忆的来源、权限给多少、成本与时间花在哪，件件都能推翻已经定好的档位。比如工作流明明选得好好的，成本与延迟一算，可能整个档位退回去。

三件事里，第一件是知识与记忆的来源，定下来之后，工具要不要挂也就有了答案。第 9 章那组实验给过一条结论，工具密集的任务上，收益算在工具头上、不算在编排头上，把搜索挂到单智能体上，播客调研照样拿 9.0 分，满分 10 分。知识不在参数里而在库里，那就走第 6 章的检索，条款库、商品库和文档库都归这类；任务跨会话要延续，走第 8 章的记忆，会话内的状态用短期，跨任务的沉淀用长期。

这里还有一条反向提醒，第 14 章引过，不是每个智能体都需要记忆。无状态更简单，也更快；记忆自带检索时延与存储成本，到底值不值得，得让评测来说话。

第二件是权限给多少。第 13 章的 Rule of Two 先划硬线，不可信输入、敏感数据、改变状态或对外通信，三项全占的会话，不许自主跑，必须引入人机协同。硬线以内还要分，第 15 章的四种形态标出拦截点，动作执行先过人的审批，人给的答复只有批或不批；任务规格有缺口，先让智能体把要害问清再开工；长任务先批方案，里程碑处停下验收；运行中随时能叫停，处理完再接着跑。前三种拦截要跨进程、跨天数都能恢复，靠的是第 15 章讲的把拦截状态入库。

放权的节奏按渐进自主走，起步时限制得紧，跟着评测数字一档一档放开，回退条件事先备好。这一件交出的是一张档位表，哪类任务跑到哪一档、过了线怎么退。

第三件是钱和时间花在哪。第 9 章四项代价里的 token 与延迟，会直接动手改架构，多角色串行轮转攒出的延迟，面向顾客的界面往往等不起；大流量高并发的业务，天生容不下成倍消耗 token 的编排。

这一件还有三个旋钮从第 14 章来，成本记录、路由和缓存，简单任务分流给小模型，固定前缀能直接命中缓存。最后一步对应第 15 章的部署形态，秒级在场的交互走同步 API，天级的长任务交给 worker。这一件最常干的事，是倒过来改写前两件的结论，同样是初审任务，一天十件的精品线与一天一万件的共享中心，模型和编排选起来完全是两回事。

档位判断加上这三件事，问完还差一问，成败可判定吗。这一问是从第 12 章评测闭环借来的，既不占档位这一层，也算不进那三件事。可成败要是判不了，改进就没了依据，于是这一问单独占一行，凑成完整的映射表。

特征问句	它逼出的决策	判据出处
只靠生成文本能完成任务吗	能就停在直连模型	第 9 章问题一
答案在模型参数里吗	不在就挂工具或检索	第 6 章、第 9 章
解法能写成固定流程吗	能写就用工作流，控制权留在开发者手里	第 9 章问题二、第 10 章
各步骤要的专长不同吗	分化才上多智能体	第 9 章第一道闸
子任务之间相互独立吗	独立可并行，动态分工用监督者	第 10 章
一份上下文装得下吗	装不下先压实与隔离，子智能体先行	第 7 章
任务跨会话要延续吗	要才上长期记忆	第 8 章
Rule of Two 占几条	三条全占必须加人机协同	第 13 章
动作不可逆吗	不可逆挂审批，风险分级定档位	第 15 章
交互是秒级在场吗	是走同步 API，长任务走 worker	第 15 章
流量大到成本敏感吗	大就上模型路由与前缀缓存	第 14 章
成败可判定吗	硬判不了就把判定要点交给裁判，闭环评测才建得起来	第 12 章

这张表从上往下问过去，问到哪一行答不下去，架构就停在哪一级；答不上的那一行，就是动手之前要先补的作业。

场景取某保险公司的车险理赔初审。送进来一份案卷，报案信息、现场照片、维修单据和保单记录都装在里面；交出去的是一页初审意见，把材料齐全性、责任认定要点、赔付金额建议和欺诈风险标记写清楚，再递到人工核赔员手里终审。

拿这份案卷对着表，从上往下一行行问。先问只靠生成文本能不能完成任务，答案是还不能，系统得读案卷、查条款、把结论写进理赔流程，直连模型这一档直接出局。接着问答案在不在模型参数里，也不在，条款跟着版本修订，具体案情全在材料里。于是给回路挂上检索工具，去接条款库，这正是第 6 章 RAG 管的场景。

第三个问题问解法能不能写成固定流程，答案是能。接案、查材料齐全性、核条款、责任初审、欺诈信号、组装意见，六步顺序基本固定，伪代码能覆盖八成情况，这条经验上的判断线来自第 9 章第三道闸。于是架构定在工作流这一档，控制权留在开发者手里。

接着问各步骤要的专长是不是各不相同。材料齐全性是规则型任务，确定性代码最稳；条款核对是检索加比对；真正称得上语言判断的只有责任认定。数下来，非模型不可的专长只有一到两种，过不了第 9 章第一道闸，于是不上多智能体编排。最后的形态是外层六步确定性流程，只在责任初审与欺诈信号两处语言节点上走模型。

再看子任务之间独不独立。六步前后咬合，接案没做完谈不上核条款，只能顺序执行，并行与监督者都用不上。

知识与记忆，从上下文容量问起，一份案卷的照片加单据几十页、条款几十条，压实再配即时检索就够用；唯独欺诈调查要翻投保人几年的历史案件，得单独开一份上下文，第 7 章的隔离策略正管这一类，单开分析智能体，只隔离、不协作。这三件事能推翻档位判断，说的就是这种时刻，档位这边刚定下不上多智能体编排，知识与记忆这件事偏偏给欺诈节点开了个例外。

接着问任务跨不跨会话。同一案件的多次补件要接上，短期记忆管得住；跨案件的模式分析属于运营层的离线活，不塞进初审回路，长期记忆第一版不上。然后走到权限这一维，拿 Rule of Two 逐条对。单据照片是外部提交的，占不可信输入这一条；保单与个人信息是敏感数据，再占一条；初审意见会推进赔付流程，等于改变状态。三条全占，硬线生效，终审权必须留给人，系统只给建议权。

再往下，看动作可不可逆。赔付打款绝不在这条链路里自动执行，人工核赔岗天然就是里程碑确认的形态，不用再造一道闸。交互是不是秒级在场？不是，案件是天级任务，走 worker 部署，白天到件的当晚跑完就行。

再问流量，大到对成本敏感吗？一天几千件，材料齐全性检查这类规则强的节点上轻量模型，责任认定上旗舰，正好用第 14 章的路由；条款库是固定前缀，缓存命中率天生就高。末了一问，成败可不可判定？可以。历史结案卷宗就是现成任务集，抽出已结案件让系统初审，拿人工终审结论去比对，第 12 章的回流管道直接搭在核赔员的改判记录上。

十二行问完，方案自己就成形了，外层是确定性工作流，两处语言节点走模型，条款库检索挂上工具，欺诈调查按需隔离一个子智能体，初审意见交人工核赔，部署走 worker、配上路由与缓存，历史卷宗拿来当任务集。每一项都能对回表上的某一行，谁也没法再凭个人喜好争来争去。

映射表还有反向的用处，及时停住过度设计。法务部要抽合同要素，甲乙方、金额、期限和管辖法院，输出结构化 JSON。这份需求第一行问句就拦住了它，只靠生成文本就能办成，拿第 3 章的结构化输出约束一下，直连模型就够。再往下，补一行评测就行，抽检错误率按第 12 章的办法盯住，哪天指标变差了，再谈升级。这份需求在映射表上两行就问完了，问句的用处本来就包括让人早点停手。

映射表长什么样，各个企业并不相同。做医疗的会多问一句合规，做出海的会多问一句数据出域；变的只是问句，机制不动，仍是把判断拆成一条条带出处的问句，按顺序问到底。

19.3 开发者的工作位与设计词汇

映射表管的是交付给用户的系统停在哪一档；开发者自己站在哪儿干活，那是另一道题。讲到自主程度，业界常摆出一条阶梯，从辅助一级一级升到全自动，越往上越自主。2026 年有两本书各自觉得这条阶梯装不下，都动手拆了，两边还没有互相引用。一本从社区流传的八级阶梯与五级阶梯出发，拆成两根轴，一根量单个智能体的自主性（即第 2 章的自主度），一根量并行编排的智能体数；另一本从认知科学的传统出发，同样画了张双轴地图，可轴选得不同，量的是认知功能与执行拓扑，把自主性放到轴外。拆法两样，共同点只有一条，一根阶梯摆不下开发者的位置，非要两根轴才铺得开。

五个档位沿对角线自左下排到右上，对角线外另有两个角落。

第一本书把轴张开，五个工作位沿对角线排开，每个位子写两件事，人干什么，智能体干什么。从下往上数，最低一档，人驱动每一步、逐个批准，智能体只提建议；再上一档，人交出一个圈定范围的任务，盯着它跑完全程，智能体自己跑多步；中间一档，人写下任务简报就走，回头只看结果，智能体无人值守交回改动；更高一档，人同时协调三五个并行的智能体；最高一档，人只定结果、按异常介入，协调交给部分自动化。

把这五档收进一张表，后文引用会顺手些，编号沿用第一本书的 S1 到 S5。

档位	人干什么	智能体干什么
S1	驱动每一步、逐个批准	只给建议
S2	交出一个圈了范围的任务、盯完全程	跑多步
S3	写下任务简报就走开、回来只看结果	无人值守交回改动
S4	同时协调三五个并行的智能体	多个智能体并行跑各自的活
S5	只定结果、按异常介入	一大群智能体，协调部分自动化

这张地图上有几条固定的误读，最好当自查清单逐条过。有人把阶段错当成了地位，以为档位越高越体面，其实把位置定对才是本事；有人把数量错当成了阶段，手工排序十个智能体就以为上了高阶段，干的却仍是手工协调；有人拿智能体对自己工作的自述当审查，那等于自导自演，不能算数，真要审，得搬 diff、测试输出和日志这类证据包；还有人把权限确认弹窗一关到底，以为自主性就此涨了，其实只降了摩擦、一分自主性都没涨，这叫许可洗白。还有一条容易弄错，验证不是第三根轴，它贴着两根轴走，位置越往上越要紧。

对角线外的两个角落，照样算健康工作位。一个智能体全自主地单干，或一群低自主的智能体高并发，都是正当的工作位，硬要按对角线走反而误解了这张图。给日常定位找参照的话，Anthropic 分析过自家约 40 万个编码智能体会话，典型会话里人做约七成规划决策、模型做约八成执行决策；这数字是厂商分析自家产品得出的，没经第三方核对。所谓高自主，就是人留下判断、交出执行。它跟第 9 章的四级阶梯并不重复，那边给产品架构定档，这边给开发者挑工作位。

第一本书在这张地图之前，还画过另一张配套的图。档位量的是组织形态，纪律是另一根独立的轴，从对智能体的产出一点工程纪律不施加，到全套纪律都施加，每个开发者天天在这条谱上滑来滑去，滑本身没错，错的是把自己在哪一格判错了。谱分五区。最低一区纯凭感觉，提示一发、结果一收，规格、评审、测试和归属一概没有，写个用完就扔的脚本可以这么干。第二区还是凭感觉，只是扫一眼改动，离谱了才打回去。第三区是大多数职业工程师的实际坐处，脑子里有个快速计划，改动看得过去，测试有一些但不够，责任感模模糊糊，做内部工具够用。第四区是完整的做法，规格先行，像样的改动都过评审，测试卡着合并，权责清楚。第五区在第四区之上再加一群并行智能体互相盯着，评审大半交给评审智能体。区位还该跟着爆炸半径浮动，内部迁移脚本停在第二区是有意的安排，对外客户的任务钉在第四区是应当的安排。

两图配着读才读得全，区谱量纪律，档位量组织，交叉出来的组合都真实存在。第四区的纪律停在 S2 的组织，一个人带着一个智能体把活干扎实，健康；第一区的纪律爬上 S4 的编排，一群智能体并行狂奔、产出没人审得动，这正是误读清单里那些问题的根源之一。最常见的自欺也有固定的样子，坐在第三区，真心相信自己在第四区，代码看着干净，测试也是绿的，底下没有一份真规格，一切都好，直到生产出事，才发现没人说得清那版到底改了什么。自查不靠问感觉，翻出上一两周的改动记录，数三个数，几份过了规格、几个改动过了评审、几回测试真卡住过合并，数字在哪一区，人就在哪一区。

另一件对照不是定论，是一家之言，说的正是工作流的形状算不算设计模式。ReAct、Plan-and-Execute 和 Reflection 这类名字确实有用，可拿设计模式的严格标准量，它们只够当提示策略与工作流形状，讲不出规范的参与者、各自的职责、怎么协作、失败了怎么处置。持这派看法的人相信，真正的设计语汇还得回到经典设计模式与企业集成模式那套，智能体应用其实就是这些模式拼出来的微架构，随便哪种工作流形状，都能拆成命令、中介者和过程管理器这些经典词汇。

第 10 章那条控制权的线，搁在这套词汇里属于工作流形状那一层；形状再往下还有一层传统技艺，谁来路由消息、失败了往哪投、怎么把一次请求和它的回应挂上钩，这一层归经典模式管。持这派观点的人还说过一句断言，智能体系统败在集成层，不在模型。这句话只是个人判断，没有数据背书，但拿它问一遍自己的设计，集成层这项成本往往确实没算过。

同一派还有两个判断值得顺路记下，都当观点听，不是定论。一个说，拿模式词表跟编码智能体说话，幻觉会更少也好认，理由是模式语料小而精确、内部一致，比几十亿行任意写成的代码好学；它给词汇之争补了第二条理由，词表不光让设计讲得清，还可能让产出错得少，信不信，可以拿自己的项目对照试。另一个是成本上的判断，维护占软件总成本的大头，这个比例比智能体老得多；智能体把生成做便宜了，维护一点没便宜，产出翻一倍，要维护的代码就翻一倍，短期省下的打字功夫，变成长期的维护成本。照这笔成本看，一套智能体开发方法值不值得，标准不是产出快了多少，是有用变更的成本降没降。代码量涨上去之后，出问题的地方多半还是集成层，那句断言也就越听越重。

映射表问完、双轴地图照完、设计词汇对完，这之后还有一道省不掉的工序，对着失败模式把自己查一遍，查过，架构才算定。

19.4 失败模式驱动的架构审查

上线之前怎么知道设计里还藏着哪些没暴露的问题？第 14 章 14.4 引过一份清单，列着十种生产失败模式。攒下这份清单的人，在 AutoGen 框架上做了两年、还负责着生产部署，结论是多智能体系统的失败方式一致而且可预测。那一节拿清单当诊断图，出了事对号入座。

同一份清单还能换个方向用，把顺序掉个头，赶在上线之前逐条自查。每种失败方式都对着设计里的一个固定位置，一条条比对过去。落到具体操作，审查成了评审会上的第二份固定材料，架构图讲打算做什么，这页问题讲哪里可能出事，两份并排放着读。

清单有个照顾不到的角落，它只管系统自己会怎么坏，不管有人存心要来打。第 13 章的沙箱与纵深防御，管的是人已经打进来之后怎么止损；要找威胁，还有一道更靠前的工序，叫威胁建模，它干的是把系统的潜在风险找出来、记下来、逐条处置。整道工序绕着四个问题转，正在开发什么；可能出什么问题；能做点什么；做得够不够好。它最好放在设计阶段做，架构定稿之前过一遍，找一组熟悉这个应用的人来弄，再请懂安全的人参与。讨论必须拿出结论、留下记录；找到的漏洞录进现成的缺陷跟踪系统，现有措施已经挡住的也记录在案，这样既不会重复劳动，措施也经得起检验。

第一个问题的答法，是先画数据流图，再在信任级别不同的组件之间划出信任边界，威胁往往聚在数据流跨过边界的地方。第二个问题找威胁，STRIDE 是现成的做法，六个字母对着六类伤害，欺骗、篡改、抵赖、信息泄露、拒绝服务和权限提升。它不算严格的分类，目的只是帮人把想漏的补上，图上每个元素都挨个过一遍，六类都问到才算完。给智能体做建模，工具还得按最大效应去写，别写只读一个文件，要写它能读到工具进程有权访问的任何文件，照最坏的情形估算，权限范围才算得清。评审会上，数据流图和失败模式问题页摆在一起，一份问谁会来打，一份问自己会怎么坏。

这道工序光讲框架容易空，拿一个最小的应用从头走一遍就落地了。应用是个带网页界面的聊天机器人，能从产品库里取信息，回答关于公司产品的咨询。图上五个元素，用户、网页前端、模型、一个查库的工具和产品库；数据顺着这条链走，信任边界画三道，用户跟前端一道，前端跟模型一道，模型跟数据库一道。威胁聚在数据流跨边界的地方，顺着流挨个问过去就找得到。用户不直接碰库，可发给模型的请求会影响进工具的输入，SQL 注入就这么钻进来；提示注入更绕，藏在一条商品描述里，等有人问到这件商品才跟着进上下文，它自己不直接造成损害，专给别的威胁开门；一个用户能读到另一个用户的聊天记录，是经典的信息泄露；网页服务器带着没更新的已知漏洞，这一条已经是组织层面的活。找到了别只记名词，一条写得好的威胁，要能指向该做的工作，光写“提示注入”四个字不算数，得写清它在这张图上从哪进、往哪去。

对策接着对号。查询一律走预编译语句，工具只授只读权限，模型就影响不到 SQL 本身；聊天记录只存在浏览器侧，功能损失一点，这个应用够用；网页那一层上防火墙，服务器补丁交给资产清单和补丁管理。对策摆完不算完，还得拿“可能出什么问题”再问一轮，防火墙挡得住绕过吗，日志能不能把可疑的访问模式查出来，第一道防线失灵之后还有什么。问出两层，才够得上第 13 章讲过的纵深防御。最要紧的是给每条对策配一个定义清晰的测试，服务器版本检查适合自动化，直接进现有测试套件；越权访问这类自动化费劲的，列进定期的渗透测试。威胁建模不是白板练习，画图那部分反而最容易，洞见只有变成措施、配上测试、持续检验，这道工序才算干过。这页从图到威胁到对策再到测试的记录，跟失败模式清单在评审会上各管一头，接下来把清单本身过一遍。

清单数下来是十条，清单之外另有一条门槛提醒。它说的不是系统会怎么失败，而是很多团队根本不需要一个多智能体系统，动手之前先得问该不该上。门槛那一条的判据，第 9 章已经讲透，这里只把它放在审查最前面，问一句“这个任务过了三道闸吗”，不展开。

十条按什么时候查，归成三组。前四条的错全刻在设计纸面上，人坐在桌边就能查，代码还没写，错已落下；中间四条得等跑起来才现形，症状都记在轨迹里；最后两条根本不是技术参数的事，是制度上缺了安排，系统做得再对也没人兜底。三拨分别过，每拨配一组审查问题。

设计期的四条，纸面阶段就能查。这四条错修正成本最低，所以最先讲。第一条是指令不够细（14.4 清单第 1 条）。症状不难认，系统提示只写一句“帮用户处理售后问题”，工单复杂起来，行为就跟着飘，同一个输入时好时坏。对策第 14 章引过，把指令当活文档养，评测每失败一条就补一条针对性规则，好的提示能长到好几页。

第二种失败方式，小模型没人管（14.4 清单第 2 条）。症状一眼可见，为了压成本，旗舰直接换小模型，指令遵循明显变差，协调类任务成片垮。想降本不能直接换小模型，先用旗舰摸清基线与任务要求，再从路由、蒸馏和模型级联三条路里选。路由能省多少，第 14 章引过数据，约 15% 的成本换约 90% 的表现，那也是单次实验里的数字。

第三条，指令与模型不匹配（14.4 清单第 3 条）。症状长这样，一换模型，同类失败成批冒出来，旧提示在新模型上明显不匹配；同一个模型只换个新版本，系统提示都不保证还能用，更不必说跨厂商。对策是按模型家族各维护一套指令集，放进版本库；换模型必须重跑评测验收，过渡走 A/B，不直接切。四条里数这条藏得最深，换模型的当下常常一切如常，退化要过好几天才从客诉里显现出来，第 12 章的回归任务集是最可靠的验收手段。

第四条，编排模式选错（14.4 清单第 6 条）。这种错一眼能认出来，token 消耗巨大，质量却不见涨，明明是线性任务，非要给它套上自主编排。第 9 章的现成数字就在手边，简单推理直连模型 9.7 分、AI 编排 9.3 分，token 差 43 倍；那是单次实验的口径。对策仍是最简可行架构原则，先从最简单且可能奏效的模式跑起来，评测证明有收益，再往上加复杂度。

设计期的审查，就问这四句。

1. 系统提示交给一个没见过项目的工程师读十分钟，他说得出遇到工具报错时该怎么办吗
2. 现在用的模型是旗舰吗；不是的话降本走的哪条路，谁验收过
3. 换模型的预案在哪份文档里，换了模型提示跟着换吗，评测重跑吗
4. 这个任务写得出伪代码吗，八成情况覆盖得住吗，覆盖得住为什么还用更重的编排

运行期的四条，跑起来才现形（14.4 清单第 4/5/7/8 条）。第 12 章说过，轨迹是评测的统一对象，这套逻辑搬进上线前的自查同样成立，把四种失败方式各跑一遍，轨迹就是证据，症状一条条写在里面。工具质量差，轨迹里是同一个工具反复报错、模型换着参数碰运气，或是工具一抛异常、整个回路跟着断。对策就一条，宁少而精，10 个可靠工具好过 50 个平庸的；工具出错永远给结构化错误，别抛异常，限流与失败模式写进工具描述。

不知道什么时候该停，轨迹里长这样，轮数逼近上限还没收敛，或是到第六轮突然交出一份半成品。反例同样是现成的，终止条件只等模型说 TASK_COMPLETE，指令里却始终没告诉模型要说这个词，于是轮次直接顶到 max_rounds。对策是让终止条件和指令保持一致，给一个显式的任务状态工具，叫模型交出完成态和理由，阈值拿生产数据来校准。

用户那头的症状最直接，每回来访都要把背景重新交代一遍。这背后是缺记忆，单看一条轨迹还看不出毛病，把同一用户两回的轨迹并排放，问题才现形，同类问题反复出现，次次从零开始。对策还是第 8 章的按需上记忆，当收益盖不过检索时延与存储成本时，就继续无状态。

元认知缺位，在轨迹上最难看出来，第三步的计划和第八步的实际越拉越远，智能体却从不回头，一路错到顶。对策是带复盘的计划式编排，每完成一步就评估一次进度，进度不够就重新规划。代价摆在那里，复盘自己也要消耗一次模型调用，这笔开销省不掉。

运行期的审查，就问这四句。

1. 抽十条失败轨迹，工具报错占几条，哪个工具最多
2. 平均几轮完成，max_rounds 与 timeout 触发的占比多少
3. 同类用户第二次来访，系统认得吗，该认得吗
4. 长任务的计划与进展偏离多远时，有谁会知道

组织期的两条，制度的缺位（14.4 清单第 9/10 条）。复盘时最先认出它们，根源都不在代码里。没有评测是其中一条，样子很好认，优化全凭感觉，说不清这一版比上一版好在哪。对策在第 12 章讲了一整章，评测从第一个案例攒起，写代码前先把那五个评测问题答完。

组织期的另一条，是拿不准什么时候该交人工，走两个极端。一个极端，高危动作没守住，查快递和发起赔付在模型眼里权重相同；另一个极端，什么都送人工审批，审批成了摆设。第 15 章整章讲对策，四种形态定位置，渐进自主定节奏。

前面八条与这两条之间，隔着一个层次。八条查的是系统，错要么在纸面上、要么在轨迹里，都有处可翻；这两条查的是制度。而制度里真缺了评测，不光这两条答不上来，其余九条查出来的对策有没有效，也没法证明，这份审查清单自己都先跑不动。

组织期的审查，就问这两句。

1. 上一次系统改动的效果数据在哪，拿得出来吗
2. 高危动作清单在哪，谁定的，多久复核一次；审批通过率长期高于 95% 了吗（长期这么高，说明什么都送审、审批形同虚设；95% 的阈值第 15 章引过）

从 19.2 理赔初审那套方案里，抽四句逐条试。第一句是门槛问题，任务过了三道闸没有？专长只一两种、路径伪代码能盖八成，三道闸把它拦了下来，结论是不上多智能体，方案里最重的是六步确定性流程，通过。再试设计期第三句，换模型的预案在哪？方案里责任认定走旗舰、材料检查走轻量，两套指令各自维护、各自挂着评测任务，通过。

运行期第二句接着看，平均几轮完成？worker 部署的天级任务，轮数与超时占比要等上线后从轨迹里取，先记成整改项。组织期第二句，审批通过率多少？人工核赔岗现成，通过率与复核周期得写进运营制度，一样记整改项。四句问完，两处当场通过、两处进整改，审查交出的是这份带答案的清单，不是一句“看着没问题”。

这份清单不是拿来回味一遍就完的，它要进评审材料。评审会上把问题一页页过，答得上的当场给答案，答不上的进整改单、定个期限，期限一到重新过一遍，不带病过关。做过大改动，还要再自查一轮，问题还是那些问题，答案却会变。

它和 19.2 的映射表各防一层错。映射表防的是档位选错，清单防的是档位选对了也没做对，指令、工具、终止和记忆要一件件补齐。门槛那一条与编排模式那条仍是第 9 章的判据，所以审查算不上新知识，只是把旧判据再查一遍，便宜也就便宜在这里。三组问题一共十句，算上门槛那一句，一次审查一小时内走完。拿一个小时的工序去抵它挡下的故障，性价比再高不过。

出了事按什么次序去修，原则现成，系统层在前，模型层最后。指令、工具、终止条件和编排结构统统归系统层，改起来便宜，见效也直接；模型层放最后，一是它贵，二是动模型必须拖着指令与评测一起动。十条清单的分组恰好顺着这个次序，直接沾模型的只有两条，还都在设计期，另外八条全是系统层与制度层的活。第 14 章 14.4 事后定位用的也是这层意思，先查系统层参数再动模型，次序一样。

两关都过了，架构与审查各自有了工序。可以做个练习，把十种失败模式当审查清单，拿手头的设计文档逐条问“这个设计会怎么败在这一条上”，每条写下一句它会怎么失败。写不出来的几条，要么是当真防住了，要么是还没看懂设计，两种情况都值得在评审会上摆出来讲清。

19.5 选型的纪律

17.3 给框架选型算过三笔成本，锁入、抽象泄漏和版本节奏，可那三笔只在框架这一件事上。这节要把同一套办法推到更多选型上，模型、协议、SDK、存储和部署，凡是拿第三方的东西拼自家系统的场合，这三种成本一样躲不掉。框架只是依赖的一种形态；只要是第三方提供、自己又控制不了它怎么演进的东西，就欠着同一种成本。这节不给任何一项选型下结论，写书时点到的具体结论都会过期，能给的是三条纪律，而纪律本身不过期。

选型为什么值得立纪律？先摆一组行业级数字。MIT 旗下一个研究项目 2025 年的报告说，生成式 AI 应用里，最终算得上创造了业务价值的不到百分之五。报告的统计口径是一家之言，方法大可争论，但方向值得记下，价值兑现远没有宣传的普遍，每引入一项都过一遍成本和收益，心里得先有这个预期。

纪律一，时效风险，今天的结论有保质期。例证不用往远找，第 17 章盘点过的框架名单就是现成的。Assistants API 从公告废弃到正式关停之间留了一年缓冲，2025 年 8 月 26 日公告，2026 年 8 月 26 日关停；AutoGen 并进了 Microsoft Agent Framework 那条线；Swarm 不再更新。两年时间，名单上的名字一个接一个换了位置。

协议层的情况一个样。MCP 规范一年多里连着出了三版，2026-07-28 那版干脆移除了协议级会话与 initialize 握手，HTTP+SSE 传输也划进了废弃一类，按 2025 年中版本写的接入代码，今天要动的不止一两处。A2A 从 0.x 版本走到 2026 年 3 月的 1.0，旧版教程里的状态机跟新版也对不上了。

变化也不全是坏消息，正面例子就摆着一个，LIDA 这个数据可视化生成系统把底座从 davinci 换成 GPT-3.5-turbo，评测错误率从 20% 跌到 3%，架构一行没动。这件事有两面，模型层的变化会整个穿透系统，朝上走是红利，朝下走是事故。第 12 章说模型一换全线失灵是高频事故，讲的就是朝下那一面。

对策在三个动作上。凡是写进文档和决策记录的现状数字，都要带保质期标注，写明截至何年何月、以哪个官方页为准。做选型决定的那一刻，当场打开官方页核对，别搬三个月前的二手结论。知识要分两堆建档，版本、价格和接口现状这类会过期的放一堆，定期清；机理与判据不过期，映射表、失败模式清单和能力清单都进另一堆。

同样这三个动作，搁在智能体领域，收益比传统软件高一个量级。传统后端，依赖一年升一个次版本，规格几年才动一次；这个领域，规范一年出头就改三版，主流厂商隔几个月发一次新版，凭印象选型，过期速度从几年缩水到几个月。核实，用在数据库选型上可有可无，在这里却天天用得上。本书给现状数字通篇标了核实日期，这套动作本身就是纪律一的示范，接手项目时直接照搬。

纪律二，供应商锁定，用得越深就越欠。框架的锁入成本 17.3 算过，检查点、会话和轨迹这三类，凡是私有序列化格式落了库的表，迁出那天都要补转换器。这里不再重算，只看这笔成本在框架之外的三种形态。头一种是模型层，提示与模型绑在一起，19.4 第三条失败模式讲的就是这个，深度调优过的系统提示，一换厂商表现就变，真正锁住人的不是接口，是那份长了好几页的提示资产。

微调这个词前文出现过好几回，第 14 章还把它当降成本的一条路用过，概念的地基却一直没打过，这里补上，不然这笔成本算不清。微调动的是权重（weights），不是架构，同一副骨架、同一套连线，调的是每条连线上的力气，所以微调后的模型仍跑在原来那类推理设施上。动多少，分全量和 LoRA 两条路。全量微调把所有参数放开更新，代价随模型大小快速增长，通常只有小模型或者大厂负担得起；LoRA 把原权重整个冻住，只训一对低秩小矩阵，参数量只占全模型的零头，单张高端消费级显卡就跑得动，改开源模型基本都走这条路，产物还是一份独立的小文件，这一点先记下，下面谈资产归属时要用。教什么，分监督微调和偏好对齐两路，监督微调（supervised fine-tuning）喂的是输入配输出的样本，教的是这项任务该怎么做；偏好对齐喂的是同一输入的优选、否决两份回答，教的是哪种做法更好。再补两个概念。灾难性遗忘（catastrophic forgetting）说的是，拿窄领域的数据一味高强度训练，新能力长出来的同时，旧能力跟着丢了，在一种规律上训熟的模型转去训另一种规律，原先的直觉就回不来。数据量级上，微调要的是精心挑的样本，量级跟着模型大小走，小模型几千条就动得起来，模型越大，需要的样本越多。

第 3 章讲中文模型时，拿权重开不开放判过私有部署；这里把同一问题的三项摆全，落点仍是权重开不开放。第一项是资产归属。闭源那边有句直白评语，借给你灵活性，但不让你拥有它，微调出的模型只活在供应商环境里，换厂商带不走。开放权重那边正好反过来，微调产物是一份自己的文件，部署与运行时全归自己管。

第二项是数据不出域。监管严的行业要求推理发生在自己的机房，权重不开放，这条路就走不通。第三项是总拥有成本。托管 API 起步便宜，不用养基础设施团队，可流量大了之后，自托管开放模型的总成本通常更低，省下的钱换成了运维的工作。

三项都摆出来，结论反而朴素，多数团队该走混合路线，先拿托管 API 把应用跑起来，等规模或合规的压力逼到眼前，再一步步转自托管。

协议层的成本来自版本锁定，实现照着某一版规范写死，规范一改版，代码就得跟着改，MCP 那次大改版里，依赖会话与握手的实现最先受影响。部署层也有类似的成本，17.1 盘点过 ADK 与 Google Cloud 绑得有多深，云绑定换来的起步便利，迁出时都得如数还回去。

对策总结成一条资产可带走原则。最值钱的资产是任务集与轨迹数据，它们必须独立于任何供应商，迁移时能一并带走；17.3 那支舆情简报团队把“任务集随时能带走”定为硬要求，用意就是这个。隔离层放在接口处，模型接入的地方放一层薄适配层，各家 SDK 在仓库里各占一个目录，业务代码只认自家接口；存储后端照同样的思路，检查点落文件还是落库，都先过自家抽象、再谈具体实现。

评估候选，先搁下品牌不看，拿 17.2 的十能力清单逐项量。两家跑分接近的时候，锁入更深的那家自动减分，这条规则当裁决，比什么偏好都经得起推敲。

单次选型之外，组织层面还能多做一件事，维护一张预先审过的候选模型清单。把常用的模型先挑一遍，除了公开跑分，还要过一遍许可协议的法务审查，审过的进表，表上记清每个模型的许可、上下文窗口、能不能微调、支持哪些模态。新项目选型从这张表起步，表外的模型不是不许用，是先补审再上。表不必长，从轻量到旗舰的常用档位盖住就行。什么任务在哪一端，也有粗判据，时延预算卡得死的、只能跑在端上的、任务面窄得能画清边界的，起点本来就在轻量端，并不是为了压低费用硬换小模型，是任务的约束先把旗舰排除了。团队既有的技能也算一项成本，工程师熟哪个模型家族，上手就快一截。

纪律三，迁移是持续负债，不是做完就清的事。AutoGen 存量用户如今正对着的迁移指南，Assistants API 用户刚走完的一年倒计时，两件事说的是同一桩，选型那天省下的，迁移那天要加倍还。LangGraph 1.0 承诺 2.0 之前不破坏兼容，可这份承诺也只到 2.0 为止。

把这条纪律落进制度有两个动作。一个是每次选型都顺手写一份退出方案（exit plan），把谁做过类似的迁移、迁出预计要重写哪几层、大概占多少工时写明白，正是 17.3 决策清单第三问的内容；另一个是常年立一张负债清单，每引入一项第三方依赖，就把依赖项、接口面、当前版本、迁移状态和上次盘点日期记进表里，季度过一遍，见到废弃公告当天更新。负债不会自己清零，只会增增减减。这表平时没人翻，等规范改版或厂商发布废弃公告的那个下午，能立刻答出“受影响的有几处”的，只有它。

三条纪律带到选型会上，就收敛成三个动作，查时效、算锁入、写退出方案，半小时足够。动作写进会议模板，会后的产出是两份文档，一份决策记录、一份退出方案，都进版本库，跟着代码评审一起维护。17.3 那张决策清单的六个问题，管的还是单次选型怎么操作；这一节的三条纪律罩在它上面，一层管单次决策怎么走，一层管所有决策共用的做法。

决策记录里有一类条目最容易漏，那些否决掉的方案。因为安全原因否决的功能，同样该留一份架构决策记录，把当时的顾虑与理由写全。这个领域的这类决策做得又快又频繁，光靠记忆根本留不住；理由不落到纸上，过两年同一个话题被人再翻出来，评审只能从头再开一遍，甚至没人记得当初是否决过它。

三条纪律并不等于锁入越少越好。隔离层和双份维护本身就是成本，退出概率近乎为零的依赖，比如只在内网工具里用的存储选型，过度抽象只会添乱；面向顾客、明知道要换代的依赖，隔离层的每一行都值。纪律再往下一层，靠的就是判断力，哪一项值得防、防到什么程度，得把退出概率与业务寿命放在一起估。

怎么判断一个决策可不可逆，亚马逊创始人贝索斯给过原则。不可逆的叫单向门，可逆的叫双向门，能选的时候优先挑可逆的，还要尽量快，快速且可逆的失败是一笔学习费。把这条落到选型，三条纪律的重心全压在单向门上，厂商私有接口一旦写进核心链路，错了退不回来，于是查时效、算锁入、写退出方案一条都省不掉；换个日志库是双向门，错了重选就行，当场核一次官方页足够。

隔离层想办的事，是把单向门改造成双向门，业务代码只认得自家接口，真换依赖还能退得回来。抽象也常有包过头的时刻，Gregor Hohpe 给的称呼是 Grim Wrapper（糟糕的包装层），底下那层复杂性它遮不住，底层工具或服务的演进它又跟不上。自家维护的抽象，维护、文档和功能多半永远追不上底层工具；打算用一层统一接口把模型厂商整个裹住，很快就会到处漏，各家厂商的独有特性实在太多。等这层抽象铺开，业务代码全挂在它的接口上，想撤又成一次大迁移，原本防锁入的保险，反而变成一扇新的单向门。

三个动作正好拿理赔初审的模型接入方式试一遍。先查时效，各家厂商的端点与现行模型是什么版本，当场开官方页核对，日期记下；再算锁入，任务集是历史卷宗、不依赖任何厂商，接入处走自家薄适配层，锁入面很小；最后写退出方案，迁出只动适配层一个目录，改动面小、退出成本低。结论落进决策记录，半年后模型换代，这份记录就是新一轮决策的起点。

把技术选型放回更大的工作流里看，行业里已有成型的实施路线图，战略基础、技术建设、智能体与舰队工厂、组织运营和治理认证五条线一起推，路线图从最小可行产品起步，也强调各团队技术基线要一致。放到那个层面看，选型纪律不是会上临场发挥的口才，是技术基线工作流里的常规工序，跟代码评审、评测回流排在一处。

这套工序的底座，是前面十八章逐章立起来的机制，机制往后还会更新，它也跟着一起变。映射把选什么架构变成一行行问句，审查把会不会失败变成逐条排查，纪律把用谁家的东西变成三笔成本加三个动作，哪一件都不是凭空来的；映射表多一行、审查清单多一句，也都在预期之内。唯一不变的就一句话，决策交给工序，不交给手感。

留个练习，把三笔成本套到最近一次技术选型上，回想当时锁入了什么、哪里漏了抽象、版本节奏有没有跟上，三项各写一句复盘，再补一条具体的退出动作。写过这一遍，下次选型会该先问哪三个问题，心里就有数了。

本章小结

• 19.1 从需求到规格。规格七类清单（目标、验收标准、不变量、集成边界、完成定义、前车之鉴和开放问题），篇幅 500 到 1000 词、不许比预期改动长；规格分三档，小活几段话、产品活七类清单、跨周大事按设计文档管并进版本控制；冲刺契约把完成定义提前谈定、冻结；计划切成一段段查得完的小阶段；该不该做的判断，外包不出去。
• 19.2 从需求到架构。白板拼最小组件（收集信息、做决策、总结和生成输出四类）再按模型调用固有代价剪枝；映射表先问架构停在哪一档，再定知识记忆、权限和成本延迟三件事，末行成败可判定，十二行问句行行带出处；问到哪行答不下去，架构就停在哪级。
• 19.3 工作位与词汇。双轴地图纵轴量单智能体自主性、横轴量并行编排数，S1 到 S5 沿对角线排开，对角线外两个角落同样健康；纪律区谱五区与档位配对，区谱量纪律、档位量组织；ReAct 这类工作流形状算不上设计模式，消息路由、失败投递和请求回应关联仍归经典模式那一层。
• 19.4 失败模式审查。威胁建模四问加数据流图与信任边界加 STRIDE 六类；十种失败模式倒过来当上线前自查，设计期四条看纸面、运行期四条看轨迹、组织期两条看制度，十句问题进评审材料，一小时内走完。
• 19.5 选型的纪律。时效风险用保质期标注加当场核实；供应商锁定用资产可带走（任务集与轨迹数据独立于供应商）加接口隔离层；迁移是持续负债，用退出方案加季度负债清单应对；选型会三动作，查时效、算锁入、写退出方案。具体版本会过期，三条纪律不过期。

架构决策从靠手感变成了走工序。这套工序写下来、收进版本库、跟着评审一起执行，新人接手时拿到的就不止一套系统，还有做下一次决策的方法。

参考资料

• MCP 官方规范 2026-07-28 版变更日志（移除协议级会话与 Mcp-Session-Id、移除 initialize 握手、HTTP+SSE 归入废弃、Roots/Sampling/Logging 标记 Deprecated，上一版为 2025-11-25），https://modelcontextprotocol.io/specification/2026-07-28/changelog ，核实于 2026-08。
• OpenAI 官方废弃公告页（Assistants API 2025-08-26 公告废弃、2026-08-26 关停，替代方向 Responses API 与 Conversations API），https://developers.openai.com/api/docs/deprecations ，核实于 2026-08。
• A2A 协议官方公告（1.0.0 于 2026-03-12 发布，此前 0.x 系），https://a2a-protocol.org/latest/announcing-1.0/ ，核实于 2026-08（转引第 17 章已核实条目）。
• Microsoft Agent Framework GA 公告与概述页（AutoGen 并线、2026-04-03 GA），https://learn.microsoft.com/en-us/agent-framework/overview/ ，核实于 2026-08（转引第 17 章已核实条目）。
• Victor Dibia《Designing Multi-Agent Systems》（2025，Manning）第 1 章（决策三问框架、四个任务特征、LIDA 底座升级错误率 20% 到 3% 的记录）、第 9 章（框架价值与维护负担转移，经第 17 章引用）、第 11 章（十种生产失败模式、彩蛋小节、路由约 15% 成本换约 90% 表现、10 个可靠工具胜过 50 个平庸工具、TASK_COMPLETE 反例）。见 txt-ref-zh/designing-multi-agent-systems/。
• LangChain 官方博客（LangChain 与 LangGraph 到达 1.0，承诺 2.0 之前不破坏兼容），https://www.langchain.com/blog/langchain-langgraph-1dot0 ，核实于 2026-09-02；LangGraph 版本口径（1.2.11）转引第 17 章已核实条目。
• OpenAI Swarm 仓库 README（Swarm 停更、实验与教学定位，转引第 17 章已核实条目），https://github.com/openai/swarm ，核实于 2026-08。
• Eric Broda、Davis Broda《Agentic Mesh》（O'Reilly）第 15 章（实施路线图的工作流结构、最小可行产品起点、技术基线一致性）。见 txt-ref-zh/agentic-mesh/。
• 《AI Agents: The Definitive Guide》第 4 章（开放权重对闭源 API 的取舍账：微调资产归属、数据出域、总拥有成本拐点，混合策略结论；LoRA 不触碰原权重、低秩矩阵小幅修正与灾难性遗忘现象亦出自该章；定性转述，价格数字不引）。见 txt-ref-zh/ai-agents-definitive-guide/。
• 《GenAI Security》（Paul Zenker，CRC Press 2026）第 5 章（威胁建模四问、数据流图与信任边界、STRIDE 六类与逐元素过法、网页聊天机器人加产品库的完整走例：SQL 注入经工具输入、商品描述里的提示注入、对策回环与对策测试自动化、"威胁建模不是白板练习"、漏洞录入缺陷跟踪、架构决策记录模板与出于安全否决功能的留痕示例）、第 11 章（架构决策快而频繁、决策记录的必要性）。见 txt-ref-zh/genai-security/（转引第 13 章已核实条目）。
• 《Breaking the Model Context Protocol》（Satheesh kumar & Sekar，Apress 2026）第 3 章（红队思维第二轮：工具按最大效应定义边界，不写读一个文件，写能读该进程有权访问的任何文件）。见 txt-ref-zh/breaking-the-mcp/。
• Ben O'Mahony、Fabian Nonnenmacher《Building AI Agent Platforms》（O'Reilly Early Release，2027 年抢先版，实体含第 1-2 章）第 2 章（贝索斯双向门原则：单向门不可逆、双向门可逆且要快做；Gregor Hohpe 的 Grim Wrapper 糟糕包装层：遮不住底层复杂性、跟不上底层演进；统一接口抽象模型厂商易成漏的抽象）。见 txt-ref-zh/building-agent-platforms/。
• 《Agentic Engineering》（Addy Osmani，O'Reilly Early Release，2026-08-28 首发，实体 5 章）第 1 章（纪律谱系五区、区位随爆炸半径浮动、"坐在第三区自以为第四区"的自欺）、第 2 章（把单级自主阶梯拆成单智能体自主性 × 并行编排数两根轴、五个工作位、误读清单、区谱量纪律对档位量组织的配对、Anthropic 会话研究的引用）、第 5 章（五份并行规格实验——分叉的是模糊不是执行力；规格七类内容与约 800 词篇幅纪律；单发、特性、倡议三种规格形态与倡议规格的版本控制、具名主人、刷新节奏；冲刺契约的签署冻结、智能体先挑规格歧义、轻活不立契约；计划读得漂亮不等于验证过、研究子智能体吃窗口、切成可验证小阶段；可被套利的验收标准；规格载得动意图载不动品味）。见 txt/agentic-engineering.txt（英文原文，第 1、2、5 章，行 244-279、661-747、789-807、961-998、2076-2092、2169-2385、2452-2600、2631-2679）。
• 《Designing AI Agents》（Jia Huang，Manning MEAP）第 2 章（认知功能 × 执行拓扑的双轴地图与同名拓扑歧义论证；血统申明"据我们所知截至 2026 年初是首个系统性尝试"，认知轴源自 ACT-R 与 BDI 一脉，与 Osmani 互不引用）。见 txt/designing-ai-agents.txt（英文原文，第 2 章，行 1454-2166、2112-2126）。
• Anthropic 研究（约 40 万个 Claude Code 会话、约 23.5 万用户，典型会话人做约 70% 规划决策、模型做约 80% 执行决策；Anthropic 对自家产品的分析，口径自报），https://www.anthropic.com/research/claude-code-expertise ，核实于 2026-09。
• 《Building Complex Multi-Agent Systems Using Pattern Prompting》（Tim O'Brien，Packt 2026）第 7 章（四类操作组件的白板拆解、按 LLM 调用固有代价剪枝、自定义微架构优于照抄现成模式）、第 8 章（ReAct 与 Plan-and-Execute 等是工作流形状而非 GoF/EIP 意义上的设计模式、智能体应用是经典模式聚成的微架构；"系统败在集成层而非模型"为作者断言，观点引）、前言（模式词表使幻觉更少更好认的断言，编码智能体在模式语料上学得更稳，观点引）。见 txt/pattern-prompting-mas.txt（英文原文，前言、第 7、8 章，行 655-668、4087-4116、4733-4749、4896-4907）。
• MIT NANDA 项目《The State of AI in Business 2025》报告（2025 年 8 月发布，被认定创造了业务价值的生成式 AI 应用不足 5%，机构报告自报口径；经 pattern-prompting-mas 第 4 章转引）。见 txt/pattern-prompting-mas.txt（英文原文，第 4 章，行 2620-2642）。
• Vasyl Zvarydchuk《Building Agent-Powered Applications》（Packt 2026）第 7 章（微调概念地基：微调调权重不改架构、全量对 LoRA、监督微调对偏好数据、灾难性遗忘与数据量级），见 txt/building-agent-powered-apps.txt（英文原文）。
• Jennifer Badham、Corinna Elsenbroich《Becoming an Agent-Based Modeller》（Routledge 2026）第 2 章（抽象删无关特征、理想化抹平无数据特征，取舍由建模目的驱动、不由数据可得性驱动），见 txt/agent-based-modeller.txt（英文原文）。
• Heiko Hotz、Sokratis Kartakis《Multimodal, Real-Time AI Agent Systems》（O'Reilly 抢先版 2026）第 5 章（预审候选模型清单：许可法务审查先行、覆盖轻量到旗舰的档位、团队既有技能计入选型），见 txt-ref-zh/multimodal-realtime-agents/。
• 《GenAI on Google Cloud》（Ayo Adedeji 等，O'Reilly 2026）第 1 章（小模型选型判据：时延敏感、端侧部署、窄任务是起点在轻量端的常见理由），见 txt/genai-google-cloud.txt（英文原文）。
• 《Claude Code: Up and Running》（Ken Kousen，O'Reilly 抢先版 2026）第 1 章（维护占软件总成本大头、智能体让产出翻倍则维护开销同步翻倍，判断标准是有用变更的成本降没降），见 txt-ref-zh/claude-code-up-running/。