原文：A dev’s guide to production-ready AI agents · Google Cloud · 2026-02-25 作者：Kanchana Patlolla（Technical Solutions Manager）· Anant Nawalgaria（Sr. Staff ML Engineer, Founder of Gen AI Intensive）
一句话导读：过去一年里，Agent 的难点已经从"能跑出 Demo"变成"能不能上线"。这篇 Google Cloud 的官方导读把答案拆成了 5 个阶段——但真正值钱的不是这 5 个阶段，而是它们对应着 5 处传统工程范式失效的地方。本文按这条骨架展开，每一节追问"为什么传统做法在这里行不通"，并给一条可量化的判断标准。
引言：原型不再稀缺，能上线的 Agent 才稀缺
把时间倒回一年前——彼时讨论 Agent，话题还停在"能不能让 LLM 自己调几个工具完成任务"。今天再开同样的会，话题已经悄悄换了：能不能 7×24 给真实用户用？出错了能不能定位、能不能回滚、能不能解释？
Google Cloud 的这篇导读就是写给"卡在这道坎上"的开发者的。它没有给一份花哨的框架对比，而是把 Agent 工程化拆成了 5 个清晰阶段：定义 / 工具互操作 / 上下文工程 / 测试评估 / 生产部署。每一阶段都对应一组新概念，也对应着一处传统工程经验"差一点就够用、但其实远远不够"的盲区。
原文最值钱的判断只有一句：Agent 会推理、行动、自适应，因此不能用确定性代码的工程范式去管它。 接下来的内容，本质上都是在围绕这句话给具体动作。
一、Agent 是什么：把它从"函数"重新定义成"自主实体"
金句判断：把 Agent 当函数调用，是所有生产事故的起点。
原文给 Agent 的定义很简单：一个能推理、行动并随时间改进的自主实体（autonomous entity）。但定义本身不重要，重要的是它由哪些零件构成——这决定了你做架构图时能不能画对。
Google 给的解剖图分三层：
- Brain（大脑）：LLM 作为认知引擎，理解任务、生成响应、基于上下文决策。
- 核心循环：
Think → Act → Observe，三步递归。每一次循环都可能改变下一步要走的路。 - Orchestration Layer（编排层）：协调通信和数据流的"神经系统"，由五个组件构成——Session State（短期记忆）、Memory Service（长期记忆）、RAG（检索）、Tool Use（工具）、Security framework（安全边界）。
看图。中间这一整块编排层是绝大多数团队最容易低估的——只把 LLM 接上几个工具就以为做完了 Agent，结果上线后才发现：用户问到第 3 轮就开始失忆，跨日来访问会重复同样的失败动作，工具调用没有审计、出了问题查不到链路。 这些不是 LLM 的锅，是编排层缺失的锅。
为什么传统范式失效？ 因为传统服务里"状态"是显式的（数据库行、Redis Key），而 Agent 里的"状态"是模型对历史上下文的理解。Session State 不是把对话拼起来就行——它要决定哪些信息保留、哪些压缩、哪些丢弃，这是个工程化的取舍问题，不是把数组追加完事。
落地动作清单：
- 把 Brain / Loop / Orchestration 三层在你们的系统里画出来，不允许"我们暂时还没有 Memory，先这样"
- Session State 与 Memory Service 必须分开抽象，不要让一个组件同时承担短期与长期
- Security framework 在 Day 1 就要画进图里，不要等"上线前再补"——Agent 的越权风险是 LLM 注入 + 工具组合产生的，事后审计极难
真实场景：某客服 Agent 上线两周后被投诉"反复让用户重新提供订单号"。排查发现整个团队只实现了 Session State，而当用户从 App 切到网页（新会话）时，Memory Service 缺位导致状态彻底丢失。修复方案不是改 Prompt，而是补一层跨会话的用户级 Memory。
二、工具与互操作：从 N×M 集成到两条标准协议
金句判断：Agent 时代的"接口"，不是 REST，而是 MCP 与 A2A。
工具用起来才有用。但如果每接一个新数据源、新外部服务都要重写一套适配层，那就是经典的 N×M 集成爆炸。原文把答案押在了两条新兴协议上：
| 协议 | 提出方 | 解决的问题 |
|---|---|---|
| MCP（Model Context Protocol） | Anthropic | Agent ↔ 工具/数据源 的标准化连接，避免每个服务都做一次定制集成 |
| A2A（Agent2Agent Protocol） | Agent ↔ Agent 跨框架直接通信：能力发现、交互协商、结构化消息 |
注意看图——这两个协议方向是垂直的，不是替代关系：
- MCP 解决的是"Agent 怎么稳定地调一个工具"，是垂直方向的 Agent ↔ World；
- A2A 解决的是"Agent 怎么稳定地接另一个 Agent"，是水平方向的 Agent ↔ Agent。
把它们看成同一层的竞品，是常见误读。
为什么传统范式失效？ 传统微服务用 REST/gRPC + OpenAPI 描述，已经是工业级标准——但 LLM 不直接消费 OpenAPI。它需要的是自然语言可理解、能力可发现、调用语义带工具描述的协议形态。MCP 在这一层做了规范化，A2A 则更进一步，让"另一个 Agent"也能像"另一个工具"一样被发现和协商。
落地判断标准：
- 你的 Agent 至少接 3 个外部工具，且工具集预计还会增长 → 上 MCP，值得
- 你的 Agent 是单体、工具固定且不会再变 → 暂时不上，不值得
- 你的系统未来一年会有 2 个以上独立 Agent 之间需要协作 → 提前关注 A2A 的发展，至少把 Agent 间通信抽象成 message 而不是函数调用
真实场景：一家中型 SaaS 厂商把"订单查询、退款、库存检查"三件事各做了一个独立 Agent，最初用 HTTP 调用串起来。两个月后发现每加一个新业务线（如售后投诉）就要重写一遍编排逻辑。改造成 A2A 风格之后，新业务线只需要让自己的 Agent 实现能力描述，就能被现有 Agent 自动发现和调用——编排逻辑从代码变成了数据。
三、上下文工程：决定 Agent 是个"助手"还是"百科条目"
金句判断：通用模型不会成为你的助手，上下文工程才会。
原文用了一个很到位的比喻：如果 LLM 是大脑，那 Context Engineering（上下文工程）就是在正确的时机、把正确的信息喂给它的实践。它至少涵盖：
- Prompt design —— 任务说明的结构化
- Retrieval mechanisms —— RAG / 向量检索 / 关键字检索的混合策略
- Tool selection —— 该轮交互暴露哪些工具，不暴露哪些
- Conversation history —— 历史对话的保留、压缩、摘要
这件事做不好的反面非常具体：Agent 会遗忘、会重复、会抓不到重点。
为什么传统范式失效？ 传统软件的"配置"是静态的——一个用户进来加载一份配置，整个会话用完。但上下文工程是每一轮都在重做一次：这一轮要不要把这条历史包进去？要不要暴露这个工具？要不要插一段从向量库里拉回来的事实？每一次都是一次小型的"状态规划"，这件事在传统系统里没有对应物。
落地动作清单：
- 给每个 Agent 写一份"上下文预算"：单轮总 Token 上限、Memory 摘要长度、暴露工具数量上限——当作 SLO 管
- Tool selection 不要永远暴露全集：长工具列表会显著拉低工具选择质量。按场景分组、按对话阶段动态注入
- Conversation history 一定要做摘要 + 关键事实抽取，不要直接 truncate；裸截断会让 Agent 在长会话里失去"为什么我们在做这件事"的认知
真实场景：某金融顾问 Agent 在第 6 轮对话时开始反复推荐用户已经明确拒绝过的产品。回放轨迹发现：上下文窗口被前面的财报数据挤满，用户的偏好被截断在第 2 轮。修复方案是在 Memory Service 中显式存"用户拒绝清单"，每轮注入。重要的不是窗口有多大，而是关键事实有没有被保住。
四、测试与评估：成功不在终点，而在轨迹
金句判断：评估 Agent 不要看它答对没有，要看它怎么走到答案的。
这是原文给我个人启发最大的一节。它提出了一个核心概念——Trajectory（轨迹）评估：
两个 Agent 可能殊途同归，但路径的质量截然不同。
举个例子：用户问"我上个月在国内出差的差旅总额是多少"。
- Agent A：先调"用户档案"确认所在地→再调"差旅记录"按月过滤→再 Sum→直接给答案。4 步，每一步都有理由。
- Agent B：先调"全部消费记录"拉了 3000 条→再用 LLM 自己判断哪些是差旅→再判断哪些在国内→给答案。结果可能也对，但这条路径在数据稍微变化时会立刻崩。
如果只看最终答案，这两个 Agent 一样优秀。只有评估轨迹，才能区分它们的工程健康度。
原文给的良好评估应检查的维度：
- Tool selection —— 选对了工具吗？
- Reasoning quality —— 推理链合理吗？
- Error recovery —— 出错时是否能识别并恢复？
- Clarification —— 该提问澄清的时候，主动提问了吗？
并列出了三类测试方法：
- Unit tests —— 针对单个组件（如某个工具调用、某段 Prompt）
- Trajectory analysis —— 多步决策序列分析
- Staged rollouts —— Sandbox / Canary / Production 分阶段发布
为什么传统范式失效？ 传统单元测试是"输入→断言输出"。但 Agent 的"中间过程"本身就是产品的一部分——一个绕了 10 步才完成 1 步任务的 Agent，即使答对了也不能上线，因为它的延时、token 成本、错误率都会被无谓放大。Trajectory 评估其实是把"过程指标"提升到了和"结果指标"同等地位。
落地判断标准（写在评估平台里）：
- 每条线上轨迹都要可回放（至少保留 30 天）
- 评估集里至少 30% 是"故意带错"的输入，验证 error recovery
- 关键工具调用必须有 ground-truth 轨迹基线，而不仅仅是 ground-truth 答案
- LLM-as-Judge 用于轨迹打分时，要单独评估 reasoning 链路而不是只看输出
五、生产部署：Sandbox → Canary → Production，错误成本逐级递增
金句判断：Agent 的灰度发布不是"放点流量看看"，而是分阶段验证不同维度的行为。
最后一节回到工程主战场——发布。Google 给出的标准动作是三段式漏斗：
每一阶段验证什么、对应什么基础设施，要求是不一样的：
| 阶段 | 流量比例 | 主要验证 | 必备基础设施 |
|---|---|---|---|
| Sandbox | 0%（合成/录制流量） | 单元功能 / 工具调用正确性 / Prompt 注入对抗 | Mock 工具、合成评估集、安全沙箱 |
| Canary | 1–10% 真实流量 | Trajectory 质量 / 错误恢复 / 长尾 case | 实时轨迹采集、影子流量对比、熔断回滚 |
| Production | 100% | 可观测 / 回滚 / 容量 / SLO | 持久化 Memory、Real-time logging、多级降级 |
原文还点名了生产级 Agent 必备的四件事：Session management、Persistent memory、带认证授权的 Tool integration、Real-time logging。这四件事都不是 Day 1 就能想清楚的——但缺一件就敢上线，迟早会出事。
为什么传统范式失效？ 传统服务的灰度本质是"流量切分 + A/B 比较输出"。但 Agent 的灰度需要比较的是轨迹分布——同样一类问题，Canary 流量里 Agent 的平均决策步数是 5.8，Production 是 4.2，那即使最终答案准确率一样，也说明 Canary 这个版本"在变啰嗦"，是个回归信号。这种信号传统蓝绿/灰度发布捕捉不到。
落地动作清单：
- Sandbox 不只是 staging：要包含 Prompt 注入、工具滥用、对话越权等对抗集
- Canary 要看分布而不只是看错误率：步数、token、tool call 数量都要监控分布漂移
- 回滚机制要可在分钟级触发：Agent 的"坏行为"扩散速度可能比传统服务快很多——一次错误推理被多个用户当真就是事故
- 每个工具调用都带审计日志：包含输入、输出、调用时机、当时的上下文摘要
真实场景：某团队在 Canary 阶段发现 Agent 平均工具调用次数从 3.1 涨到 5.7，错误率却没明显变化——以为不是问题。一周后正式 Production 之后，云厂商账单暴涨 30%，才回头查到是 Prompt 改动后 Agent 开始反复调用同一个昂贵的检索工具。轨迹分布是发布期的核心健康指标，不能只看错误率。
给"上线者"的浓缩落地清单
如果只能从这篇文章里带走一份 checklist，应该是这一份：
- 架构层
- 画出 Brain / Loop / Orchestration 三层，明确 Session State 与 Memory Service 的边界
- Security framework 是 Day 1 决策，不是事后补救
- 工具层
- ≥3 个外部工具时考虑 MCP；多 Agent 协作时关注 A2A
- 工具调用全链路可审计、可重放
- 上下文层
- 每个 Agent 一份"上下文预算"SLO
- 历史摘要 + 关键事实抽取，禁止裸截断
- 工具列表按对话阶段动态注入
- 评估层
- Unit + Trajectory + Staged，三层都要做
- LLM-as-Judge 单独评估推理链
- 评估集 ≥30% 故意带错的输入
- 发布层
- Sandbox 包含对抗集
- Canary 监控轨迹分布漂移
- 回滚分钟级触发
- 工具调用全审计
学习路径地图：把 5 篇白皮书按你的角色分流
原文最后给了一份配套白皮书清单，但平铺一份"全部读完"对忙碌的工程师没有用。下面按角色分流：
- 如果你刚开始接触 Agent（前端/后端转 AI 工程师）
- 先读《Introduction to Agents》——把"Agent 不是函数"这件事建立起直觉
- 然后读《Tools and Interoperability with MCP》——理解 LLM 如何"动手"
- 如果你正在构建 Agent 但还没上线（已经有 Demo，要做生产化）
- 重点读《Context Engineering: Sessions and Memory》——多数 Demo→Prod 失败都失败在这里
- 配套读《Agent Quality》——把 Trajectory 评估纳入你的 CI 流程
- 如果你已经在线上跑了 Agent，要稳定与扩展
- 把《Prototype to Production》当 SOP 反复对齐
- 回头补《Agent Quality》——线上事故大多对应一类未覆盖的轨迹模式
结语：Agent 工程不是新一门学科，是工程范式的一次升级
读完原文最大的收获，不是学会了 5 个新名词，而是意识到：Agent 工程并不是从零起步的全新学科——它是把传统软件工程里那些"显式"的部分（状态、配置、控制流），让出一部分给"涌现"。 让出之后，传统的工程纪律（可观测、可回滚、可审计、可评估）反而要求更高，而不是更低。
下次再有人说"Agent 不就是 LLM + 工具吗"，你可以把这张图甩过去——五个阶段，每一阶段都有传统工程范式失效的地方。Demo 容易做，是因为前两阶段就够；上线难，是因为后三阶段才真正考工程功底。
「真诚赞赏，手留余香」
爱折腾的工程师
真诚赞赏，手留余香
使用微信扫描二维码完成支付
