第 18 章 智能体的组织与实施

本章把讨论范围从一个团队放大到整个组织，甚至组织与组织之间，回答四个问题，三百个智能体彼此怎么找到对方、市场上冒出来的陌生智能体凭什么信它放它进场、它闯祸之后责任记到谁头上、公司想把智能体交到客户手里靠哪种团队哪种人。18.1 讲智能体为什么不能当成一种更聪明的代码来管理，这是后面所有组织手段存在的理由；18.2 看智能体多起来之后，发现、复用和批量管理这三个真实问题目前有哪些经得起核实的解法；18.3 看智能体之间、组织之间怎么建立信任，落到身份、授权与问责；18.4 把视角拉回到人和团队，看已有实践验证的组织手法怎么搬过来用，也看一个正在真实发生的新职业现象，结尾拿一份扎实的行业证据，把对智能体生产力的预期校准一次。这一章的口径先说清楚，协议与标准这块眼下已有硬事实可讲，A2A、MCP 这些协议都有版本号、有治理机构、有可查的采纳数字，正文随文标注来源；组织怎么管、信任怎么立、人怎么配，行业里一部分是可以核实的真实实践，另一部分只是个别厂商、个别作者的构想，本章只展开能找到多个独立信源互相印证的内容，只在单一来源里出现、没有旁证的成套构想，这一版不采用，免得把某个人的一套设想误当成行业已经这么做了。

18.1 智能体与传统代码的根本差异

一个智能体造好之后，跟一段写好的传统代码到底是不是同一类东西，这个问题的答案直接决定后面几节讲的所有组织手段是不是必要。前面十七章讲的全是怎么造好一个智能体，这一节退一步问的就是这个更基本的问题，它听起来像哲学题，落点却全是工程。

传统代码有一条默认假设，写完、测完、上线，它的行为就此冻结。同一个输入，今天跑和明年跑，只要代码没改，结果就该一样。这条假设撑起了整套软件工程的常规做法，代码审查审一次就管一辈子，单元测试通过一次就代表这条路径永远正确，一个函数的作者就是它永久的负责人，出了问题回去看那次提交记录就够了。

智能体从第一天起就不满足这条假设。第 1 章讲过，同一份输入喂给模型，两次调用可能给出不同的答案，这是模型本身的工作方式决定的，不算 bug。更麻烦的是，智能体的行为不只取决于自己那份提示词，还取决于背后那个模型，而这个模型是一个调用方完全不掌控的外部依赖。厂商悄悄换一版模型、调一次安全策略，自己的提示词一个字没动，智能体的行为却可能已经变了。传统代码里，依赖升级至少会留下一个版本号可查；模型这个依赖，很多时候连版本号都不透明。第 12 章讲评测、第 14 章讲运维时反复出现的一句话，模型一换，全线失灵，说的就是这种依赖。

这条差异往下推，能推出一串连锁反应，而这些反应恰好解释了本书第五部分为什么要单独用四章去讲评测、安全、运维和人机协同。

第一层反应是，正确性变成了需要持续监测的状态。传统软件测试问的是这份代码对不对，答案非对即错；智能体系统问的是这份代码这一周表现得怎么样，答案是一个会随时间移动的分数。这正是第 12 章整章要建立评测体系、而不是简单写几个断言的原因。

第二层反应是，行为的边界不能只写在代码里，还得有一层代码之外的约束。传统代码不会做超出它逻辑范围的事，没写的分支就是执行不到；智能体不一样，只要工具挂在那儿，模型在某次推理里想到一种没人预料到的组合用法，就真的会去调用，13.2 讲执行器为什么要绑最小权限、要做沙箱隔离，讲的正是这层额外的约束不能省。

第三层反应是，谁对一个行为负责，变得比传统代码复杂。一段函数的作者是唯一的责任人，这条对智能体不成立。一次糟糕的输出，可能是提示词的问题，可能是工具返回了错误数据，可能是模型那一轮恰好推理跑偏，也可能是几个月前一次系统提示的改动埋下的隐患，中间还可能隔着一次模型升级。第 13 章讲的问责、第 18.3 节要讲的身份与审计，都是在给这条越来越模糊的责任链找回一个可以指认的落点。

第四层反应最容易被忽略，智能体系统的部署是持续的运营过程。传统软件交付讲究里程碑，上线即交付完成；智能体系统上线那一刻，恰恰是需要开始持续关注的起点，因为它的行为会随着模型版本、用户问法和业务数据一起漂移。第 14 章的运维体系、第 15 章的渐进自主，都是把这条道理落到工程实践里的具体做法。

把这四层反应放在一起看，就能明白为什么前面十七章要花那么多篇幅讲评测、护栏、可观测和审批，行为不冻结这个基本事实逼出了这批必要配套，其中没有一项是“锦上添花”的可选项。一段传统代码写完可以束之高阁，一个智能体系统写完，恰恰进入最需要人盯的阶段。

这条根本差异，也正是本章后面几节要讲的组织问题的源头。发现、信任和问责这些问题，回答的其实是同一件事，一个行为会持续变化、责任链条会变模糊的系统，组织该怎么去管住它。传统软件工程那套“写完、测完、交付、归档”的组织经验，处理不了这个问题，这才是需要专门讨论组织与实施的原因，不是因为智能体这个词听起来新潮，需要配一套新潮的管理方法。

18.2 发现、复用与批量管理

