简介这是一份聚焦生成式AI智能体的谷歌白皮书中英文对照版面向具备AI与软件开发基础、从事智能体设计开发或运维的工程师、技术管理者及研究人员。内容围绕模型、工具与交互协调三大组件展开系统讨论AgentOps、能力、轨迹与最终响应评估及人机协同评估并延伸至多智能体架构的分层、协作、对等模式与汽车AI案例同时覆盖Agentic RAG、Google企业级智能体平台及“从智能体到承包商”的合同化机制兼顾理论框架、评估方法与企业落地思路。资源包共1个PDF文件大小约2.17MB中英文对照便于术语核对与原文理解。已有1509人学习适合系统建立智能体架构、评估与多智能体协作的整体认知并结合评估工具、开发平台和案例梳理企业级部署与运维要点。1. 这份 AI Agent 白皮书该摆在什么位置一份写给开发者的 102 级手册把 Agent 推上生产的团队最后卡住的通常不是模型够不够聪明而是评估做不出来、故障复现不了、成本压不下去。这份 2025 年 2 月定稿的 AI Agent 白皮书定位很明确——它是入门篇之后的 102 级配套读物中英文对照排版全书围绕 AgentOps、评估体系、多智能体架构三条主线展开还带了一个车载场景的完整落地案例。适合已经把 ReAct 跑通过一遍、正准备把 Agent 接进真实业务系统的工程师纯新手读起来会有点跳因为开篇就假设你知道什么是工具调用。后面几章按「能抄作业」的方式拆一遍顺便标出哪些地方翻译腔重、哪些图必须对着英文原文看。2. 智能体的三件套怎么落到工程上模型、工具与编排层白皮书开篇给出的定义很克制Agent 是一个被工程化构造出来的应用通过感知环境、并借助手头工具采取行动来达成特定目标。这句话里藏着一个容易被忽略的限定词——「被工程化构造」。一个裸模型加一个函数调用接口不算 Agent真正让它成为 Agent 的是那个把推理、行动、观察串成闭环的编排层。这一章按模型、工具、编排层三块拆重点放在编排层因为前两块是选型问题编排层是设计问题。2.1 编排层才是分水岭为什么「模型 工具」撑不起一个 Agent白皮书把模型称作 Agent 框架里的核心决策单元承担基于指令的推理和逻辑判断。这个定位意味着模型本身不保存任务状态它只是被反复调用的一次次「思考」。状态保存在编排层记忆里存过往轮次scratchpad 里存本轮推理轨迹规划模块决定下一步是继续调工具还是收口给用户。三者缺一Agent 就会退化成一次性的问答封装。选型上白皮书的说法是从通用模型到多模态、再到微调模型都可以取决于需求。落到实际工程我一般按三个维度切任务是否需要读图读表多模态、工具调用格式是否要求极稳定的结构化输出微调或强约束解码、单轮推理链是否超过七八步长上下文与推理成本。前两个维度决定模型档位第三个维度决定你要不要上规划模块。推理技术这一层白皮书点了 ReAct、思维链CoT、思维树ToT三个名字但没说清什么时候用哪个。血泪经验是这样的技术适用场景代价常见误用CoT单步复杂判断如工单分类、条款比对输出 token 涨 24 倍用在多步工具调用上链一长就跑偏ReAct需要边查边改的任务如检索问答、数据核对轮次不可控需设上限不设 max_steps遇到工具报错就死循环ToT分支决策如方案比选、路径规划调用量呈树状放大在简单任务上硬套成本翻十倍收益为零实际项目里 ReAct 是主力CoT 用在 ReAct 的单个 thought 内部做细化ToT 只在少数需要「先想三条路再选一条」的场景开。白皮书把三者并列写容易让人以为是三选一的架构选项其实它们处在不同粒度上。还有一层是记忆。白皮书把记忆放在编排层里一句话带过但工程上记忆是最容易失控的部分短期记忆本轮 scratchpad必须做截断长期记忆跨会话画像必须做写入策略否则上下文窗口会被历史对话撑爆。常见做法是给 scratchpad 设一个字符预算超出就把最早的工具返回结果压缩成一行摘要保留结论、丢掉原始 payload。2.2 用 ReAct 写一个最小编排循环代码骨架与四个关键参数不依赖任何特定厂商 SDK 的骨架最能说明问题。下面这段是一个可以直接跑的 ReAct 循环模型客户端用一个抽象接口表示换成自家的推理服务即可。# react_loop.py —— 最小 ReAct 编排骨架不绑定具体模型厂商 import json from dataclasses import dataclass, field dataclass class AgentState: goal: str # 用户目标全程不变用于最终收口判断 scratchpad: str # 本轮推理轨迹受 MAX_PAD_CHARS 约束 history: list field(default_factorylist) # 已完成的 (action, observation) 对 steps: int 0 MAX_STEPS 8 # 硬上限超过强制收口防止死循环 MAX_PAD_CHARS 6000 # scratchpad 字符预算超出触发压缩 TOOL_TIMEOUT_S 10 # 单个工具调用超时 TOOL_RETRY 1 # 仅对幂等工具开启重试 def build_prompt(state: AgentState, tools_spec: str) - str: # 工具清单每轮都重放格式必须是稳定的 JSON Schema 描述 return f目标{state.goal} 可用工具{tools_spec} 已完成步骤{json.dumps(state.history, ensure_asciiFalse)} 推理轨迹{state.scratchpad} 请输出 JSON{{thought: ..., action: 工具名或 finish, action_input: {{...}}}} def compress_pad(state: AgentState) - None: # 压缩策略保留最近两轮完整内容更早的 observation 只留首行结论 if len(state.scratchpad) MAX_PAD_CHARS: return keep_tail state.scratchpad[-MAX_PAD_CHARS // 2:] state.scratchpad [早期步骤已压缩]\n keep_tail def run_agent(goal: str, tools: dict, llm) - str: state AgentState(goalgoal) tools_spec json.dumps({k: v[schema] for k, v in tools.items()}, ensure_asciiFalse) while state.steps MAX_STEPS: raw llm.invoke(build_prompt(state, tools_spec), temperature0.2) try: decision json.loads(raw) # 解析失败直接进入下一轮不抛给用户 except json.JSONDecodeError: state.scratchpad \n[格式错误请只输出合法 JSON] state.steps 1 continue if decision[action] finish: return decision[action_input].get(answer, ) name, args decision[action], decision.get(action_input, {}) if name not in tools: # 幻觉工具名回灌错误信息让它自己纠正 obs f工具 {name} 不存在可用工具{list(tools)} else: try: obs tools[name][fn](**args, timeoutTOOL_TIMEOUT_S) except Exception as e: obs f工具执行失败{type(e).__name__}: {e} state.history.append({action: name, args: args, obs: str(obs)[:800]}) state.scratchpad f\nThought: {decision[thought]}\nAction: {name}\nObservation: {str(obs)[:800]} state.steps 1 compress_pad(state) return 任务未在步数上限内完成请缩小问题范围后重试。逻辑上分四段构造提示、解析决策、执行工具、回写观察。提示里工具清单每轮完整重放而不是只放增量是因为模型没有跨轮记忆之外的机制去「想起」某个工具省这几百 token 换来的是显著更低的工具名幻觉率。四个参数值得单独说。MAX_STEPS是后悔药设多少取决于任务链长度检索类任务 58 步够用跨系统核对类 12 步以上超过上限不要静默返回空要返回一句明确的未完成提示否则前端会显示成「已完成」但内容是空的。MAX_PAD_CHARS直接决定单次调用成本6000 字符大约对应两千多 token调大之前先算一遍单任务成本。TOOL_TIMEOUT_S必须设不设的话一个挂住的下游接口能把整个 Agent 拖死。TOOL_RETRY只对查询类工具开写库类工具重试一次就可能产生重复记录这类翻车在第 5 章会细说。解析失败的处理方式也值得注意直接把格式错误回灌进 scratchpad让模型自我纠正比在代码里写一堆正则去「抢救」输出更稳。抢救逻辑往往只覆盖了你见过的那几种坏格式模型下次会给你新的。2.3 工具层的三种形态扩展、函数、数据存储的选型边界白皮书把工具分成扩展Extension、函数Function、数据存储Data Store三类这个分法比常见的「API / 本地函数 / 向量库」更贴近职责划分但中译版读起来容易混——尤其「扩展」这个词英文原意是桥接 API 与 Agent 的那层适配器。先给结论性的选型边界形态本质什么时候用什么时候别用扩展把外部 API 的鉴权、重试、分页封装成 Agent 可直接调用的单元下游是成熟 REST 服务且需要 OAuth 之类复杂鉴权下游接口本身不稳定、错误码语义混乱函数一段自包含的代码模块跑在你自己的进程里需要在调用前后做数据整形、校验、脱敏逻辑需要访问内网资源而 Agent 部署在外部环境数据存储向量库、文档库、结构化库提供动态事实来源答案依赖最新业务数据且模型知识已过期数据量很小、直接塞进提示更省事三种形态最容易出问题的地方不在选型而在描述。工具描述是写给模型看的接口文档不是写给同事看的注释。我看到过的典型翻车是把描述写成「查询订单信息」六个字模型根本不知道要传订单号还是手机号、不知道返回里有没有物流状态于是反复试探步数烧光。好的工具描述包含四件事这个工具解决什么问题、必填参数的含义与格式、返回值的结构、什么情况下不该调用它。第四点几乎没人写但它能显著降低误调用率。比如一个「发送短信」的工具描述里加一句「仅在用户明确确认发送内容后调用」误触发率能降一个量级。数据存储这一层的坑在切分和时效。白皮书提到 Agentic RAG 时说得很清楚更好的检索来自更好的搜索策略而不是更大的向量库。文档切分粒度、是否保留表格结构、增量更新怎么触发重建索引这些决定了后面所有推理的质量上限。我一般会把「检索到的原文片段」和「模型改写后的查询」都打进日志出问题时能立刻判断是检索没召回还是召回了但模型没用上。工具数量也需要控制。给一个 Agent 挂三十个工具工具选择的准确率会明显下滑因为模型在长清单里做区分的成本很高。超过十五个工具就该考虑分组或者拆成多个专职 Agent 用路由分发——这也正是白皮书后半部分讲多智能体架构的现实动因之一。3. AgentOps 落地从 Ops 谱系到可埋点的成功指标白皮书对 AgentOps 的定义是 GenAIOps 的一个子类专注于 Agent 的高效运营化额外承担工具管理、Agent 大脑提示目标、画像、指令与编排、记忆、任务分解这几块。这个定义本身没什么争议真正有价值的是它给出的谱系图——把 DevOps、MLOps、FMOps、PromptOps、RAGOps、AgentOps 排成一条依赖链明确说了新实践不替代旧实践。3.1 六种 Ops 的依赖关系哪些能力可以直接继承很多团队做 Agent 运维时从零搭一套结果是重复造轮子还造得不好。谱系图的意义在于告诉你哪些能力可以直接从上一代继承。层级关注对象新增的核心能力可直接继承的部分DevOps确定性软件CI/CD、版本控制、监控告警——MLOpsML 模型数据版本、模型训练流水线、漂移监控全部 DevOps 能力FMOps预训练/微调基础模型模型卡、微调数据治理、推理资源调度全部 MLOps 能力PromptOps提示提示存储、血缘、元数据含评分、集中模板注册表、提示优化器版本控制、灰度发布RAGOps检索增强离线数据准备清洗、切分、向量化、相似检索、重排 生成侧增强与接地提示管理、评估框架AgentOps智能体内外部工具管理、Agent 大脑提示与编排、记忆、任务分解鉴权、限流、配额、异常处理、可观测性这张表最有用的地方是最后一行。白皮书特别强调Agent 调工具用的往往就是非 Agent 软件调的那批 API所以身份认证、密钥管理、安全、隐私、异常处理、限流、配额、可扩展性这些照样是硬要求而且需要在 API 设计阶段就考虑不是套在 Agent 外面补一层。实际落地时我见过一个典型误判团队认为 Agent 是「新东西」于是单独建了一套告警体系结果工具侧的超时告警和原有 API 网关的告警重复触发值班同学一晚上收到四遍同样的信息。正确做法是工具调用的底层指标复用原有网关的埋点Agent 层只补编排相关的指标。PromptOps 那一层也常被跳过。提示没有集中注册表典型后果是同一个系统里三个服务各存一份「客服系统提示」改了一处另外两处继续用旧版线上表现时好时坏排查时怀疑模型、怀疑检索就是不怀疑提示不一致。集中模板注册表加血缘记录能省掉大量这类玄学问题。3.2 A/B 实验埋点业务北极星指标与 Agent 过程指标怎么分层白皮书里有个很好的思维实验假设你在生产环境给新 Agent 开 A/B实验组上 Agent、对照组不上你要用哪些指标判断实验组更好这个问题逼着人区分两类指标——业务指标收入、转化、用户参与度是北极星但它通常不在 Agent 自身的范围内Agent 指标任务完成率、步数、工具成功率是你能直接优化和归因的东西。分层埋点我一般这么设计层级指标采集位置用途业务层任务转化率、人工接管率、单均成本业务系统判断值不值得继续投入任务层任务完成率、平均步数、超步数上限比例编排循环判断 Agent 本身是否在进步步骤层工具选择准确率、参数正确率、工具错误率工具调用包装器定位具体退化点质量层最终响应事实性、格式合规率评估流水线离线回归与线上抽检成本层单任务 token、单任务时延 P50/P95模型客户端容量规划与预算控制关键在「超步数上限比例」这个指标它比平均步数敏感得多。平均步数从 4.2 涨到 4.6 可能只是任务分布变了但超上限比例从 2% 涨到 9% 基本可以确定是某个工具的返回格式改了或者描述写坏了直接去看步骤层日志就能定位。埋点代码最忌讳写得太重。下面这个函数在循环里每步调一次字段够用就好# telemetry.py —— 每个步骤打一条 span字段控制在 12 个以内 import time, uuid, json, logging log logging.getLogger(agent.span) def emit_span(state, step_index, decision, obs, latency_ms, tokens): log.info(json.dumps({ trace_id: state.trace_id, # 一次任务一个跨步骤串起来 step: step_index, action: decision.get(action), # 工具名finish 也记 action_args_keys: sorted(decision.get(action_input, {}).keys()), # 只记 key 不记值防泄漏 obs_len: len(str(obs)), # 观察长度用于观察上下文膨胀 obs_ok: not str(obs).startswith(工具执行失败), latency_ms: latency_ms, tokens: tokens, step_limit_hit: step_index 7, # 接近上限时提前预警 }, ensure_asciiFalse))参数上有个细节action_args_keys只记参数名的 key不记值。参数值里经常有手机号、地址、订单金额直接落日志就是一次数据合规事故。需要复现时靠 trace_id 去业务系统查原始入参而不是让日志成为一份脱敏不彻底的副本。obs_ok用字符串前缀判断是个权宜之计更稳的做法是让工具包装器统一返回{ok: bool, data: ..., error: ...}结构编排层和埋点都读这个字段。前期偷懒用字符串约定后期接入第二种工具时一定会后悔。还有一个指标白皮书没提但线上很要命首次工具调用的时延。用户感知的等待主要发生在前两三步后面步骤即使慢用户已经在看进度反馈了。把 P95 首次工具时延压到两秒以内比把总时延优化 30% 的体感收益大得多。3.3 提示、工具 schema 与记忆的版本管理AgentOps 的版本控制和普通服务不太一样因为它有三个独立演进的版本维度提示、工具 schema、记忆结构。三者任一改动都可能让线上表现突变而这三者的变更往往由不同角色发起。我习惯的目录结构是这样的重点是每次变更必须同时留一份变更说明和一份基线评估结果agent_config/ ├── prompts/ │ ├── system.20250210.v3.txt │ └── system.20250210.v3.md # 变更说明改了什么、为什么、基线分数 ├── tools/ │ ├── order_query.schema.v2.json # 参数增减必须升版本不能直接改 │ └── order_query.impl.v2.py └── memory/ ├── short_term.policy.v1.json # 截断策略、压缩策略 └── long_term.schema.v1.json # 写入字段、过期时间三条硬规则。第一工具 schema 的破坏性变更删参数、改类型、改必填性必须升大版本并且新旧并行一段时间因为模型侧的提示里缓存了旧 schema切换需要灰度。第二提示文件的命名里带日期便于按时间回滚文件名里不带「final」「new」这种词——我见过一个仓库里七个system_final.txt。第三记忆结构的变更必须做数据迁移方案长期记忆里存着用户画像schema 一改老数据读出来就是脏的。白皮书在 AgentOps 部分还提了任务分解这块的版本管理容易被忽略。分解策略先拆子任务还是边做边拆本质上也是配置改一次就等于换了套系统同样需要基线评估兜底。4. 智能体评估的三个切面能力、轨迹与最终响应评估是这份白皮书里分量最重的部分从 Agent Evaluation 一路写到多智能体评估中间拆出能力评估、轨迹与工具使用评估、最终响应评估、人机协同评估四块。这个拆法是对的因为 Agent 的失败模式太多样了——有的任务做对了但绕了十步有的每步都对最后汇总错了有的答案对但工具调用越权了。用单一指标衡量永远只能看到一角。4.1 能力评估把「会不会用工具」拆成可判定项能力评估回答的是「这个 Agent 具备哪些本领」听起来抽象落下去必须变成可判定的二元项否则没法算分。白皮书的思路是先定义能力清单再为每项能力设计测试用例。我一般拆成四类能力项判定方式典型失败表现工具选择给定意图第一步调用的工具是否在期望集合内该查订单的去查了物流参数构造必填参数是否齐全、格式是否合法日期传成「昨天」而不是 ISO 格式多步规划完成任务的步数是否在参考区间内反复调用同一工具刷步数边界识别超出能力范围时是否明确拒答或转人工硬编一个看起来像样的答案边界识别这一项最容易被漏掉但它在生产环境里的价值最高。一个不会拒答的 Agent错误答案会以很高的置信度流到用户手里而错误答案的修复成本远高于「暂时无法处理已转人工」。测试用例的构造有个实用技巧不要从「正确路径」出发写用例从工具的错误返回出发写。把每个工具可能返回的 4xx、5xx、空结果、超时都造一遍看 Agent 是重试、换路还是收口。这批用例的通过率往往比正常路径的通过率更能预测线上表现。能力评估的另一个坑是用例集泄漏。同一批用例被反复用来调提示、调工具描述几轮之后分数很好看但那只是过拟合。常见做法是留一个从不参与调试的留出集只在版本发布前跑一次两次发布之间的分数变化才有参考意义。4.2 轨迹评估单步正确不等于任务完成轨迹评估是 Agent 特有的传统模型评估没有这一层。白皮书把轨迹和工具使用放在一起讲因为它们本质上是同一件事的两个视角轨迹是过程工具使用是过程中的关键动作。轨迹层面我关注五个信号总步数、重复调用、无效调用、恢复能力、终止原因。前三个是效率问题后两个是可靠性问题。「恢复能力」这个信号特别好用定义是工具返回错误后Agent 在接下来两步内是否采取了不同的动作。如果它原样重试同一个工具同一个参数说明它根本没读 observation如果它换了个工具但目标不变说明它有基本的纠错意识。这个指标在版本对比时比任务完成率更早出现分化适合做早期预警。批量跑轨迹评估的脚本大概是这个形状核心是把每一步的决策和执行结果都落到结构化记录里再做规则判定# eval_trajectory.py —— 离线跑批输出每条用例的轨迹诊断 import json from collections import Counter def diagnose(trace: list[dict]) - dict: trace 是一串 step 记录每步含 action / args / obs_ok actions [s[action] for s in trace if s[action] ! finish] pairs [(s[action], json.dumps(s[args], sort_keysTrue)) for s in trace] dup sum(c - 1 for c in Counter(pairs).values() if c 1) # 完全相同的调用算重复 recover 0 for i, s in enumerate(trace[:-2]): if not s[obs_ok]: nxt trace[i 1] if (nxt[action], json.dumps(nxt[args], sort_keysTrue)) ! pairs[i]: recover 1 # 失败后换了动作即算一次恢复 errs sum(1 for s in trace if not s[obs_ok]) return { steps: len(actions), duplicate_calls: dup, tool_errors: errs, recover_rate: round(recover / errs, 3) if errs else None, terminated_by: trace[-1][action] if trace else empty, } def run_batch(cases, agent, threshold): rows [] for c in cases: trace agent.run_with_trace(c[input]) # 需要编排层支持返回完整 trace d diagnose(trace) d[case_id] c[id] d[passed] d[steps] threshold and d[duplicate_calls] 0 rows.append(d) return rowsrecover_rate为 None 表示整条轨迹没遇到工具错误这类用例要从恢复率统计里剔除否则会把「没机会恢复」算成「恢复失败」把指标拉低。这个细节在第一次算分时几乎必然踩到。duplicate_calls用的是「动作 参数」的完全匹配比只比动作名严格。有些任务确实需要连续两次查同一个接口但参数不同比如翻页按动作名判重会误伤。反过来如果 Agent 把同一份长文本每次都完整塞进参数里完全匹配能抓出来这是省成本的关键。passed的判定条件写得很粗只看步数和重复。生产环境里还要加「终止原因必须是 finish 而非步数上限」以及「关键工具必须被调用过」。后者可以防一种很隐蔽的作弊Agent 不调任何工具直接凭模型知识编了个答案任务看着完成了实际全是幻觉。4.3 最终响应评估与人机协同打分最终响应评估看起来最简单——比对答案对不对实际最难因为很多任务的正确答案不是字符串。白皮书给了三个方向事实性、相关性、完整性工程上还要加格式合规。事实性可以用检索接地的方式判把响应里的事实性陈述抽出来逐条回查权威数据源能否支撑。相关性靠模型裁判给一段评分标准和几个示例让它打 15 分。完整性最难自动化我一般用「要点覆盖率」近似预先标注该任务必须覆盖的 N 个要点统计命中几个。这个方法粗糙但可解释业务方看得懂比一个黑盒分数更容易推动改进。模型裁判要注意两个偏差。一是位置偏差A/B 对比时把两个响应交换顺序各打一次分取平均。二是长度偏差裁判模型倾向于给长答案高分所以评分标准里必须明确写「冗余信息扣分」。不加这条优化方向会跑偏成「把所有相关的内容都堆上去」。人机协同评估是白皮书单列的一节核心观点是自动化评估不能完全替代人。落地方式我建议做成抽检流水线线上每天按固定比例抽一批真实会话让标注同学按统一 rubric 打分同时记录他们的判断理由。理由字段比分数值钱它是后续调整自动评估标准的依据。标注一致性要算两个标注同学对同一批样本的 Cohens kappa 低于 0.6说明 rubric 本身写得有问题先改 rubric 再谈模型好坏。这一步跳过的话后面所有的评估结论都建立在一套互相矛盾的标注上。4.4 多智能体评估的归属难题单 Agent 评估的链路是清楚的输入、轨迹、输出三段都能归因。多 Agent 一上来就把这个链路打散了——任务失败了是路由 Agent 分错了是子 Agent 执行错了还是汇总 Agent 拼接错了白皮书在讨论多智能体时提到几个挑战组件间通信、任务分配的合理性、系统级的可观测性。评估上的应对办法我常用两条。第一条是分层评估。每个子 Agent 单独跑自己的能力用例保证单个组件的下限再跑端到端用例只看最终结果。两套分数分开看不要混成一个总分。总分好看但子 Agent 分数参差说明路由逻辑在掩盖某些子 Agent 的缺陷换个任务分布就会暴露。第二条是轨迹归属标注。在 trace 里给每个步骤打上执行者标签端到端失败时先看失败步骤归属哪个 Agent再看这个 Agent 在分层评估里的分数。如果它自己的分数很高但端到端里表现差问题多半出在上下文传递——上游给的输入缺了关键信息或者格式不符合下游预期。上下文传递是多智能体系统里最隐蔽的故障源。两个子 Agent 之间的交接内容如果是自然语言信息损耗极大如果用结构化字段又容易因为 schema 演进不同步而丢字段。常见做法是交接内容用「结构化主干 自然语言补充」主干字段有严格的 schema 校验补充部分给下游做背景理解。5. 避坑与排查多智能体落地时最容易翻车的五个地方前面几章讲的都是「应该怎么做」这一章讲「实际上会怎么坏」。下面五条都是我在真实项目里反复见到的按现象、原因、解决三段写方便直接对照排查。5.1 工具层与编排层的三类翻车第一条工具描述写得太简模型反复试探。现象单任务平均步数从 4 涨到 9日志里能看到 Agent 连续用不同参数调用同一个查询工具像是不知道要传什么。原因工具描述只写了一句话参数说明缺失模型只能靠猜测填参数第一次填错拿到空结果就换个参数再试。这类试探在步数上限内会一直持续用户的体感是「卡了很久然后说找不到」。解决把工具描述补成四段式——用途、必填参数含义与格式、返回结构、禁用条件。补完之后先在离线用例上跑一遍看平均步数有没有回落。如果回落不明显说明问题不在描述而在参数设计比如必填参数太多考虑给默认值或者拆成两个工具。第二条记忆无限增长成本和时延同时失控。现象同一个功能上线两周后单任务 token 消耗涨了三倍P95 时延从 3 秒涨到 11 秒但代码没改过。原因长期记忆只写不读、只增不删每轮都全量塞进提示。用户用得越久历史越长提示越大。这种劣化是渐进的监控上不会报警只会慢慢变贵。解决给记忆加三件事——写入时的字段白名单只存对后续任务有用的、检索时的相关性过滤按当前任务召回 top-k不全量塞、过期策略比如画像类记忆 90 天未命中就归档。上线后加一个「单任务提示 token」的监控曲线涨势一旦抬头就能立刻发现。第三条工具重试没有幂等保护产生了重复副作用。现象用户反馈收到了两条一样的短信或者订单被创建了两次。原因编排层对工具失败做了重试但重试的是写操作。第一次调用实际上成功了只是响应超时Agent 以为失败重试一次下游就多了一条记录。这个问题在测试环境几乎不会出现因为测试环境的超时不会真的发生。解决工具注册时给每个工具打上idempotent标记只有标记为真的工具才允许自动重试。写操作要么不重试要么带上幂等键由编排层生成并在重试时复用同一个键让下游做去重。这一条不改迟早出事故。5.2 评估与协作流程的两类翻车第四条离线评估 95 分上线一周跌到 60。现象发布前评估集上表现很好灰度到 20% 流量后任务完成率断崖式下跌但错误日志里没有任何异常。原因评估集是从早期人工构造的样本里来的句式规整、意图明确线上真实输入有错别字、有多意图混杂、有大量「帮我看看那个东西怎么样了」这类指代不明的表达。分布不一致分数就没有可比性。解决评估集必须掺真实样本。我一般要求线上抽检样本占评估集的三成以上并且每月更新一次。另外加一个「分布漂移监控」——统计线上输入的平均长度、工具调用分布和评估集对比偏差超过阈值就提示补样本。这件事没有一次性解决方案只能持续维护。第五条多智能体互相等待任务挂死不报错。现象端到端任务偶发超时trace 里能看到两个 Agent 之间来回交接了十几次每次交接内容都差不多。原因交接没有终止条件。A 把任务交给 BB 觉得信息不全又交回给 A 补充A 补充完再交给 BB 仍然认为不全——循环成立因为没有一方负责判定「信息已经够了」。解决给交接加三样东西。交接次数上限比如同一对 Agent 之间最多 3 次交接时必须携带「已确认信息清单」下游只能要求清单外的信息指定一个最终裁决者超过上限直接由裁决者收口哪怕信息不全也要给出带不确定性的答复。第三点很关键宁可给出「部分信息缺失」的明确答复也不要让用户对着转圈等十分钟。6. Agentic RAG 与协作模式选型把架构图变成可验证的配置白皮书后半段有两个内容密度很高的部分一个是 Agentic RAG一个是车载场景里的多智能体模式。前者讲的是检索增强的演进方向——从「一次检索 一次生成」变成「改写查询、迭代检索、自我批判、必要时换检索源」后者把层级、钻石、对等、协作、响应混合、自适应循环这几种模式摊开配了具体的车载场景。两件事合起来其实回答同一个问题什么时候该加一个 Agent。我的判断标准很土但有效看这个子任务是否需要独立的状态和独立的工具集。需要就拆只是「步骤多一点」就别拆加一步 ReAct 更省事。拆错的代价是多智能体评估的归属难题全部落到你头上。模式结构特征适用场景必须配的终止条件层级一个主控拆任务子 Agent 执行子任务边界清晰、可并行主控汇总轮次上限钻石先分发再汇聚中间有交叉验证需要多视角核对的事实类任务交叉验证通过即收口对等Agent 之间直接协商能力对等、需要谈判的场景协商轮次上限 裁决者协作多个 Agent 共享中间产物内容生产类如文案 校对产物收敛判定响应混合多路结果由混合器加权输出多来源答案需要融合混合器置信度阈值自适应循环根据中间结果动态改变编排任务路径高度不确定全局步数 成本双上限实操上有个技巧值得单独说把每次线上失败的 trace 存下来改造成回归用例放进离线评估集。注意要保留完整的 step 记录而不是只留最终答案因为你要验证的是「这个版本会不会重复同样的错误动作」。我一般会给失败 trace 加三个标签——失败类型工具、规划、幻觉、超时、责任 Agent、是否可自动判定。只把「可自动判定」的那部分放进回归集其余的转人工抽检否则回归集会越滚越大跑一次要两小时。踩过最深的一次坑是某个版本的提示调整让任务完成率涨了四个点团队很高兴地全量了两周后发现单任务成本涨了六成——因为新提示让 Agent 更倾向于「多查一次保险」。从那以后我每次做提示或编排变更都把「任务完成率」和「单任务 token」两条曲线强制放在同一张图上看任何一条恶化超过 15% 都不允许全量。这条习惯救过我不止一次。希望帮到你。本文还有配套的精品资源点击获取