简介谷歌AI Agent白皮书中英文对照版面向具备一定AI与软件开发基础、从事智能体系统设计开发或运维的工程师、技术管理者与研究人员聚焦生成式AI智能体的核心架构、评估方法、智能体运维与多智能体协作落地。内容从模型、工具与交互协调层三大组件切入延伸到能力评估、轨迹与工具使用评估、最终响应评估及人机协同评估并讨论分层、协作、对等、钻石与自适应循环等设计模式结合汽车AI、企业知识管理、代理式检索增强生成、Google Agentspace与NotebookLM Enterprise等场景展开还涉及从智能体到承包商的合同化机制。压缩包仅含1个PDF大小约2.17MB中英文对照便于术语核对与对照阅读。已有1509人学习下载适合用来建立智能体架构、AgentOps与评估的系统框架并对照Vertex AI Eval Service、Agent Builder等平台思路梳理企业级落地方案与复杂任务协作流程。1. 从三天跑通 Demo 到三个月交不了差Agent 项目的真实卡点A 同学的毕设卡在一个很典型的位置用现成框架三天就搭出了能查资料、能调接口的智能体演示效果漂亮但答辩前两周被导师追问“换个问法还能不能行、失败了怎么定位”结果一测就崩——没有评估集、没有轨迹日志、没有指标全靠手动点几下。这不是模型不够强缺的是从概念验证走向生产的那一段工程体系。这份 AI Agent 白皮书中英文对照版Agents Companion2025 年 2 月版正好补的就是这一段AgentOps 运维分层、能力/轨迹/最终响应三层评估、多智能体拓扑与 Agentic RAG以及企业级平台和“智能体到承包商”的范式演进。它适合两类人要交毕设或课设、需要一个完整可讲结构的学生要出一份能交付、能验收方案的工程师。2. 智能体总体架构模型、工具、编排层三件套的职责边界白皮书对智能体的定义很克制一个被工程化构造出来的应用通过感知环境、并借助可用工具采取行动来达成特定目标。这个定义里有两层意思要拆开看——智能体不是“更聪明的模型”而是“模型 工具 编排”的组合体它的能力上限由模型决定但它的可靠性上限由编排和工具设计决定。很多项目翻车不是因为模型不够强而是把三件事的边界搅在一起让模型直接拼 SQL、让编排层去做业务校验、让工具返回一整页未结构化的文本。三件套的分工我在做方案时一般按这个原则切模型只负责“决策”即判断下一步该干什么工具只负责“动作”即执行一个有明确输入输出契约的操作编排层负责“流程”即维护状态、记忆和循环终止条件。任何一个职责越界后面评估就没法拆开归因出问题只能当黑匣子整体重跑。2.1 模型层决策中枢的三种选型与三个判断问题白皮书里“模型”指的是作为核心决策单元的语言模型采用基于指令的推理和逻辑框架具体可以是通用模型、多模态模型也可以是针对特定任务微调过的模型。这句话在方案里对应的是一个选型决策而不是“选最强的那个”。我通常用三个问题收敛第一任务输入是不是只有文本。只要涉及界面截图、车辆状态图、语音指令就必须走多模态纯文本模型再强也没用——汽车场景里“对话式媒体搜索”这类智能体输入天然带封面图和播放列表结构。第二上下文里要塞多少东西。工具返回的长文档、多轮对话历史、检索到的分块都会挤占上下文。上下文预算紧张时宁可把模型调用拆成“摘要 决策”两跳也不要把一堆原始数据硬灌进去否则模型会在长上下文里丢掉指令约束。第三延迟和隐私的边界在哪。白皮书在汽车案例里点得很清楚现代车辆需要“有网和无网都能用”的交互还要在端侧处理和云端处理之间做平衡兼顾安全和体验。这条约束直接影响模型选型——需要离线可用的能力比如车辆手册问答走端侧小模型需要复杂推理的比如行程规划走云端。方案文档里如果不写这条边界评审时一定会被问。提示模型层选型别只写“采用某大模型”要写成“哪类任务走端侧、哪类走云侧、降级时切到哪个”这才是可验收的设计。2.2 工具层扩展、函数、数据存储三类工具的契约设计白皮书把工具分成三类这个分法在方案里特别好用扩展extensions架在 API 和智能体之间的桥让智能体能无缝调用已有 API。函数functions自包含的代码模块完成特定任务跑在本地或自有服务里。数据存储data stores提供对动态、实时更新信息的访问保证回答基于事实而不是模型记忆。三者的差别不只是实现方式而是“谁承担契约责任”。扩展类工具的契约由既有 API 定义方案里要做的是把 OpenAPI 描述翻译成模型能读懂的说明函数类工具的契约完全由自己写写不好就是自找麻烦数据存储类工具的关键不在接口而在检索质量和新鲜度。我见过最常见的翻车是工具描述写得太随意。模型决定调不调工具、怎么填参数靠的全是description和参数 schema——它本质上是提示词的一部分。举个具体写法# 工具定义即提示description 决定调不调schema 决定填得对不对 QUERY_FORECAST_TOOL { name: query_forecast, description: ( 查询指定城市未来若干天的天气预报。 仅当用户明确给出城市名时才调用 天数未给出时默认 3 天超过 7 天一律截断为 7 天。 若用户只说了明天这类相对时间请先换算成具体天数再调用。 ), parameters: { type: object, properties: { city: { type: string, description: 标准城市名不要带市以外的行政区后缀 }, days: { type: integer, minimum: 1, maximum: 7, description: 预报天数缺省 3 } }, required: [city] } }这段定义里description承担了三个职责限定调用时机明确给出城市名才调、给出缺省值策略未给天数默认 3 天、规定换算规则相对时间先换算。参数 schema 用minimum/maximum做硬约束比在提示里写“不要超过 7 天”可靠得多因为多数模型调用层会把 schema 直接作为结构化输出约束。工程上还有两个细节值得写进方案一是工具返回值的结构要稳定别今天返回{temp: 25}、明天返回{temperature: 25 度}模型解析会随机出错二是工具要区分“业务失败”和“系统失败”前者比如城市不存在应该作为正常 observation 回填给模型让它自我修正后者超时、鉴权失败应该直接触发重试或降级不要让模型去猜。2.3 编排层ReAct、CoT、ToT 与记忆状态的落地写法编排层是一个循环过程决定智能体如何吸收信息、进行内部推理、并用推理结果指导下一步动作。它负责维护记忆、状态、推理和规划通常用提示工程框架来引导推理路径。白皮书点名了三类推理技术ReAct、思维链CoT、思维树ToT。选型上我的经验是绝大多数业务智能体用 ReAct 就够了它的“思考—行动—观察”循环天然适合工具调用场景轨迹也最好记录、最好评估CoT 适合不需要外部工具、但需要多步推理的任务比如方案比对ToT 适合需要探索多条路径再回溯择优的任务但成本高、轨迹长评估起来很痛苦不建议在毕设规模的项目里上。编排循环的最小实现大致是这样MAX_STEPS 8 # 硬性步数上限防死循环超过即降级转人工 def run_agent(goal, tools, model, memory, tracer): state {goal: goal, trajectory: []} for step in range(MAX_STEPS): # 1) 组装上下文目标 历史轨迹 工具清单 prompt build_prompt(goalstate[goal], trajectorystate[trajectory], toolstools) # 2) 模型决策三分类输出 —— final / tool_call / ask_user decision model.invoke(prompt, response_schemaDECISION_SCHEMA) if decision.kind final: tracer.emit(agent.finish, stepsstep, answerdecision.content) return decision.content, state if decision.kind ask_user: # 参数不足时主动追问而不是瞎猜一个参数去调工具 return decision.question, state # 3) 执行工具把结果作为 observation 回填形成闭环 obs execute_tool(decision.name, decision.args, tools) record {thought: decision.thought, action: decision.name, args: decision.args, observation: obs} state[trajectory].append(record) memory.write(record) # 落盘供下一轮与事后评估复用 tracer.emit(agent.step, **record) tracer.emit(agent.abort, reasonmax_steps) return 任务超出步数上限已转人工处理, state这段代码里几个参数值得单独说明。MAX_STEPS 8是安全阀业务型智能体的合理区间通常在 510 步超过说明任务拆得不够细或者工具设计有问题与其让模型无限试错不如直接降级。DECISION_SCHEMA把模型输出约束成三分类这是让轨迹可评估的前提——如果模型自由输出文本你事后根本没法用程序判断它“想干什么”。memory.write和tracer.emit双写不是冗余前者服务于下一轮上下文后者服务于离线评估和线上监控两个消费方需要的字段不一样。ask_user这个分支最容易被省略。很多实现里模型拿不到参数时会自己编一个比如把“帮我看看天气”里的城市默认成某个大城市表面上有响应实际是错误答案。把“追问”作为一等公民写进循环是提升最终响应正确率成本最低的一招。注意编排层不要用递归实现循环一旦工具之间互相调用出错递归栈会直接打穿日志也很难看。用显式 for 循环加步数上限是所有排查手段里最省事的一种。3. 多智能体架构分层、钻石、对等、协作四种拓扑怎么选单智能体撑不住的时候第一反应往往是“加一个智能体”。但白皮书对多智能体的态度很务实它既讲设计模式和商业价值也专门用一节讲挑战。多智能体不是免费的——每多一个节点就多一份上下文传递损耗、多一处失败点、多一层评估复杂度。方案里如果只写“采用多智能体架构提升能力”评审一句“为什么不拆成两个函数”就能问住。判断标准其实很简单任务能不能按“领域知识”切开而不是按“处理步骤”切开。能按领域切导航、媒体、消息、车辆手册每个子域有自己的工具集和话术多智能体收益明显只是步骤多先查再算再写那是一个智能体加多个工具的事硬拆成多个智能体纯属给自己找麻烦。3.1 六种协作模式与它们的失败边界白皮书在汽车案例里给出了几种典型的协作模式我把它们和适用场景、失败边界整理成一张对照表方案文档里直接放这张表比写三段文字更清楚模式拓扑结构适用场景主要风险评估重点分层Hierarchical编排者向下分派子智能体不互相通信领域边界清晰、子任务可独立完成编排者误判意图把任务分给错的子智能体分派准确率钻石Diamond并行拆解分头执行最后汇总需要多视角产出如方案对比、多源调研汇总节点丢信息或强行折中汇总保真度对等Peer-to-Peer智能体之间直接交接形成流水线连续型任务上游产出即下游输入交接处上下文丢失责任不清交接完整率协作Collaborative多方共享上下文共同推进开放式探索、复杂问题求解上下文膨胀、反复确认、收敛慢收敛步数响应混合Response Mixer多个候选结果由一个节点融合多个子智能体都能出答案需要择优混合节点变成新的单点故障融合后的一致性自适应循环Adaptive Loop根据中间结果动态决定下一轮路径结果质量不确定需要多轮逼近循环不收敛、成本不可控轮次上限与收益曲线分层模式的好处是故障隔离——导航智能体挂了不影响媒体播放这在车机上不是可选项而是硬要求。钻石模式的关键在汇总节点我一般会把汇总节点的输入格式固定成结构化字段结论、证据、置信度而不是让它读三段自由文本再总结否则信息在汇总这一步被稀释前面并行做得再漂亮也没用。自适应循环是最容易失控的一种。方案里必须写死两件事轮次上限和“下一轮收益低于阈值就停”的判据。否则模型会觉得“还能再改改”一路循环到超时。3.2 Agentic RAG把检索从固定管道改成智能体的一次决策常规 RAG 的流程是固定的问题进来改写查询向量检索 top-k拼进提示生成答案。这条管道在单跳事实型问答上很好用但一旦问题需要多跳推理、需要换数据源、或者根本不需要检索比如用户在闲聊固定管道就开始拖后腿——检索回来的无关分块反而会污染答案这就是很多项目“接了 RAG 之后效果更差”的真实原因。Agentic RAG 的改动点在于把“检索”从流程的一个固定环节变成智能体可以调用的一个工具。什么时候检索、检索几次、用哪个查询、换不换数据源、检索结果够不够支撑回答全部由智能体决策。白皮书里“更好的搜索带来更好的 RAG”这个说法落到的就是这一层。实现上最关键的不是检索器而是“检索充分性判断”这个环节def agentic_retrieve(question, retriever, judge, max_rounds3): 把检索做成可决策的循环而不是一次性管道 evidence, query [], question for r in range(max_rounds): hits retriever.search(query, top_k5) evidence.extend(hits) # 充分性判断答案能否只依据现有证据得出 verdict judge.invoke({ question: question, evidence: evidence, schema: {enough: bool, missing: str, next_query: str} }) if verdict[enough]: return evidence, r 1 # 不够则改写查询再检索改写依据是缺什么不是随机换词 query verdict[next_query] or query if not verdict[missing]: break # 连缺什么都说不出来继续检索也是浪费 return evidence, max_roundsmax_rounds3是成本阀实测超过 3 轮还补不齐证据的通常是知识库本身就没有这块内容再检索也是空转。judge的输出要求里missing字段比enough更重要——它把“不够”这个模糊判断变成了“缺哪一类信息”的具体指令下一轮查询改写才有方向。如果judge连缺什么都说不出来说明问题本身超出了知识库覆盖范围这时候正确动作是回退到通用知识或直接告知用户而不是硬检索。提示评估 Agentic RAG 时别只看最终答案准确率要单独统计“平均检索轮次”和“充分性判断的准确率”前者决定成本后者决定这套机制到底有没有在工作。3.3 汽车 AI 案例拆解五个专用智能体加一个响应混合器白皮书用汽车场景做了完整案例这个案例的价值不在于汽车本身而在于它演示了一套“按领域切分”的方法论任何行业都能套。案例里的专用智能体包括对话式导航智能体、对话式媒体搜索智能体、消息撰写智能体、车辆手册智能体、通用知识智能体。这五个的切分逻辑很讲究——前四个都有明确的领域边界和专属工具地图与路线、媒体库、通讯录、车辆手册知识库第五个是兜底接住所有不属于前四类的问题。这个结构里有三个设计点值得抄第一兜底智能体是必需品不是补丁。没有它用户问“这车保修多久”以外的任何闲聊系统要么硬塞给某个专用智能体导致答非所问要么直接报错。兜底节点的存在让“我不知道”变成一个体面的答案。第二响应混合器解决的是“多个智能体都能回答”的冲突。比如用户说“放点轻松的音乐路上别堵”媒体智能体和导航智能体都有事可做。混合器不是简单拼接而是按优先级和上下文决定先响应哪个、怎么串成一句自然的话。第三端云边界写在架构层而不是实现层。需要离线可用的能力车辆手册、基础控制落在端侧需要实时数据的路况、在线搜索走云侧中间有明确的降级路径。方案里如果不画这条线实现阶段一定会纠结“这个功能断网了怎么办”而这个问题在车机上是要命的。4. AgentOps 落地六层运维栈与三层指标埋点到了交付阶段最容易被低估的是运维。白皮书花了很大篇幅讲 AgentOps原因很直白质量和可靠性是部署到生产环境时被提及最多的顾虑。这套运维体系不是凭空造出来的它是在既有的 DevOps、MLOps 之上长出来的理解这层继承关系方案里的运维章节才不会写成空话。4.1 从 DevOps 到 AgentOps六层运维栈的包含关系白皮书把几个 Ops 术语的边界讲得很清楚我按“关注对象”重新整理了一遍层级关注对象特有的运维资产复用的下层能力DevOps确定性软件代码版本、CI/CD 流水线——MLOps机器学习模型输出非确定性训练数据版本、模型注册表、离线评估全部 DevOpsFMOps预训练或微调的基础模型基座版本、微调数据集、适配器权重全部 MLOpsPromptOps提示提示存储、血缘、元数据含评估分、集中模板注册表、提示优化器全部上层RAGOps检索增强链路离线数据准备清洗、分块、向量化、相似度检索、重排、生成侧提示增强与事实对齐全部上层AgentOps智能体内外部工具管理、大脑提示目标/画像/指令、编排、记忆、任务分解全部上层这张表的用法不是背概念而是判断“我这个项目的运维缺口在哪一层”。很多毕设项目的实际情况是DevOps 层面有 Git 就算过关MLOps 层面完全没有AgentOps 层面的工具管理和记忆管理更是空白。方案里如果把这六层铺开写评审一眼就能看出你理解到了哪一层。白皮书特别强调了一句容易被忽略的话新实践不替代旧实践。工具调用最终还是要调用普通 API所以身份认证、密钥管理、安全、隐私、异常处理、限流、配额、可扩展性这些老问题一个都不会消失反而因为模型的不确定性变得更难处理——同一个 API非智能体软件只会按固定逻辑调智能体可能用一百种参数去调它。注意AgentOps 章节里如果没有“限流与配额”这一条基本可以判定方案没落地过。工具被模型高频误调用打爆下游服务是真实项目里最常见的生产事故之一。4.2 AgentOps 多出来的四件事工具管理、大脑提示、记忆、任务分解在白皮书列出的 AgentOps 特有组件里我挑四个在方案里必须写清楚的工具管理、大脑提示、记忆、任务分解。工具管理不只是“有哪些工具”而是工具的注册、版本、权限和灰度。工具 schema 改一个字段名所有依赖它的智能体行为都会变所以工具必须有版本号且新旧版本要能并存一段时间。方案里我一般会要求工具清单落成配置文件# agent_manifest.yaml —— 智能体的可交付清单版本、工具、提示、记忆策略全在这里 agent: name: trip_assistant version: 1.3.0 # 语义化版本行为变更必须升 minor 以上 brain: goal: 帮用户完成出行相关的查询与安排 profile: 面向普通用户回答简洁不主动推荐付费服务 instructions: | 1. 参数不全时先追问不要猜测 2. 涉及金额、时间的信息必须来自工具返回不得自行推断 3. 无法完成时明确说明原因并给出可行的替代方案 tools: - name: query_forecast version: 2.1.0 timeout_ms: 3000 retry: 1 fallback: 天气服务暂不可用请稍后再试 - name: search_poi version: 1.0.4 timeout_ms: 5000 retry: 0 memory: short_term: 最近 8 轮对话 long_term: 用户偏好写入前需确认 ttl_days: 30 limits: max_steps: 8 max_tool_calls: 12 max_tokens_per_turn: 8000这份清单的价值在于它是可 diff 的。行为发生变化时比如把max_steps从 8 调到 12版本的 diff 会直接暴露出来评估结果一变就能定位到是哪次改动导致的。没有这份清单智能体的行为漂移就是玄学。记忆这块方案里最容易写虚。至少要区分短期记忆对话轮次窗口和长期记忆用户偏好、历史结论并明确写入策略——长期记忆写入前是否需要确认是很关键的一条。把模型的推测写进长期记忆后面所有回答都会被污染这种坑一旦踩了清理成本极高。任务分解则是把“一个大目标”拆成可独立评估的子任务。它不只是为了提升效果更是为了失败可归因一个 20 步的失败轨迹如果没做任务分解你只能看到“最后失败了”做了分解你能定位到“第三步的子任务就已经错了”。4.3 指标分层北极星、任务级、步骤级三层埋点白皮书写得很直接业务指标收入、用户参与度可能超出智能体本身的范围但它们应该是智能体的北极星指标。这句话解决了一个常见困惑——到底该拿什么衡量智能体好不好。我在方案里一般铺三层指标每层解决不同的问题层级指标示例回答的问题采集位置北极星业务任务完成率、人工接管率、单任务成本、用户留存这套系统值不值得继续投业务系统任务级任务成功率、平均步数、工具调用成功率、P95 延迟这次版本改动是变好还是变差编排层步骤级工具入参合法率、工具返回码分布、重试次数、单步耗时失败具体发生在哪一步工具层三层的关系是逐级下钻北极星指标掉了看任务级定位是哪个环节退化任务级里工具成功率掉了看步骤级定位是哪个工具、哪类参数出错。埋点不要靠在业务代码里到处写日志用一个装饰器包住工具调用最省事import time, functools def instrument(tool_name, tracer): 工具调用的统一埋点耗时、返回码、入参合法性、重试次数 def deco(fn): functools.wraps(fn) def wrapper(*args, **kwargs): start time.time() status ok try: result fn(*args, **kwargs) return result except ValueError as e: # 业务失败参数不合法属于模型的问题要单独统计 status invalid_args raise except TimeoutError: # 系统失败下游问题触发重试或降级 status timeout raise finally: tracer.emit(tool.call, { tool: tool_name, latency_ms: int((time.time() - start) * 1000), status: status, args_keys: sorted(kwargs.keys()), # 只记字段名不记值避免敏感信息落库 }) return wrapper return deco这里把业务失败invalid_args和系统失败timeout分开统计是这套埋点最重要的设计。两者混在一起看你会得出“工具成功率 92%”这种没用的数字分开看才知道8% 的失败里有多少是模型参数填错该改提示和 schema有多少是下游不稳该加超时和熔断。args_keys只记字段名不记值是隐私上的底线要求方案里最好显式写一句。5. 常见排查智能体上线后最容易翻车的五个点前面讲的都是“应该怎么设计”这一章讲“实际会怎么坏”。这五条基本覆盖了我见过的大部分线上问题每条按现象、原因、解决三段写方案文档里可以直接作为“风险与应对”章节的素材。5.1 工具调用成功率很高但最终答案错得离谱现象监控面板上工具调用成功率 95% 以上平均步数也正常但用户反馈答案不对抽检发现错误率明显高于预期。原因工具“调通了”不等于“调对了”。模型可能传了一个格式合法但语义错误的参数——比如把“明天”解析成days1是对的但把“下周三”也解析成days1。这类错误在工具层看是成功的下游返回了 200只有到最终答案才会暴露。另一种情况是工具返回的数据结构里字段太多模型只读了第一个字段就开始编。解决在工具返回值和模型之间加一层“结果摘要”把关键字段显式提取出来再回填而不是把原始 JSON 整个塞回去。同时在评估集里专门设计一类“相对时间/相对指代”的用例把这类语义解析错误单独统计出来。参数校验也不能只靠 schema业务层要加一道语义校验比如days和查询词里的时间表述是否一致。5.2 轨迹看起来对答案不对答案看起来对轨迹不对现象人工抽检时发现两种相反的情况——有的轨迹每一步都合理最后答案却错了有的答案碰巧对了但轨迹里有一次明显的工具误调用。原因这两种情况说明评估维度混在一起了。轨迹对但答案错通常出在最后一步的“汇总生成”模型在整合证据时引入了自己的先验知识答案对但轨迹错是典型的“蒙对”说明评估只看了结果没看过程这种系统换个问法就会崩。解决把轨迹评估和最终响应评估拆成两个独立指标都进版本对比。轨迹评估看的是工具选择是否合理、参数是否正确、有没有多余步骤最终响应评估看的是答案是否忠于证据、是否完整回答了问题。两个指标任何一个下降都要拦版本不能只看综合分。提示白皮书把评估拆成能力评估、轨迹与工具使用评估、最终响应评估、人机协同评估几块这个拆法可以直接搬到方案里当评估框架比自创一套更容易讲清楚。5.3 多智能体互相踢皮球或者反复确认现象任务在多个智能体之间来回转交日志里能看到同一个子任务被转手三四次最后超时或者两个智能体反复向对方确认“你确定吗”迟迟不产出结果。原因分派逻辑没有唯一性。分层模式里如果编排者的分派规则写得模糊“根据用户意图选择合适的子智能体”遇到跨领域问题就会来回试。协作模式里如果没有明确的收敛判据各方都会觉得“再确认一下更稳妥”。解决给分派加一个显式的“归属判定”步骤要求编排者输出一个带置信度的归属结论低于阈值直接走兜底智能体不允许“试试看”。协作模式必须设轮次上限和收敛判据比如两轮之内结论不变就停止。转交时传递结构化上下文已完成什么、缺什么、下一步建议而不是把整段对话历史甩过去——后者是上下文膨胀的主要来源。5.4 接了 RAG 之后效果反而变差现象知识库上线前通用回答虽然笼统但不出错接上检索之后答案开始出现“引用了不相关文档里的数字”这类问题准确率反而下降。原因固定管道式 RAG 对“要不要检索”没有判断权闲聊类问题也会触发检索召回的分块被强行拼进提示模型为了“用上”这些上下文会硬凑答案。另一个原因是分块策略和问题类型不匹配长文档按固定长度切切断了论证链条检索回来的片段语义不完整。解决把检索改成智能体可调用的工具加一道充分性判断见 3.2。“不需要检索”要成为一个合法决策而不是异常路径。分块策略按文档结构切而不是按字数切同时保留父子块关系检索命中子块时把父块一并提供给模型。评估时单独统计“检索命中率”和“答案对检索内容的忠实度”两个指标分开看。5.5 评估集是自己造的越评越好上线就崩现象离线评估分数一路走高从 70 分刷到 92 分上线后用户反馈问题依旧。原因评估集和提示调优用的是同一批数据模型或者调提示的人已经把答案“背”下来了。更隐蔽的一种是评估集的分布太窄全是标准问法没有口语化、错别字、多意图混合的真实输入。解决评估集至少分三份——调优用的、验证用的、留出最后验收的三份不重叠。留出集在交付前只看一次看之前不许改提示。评估集的构造要覆盖真实分布的尾部一句话里混两个意图、参数缺失、指代不明、领域外问题。这部分工作枯燥但没有替代方案我见过太多项目在这上面栽跟头。6. 验收与答辩把白皮书变成一张可交付的验收清单到了交付环节最有效的做法不是再讲一遍架构而是给出一张能被逐项打勾的验收清单。答辩现场评委问的往往是“你怎么证明它行”而不是“它用了什么技术”。我一般会准备这样一张表每一行都对应一个可以当场演示或出示的证据验收项证据形式通过标准架构完整性架构图与模块清单模型、工具、编排三层职责无重叠工具清单带版本号工具契约工具 schema 文件每个工具有描述、参数约束、超时与降级策略轨迹可追溯一次完整任务的轨迹日志能看到每步的思考、动作、参数、观察结果三层指标监控看板截图北极星、任务级、步骤级指标均有数据评估体系评估报告能力、轨迹、最终响应三类指标分开呈现含留出集结果失败处理现场演示参数缺失时追问、工具超时时降级、超步数时转人工多智能体若有拓扑图与转交日志分派有唯一性判定转交带结构化上下文这张表的使用方式有个技巧不要等答辩时一次性展示而是在讲架构的时候就顺带说“这一块对应验收清单第几项”让评委形成“每讲一个设计都有对应证据”的印象。演示环节优先演失败路径——参数缺失、工具超时、领域外问题——这些比成功路径更能证明系统是工程化做出来的。答辩问答里最高频的三个问题提前准备好答案为什么不直接用一个更强的模型答能力上限与可靠性上限是两件事编排和工具决定后者多智能体的必要性在哪答按领域切分而非按步骤切分并给出故障隔离的具体收益评估分数怎么保证不是自嗨答三份不重叠数据集留出集只看一次。我早期做这类方案时吃过的最大一次亏是把所有精力都放在“让它跑通”上验收材料是最后两天拼出来的结果评委问“你怎么知道它稳定”时我拿不出任何一条轨迹日志。从那以后我每次起项目第一天就把埋点和评估集骨架搭起来哪怕功能还是空的——顺序反过来后面全是补丁。希望帮到你。本文还有配套的精品资源点击获取