智能体从三个涨到三百个，会冒出发现、复用和批量管理三类从前不存在的麻烦。设想一家中等规模的电商公司，一年前它上线了三个智能体，分别是客服问答、评论摘要与每周销售日报，都是一个小小的后端组顺带维护的；半年后各业务线跟着上，数量涨到三十个；再过一年，到了三百个。

数字涨到多少并不关键，关键是这三类麻烦都真实出现了。先是发现，新来的工程师花了三周，都没搞清哪些智能体调得动、入口在哪儿、该找谁申请。接着是复用，五个团队各写各的文档摘要智能体，谁也不知道别人也在做，同一件事做了五遍。最后是批量管理，一次提示注入事件之后，安全团队想弄清楚哪些智能体手里有支付系统的凭据，问遍全公司也拼不出一份清单。

只有三个智能体时，点对点手工对接一点问题都没有，谁要用谁，写一段适配代码就完事。到了三百个还沿用老办法，连接数按平方往上涨，协调的成本会先把团队拖垮。这是个通用的规模化问题，参与方一多，通信、依赖和协调的开销一起猛涨，互联网和云计算当年也是这么走过来的，登记、发现和治理这些结构化设施一层层搭上去。智能体会不会走出同一条路，眼下还看不到定论，能确定的只是问题本身是真的，三百个智能体一旦真的堆出来，发现、复用和批量管理这三件事迟早要有人管。

发现这一层已经从设想走进了标准化流程，有具体的协议、机构和文件可查。

机制层面，第 11 章 11.1 已经讲过一套真实存在的做法。A2A 协议里的智能体名片（Agent Card）是智能体元数据的协议化表达，1.0 版给名片加上了 JWS 签名，防止传输途中有人篡改能力声明。一个智能体值不值得信，第一步靠这份签过名的自我描述。

协议底座本身，截至 2026-08 有硬事实支撑。A2A 最初是 Google 在 2025 年 4 月发起的，随后治理权交给 Linux Foundation，技术指导委员会的八个席位坐着 AWS、Cisco、Google、IBM Research、Microsoft、Salesforce、SAP 和 ServiceNow。2026 年 3 月，1.0 的第一个稳定版发布。等发起满一周年，表态支持的组织超过 150 家，核心仓库在 GitHub 上的 star 数超过 2.2 万，Google Cloud、Azure 和 AWS 三大云平台都打开了集成入口，这组数字第 11 章已经数过一遍。Linux 基金会旗下还有 AGNTCY，做智能体发现、身份、消息和可观测的开放协议栈（截至 2026 年 9 月）。

MCP 这边，规范最新一版停在 2026-07-28。OpenAI 在 2025 年 3 月采纳了它，Google DeepMind 在 2025 年 4 月跟上，官方注册表上线几个月，收录的服务器已接近两千个，SDK 月下载量逼近亿次。这几个数属于二手汇总，只能当转述看，别当成官方数字。协议不再停在纸面上，这一点是事实。

发现这一层还在往更底层的网络基础设施上走。截至 2026 年 9 月，IETF 里有了智能体发现协议（Agent Discovery Protocol）的草案，属于个人提交的工作草案，还没被工作组正式采纳。.agent 顶级域赶上了 ICANN 2026 轮的申请窗口，多份申请正在竞争，具体归属要等官方后续公布。Verisign 也提议了两种用于智能体发现的新 DNS 资源记录类型。这三件事合起来说明一件事，发现层的标准化工作是真实在推进的，但还没有一件定稿、大规模用起来。判断这层设施最终会长成什么样，现在下结论为时尚早。

复用这一层，问题是清楚的，同一个能力好几支团队各写各的，是三百个智能体规模下几乎必然会碰上的浪费。解法也不复杂，某种形式的内部索引，能查到谁已经做过类似的事，让后来者复用而不是重做。这跟软件包管理、内部工具共享是同一个思路，直接借用组织里已经在用的内部知识库、内部文档系统，加一层智能体专属的元数据（谁维护、调什么模型、接了哪些数据），大概率就够用。

复用这层最大的浪费，还不是同一件事做了五遍，而是验证过的做法没有沉淀。快递客服的智能体修过一类投诉的处理办法，先查物流轨迹的最后一个节点，再判断是丢件还是地址错了，这个做法过了评测、上了线；可它只留在当次的修复记录里，下个月另一个团队做退货助手，同一个失败从头再来一遍，评测和修复的工夫全部重花一遍。连锁品牌的周报也一样，取数口径和成稿检查单是人工核对过一轮才定下来的，经手的人一换，这些做法就丢了。

堵住这个浪费的办法，是把验证过的做法做成技能包。一个技能包，就是一份写清某类任务怎么做的说明，配上它要用的模板、脚本或参考资料，外面挂一张清单，写明名称、版本、适用条件、依赖的工具和验收标准。清单里最要紧的是适用条件和验收标准这两栏，适用条件写清什么任务用它、什么任务别用它，验收标准写清用了它的智能体交出来的成果该长什么样，这两栏填好，别的团队查到它，就知道能不能放心拿去用。加载有现成的机制，技能平时只有一行描述留在窗口里，正文等真用到才载入，第 4 章 4.6 的渐进披露是这个做法的思想源头，产品里怎么实现，第 21 章 21.5 解剖时看得到。库里技能攒得再多，常驻窗口的也只有那行描述，正文一个字不占。

