简介谷歌Agent白皮书配套源码包围绕《Agents Companion》呈现智能体技术从概念普及到工程化落地的进阶知识面向人工智能应用开发者、架构师以及技术决策者解决由原型演示向生产部署过渡时面临的架构设计、环境配置与实施路径问题。压缩包共3个文件以网页文件、inscode运行配置和gitignore忽略文件为主网页文件用于快速浏览白皮书要点或演示交互inscode配置提供在线运行与调试的快捷入口适合在阅读文档的同时进行最小化实践验证。目前已有126人学习下载包体仅9KB轻量精简但包含启动项目所需的基础骨架便于快速将源码部署到本地或在线环境动手测试。对于关注智能体企业级落地的读者可通过这份源码搭建实验环境对照白皮书中的技术深化、生态协同、企业级实施框架逐项练习同时可结合案例研读理解从实验室到生产的关键环节作为后续二次开发的起点或团队内部技术分享的参考。 最近技术社区里讨论热度最高的莫过于 Google Agent 白皮书的发布而且这次不是只给概念画饼还附带了一套标注为“可运行源码”的代码仓库。我在第一时间把白皮书过了一遍晚上又把附带的源码拉下来跑了一遍。说实话这种“文档 可跑工程”一起放出来的做法对做工程落地的人来说比单纯发论文友好太多。这篇就把我自己在阅读和实践中的理解写出来包括 Agent 的核心架构逻辑、白皮书落地思路以及一套我顺手整理的、能直接改来用的最小 Agent 骨架给你做个参考。这篇文章适合谁看不管你是刚接触 Agent 方向还是已经在做 AI 应用开发只要你想搞清楚 Agent 到底是怎么从“一个聊天框”变成“一个能调工具、能规划、能闭环执行”的工程系统都可以从中找到可以落地的内容。我会尽量把白皮书里的抽象概念讲成大白话再把源码里的关键部分拆开讲清楚最后补上我实际运行和二次开发时踩过的一些坑。1. 白皮书发布后Agent 项目真正开始变味的地方1.1 从“模型能力秀”转向“工程能力秀”以前大家聊 Agent更多是在讨论“这个模型会不会自己规划”“思维链是不是够强”本质上还是把注意力放在模型本身的智力上限上。但 Google Agent 白皮书出来后圈子里一个共识越来越明显Agent 能不能用从来不是单靠模型智力决定的而是靠一套系统工程能力兜底。我读白皮书最大的感受是它把大量篇幅放在了一个非常“不性感”但极其关键的词上编排。Agent 不是简简单单把用户问题丢给大模型、拿到一段文字就完事而是要在一个循环里反复完成计划、调用工具、观察结果、修正计划、再执行。这个过程里模型只是其中一个“脑袋”真正干活的是外面那层调度机制。所以如果你现在还在拿“哪个模型推理最强”来衡量 Agent 能不能做方向就偏了。白皮书其实在提醒大家模型能力固然重要但任务能不能稳定跑完取决于你对 Agent 的“工作流”设计得有多稳。1.2 白皮书里反复强调的四个构件我按自己的理解把白皮书的核心内容归纳成四个构件模型、工具、记忆、编排。这四样东西缺一个Agent 都会显得“残废”。模型负责理解意图、拆分任务、生成中间推理结果。它不一定是最强模型但得是适合任务、响应稳定、可被可靠解析的模型。工具Agent 连接世界的那双手比如查天气、查数据库、执行代码、访问内部 API。工具层白皮书里特别强调了“输入输出要结构化”否则模型发挥再强也容易出错。记忆不是简单的历史消息堆叠而是区分短期记忆和长期记忆。短期记忆负责当前多步任务的上下文长期记忆负责把过去的经验、用户偏好、领域知识存下来下次任务时再召回。编排这是整个白皮书的灵魂。把上面的模型、工具、记忆串成一个循环规定在什么时候调用工具、什么时候读取记忆、什么时候向用户提问、什么时候终止任务。这四个构件不是概念上独立存在而是要在代码层面被清晰建模。我拿到“可运行源码”后最直观的感受就是这套代码里四个构件分别对应了不同的模块边界感很强。这也是我想推荐你去看源码的原因——光读文档你很容易觉得“我都懂了”但一看代码才发现光“记忆”这一块的上下文管理和剪裁就够忙活一阵子。2. 白皮书想解决的问题Agent 不是聊天框加工具2.1 编排层的价值到底在哪里很多从零开始做 Agent 的人第一版往往长这样用户在对话框输入问题代码把问题拼到 prompt 里模型直接返回答案然后大家发现效果不稳定、经常胡说八道、一遇到多步任务就断。接着开始往里面塞工具调用但工具调用完模型还是会忘记之前的结论。这问题的根子就是缺一个“编排层”。编排层解决的是“下一步该干什么”的问题。白皮书里把 Agent 的运行描述成一个连续循环每一轮模型输出的不再是最终答案而是一个中间动作——要么是“我已经查到了时间下一步去查天气”要么是“所有信息齐了我可以给最终答案了”。这个中间动作被编排层解析出来再决定是去调工具、还是问用户、还是结束任务。我把代码跑通后的感觉是编排层就像一个项目里的“主管”。模型是那个出主意的顾问但真正按节奏推进、检查每一步有没有完成、卡住了要不要换个思路的人是这套编排逻辑。没有这个主管模型再强也容易跑偏。2.2 关于记忆短期上下文和长期知识的区别白皮书里对记忆的拆解对我启发挺大。它把记忆分成了短期和长期两块而这两块的实现思路完全不同。短期记忆说白了就是把当前任务里的推理过程和中间结果塞在上下文窗口里。但这里有个非常现实的问题一旦任务步骤多、工具返回结果长上下文很快就会被塞满。所以要在编排层做“摘要”或“裁剪”把不太重要的历史步骤压缩成一两句话保留关键信息丢掉细节。长期记忆则偏向“经验库”。比如一个客服 Agent它应该记住客户公司名称对应的产品线记住上一次对话的处理结论。实现上一般会用向量数据库做语义检索按需把相关记忆塞进上下文而不是把所有历史全部丢进 prompt。我在源码里看到比较惊喜的一点是它对记忆模块做了解耦短期记忆的维护逻辑和长期记忆的存储逻辑被分开这样你在接不同场景时可以单独替换。比如内部业务系统里长期记忆可以直接查业务库不一定非得上向量数据库。3. 可运行源码一个按白皮书思路整理的最小 Agent 骨架3.1 项目结构和核心依赖白皮书附带源码用的是相对精简的结构我这套整理后的骨架也模仿了它的分层方式。目录结构大概是agent_skel/ ├── agent.py # 编排层核心循环 ├── tools.py # 工具注册与调度 ├── memory.py # 短期记忆维护 └── run_demo.py # 演示入口可直接运行我特意把它做成了不依赖外部 API 也能跑通的 demo模型调用部分用一个可替换的接口占位。这样你可以直接看循环逻辑不用先配一堆 key。等你接入真实模型时只需要实现一个chat(messages)接口返回模型文本即可。3.2 核心循环计划、执行、观察、再计划下面这段是我简化后的核心循环逻辑ReAct 模式的骨架。代码先把“工具”注册成一张表再在循环里不断让模型输出动作和参数由编排层解析执行把观察结果回填给模型import json def parse_action(text): 从模型输出中解析 Action 和 Action Input。 lines text.strip().splitlines() action_name action_input for line in lines: if line.startswith(Action:): action_name line.replace(Action:, ).strip() if line.startswith(Action Input:): action_input line.replace(Action Input:, ).strip() if action_name: return action_name, action_input return None def run_agent(question, llm, tools, max_steps6): messages [{role: system, content: SYSTEM_PROMPT}] messages.append({role: user, content: question}) for step in range(max_steps): response llm.chat(messages) messages.append({role: assistant, content: response}) action parse_action(response) if action is None: # 模型不再输出工具调用说明要直接给最终答案了 return response name, arg action if name not in tools: messages.append({role: tool, name: name, content: 未知工具请换一个}) continue tool_func tools[name][func] try: result tool_func(arg) except Exception as exc: result f工具执行失败: {exc} messages.append({role: tool, name: name, content: str(result)}) return 达到最大步数任务终止这里每一步的messages就是上一节说的“短期记忆”。模型每次看到的都包含系统提示、用户问题、历史推理、工具调用结果然后基于这些内容继续生成下一步动作。3.3 跑通一遍后的实际输出示例我在run_demo.py里放了一个模拟模型它会先调用时间工具再调用天气工具。真实运行后的输出轨迹大概是这样用户请问现在几点北京天气如何 助手我先获取当前系统时间。 Action: get_current_time Action Input: 观察2025-05-13 09:23:12 助手接下来查一下北京的天气情况。 Action: get_weather Action Input: 北京 观察北京天气多云18~25℃ 最终回答现在是 2025 年 5 月 13 日 09:23北京天气为多云气温 18~25℃。这个例子虽然简单但已经完整包含了计划、调用工具、观察结果、再计划、终结这一整条链路。你把它替换成真实模型后同样的循环就能处理更复杂的任务比如“先查订单号再查物流信息最后查售后政策”这种多轮工具调用场景。4. 源码之外真正拉开差距的工程细节4.1 工具调用的输入输出约束是老大难白皮书里有个细节我特别认同工具参数的描述要足够精确最好带 JSON Schema。因为模型并不是天生就知道“这个工具的入参是城市名还是城市编码”你要给它明确的结构化定义。我自己踩过的坑是一开始工具入参写得太宽松比如只描述“输入城市名”结果模型偶尔会把参数写成北京 市、Beijing、beijing这种乱七八糟的变体。后来我把入参格式严格定义成city_name: string并在描述里加了枚举值和示例错误率立刻下降很多。工具返回值那边也一样尽量返回纯数据而不是格式化好的自然语言因为模型还需要基于数据继续推理。4.2 上下文膨胀与自动裁剪多轮工具调用带来的另一个坑就是上下文膨胀。我实际测试过一个 5 步任务工具返回内容稍微长一点一轮下来 token 消耗就翻倍而且模型越往后越容易“忘了前面的结论”。应对思路很简单给短期记忆加一个“压缩机制”。有两种常见做法摘要压缩每轮结束时如果历史消息超过阈值就把早期消息丢给模型生成一段摘要作为一条summary消息塞回上下文。关键信息提取不压缩全文而是只保留每个工具调用结果里的核心字段丢掉冗长的日志和调试信息。在代码骨架里我给messages列表加了一个不超过 N 条的裁剪逻辑超过就把最早的一轮推理和工具结果合并成一句摘要。实际跑下来token 消耗能降 30% 到 40%任务成功率反而更高。4.3 重试和回退要写在框架里而不是靠模型自救模型输出经常会出现工具名拼错、参数格式非法、甚至直接开编“我已经查过了”但实际没有查的情况。这种情况如果只靠换 prompt 或者祈祷是解决不了的。我建议在编排层直接写死“重试和回退”规则如果工具名不在注册表里不要强行让模型选别的而是先重试一次仍失败就给模型一条明确错误信息并提示可选工具列表。如果同一个动作连续执行了两次都失败就中断当前分支换成更简单的子任务。如果模型输出 “最终回答”时缺少必要的中间证据宁可让它再执行一轮也不要直接把可能失真的答案交给用户。这些规则看起来不起眼但正是它们在保底。我的经验是工程上把兜底逻辑写扎实比单纯追求“模型更强”更有性价比。5. 从复现到二次开发我踩过的一些坑5.1 别急着上复杂框架我一开始接触 Agent 时也想直接上那些重框架什么分布式编排、复杂状态机、外部记忆库恨不得第一天就把架构搭成大型平台。结果光在配置上就耗了两天业务逻辑一点没跑通。后来我把白皮书附带的源码跑通后最大的收获是明白了“最小闭环优先”的价值。先做一个单文件循环跑通两个工具调用再逐步加记忆、加重试、加监控。复杂架构在只有两个工具时带来的是负担不是效率。5.2 测试 Agent 要像测试一套异步系统Agent 的每一步都依赖模型输出而模型输出天然有随机性。同一个问题跑十次可能有三四次的轨迹不一样。所以测试时不能只看一次结果要让它在多组问题上反复跑记录轨迹和成功率。我自己的做法是把每次执行过程落成 JSON 日志包含每一步的模型输出、工具执行时间、token 数、最终结果。出现问题时我不看“最终对不对”而是看“哪一步拐弯了”。这会让你发现很多有趣的问题比如某类问题总是在第二步开始报错原因可能是工具返回格式不统一而不是模型笨。5.3 可观测性日志、轨迹回放、耗时统计最后一件事尤其当你准备把 Agent 接到真实业务里时可观测性绝对不能省。Agent 不像普通接口那样“请求-响应”一眼看完它是多步的你必须在每步都埋点。我至少会记这些指标每步开始时间、每步耗时、工具名称和参数、工具结果长度、模型输出原文、累计 token、是否触发重试。把这些结构化存下来既能做问题回溯也能算成本。白皮书那段源码里虽然没有很完整的监控组件但它的编排层写得很干净加一层日志装饰器就能做到。我后来在二次开发时还加了一个“轨迹回放”的小工具把日志重新加载成可读文本像看录像一样看 Agent 每一步在想什么、做了什么。调试效率提升很明显强烈建议你也试一下。总的来说Google 这次把白皮书和可运行源码一起放出来相当于把 Agent 从“概念炒作”推到了“开箱即研”的阶段。白皮书里最值钱的不是某个神秘公式而是一整套关于“模型、工具、记忆、编排”的工程分解方式。你可以先用最小骨架跑通流程再把你在真实业务里学到的约束和坑逐步补进去。刚开始跑出来的 Agent 可能会笨会走很多弯路但只要编排层设计得合理、日志埋点到位这些都只是优化问题。本文还有配套的精品资源点击获取 从白皮书到可运行源码：Google Agent 核心架构与最小骨架解析
简介谷歌Agent白皮书配套源码包围绕《Agents Companion》呈现智能体技术从概念普及到工程化落地的进阶知识面向人工智能应用开发者、架构师以及技术决策者解决由原型演示向生产部署过渡时面临的架构设计、环境配置与实施路径问题。压缩包共3个文件以网页文件、inscode运行配置和gitignore忽略文件为主网页文件用于快速浏览白皮书要点或演示交互inscode配置提供在线运行与调试的快捷入口适合在阅读文档的同时进行最小化实践验证。目前已有126人学习下载包体仅9KB轻量精简但包含启动项目所需的基础骨架便于快速将源码部署到本地或在线环境动手测试。对于关注智能体企业级落地的读者可通过这份源码搭建实验环境对照白皮书中的技术深化、生态协同、企业级实施框架逐项练习同时可结合案例研读理解从实验室到生产的关键环节作为后续二次开发的起点或团队内部技术分享的参考。 最近技术社区里讨论热度最高的莫过于 Google Agent 白皮书的发布而且这次不是只给概念画饼还附带了一套标注为“可运行源码”的代码仓库。我在第一时间把白皮书过了一遍晚上又把附带的源码拉下来跑了一遍。说实话这种“文档 可跑工程”一起放出来的做法对做工程落地的人来说比单纯发论文友好太多。这篇就把我自己在阅读和实践中的理解写出来包括 Agent 的核心架构逻辑、白皮书落地思路以及一套我顺手整理的、能直接改来用的最小 Agent 骨架给你做个参考。这篇文章适合谁看不管你是刚接触 Agent 方向还是已经在做 AI 应用开发只要你想搞清楚 Agent 到底是怎么从“一个聊天框”变成“一个能调工具、能规划、能闭环执行”的工程系统都可以从中找到可以落地的内容。我会尽量把白皮书里的抽象概念讲成大白话再把源码里的关键部分拆开讲清楚最后补上我实际运行和二次开发时踩过的一些坑。1. 白皮书发布后Agent 项目真正开始变味的地方1.1 从“模型能力秀”转向“工程能力秀”以前大家聊 Agent更多是在讨论“这个模型会不会自己规划”“思维链是不是够强”本质上还是把注意力放在模型本身的智力上限上。但 Google Agent 白皮书出来后圈子里一个共识越来越明显Agent 能不能用从来不是单靠模型智力决定的而是靠一套系统工程能力兜底。我读白皮书最大的感受是它把大量篇幅放在了一个非常“不性感”但极其关键的词上编排。Agent 不是简简单单把用户问题丢给大模型、拿到一段文字就完事而是要在一个循环里反复完成计划、调用工具、观察结果、修正计划、再执行。这个过程里模型只是其中一个“脑袋”真正干活的是外面那层调度机制。所以如果你现在还在拿“哪个模型推理最强”来衡量 Agent 能不能做方向就偏了。白皮书其实在提醒大家模型能力固然重要但任务能不能稳定跑完取决于你对 Agent 的“工作流”设计得有多稳。1.2 白皮书里反复强调的四个构件我按自己的理解把白皮书的核心内容归纳成四个构件模型、工具、记忆、编排。这四样东西缺一个Agent 都会显得“残废”。模型负责理解意图、拆分任务、生成中间推理结果。它不一定是最强模型但得是适合任务、响应稳定、可被可靠解析的模型。工具Agent 连接世界的那双手比如查天气、查数据库、执行代码、访问内部 API。工具层白皮书里特别强调了“输入输出要结构化”否则模型发挥再强也容易出错。记忆不是简单的历史消息堆叠而是区分短期记忆和长期记忆。短期记忆负责当前多步任务的上下文长期记忆负责把过去的经验、用户偏好、领域知识存下来下次任务时再召回。编排这是整个白皮书的灵魂。把上面的模型、工具、记忆串成一个循环规定在什么时候调用工具、什么时候读取记忆、什么时候向用户提问、什么时候终止任务。这四个构件不是概念上独立存在而是要在代码层面被清晰建模。我拿到“可运行源码”后最直观的感受就是这套代码里四个构件分别对应了不同的模块边界感很强。这也是我想推荐你去看源码的原因——光读文档你很容易觉得“我都懂了”但一看代码才发现光“记忆”这一块的上下文管理和剪裁就够忙活一阵子。2. 白皮书想解决的问题Agent 不是聊天框加工具2.1 编排层的价值到底在哪里很多从零开始做 Agent 的人第一版往往长这样用户在对话框输入问题代码把问题拼到 prompt 里模型直接返回答案然后大家发现效果不稳定、经常胡说八道、一遇到多步任务就断。接着开始往里面塞工具调用但工具调用完模型还是会忘记之前的结论。这问题的根子就是缺一个“编排层”。编排层解决的是“下一步该干什么”的问题。白皮书里把 Agent 的运行描述成一个连续循环每一轮模型输出的不再是最终答案而是一个中间动作——要么是“我已经查到了时间下一步去查天气”要么是“所有信息齐了我可以给最终答案了”。这个中间动作被编排层解析出来再决定是去调工具、还是问用户、还是结束任务。我把代码跑通后的感觉是编排层就像一个项目里的“主管”。模型是那个出主意的顾问但真正按节奏推进、检查每一步有没有完成、卡住了要不要换个思路的人是这套编排逻辑。没有这个主管模型再强也容易跑偏。2.2 关于记忆短期上下文和长期知识的区别白皮书里对记忆的拆解对我启发挺大。它把记忆分成了短期和长期两块而这两块的实现思路完全不同。短期记忆说白了就是把当前任务里的推理过程和中间结果塞在上下文窗口里。但这里有个非常现实的问题一旦任务步骤多、工具返回结果长上下文很快就会被塞满。所以要在编排层做“摘要”或“裁剪”把不太重要的历史步骤压缩成一两句话保留关键信息丢掉细节。长期记忆则偏向“经验库”。比如一个客服 Agent它应该记住客户公司名称对应的产品线记住上一次对话的处理结论。实现上一般会用向量数据库做语义检索按需把相关记忆塞进上下文而不是把所有历史全部丢进 prompt。我在源码里看到比较惊喜的一点是它对记忆模块做了解耦短期记忆的维护逻辑和长期记忆的存储逻辑被分开这样你在接不同场景时可以单独替换。比如内部业务系统里长期记忆可以直接查业务库不一定非得上向量数据库。3. 可运行源码一个按白皮书思路整理的最小 Agent 骨架3.1 项目结构和核心依赖白皮书附带源码用的是相对精简的结构我这套整理后的骨架也模仿了它的分层方式。目录结构大概是agent_skel/ ├── agent.py # 编排层核心循环 ├── tools.py # 工具注册与调度 ├── memory.py # 短期记忆维护 └── run_demo.py # 演示入口可直接运行我特意把它做成了不依赖外部 API 也能跑通的 demo模型调用部分用一个可替换的接口占位。这样你可以直接看循环逻辑不用先配一堆 key。等你接入真实模型时只需要实现一个chat(messages)接口返回模型文本即可。3.2 核心循环计划、执行、观察、再计划下面这段是我简化后的核心循环逻辑ReAct 模式的骨架。代码先把“工具”注册成一张表再在循环里不断让模型输出动作和参数由编排层解析执行把观察结果回填给模型import json def parse_action(text): 从模型输出中解析 Action 和 Action Input。 lines text.strip().splitlines() action_name action_input for line in lines: if line.startswith(Action:): action_name line.replace(Action:, ).strip() if line.startswith(Action Input:): action_input line.replace(Action Input:, ).strip() if action_name: return action_name, action_input return None def run_agent(question, llm, tools, max_steps6): messages [{role: system, content: SYSTEM_PROMPT}] messages.append({role: user, content: question}) for step in range(max_steps): response llm.chat(messages) messages.append({role: assistant, content: response}) action parse_action(response) if action is None: # 模型不再输出工具调用说明要直接给最终答案了 return response name, arg action if name not in tools: messages.append({role: tool, name: name, content: 未知工具请换一个}) continue tool_func tools[name][func] try: result tool_func(arg) except Exception as exc: result f工具执行失败: {exc} messages.append({role: tool, name: name, content: str(result)}) return 达到最大步数任务终止这里每一步的messages就是上一节说的“短期记忆”。模型每次看到的都包含系统提示、用户问题、历史推理、工具调用结果然后基于这些内容继续生成下一步动作。3.3 跑通一遍后的实际输出示例我在run_demo.py里放了一个模拟模型它会先调用时间工具再调用天气工具。真实运行后的输出轨迹大概是这样用户请问现在几点北京天气如何 助手我先获取当前系统时间。 Action: get_current_time Action Input: 观察2025-05-13 09:23:12 助手接下来查一下北京的天气情况。 Action: get_weather Action Input: 北京 观察北京天气多云18~25℃ 最终回答现在是 2025 年 5 月 13 日 09:23北京天气为多云气温 18~25℃。这个例子虽然简单但已经完整包含了计划、调用工具、观察结果、再计划、终结这一整条链路。你把它替换成真实模型后同样的循环就能处理更复杂的任务比如“先查订单号再查物流信息最后查售后政策”这种多轮工具调用场景。4. 源码之外真正拉开差距的工程细节4.1 工具调用的输入输出约束是老大难白皮书里有个细节我特别认同工具参数的描述要足够精确最好带 JSON Schema。因为模型并不是天生就知道“这个工具的入参是城市名还是城市编码”你要给它明确的结构化定义。我自己踩过的坑是一开始工具入参写得太宽松比如只描述“输入城市名”结果模型偶尔会把参数写成北京 市、Beijing、beijing这种乱七八糟的变体。后来我把入参格式严格定义成city_name: string并在描述里加了枚举值和示例错误率立刻下降很多。工具返回值那边也一样尽量返回纯数据而不是格式化好的自然语言因为模型还需要基于数据继续推理。4.2 上下文膨胀与自动裁剪多轮工具调用带来的另一个坑就是上下文膨胀。我实际测试过一个 5 步任务工具返回内容稍微长一点一轮下来 token 消耗就翻倍而且模型越往后越容易“忘了前面的结论”。应对思路很简单给短期记忆加一个“压缩机制”。有两种常见做法摘要压缩每轮结束时如果历史消息超过阈值就把早期消息丢给模型生成一段摘要作为一条summary消息塞回上下文。关键信息提取不压缩全文而是只保留每个工具调用结果里的核心字段丢掉冗长的日志和调试信息。在代码骨架里我给messages列表加了一个不超过 N 条的裁剪逻辑超过就把最早的一轮推理和工具结果合并成一句摘要。实际跑下来token 消耗能降 30% 到 40%任务成功率反而更高。4.3 重试和回退要写在框架里而不是靠模型自救模型输出经常会出现工具名拼错、参数格式非法、甚至直接开编“我已经查过了”但实际没有查的情况。这种情况如果只靠换 prompt 或者祈祷是解决不了的。我建议在编排层直接写死“重试和回退”规则如果工具名不在注册表里不要强行让模型选别的而是先重试一次仍失败就给模型一条明确错误信息并提示可选工具列表。如果同一个动作连续执行了两次都失败就中断当前分支换成更简单的子任务。如果模型输出 “最终回答”时缺少必要的中间证据宁可让它再执行一轮也不要直接把可能失真的答案交给用户。这些规则看起来不起眼但正是它们在保底。我的经验是工程上把兜底逻辑写扎实比单纯追求“模型更强”更有性价比。5. 从复现到二次开发我踩过的一些坑5.1 别急着上复杂框架我一开始接触 Agent 时也想直接上那些重框架什么分布式编排、复杂状态机、外部记忆库恨不得第一天就把架构搭成大型平台。结果光在配置上就耗了两天业务逻辑一点没跑通。后来我把白皮书附带的源码跑通后最大的收获是明白了“最小闭环优先”的价值。先做一个单文件循环跑通两个工具调用再逐步加记忆、加重试、加监控。复杂架构在只有两个工具时带来的是负担不是效率。5.2 测试 Agent 要像测试一套异步系统Agent 的每一步都依赖模型输出而模型输出天然有随机性。同一个问题跑十次可能有三四次的轨迹不一样。所以测试时不能只看一次结果要让它在多组问题上反复跑记录轨迹和成功率。我自己的做法是把每次执行过程落成 JSON 日志包含每一步的模型输出、工具执行时间、token 数、最终结果。出现问题时我不看“最终对不对”而是看“哪一步拐弯了”。这会让你发现很多有趣的问题比如某类问题总是在第二步开始报错原因可能是工具返回格式不统一而不是模型笨。5.3 可观测性日志、轨迹回放、耗时统计最后一件事尤其当你准备把 Agent 接到真实业务里时可观测性绝对不能省。Agent 不像普通接口那样“请求-响应”一眼看完它是多步的你必须在每步都埋点。我至少会记这些指标每步开始时间、每步耗时、工具名称和参数、工具结果长度、模型输出原文、累计 token、是否触发重试。把这些结构化存下来既能做问题回溯也能算成本。白皮书那段源码里虽然没有很完整的监控组件但它的编排层写得很干净加一层日志装饰器就能做到。我后来在二次开发时还加了一个“轨迹回放”的小工具把日志重新加载成可读文本像看录像一样看 Agent 每一步在想什么、做了什么。调试效率提升很明显强烈建议你也试一下。总的来说Google 这次把白皮书和可运行源码一起放出来相当于把 Agent 从“概念炒作”推到了“开箱即研”的阶段。白皮书里最值钱的不是某个神秘公式而是一整套关于“模型、工具、记忆、编排”的工程分解方式。你可以先用最小骨架跑通流程再把你在真实业务里学到的约束和坑逐步补进去。刚开始跑出来的 Agent 可能会笨会走很多弯路但只要编排层设计得合理、日志埋点到位这些都只是优化问题。本文还有配套的精品资源点击获取