简介谷歌AI Agent白皮书中英文对照版面向具备AI与软件开发基础的智能体开发者、技术管理者及研究人员聚焦智能体从概念验证走向生产落地的完整方法论。内容围绕模型、工具与交互协调层三大组件展开系统讲解AgentOps运维体系、能力/轨迹/最终响应三维评估与人机协同评估并剖析多智能体系统的分层、钻石、对等、协作等设计模式再配合汽车AI真实案例延伸到代理式RAG、Google Agentspace、NotebookLM Enterprise等企业级方案末尾提出“从智能体到承包商”的合同化范式。包内共1个PDF文件约2.17MB中英对照排版便于双语精读与术语核对已有1509人学习下载。读者可借此建立评估指标与运维流程的整体认知对照Vertex AI Eval Service、Agent Builder等工具完成实操并为多智能体选型与企业部署提供参考。1. 智能体的分水岭不在模型为什么“跑通 Demo”和“能上线”是两套工程这份 AI Agent 白皮书中英对照版的篇幅分配很反常真正讲模型的部分不到一页剩下上百页全在讲评估、运维、协作拓扑和失败案例。编写团队显然认定了一件事——把语言模型包一层工具调用做成 Demo 是周末工作量让它在一堆不确定的工具返回和中间状态里持续产出可验收的结果是另一个量级的工程问题。智能体在里面的定义很克制一个通过感知环境、动用可用工具去达成特定目标的应用程序。它和“更长的提示词”的区别不在输出长度而在于它能在没有明确指令的情况下自主决定下一步动作。一旦系统开始自己决定下一步问题就从“模型答得对不对”变成“这个过程可不可观测、可不可回滚、可不可比较”。这三个“可不可”才是这份材料真正想拆开讲的东西。2. 模型、工具、编排层三件套的职责边界是怎么划出来的智能体架构被切成三块模型、工具、编排层。这个划分看着平平无奇价值在于它把“出问题该往哪查”变成了一个有答案的问题——模型答得离谱、工具调不通、编排没把观察喂回去是三类完全不同的故障排查手段也完全不同。混在一起看就只能凭感觉调提示词那是玄学。2.1 模型负责决策不负责记住事实模型在架构里的定位是中央决策单元靠基于指令的推理和逻辑框架工作。它可以是通用模型、多模态模型也可以是微调过的模型具体选哪种取决于智能体要干什么。这个位置很关键模型输出的是判断和下一步动作不是事实本身。最常见的误判是“让模型记住我们的产品手册”于是兴冲冲去微调。微调改变的是模型在特定输入下的行为分布它不会凭空长出一份可实时更新的知识库。手册改了版本微调模型不会自动知道手册里有一百页微调也未必背得全。所以架构里把“数据存储”单独列为工具的一种用意很明确事实性内容走检索行为倾向才走微调。另一个容易被忽略的点是选型标准不是“越强越好”而是“够用且延迟可接受”。车机这类场景里离线可用是硬约束云端大模型再强断网那一刻等于零。这也解释了为什么架构里要保留多模态和微调的位置——不是炫技是被部署环境逼出来的。2.2 工具的三分法扩展、函数、数据存储各自解决什么工具是填平“智能体内部能力”和“外部世界”之间那道沟的东西。白皮书把它拆成三类拆的依据不是功能而是执行位置和控制权。扩展是 API 与智能体之间的桥让智能体能无缝执行 API。模型看到的是工具的自然语言说明和参数 schema编排层负责把它翻译成真实调用。函数是自包含的代码模块完成特定任务它和扩展的关键差别在于执行位置——有些函数由客户端侧执行模型只输出“我要调这个函数、参数是这些”真正的执行发生在宿主程序里。这个差别在端侧场景里是硬需求敏感操作不该由云端模型直接触发。数据存储提供对动态、最新信息的访问保证响应始终基于事实。判断该用哪种我一般看三个问题谁执行、状态在哪、更新频率多高。类型执行位置典型用途关键风险扩展服务端经编排层调用外部业务 API鉴权与配额没配好会被打爆函数可端侧可服务端本地计算、敏感操作参数校验缺失导致越权数据存储检索服务手册、政策、实时数据索引过期导致“自信地答错”这张表里最右边一列才是重点。工具不是加进去就完事每加一个就多一个失败面。工具数量一多模型选错工具的概率会肉眼可见地上升后面讲多智能体拆分时还会回到这个问题。2.3 编排层为什么必须是循环ReAct / CoT / ToT 落在哪编排层是一个循环过程决定智能体怎么吸收信息、怎么内部推理、怎么把推理变成下一步动作。它维护记忆、状态、推理和规划用提示工程框架去引导推理路径。ReAct、思维链CoT、思维树ToT这些技术都落在这层不在模型里也不在工具里。为什么非要是循环因为单次调用拿不到工具返回值也就没有根据返回值修正计划的机会。工具调用失败、返回空、只返回一半结果这些在真实系统里是常态而不是异常只有循环结构才能接住。下面是编排层最小可用的循环骨架# 编排层最小循环推理 - 行动 - 观察 - 再推理 state {goal: goal, history: [], scratchpad: } step, MAX_STEPS 0, 12 # 步数上限防止无限循环烧 token while not state.get(done) and step MAX_STEPS: # 1) 推理目标 历史观察 可用工具描述一起进上下文 thought model.reason(state[goal], state[history], tool_specs) state[scratchpad] thought.text # CoT 的中间步骤留痕便于事后评估 # 2) 决策这一步是调工具还是直接给最终答复 action thought.action # {tool: ..., args: {...}} 或 {final: ...} if final in action: state[done] True break # 3) 行动 观察返回值必须回灌 history否则下一轮等于失忆 observation registry.call(action[tool], action[args]) state[history].append({action: action, observation: observation}) step 1几个参数值得单独说。MAX_STEPS是花钱和延迟的总闸门车机场景通常压到个位数后台批处理任务可以放宽到几十。history承担短期记忆它的裁剪策略直接决定系统会不会重复调同一个工具——把上一次观察截掉了模型下一轮就真的不知道刚才查过什么。scratchpad存的是推理中间态它的真正价值不是让模型想得更清楚而是让你事后能看懂它当时在想什么这是后面轨迹评估的数据来源。registry是工具注册表所有可调工具在这里登记权限和 schema 变更也在这里管。三种推理技术的落点不太一样。CoT 是把推理展开成中间步骤主要作用是让推理过程可检查顺带成了评估的抓手。ReAct 是在 CoT 的基础上接上外部世界的返回值形成“推理—行动—观察”的交替。ToT 是在多个候选路径之间探索和回溯代价是 token 消耗成倍增长只在需要权衡的分支上才划算。工程上比较常见的组合是外层是 ReAct 循环循环内的单步推理用 CoT 展开遇到真正需要比较方案的岔路口才启用 ToT。全流程都上 ToT账单会教你做人。3. AgentOps为什么 MLOps 那一套指标搬到智能体上会失灵过去两年生成式 AI 领域的讨论重心从“能不能做”滑到了“怎么投产”于是冒出一串 Ops 名词。名词多了容易糊但它们的层级关系其实很清楚每一层都在上一层的能力之上加一类新的不确定性。智能体是这套谱系里不确定性最多的一层因为它同时引入了工具、状态和多步决策。3.1 从 DevOps 到 AgentOps 的依赖链以及“新实践不替代旧实践”DevOps 是把确定性软件高效投产的实践整合人、流程和技术是后面所有概念的地基。MLOps 建在 DevOps 之上专注 ML 模型的投产核心区别是模型输出非确定性、依赖输入数据垃圾进垃圾出。再往上是基础模型运维管的是预训练或微调过的基座模型怎么投产。然后是提示运维管提示的存储、血缘、元数据含评估分数、集中式模板注册表和提示优化器。检索运维管两头离线数据准备那一侧包括清洗、分块、向量化、相似度搜索和重排生成那一侧包括提示增强和事实锚定。最后是 AgentOps它额外要管的是内部与外部工具管理、智能体脑提示目标、画像、指令、编排、记忆和任务分解。这条链上最容易被忽略的一句话是新实践不替代旧实践。智能体的工具调用调的就是非智能体软件调的那批 API。鉴权、密钥管理、安全、隐私、异常处理、限流、配额、可扩展性一样都不能少而且要在 API 设计阶段就想清楚不能指望编排层兜底。这里有一条血泪经验不少团队一上来就搭评估流水线指标看板做得漂漂亮亮结果压测那天工具侧的限流没配直接把下游业务系统打挂了。评估体系再精细也救不了一个没做配额的工具网关。运维的功夫在下面那层不在看板上。3.2 AgentOps 多出来的四件事工具管理、脑提示、记忆、任务分解第一件是工具管理。工具的注册、版本、权限、schema 变更都要管。schema 一改历史轨迹的评估数据就对不上了——旧参数名和新参数名混在一张表里等于给自己埋雷。第二件是脑提示也就是目标、画像、指令三件套。目标决定它为什么做画像决定它扮演谁指令决定它怎么做。这三样必须版本化否则评测分数掉了你根本不知道是哪一句改动引起的。这就是所谓的“后悔药”得提前备。第三件是记忆。短期记忆是当前任务的观察历史长期记忆是跨会话的偏好和事实。写入策略比读取策略更容易出事读错了顶多这一轮答偏写错了会一直错下去而且越用越错。第四件是任务分解。把大目标拆成可验证的子任务拆得好不好直接决定轨迹评估能不能做。子任务边界模糊中间步骤就没法判对错最后只能回到“看最终答案”这条退化路径上。3.3 指标分层北极星指标、成功指标、评估指标白皮书里做了个思维实验挺值得照着做一遍生产环境给新智能体上 A/B实验组用新智能体对照组不用你测什么来判断实验组更好ROI 又怎么算是目标达成率、销售总额还是用户旅程里的某几个关键步骤指标得分三层看。最上层是业务北极星指标比如收入、用户参与度——它在智能体边界之外但它决定这个智能体该不该继续存在。中间层是智能体成功指标比如目标是否达成、关键步骤是否走完、平均步数、失败率。最下层才是评估指标能力、轨迹、最终响应这些。三层之间要能对上账。离线评估涨了 5 分、业务指标纹丝不动通常不是模型的问题是评估集和真实流量分布脱节了。反过来业务指标掉了但评估分数没掉八成是评估集里缺了某类真实的长尾输入。这种对账习惯比多买几张 GPU 有用。3.4 评估的三把尺子能力、轨迹、最终响应能力评估回答的是“在给定工具集下它能不能把任务做完”。这一步的关键是分清“模型不会”和“编排没给机会”工具明明在注册表里但提示里没描述清楚模型压根不知道有这个工具这是编排的问题再怎么换模型也没用工具描述很清楚模型还是选错那才是模型能力问题。两种情况的修法完全不同混在一起就只能靠猜。轨迹与工具使用评估看的是路径不是答案。工具选对没、参数填对没、有没有绕路、有没有重复调用、失败之后有没有正确重试、总共走了几步。最终响应评估看正确性、完整性和是否锚定在检索到的事实上。人机回环则负责兜住那些自动打分不了的场景主观质量、高风险决策、冷启动阶段的数据积累。轨迹评估需要落到数据结构上否则没法聚合分析trajectory { task_id: T-1042, steps: [ {i: 0, tool: search_manual, args: {q: 胎压告警}, ok: True, latency_ms: 320}, {i: 1, tool: read_sensor, args: {id: tpms}, ok: False, error: permission_denied}, {i: 2, tool: search_manual, args: {q: 胎压告警}, ok: True, latency_ms: 310}, # 重复检索 ], final: ..., outcome: success, cost_tokens: 4210, } # outcome 说结果是对的但 steps[1] 权限失败、steps[2] 重复检索 # 说明工具权限配置和已获取信息的去重逻辑都有问题。只看最终答案这两条全被平均掉了。这段结构里outcome是结果维度steps是过程维度cost_tokens是成本维度。三个维度必须分开统计一旦合并成一个“总分”过程问题就永远浮不上来。多智能体的评估还要再难一层。中间有移交责任归属天然模糊最终答案错了是调度者分派错了还是子智能体执行错了还是响应合成时把对的答案改错了所以多智能体评估的每一步都必须带“哪个智能体、在第几个移交点、做了什么”的标记否则出了问题只能整条链路一起回滚。黑匣子式的多智能体系统上线之后基本没法迭代。4. 多智能体协作模式五种拓扑一张汽车场景的取舍表一个智能体包打天下在工具少的时候没问题。工具一多工具描述之间开始互相干扰选错率往上走领域知识一多上下文被挤满注意力被稀释更麻烦的是语气导航要简洁、媒体搜索要轻快、消息组合要得体一个提示要同时满足三种人格怎么调都是折中。4.1 从一个大智能体到一组专业智能体拆分的逻辑是按领域切不是按功能切。汽车 AI 这个案例里切出了五类专业智能体对话导航、对话媒体搜索、消息组合、汽车手册、通用知识。每个智能体只面对窄工具集和窄知识域提示词也只需要服务一种交互风格。真正的驱动力是部署约束。现代车辆的交互界面要在有网和没网时都能用端侧和云端之间要做平衡——安全相关的判断尽量靠端侧体验相关的重活交给云端——导航、媒体控制、消息、车控这几套系统还得无缝协同。这些约束直接决定了拓扑离线可用要求一部分智能体跑在端侧端侧算力和模型尺寸有限所以必须切细一个大模型塞不进去。4.2 五种模式的结构与代价分层模式是顶层调度者把任务分派给子智能体。职责清晰加新能力只要加个叶子节点代价是调度者成了单点它分派错了整条链路就全错而且多了一跳延迟。钻石模式是入口先分发到多个专业智能体并行处理结果汇聚到一个响应混合器。它适合需要多源合成的请求比如“找个沿途评分高的充电站顺便看看那段的天气”。对等模式是智能体之间直接移交不经过中心节点。延迟低适合端侧代价是全局状态难追踪而且特别容易出现两个智能体来回推诿的乒乓移交。协作模式是多个智能体共享中间结果、共同推进一个任务适合强耦合的任务但状态同步成本高。响应混合器严格说不是一个独立拓扑而是钻石这类模式的收口组件负责把多路结果合成一段自然回复顺带处理冲突和去重。自适应循环则是根据中间结果动态决定下一跳而不是走固定路径。模式控制流适合场景主要代价分层中心调度 → 子智能体能力多、边界清晰调度者单点 一跳延迟钻石分发 → 并行 → 汇聚多源信息合成汇聚层要做冲突消解对等智能体间直接移交低延迟、端侧离线全局状态难追踪、易乒乓协作共享中间结果任务强耦合状态同步成本高自适应循环动态决定下一跳输入差异极大难预测、难评估选型的时候别盯着“哪个最先进”要盯着“我的约束是什么”。端侧离线场景硬上分层多一跳延迟就可能超出交互预算云端场景硬上对等状态丢失之后的排查成本会让你怀念中心调度。4.3 Agentic RAG检索为什么必须变成动作传统 RAG 的流程是固定的一次检索、拼上下文、生成。它在检索质量好的时候表现不错问题在于检索质量差的时候生成端没有任何补救手段——它只能拿着不相关的文档硬答。Agentic RAG 把检索从“前置管道”变成“智能体的一个动作”。智能体自己决定检索什么、检索几次、要不要换查询词、要不要换数据源、结果不够要不要再查一轮。“更好的搜索带来更好的 RAG”这句话说的是这个意思检索质量成了循环里可以被修正的变量而不是一次性的赌注。代价也很实在。延迟和成本都会上去而且多了一个必须评估的对象——检索决策本身的质量。该查的时候没查是漏不该查的时候连查三次是浪费这两种错误在最终答案上可能都看不出来只能靠轨迹评估抓。4.4 从智能体到承包商合同化协作材料最后提了个挺有意思的范式转变把智能体当承包商而不是当助手。核心是合同——把“要做什么、验收标准是什么、什么情况下算违约”写成显式契约而不是靠提示词里的软约束。合同的生命周期分几段定义、执行、协商、反馈以及分包。分包正好对应多智能体场景主承包商把子任务包给子智能体子智能体同样要签子合同交付物同样要验收。这个思路的价值在于它把智能体之间的协作从“互相发消息”变成“有明确输入输出和验收条件的调用”评估和追责才有落点。{ contract_id: nav-sub-07, issuer: orchestrator, contractor: navigation_agent, inputs: {destination: string, avoid_tolls: boolean}, deliverables: [route_plan, eta_minutes], acceptance: {eta_error_max_min: 5, must_include_route_plan: true}, deadline_ms: 1500, on_violation: return_to_issuer }acceptance是整份合同的核心它把“做得好不好”从主观判断变成可校验的条件deadline_ms给了超时边界超时就算违约触发退回on_violation定义了违约后的处理路径避免子智能体卡死之后主链路跟着一起挂。少了这三项合同就退化成了又一层提示词。5. 上线前排查五类最容易翻车的地方这些坑有个共同特征离线评测分数都不难看问题全藏在轨迹里。下面五条是按我自己踩过的顺序排的前面两条出在工具层中间两条出在状态和评估层最后一条出在配置管理上。5.1 工具描述写成产品文档模型就是选不对工具现象明明注册了专用工具模型还是反复去调通用搜索答案质量不稳定。原因工具描述写的是“本工具用于查询车辆状态信息”这种产品文档式句子模型看到的是业务黑话不是判断依据。它不知道什么时候该用这个工具、什么时候不该用。解决描述里补三样东西——触发条件、反例、参数取值范围。比如写成“当用户询问胎压、油量、续航里程这类实时读数时使用用户询问保养周期这类静态知识时不要用改用手册检索参数 id 只接受 tpms、fuel、range 三个值”。加完这三样选错率通常会明显下降。5.2 观察不回灌、历史无限增长工具被重复调用现象同一个检索工具在一次任务里被调了三四次参数一模一样延迟翻倍。原因两个极端都会导致这个问题。一种是历史裁剪太激进上一轮的观察被截掉了模型下一轮真的不知道刚查过另一种是历史完全不裁剪上下文太长模型的注意力被稀释看不见那条观察。解决分层管理历史。最近 N 轮的完整观察原样保留更早的压缩成摘要保留结论丢掉原文同时在编排层加一层去重——相同工具加相同参数在最近若干步内出现过直接返回缓存结果不再真实调用。这一层放在代码里比指望模型自觉靠谱得多。5.3 只看最终答案轨迹里的失败被平均掉现象离线评测 92 分上线一周用户投诉工具权限报错可评测报告里一个错误都没有。原因评估只统计了最终响应中间的失败重试被outcome: success掩盖了。重试成功也是成功但代价是延迟和 token 翻倍用户体感是“这个功能好慢”。解决把工具错误率、重复调用率、平均步数、P95 延迟单独列成一级指标和最终答案正确率并列看。轨迹数据结构里那些ok、error、latency_ms字段就是为了这个建的不能只存不用。5.4 多智能体互相移交延迟越滚越大现象两个对等智能体来回移交一次请求延迟从 1.2 秒飙到 8 秒日志里全是 handoff 记录。原因没有移交次数上限也没有兜底的终止条件。每个智能体都觉得“这不是我的领域转给隔壁更合适”于是形成死循环。解决加两个硬约束。一是 hop limit移交超过 N 次强制终止二是兜底的通用智能体任何移交失败或超限都落到它身上由它给用户一个明确回复。另外在评估里加一项“移交次数分布”这个指标异常往往比延迟更早暴露设计问题。5.5 提示改了没版本评测分数无法归因现象同一份评测集昨天 88 分今天 71 分代码一行没动。原因脑提示目标、画像、指令被人手改了但没进版本控制也没和评测分数绑定。提示在智能体系统里就是配置配置没有版本管理等于没有实验记录。解决提示纳入版本控制每次评测结果都带上提示版本号和工具 schema 版本号。工具 schema 变更时历史轨迹要么迁移要么标记失效别让两代数据混在一张表里算平均分。6. 把多少决策交给模型一个关于确定性边界的取舍智能体的能力来自“把决策权交给模型”可靠性来自“把关键路径收回来”。这两件事天然对冲所有设计争论最后都会落到同一个问题这条边界画在哪。我自己的画法是看两个维度可逆性和可观测性。可逆且可观测的决策大胆交给模型——选哪个工具、检索几次、先问哪一个参数这些错了可以重来过程也能从轨迹里看清楚。不可逆的决策比如下单、发送消息、删除数据、改变车辆行驶状态一律走确定性代码模型只负责生成“建议动作”执行前必须有人或规则确认。中间地带是那些可逆但不可观测的决策典型代表是把多个工具结果合成一段自然语言——错了用户能重说一遍但你很难事后解释它为什么这么合成这类就得靠响应混合器这类收口组件加约束。提示判断一条决策该不该交给模型别问“模型能不能做对”要问“做错了要花多大代价才能发现和撤回”。这两个问题的答案经常相反。验证边界画得对不对靠的不是离线评测分数是小流量对照加轨迹抽检。具体做法是切 5% 流量给新版本对照组保持原样除了业务指标之外重点盯三个数——平均步数、工具错误率、移交次数。这三个数里任何一个显著上升都说明模型在做超出它职责范围的决策边界画错了。离线评测涨分但平均步数涨了 40%那不是能力提升是模型在乱试。还有一个常被忽略的取舍是“拆多细”。多智能体拆得越细每个智能体的工具集越窄、选错率越低但移交次数和状态同步成本越高。拆到五个差不多是个经验拐点再往下拆收益会被协调开销吃掉。这个数字没有普适答案取决于你的延迟预算和评估能力——评估做不到定位到单个智能体拆得再细也是一团黑。那份材料里“从智能体到承包商”的提法我一开始觉得有点绕后来想明白了它本质上就是在给这条边界找一个可执行的表达方式。合同里的验收条件就是确定性边界的具体化——模型可以自由决定怎么完成任务但交付物必须过验收过不了就退回。从那以后我每次设计智能体都强制先把轨迹字段和验收条件定下来再写第一行提示词顺序反了就得返工。希望帮到你。本文还有配套的精品资源点击获取