技能包要当软件资产来管理，纪律跟第 1 章给系统提示词定的是同一条，进版本库，改动留记录，上线前先过任务集。落到技能包上是三件事。内容一改就出新版本，旧版本原样保留不覆盖，因为别的团队可能还挂着旧版在跑。新版本启用前先过一轮评测，拿第 12 章的任务集跑，用这个包的团队，把自己场景的题也补进去，成绩不比旧版差才替换上去；这一步就是第 15 章的变更验证搬到技能包上，离线评测先过，再逐步替换在用的版本。替换之后出了问题就回滚，退回上一个版本。清单上还得写维护者，技能包跟智能体一样是持续运营的东西，没人管的技能包，适用条件早就过时了还有团队加载它，反而误事。

技能包的原料，可以从历史轨迹里批量挖。第 8 章 8.3 讲过逐案积累的三元组，记当时的查询、执行的行动计划、最终的结果；团队级的做法是把积累这件事批量做，圈定一类任务和一段时间，把成功与失败的轨迹一起收进来，从里面挖出遇到什么情况、当时怎么处理、结果好不好。挖出来的每一条都要能回溯到源轨迹，维护者点开记录，核对当时确实这么做过、结果确实成立；像仔细分析、正确处理这类放在哪里都对、在哪里都没用的空话，直接筛掉。经验入了库，智能体运行时接到相似任务先查一遍，查到对症的条目就照着办。

查经验这个动作自己带参数，相关性阈值卡多严、一次查回几条、什么时机查，三样都不能凭主观定。经验查回来要占上下文、耗 token，简单任务多查一次可能净亏，复杂任务一条对症的经验能省掉好几轮试错，是否划算，全看自己的任务长什么样。定参数不用另想办法，第 12 章的对照实验原样搬过来：留一组不查经验库的任务当基线，同模型同任务集跑候选参数。阈值收紧，看无关内容少了没有；放宽，看有没有漏掉本该帮上忙的条目。条数从一条试到几条，看多查进来的经验是补了有效条件，还是白占篇幅。时机上比较任务开始前查和失败之后查。检索和阅读的 token 一并计入开销。拿快递客服举例，一轮实验跑完，结果可能是复杂投诉的通过率上去了，简单查件的耗时反而多了，那就把查经验放到失败之后再触发，简单任务一次都不多查。

做法的沉淀，这本书里前后有三级。第 1 章的版本纪律管一份提示词，第 8 章的三元组管一个系统自己的经验积累，这一节补的是团队这一级，做法从个人的会话里搬出来，进共享的库，别的团队查得到也用得上，出了问题退回旧版就行。实施不必另起炉灶，版本库里开一个目录，一张清单跟着每个技能包走，再登记进前面说的内部索引，谁维护、上次评测什么时候跑的、分数多少，这些元数据填齐，复用才谈得上是资产，不是一堆没人敢用的资料。

复用一旦跨出公司边界，钱怎么算是个绕不开的问题。这里有个真实存在、可以核实的产品案例。微软的 Azure 市场提供一套自定义计量计费（custom metered billing）机制，卖家自己定计费维度，每个维度就是一个价值单位，比如对话次数、索引的数据量和推理烧掉的 token。应用后端在用量发生的那一刻调计量接口，上报客户是谁、属于哪个维度、数量多少，平台把用量汇总之后并入客户费用。这套机制是 Azure 市场本来就有的通用能力，智能体产品恰好用得上。

发现还有个反方向，让智能体找得到自家的服务。网站根目录放一份给模型读的结构化说明，llms.txt 就是一个真实存在、有开放规范和已经被不少网站采用的约定，作用跟站点地图对搜索引擎的作用一样。对要往智能体渠道卖东西的团队来说，这是一个可以核实、可以直接去用的新入口。

最后是批量管理这一层。三百个智能体要一个一个盯着升级、盯着资源占用，人力肯定不够，这个判断没什么好争的。把一组服务同一使命的智能体当成一个单元来启动、扩缩、升级，这个思路本身是常识性的运维手段，容器编排、微服务治理里早就有对应的做法。至于智能体之间具体该用发布订阅还是别的通信方式、该选哪个消息中间件、要不要给它们设计一套共享的对话记忆层，这些属于架构设计的选型问题，目前没有哪一种做法算得上通行最优解，不同团队的具体选择会因为任务形态、组织规模差别很大，本书不替这类选型下判断。

智能体之间要不要设一个总管的角色，还是完全对等地互相协商，这道题在多智能体系统文献里其实是老问题，第 10 章那条控制权的线已经完整讲过，从监督者式的层级到蜂群式的完全对等，控制与灵活之间的取舍是通用规律，不因为规模到了三百个就变出新答案，用第 10 章那套判断照样够用。

组织设施还没有定型，可另一层“生态”已经在真实发展，这一层跟前面讲的智能体互联不是一回事。社区这两年围绕怎么让智能体完成开发工作，在工作流层沉淀出一大批工具与实践，合起来的做法叫规格驱动开发（specification-driven development）。做法本身很简单，先把规格写明白，再让智能体照规格写代码。

这片生态里的各个工具与团队做法并不相同。有的只用六行模板，逼着人把没想清的假设一条条交代出来；有的把计划、进度和发现全部写进文件，上下文一断就靠重读文件续上；有的一份规格能在十几个编码工具之间通用；有的把测试先行定成硬纪律，不写测试的代码直接删；还有团队把出过的问题写成一份份文档，新问题来了先查这些记录。做法虽然杂，共同点只有一条，都把规格当作源头工件，规格一旦立住，代码就成了它的下游。这层生态是真实观察到的社区现象，不是某本书提出的构想，值得区别对待。至于规格本身怎么写才算可靠，留到第 19 章展开。

发现、复用和批量管理，三个问题各自有已经核实的部分，也各自有还没定论的部分。

18.3 身份、授权与问责

智能体之间、组织之间的信任，这一节拆成身份、授权、行为记录、认证审批、策略和责任分配几件分别能核实、能建设的事，只讲有具体标准或者已经在真实产品里用上的机制，避免整套自造的分层体系。市场里冒出一个从没打过交道的智能体，开口就说自己能处理客户数据，还自带一份合规声明，可调用方对它一无所知。传统软件碰上这种情况，靠的是代码审查加测试，审过一次，行为就锁死在代码里。18.1 已经讲过，这套前提对智能体不成立，模型换个版本、提示词改一句，行为就漂移，上次审查的结论跟着作废。所以这里的信任不能是信或不信的布尔值，得拆开逐件核实。

先看身份这一层，这一层技术上是成熟的，用的都是标准协议，不是智能体专属的新发明。

给每个智能体发一个可验证的密码学身份，通信双方用 mTLS（双向传输层安全认证）先互相确认身份，这是网络安全里成熟多年的标准做法，接进企业已有的目录系统、配上凭据轮换与吊销机制，跟给一台新服务器、一个新微服务做身份管理是同一套流程，只是对象换成了智能体。

智能体替人行动时，通常走 OAuth2 委派，把授权范围一并限定，第 16 章 16.2 讲的后端代签短时效令牌，正是这类委派的实例，权限跟着用户走，智能体自己名下不累积权限。智能体作为一台服务去调别的服务时，则需要自己的机器身份，这里有一条标准路径叫 OAuth 2.0 客户端凭据流（client credentials flow）。智能体在授权服务器上以服务账号登记，要访问受保护资源时出示登记凭据，换一枚通常是 JWT 的短期访问令牌，放进请求头去调对方。验签不必每家自己做，API 网关把它集中起来，拦下每个进来的请求，验真伪、核权限，把身份递给下游。它与 mTLS 不冲突，一个在应用层发令牌，一个在传输层做双向认证，企业里常叠着用。这一整套都是标准协议里现成的做法。

授权这一层，第 13.2 节讲最小权限时已经完整展开过，实时裁决交给 Open Policy Agent 这类策略引擎、越权动作当场拒绝，原则不因为换到跨组织场景而改变，这里不重复。要单独提一句的是引擎选型，第 13 章的例子是单系统内的授权检查，跨组织场景多一层要求，裁决引擎最好独立于任何一方，双方都能核对它的判定逻辑，不能是调用方自己悄悄改过的一套规则。

身份与授权之外，还有一层是行为记录与可审计。每个动作都带时间戳、身份与任务标识，落进防篡改的日志；跨智能体的链路靠统一标识串成一条。这一层直接接上第 11 章讲过的任务标识与上下文标识，也接上第 14 章的可观测性实践。规模放大以后，日志属于运行契约的一部分，不接日志的智能体不该进生产。这些做法在第 13、14 章已经用具体代码讲过，这里不重复，只强调一点，跨组织协作时，这份记录必须是防篡改、可核验的，不能只是一份自己说了算的内部日志。

至于认证与合规这一层该怎么设计，现实里已经有真实运转的产品案例可以参照，而不需要凭空设计一套新框架。微软生态里，智能体从 Foundry 这条路径部署进 Microsoft 365 与 Teams，得经过 Microsoft 管理中心审批，IT 管理员在这一个入口里管审批，治理、合规的情况都看得见。这套审批设计有一条值得学习的切分线，审批看的是名称、图标、描述和连接器这类上架元数据，内容更新不用重新提交，随改随发；只有图标、描述这类东西变了，审过的元数据失效，才需要再走一遍审批。这条切分线背后的道理是通用的，哪些变更改变了行为、必须重新评估，哪些变更只是外观调整、可以免审，这条界线划清楚，审批负担才不会失控，值得任何团队设计自己的认证流程时参照，不需要照抄某个理论框架。

策略这一层，第 13.3 节已经用代码完整演示过双轨机制，提示词轨引导模型、运行时轨做确定性校验，书面政策必须翻成机器可执行的规则，机制本身不重复。跨组织场景多出的是一个新问题，这份策略谁来维护、版本怎么对齐。策略规定客服智能体不能说出成本价，这条规则如果是甲方定的、乙方的智能体去执行，双方对这条规则的理解和版本必须一致，规则改了一方不知道，防线就有了缺口。这一点在单系统内部不成问题，跨组织时却是新增的运维负担。

平台把这些约束统一管起来之后，容易滑向两种常见的失衡，这两种失衡不是智能体领域独有的现象，在任何内部平台建设里都反复出现过。一种是平台管得太松，入口绕、文档跟不上，团队绕开平台自行解决，平台名存实亡。另一种是管得太死，铺了一条默认路径，路径之外一步不许偏，团队想用平台没预料到的方式解决问题，发现根本没有门路。第一种失衡的解法是把平台做到好用，第二种失衡有个现成的应对思路，来自 htmx 的作者 Carson Gross 提出的分层 API 设计，允许用户往下探到更低一层的抽象。日常场景从高层起步，几行配置就能转起来；专家想要平台没预设的灵活性，就往下走一层，动用更锐利的工具。这个设计思路出自他在设计 Web 框架时提出的一般原则，放到智能体平台上同样适用。

技术上给了偏离的自由，责任怎么分配是另一回事。团队偏离平台推荐的选型、自行集成平台之外的工具，这部分责任就该自己担起来；平台团队负责平台自身的合规，并把平台覆盖了哪些要求讲清楚，应用层面的合规交给独立的审计去验，这个分工思路跟公有云厂商与客户之间的责任共担（shared responsibility）划分是同一套逻辑，AWS、Azure、Google Cloud 都用这套语言描述过自己和客户的安全边界。

责任最终要落到具体的人身上，这一点第 13 章 13.4 已经讲过，多手问题的解决办法只有一条，责任要在上线之前落到一个具名的人和部门头上。这个结论不因为规模变成三百个智能体而改变，只是执行起来的复杂度会跟着放大。

治理还有一半在采买上。评估一个 MCP 平台、一台第三方服务器和一套企业智能体框架的时候，把问题问对，比翻宣传页有用得多。下面这份清单是一套通用的安全尽调问题，按该问的对象分成三组，问服务器所有者的、问宿主平台团队和问自家安全与基础设施团队的，逻辑上跟评估任何第三方软件供应商没有本质区别，只是加入了智能体特有的几个关注点。

供应商质询清单
问 server 所有者：
1. 你们怎么对 client 做认证，用户怎么认证你们？发布是否版本化、可复现，防的是发布后悄悄换代码。
2. 一个租户的智能体凭什么看不到另一个租户的数据？工具输出里会不会混进多个租户的数据？
3. 底层 API key 真正需要的最小权限集是什么？能不能按工具配作用域，比如只读、按环境限制？
4. 每次工具调用记了哪些日志，保留多久？疑似事件之后，多久能拿到一份审计导出？
问 host 平台团队：
5. 哪些工具默认开放给哪些智能体？能不能定义严格的配置档案，比如只读分析师、有写权限的运维？
6. 新接入的 server 做不做静态 schema 审计，把隐藏指令揪出来？发出工具调用前，剔不剔除未声明的参数？
7. 哪些工具硬性要求人工审批？审批提示呈现的上下文够不够做判断：谁发起、动了哪些数据、最终发往哪里？
问安全与基础设施团队：
8. 这些 server 实际跑在哪里？有哪些操作系统层与网络层的管控，能约束一台被攻陷的 server 的触达范围？
9. 从登记库批准接入一台新 server 走什么流程？既有 server 更新代码、新增高权限工具时又是什么流程？
10. 哪些具体异常会触发智能体滥用告警？单步看着都正常、连起来却在造成危害的调用链，有没有为它单独设的告警，还是只盯着原始错误率？

这份清单里能落到具体技术上的部分，身份、授权、日志、认证的切分线、策略双轨和责任共担，都是有真实标准或者真实产品案例支撑的，不依赖单一构想。至于智能体之间要不要设一套专门给它们互相核查的监督机制，行业里确实有人提过这类设想，但目前没有看到真做出来的案例，也没有第二方信源可以印证，这一版暂不展开，留给读者自己判断这条路值不值得投入。

18.4 组织实施、一个新职业与证据校准

技术组件讲完，最后剩下的难题是组织。谁负责登记一个新智能体，谁批准它接触敏感数据，谁在出事之后担责，这些都得有人负责、有流程接手。这一节不去发明一套新的岗位体系，而是看已经在软件工程与平台工程领域验证过的组织手法，哪些能直接搬过来用；再看一个眼下正在真实发生、有扎实数据支撑的新职业现象；结尾拿一份扎实的证据，把智能体到底能带来多大杠杆这件事重新校准一次。

先说一个大方向上没有争议的判断，谁拥有一个智能体、出了问题谁负责，这两件事必须写成明文，不能含糊。哪些动作智能体可以独立做、哪些要事先审批、哪些要事后抽查，这套决策权的划分方式，本质上和给任何一个自动化系统、任何一套线上服务定运维规范是同一件事，第 15 章的渐进自主已经把这套逻辑讲得很具体了，自主度不是靠信任感觉出来的，是靠评测数字撑出来的，错误率超过某个阈值就该收权，这一条原则不会因为智能体数量变多而改变，只是需要有人专职去看这些数字、去做这个决定。

至于要不要为此新设一批专属岗位，比如专门的智能体可靠性工程师、专门的智能体治理负责人，现在下判断还早。能确定的是，这些职责总得有人担着，具体是新设岗位还是并进现有的 SRE、平台工程和安全合规团队的职责范围，取决于每个组织自己的规模和现状，本书不替读者预设一套具体的头衔清单。

组织能力建设上，有几套方法论已经反复验证过，值得直接搬过来用。

一套是 Team Topologies 提出的团队拓扑思路，这是 Matthew Skelton 与 Manuel Pais 在同名著作里系统化的一套团队组织方法，DevOps 与平台工程社区引用得很广。核心区分是，业务团队应该是贴着业务价值流走的自治团队，平台团队负责把身份、数据和可观测这些共享基础设施提供到位，让业务团队专注在自己的领域问题上；还有一类赋能团队（enabling team），不直接建设平台，专门帮别的团队用好平台，做培训、做结对编程，这个角色定位对智能体平台同样适用，因为智能体平台面临的问题（新工具怎么用、新范式怎么上手）和任何一个新技术平台推广期面临的问题是一样的。

文档这件事常被平台建设者低估，这里有个真实存在、不少开源项目已经在用的框架，叫 Diátaxis，由 Daniele Procida 提出，把文档拆成教程、操作指南、参考和解释四类，各自服务不同的读者需求，不要混在一起写。Django 项目的官方文档就是一个采用了这套框架的公开例子。

平台建设的起步方式，也有现成的、经过验证的方法论可以借用。行走骨架（walking skeleton）这个概念出自 Alistair Cockburn，指一份最小化的端到端实现，从开发到部署到监控全部打通，团队拿最少配置就能跑起来，再往里面逐步添加真实功能。黄金路径（golden path）是平台工程社区里常见的说法，指平台团队为常见场景铺好的一条默认路线，Spotify 等公司的工程博客都讨论过这个概念，核心分寸在于，这条路径应该是鼓励走的默认选项，而不是强制走的唯一选项，一旦变成后者，就滑向了此前讲过的那种“没有门路”的失衡。这两个概念都是成熟的软件工程实践，直接拿来用就行。

模型这一头，也需要某种形式的登记记录，知道组织里到底在用哪些模型、谁负责、有没有做过安全评估。记录格式上，模型卡（model card）是一个真实存在、已经被业界采用的标准，最早由 Margaret Mitchell 等人 2019 年提出，用来记录一个模型的适用范围、局限与数据来历，医疗、金融等监管较严的行业已经在用这套格式做模型登记。智能体、模型和工具，理论上应该各有一份能查的记录，这样出了事才有据可查，具体怎么建、谁来维护，还是要看组织自己的规模。

上面这几套方法论解决的是组织内部怎么管，还有一层问题这几年出现得很快，公司怎么把智能体真正交到客户手里，让它在客户自己的系统、自己的数据和自己的工作流里跑起来。这层问题正在催生一个具体的新职业。它不是哪本书的构想，是有多家独立媒体和数据机构在同期报道、能互相印证的真实现象。

这个职业叫前置部署工程师（Forward Deployed Engineer，简称 FDE）。Palantir 十几年前就开始用这套模式，做法是把工程师直接派进客户的组织里，贴着客户的真实数据和真实工作流写代码、搭系统，而不是坐在自己公司里做出一个通用产品再卖给所有人。外界过去常把这套模式当成披着技术外衣的重咨询，一度看轻它。

2026 年上半年，这个岗位突然成了整个 AI 行业最紧俏的招聘方向之一。一家猎头公司在 2026 年上半年做了一项调研，访谈了一百八十多家公司的两百五十多位高管、外加三百多位从业者，发现年初还只有 5% 到 10% 的公司计划招募 FDE，大多只是小范围试点；到第二季度末，这个比例跳到了 70%，一些大型咨询与服务公司报告说，自己的 FDE 编制需要扩大十倍，要建起二三十到上百人的整支团队。同一份调研估计，美国市场上现有的 FDE 总数大约一万七千人，其中相当一部分已经在 Palantir 供职。

这个岗位为什么会在这个时间点突然火起来，跟智能体系统的部署方式直接相关。风险投资机构 a16z 在分析这类企业级智能体应用时提到一个具体的例子，做客服智能体的公司 Decagon，配了一支规模不小的“智能体产品经理”团队，这些人相对懂技术，工作是跟客户一起把智能体立起来、跑通、能应付客户复杂多样的真实客服请求。a16z 的判断是，智能体要在客户那边发挥作用，需要持续的管理、持续的引导，以及能读写客户内部系统的深度上下文。这件事换成人来做，通常是一位管理者的角色；换成智能体产品，往往由一位专业服务人员承担。这类人有时候就直接叫前置部署工程师，有时候叫实施专员或者方案专家，名字不完全统一，做的事是同一类。

这个现象背后的道理，正好接上 18.1 讲的那条根本差异。传统 SaaS 软件大体上是一套代码服务所有客户，配置差异有限；智能体系统要好用，往往得深度贴合每家客户自己的数据结构、业务规则和工作流细节，这种定制深度是传统软件不常需要的。公司想把智能体卖出去、用起来，光靠一套通用产品往往不够，需要有人到客户现场，把智能体和客户的具体环境对接起来，这正是前置部署工程师存在的理由。

这个新职业对读者的启发，不在于要不要去应聘这个岗位，而在于它印证了本章一直在讲的道理。智能体系统的实施难点，往往不在造出那个模型或者那套编排逻辑，而在于让它在一个具体组织的具体环境里跑起来、被信任、解决问题，这件事目前还高度依赖人的深度参与，工具和流程还没法把它压缩成一份文档或一套自动化脚本。这个岗位会不会随着智能体定制变得更容易、模板变得更成熟而逐渐淡化，还是会长期存在下去，现在同样下不了结论，只能说眼下这是一个真实、可核实、正在快速膨胀的现象，不是某本书的预测。

先干什么后干什么，第 15 章 15.6 生产化改造的结论已经给过一个大方向的提示，时间消耗最大的地方往往不在模型本身，而在制度与流程。这个观察在个案层面是成立的，能不能直接放大到整个生态层面，目前没有足够的证据支撑，这里只把它当作一个值得留意的方向，不当作结论。

整章讲到这里，有一个更根本的问题一直没有正面回答，智能体究竟能带来多大的生产力杠杆？这个问题几乎所有讨论智能体的文章都会预设一个乐观的答案，可惜大多数时候这个预设本身没有证据支撑。2025 年上半年，研究机构 METR 做了一项随机对照试验，提供了这个领域少见的硬答案。16 名资深开源开发者在自己熟悉的成熟仓库里带着智能体干活，事前预期提速 24%，实测结果反而慢了 19%；做完之后再问这些开发者，他们仍然坚信自己这次提速了 20%。这项研究已经公开发表并有 arXiv 编号，是这一章里少数能独立核实、有真实数据支撑的证据。人对自身效率的体感，连方向都可能弄反，这一点值得所有读到本章、正在评估要不要大举推广智能体的人认真对待。

这个结果不该简单读成智能体没用，实验本身测的是资深开发者在自己已经很熟悉的老代码库里做调试改动，这是对智能体最不友好的一类场景。合理的推断是，真实的生产力杠杆，比营销话术描述的要小，具体大小会随任务类型、代码库新旧和团队纪律水平大幅波动，规格写得清楚的新项目，杠杆会明显一些；扎在陌生的老代码里做调试，往往只是打平，甚至像这项实验显示的那样，实际是负的。想知道自己的团队会在哪一档，眼下没有捷径，只能拿第 12 章讲过的评测方法，在自己的真实任务上跑出数字，而不是相信任何一份公开案例的自我报告。

网上确实流传不少团队自称做到了“无人值守”的智能体开发实践，代码不经人写、不经人审就直接上线。这类自述本身可能是真的，问题在于它们几乎都出自极少数经验丰富的工程师、在自己最熟悉的项目上做到的结果，缺乏可以独立验证的第三方数据，也没有看到任何一份公开案例把这套做法用在真正高风险、容错率极低的系统上。这类自述值得作为个案了解，不适合当作可以直接复制的行业实践来采纳。

组织怎么建、信任怎么立、人怎么配，这一章能给的答案比前面几部分要少，也更谨慎。能确定的部分都在正文里标了来源，说不清楚的部分，本章选择不替读者下结论。协议层的底座是真实的，前置部署工程师这个岗位的兴起也是真实的，组织与治理怎么把这些用起来，还是每个团队自己需要用证据回答的问题。

本章小结

• 18.1 根本差异。智能体的行为不能像传统代码那样一次冻结，推出四层后果，正确性要持续监测、边界要靠代码之外的约束、责任链条容易变模糊、部署是持续运营而非一次性交付。
• 18.2 发现、复用、批量管理。A2A 与 MCP 两条协议底座是可核实的硬事实（A2A 1.0 稳定版、治理在 Linux Foundation、超 150 家组织支持、GitHub 超 2.2 万 star；MCP 注册表服务器近两千、SDK 月下载近亿为二手转述）；复用往深一层是做法资产化，验证过的做法做成技能包，清单带名称、版本、适用条件、依赖和验收标准，版本化、启用前过评测、可回滚，历史轨迹批量挖经验、运行时查库、参数用对照实验定；复用跨边界有 Azure 自定义计量计费、llms.txt 这类真实做法；批量管理借容器编排、微服务治理的现成手段，通信与中间件选型不下判断。
• 18.3 身份、授权与问责。身份走 mTLS 与 OAuth2（含客户端凭据流）；授权用独立于双方的政策引擎；日志防篡改、可核验；认证参照微软 Foundry 的审批切分线（上架元数据变更才重审，内容更新免审）；责任共担借用公有云的分工语言；采买前过一遍三组供应商质询清单。
• 18.4 组织与证据。Team Topologies、Diátaxis、行走骨架、黄金路径和模型卡都是已验证的现成方法；前置部署工程师是多方数据印证的真实现象，2026 上半年计划招募的公司从年初的 5% 到 10% 跳到二季度末的 70%，美国存量约 1.7 万人；METR 随机对照试验给出硬数字，16 名资深开发者事前预期提速 24%、实测慢 19%、事后仍自评提速 20%，评估杠杆只能回到自己任务集上跑第 12 章那套评测。

参考资料

• A2A 官方规范 1.0.0（JWS 签名的 Agent Card、多协议绑定），https://a2a-protocol.org/latest/specification/ ，核实于 2026-08。
• A2A 官方公告 Announcing A2A 1.0（首个稳定版、Linux Foundation 治理、技术指导委员会构成），https://a2a-protocol.org/latest/announcing-1.0/ ，核实于 2026-08。
• Linux Foundation 新闻稿（2026-04-09，A2A 一周年超 150 家组织支持、GitHub 超 2.2 万 star、Google Cloud、Azure、AWS 接入），https://www.linuxfoundation.org/press/a2a-protocol-surpasses-150-organizations-lands-in-major-cloud-platforms-and-sees-enterprise-production-use-in-first-year ，核实于 2026-08。
• MCP 官方规范（最新版本 2026-07-28；OpenAI 2025-03、Google DeepMind 2025-04 采纳，注册表服务器近两千与 SDK 月下载近亿为二手转述），https://modelcontextprotocol.io/specification/ 与 https://workos.com/blog/everything-your-team-needs-to-know-about-mcp-in-2026 ，核实于 2026-08。
• IETF Internet-Draft draft-pro-adp-agent-discovery-02（Agent Discovery Protocol v1.1；个人提交的工作草案，截至 2026-09 尚未被工作组采纳），https://datatracker.ietf.org/doc/draft-pro-adp-agent-discovery/ ，核实于 2026-09。
• ICANN New gTLD Program 2026 轮（申请窗口 2026-04-30 至 2026-08-12；.agent 为该轮申请的字符串之一，二手口径称有多份申请竞争，份数以官方后续公布为准），https://newgtldprogram.icann.org/ ，核实于 2026-09。
• Verisign 博客 Proposed New DNS Resource Record Types for AI Agent Discovery，https://blog.verisign.com/security/proposed-dns-record-types-ai-agent-discovery/ ，核实于 2026-09。
• AGNTCY 官网与 Linux Foundation 新闻稿（开放协议栈四大件：Agent Directory 发现、Identity 身份、SLIM 消息、Observability 可观测；Cisco Outshift 孵化后捐给 Linux Foundation），https://agntcy.org/ 与 https://www.linuxfoundation.org/press/linux-foundation-welcomes-the-agntcy-project-to-standardize-open-multi-agent-system-infrastructure-and-break-down-ai-agent-silos ，核实于 2026-09。
• Julian Soh、John Tidwell、Priyanshi Singh《Building and Distributing Agentic AI Solutions: A Comprehensive Guide to Productizing AI》（Apress 2026）第 7 章（自定义计量计费：维度即价值单位、用量实时上报并入 Azure 账单，此为 Azure 市场既有通用能力）、第 8 章（从 Foundry 路径把智能体发进 Microsoft 365 与 Teams 须经 Microsoft 管理中心审批；内容更新免重审、图标与描述等详情变更须重审）。见 txt-ref-zh/building-distributing-agentic-ai/。
• 《Breaking the Model Context Protocol》（Satheesh kumar & Sekar，Apress 2026）第 12 章（供应商质询指南：问 server 所有者、问 host 平台、问安全与基础设施三组问题）。见 txt-ref-zh/breaking-the-mcp/。
• METR《Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity》（随机对照试验：16 名资深开源开发者，事前预期提速 24%、实测慢 19%、事后自评仍信提速 20%），arXiv:2507.09089，https://arxiv.org/abs/2507.09089 ，核实于 2026-09。
• Matthew Skelton、Manuel Pais《Team Topologies: Organizing Business and Technology Teams for Fast Flow》（IT Revolution Press，2019；stream-aligned team 与 enabling team 等团队拓扑概念的原始出处）。
• Daniele Procida，Diátaxis 官方文档框架站点（教程、操作指南、参考、解释四分法），https://diataxis.fr/ ，核实于 2026-09。
• Alistair Cockburn 关于 walking skeleton 的原始表述，另见 Growing Object-Oriented Software, Guided by Tests（Steve Freeman、Nat Pryce，Addison-Wesley 2009）对该概念的系统化阐述。
• Mitchell 等《Model Cards for Model Reporting》（FAT* 2019），https://arxiv.org/abs/1810.03993 ，核实于 2026-09。
• Carson Gross 关于分层 API 设计与 htmx 设计哲学的公开表述，见 htmx 官方文档 Essays 部分，https://htmx.org/essays/ ，核实于 2026-09。
• llms.txt 官方规范（网站根目录面向大语言模型的结构化说明文件），https://llmstxt.org/ ，核实于 2026-09。
• 《The Claude Code Operating Model》（2026）第 10 章（规格驱动开发的社区生态快照：六行模板逼清假设、计划与进度落盘续跑、同一份规格跨十几个编码工具通用、测试先行的技能包、经验沉淀成文档目录）。见 txt/claude-code-operating-model.txt（英文原文，第 10 章，行 11521-11623）。
• TechCrunch《Forward-deployed engineers are the AI industry's latest talent obsession》（2026-07-30；Christian & Timbers 研究：180 家公司 250 余位高管访谈、300 余位 FDE 与应用型 AI 工程师访谈，年初 5%–10% 公司计划招募 FDE、二季度末升至 70%，美国市场现有约 1.7 万名 FDE，Palantir 首创该岗位），https://techcrunch.com/2026/07/30/forward-deployed-engineers-are-the-ai-industrys-latest-talent-obsession/ ，核实于 2026-09。
• a16z《Trading Margin for Moat: Why the Forward Deployed Engineer Is the Hottest Job in Startups》（2025-06-04；智能体应用需要持续管理与深度上下文、客服智能体公司 Decagon 配备"智能体产品经理"团队协助客户部署的具体案例），https://a16z.com/services-led-growth/ ，核实于 2026-09。
• 《AI Agent Handbook》（开源白皮书，Apache 2.0 许可）第 15 章（技能按完整能力包管理：清单写明标识、版本、依赖与权限，发布后包内容不覆盖、改动即出新版本，上线前过结构、依赖与行为验证，废弃与撤回各有处置）与第 23 章（经验库从轨迹批量挖掘，每条回溯源轨迹核对，运行时检索，检索阈值、返回条数、触发时机拿不查经验库的基线做对照实验确定，检索与阅读开销一并计入）。见 参考资料/ai-agent-handbook/，核实于 2026-10-01。