Google 最近推出了一门免费的 Agent 课程。

课程从 Prompt、Agent Loop 一直讲到 Graph Workflow、多 Agent 和自进化系统。乍看之下，像是在介绍一套新的 Agent 开发方法。

但把 Google ADK 2.0 的官方资料、Google Cloud 架构指南，以及近期几份 Agent 评测研究放在一起看，我觉得真正值得关注的并不是某一个 API，而是一个更大的变化：

Agent 开发正在从“调模型”进入“设计系统”的阶段。

过去，AI 应用大多是这样的：

输入 → Prompt → 模型 → 输出。

翻译、摘要、分类、信息抽取、内容改写，这些任务通常一次调用就能完成。

开发快，成本容易估算，出错了重新调用一次就可以。

但工具调用出现之后，Agent 开始真正进入业务流程。

它可以搜索资料、调用 API、执行代码、查询数据库，然后根据工具返回的结果决定下一步。

模型不再只是“回答问题”。

它开始“做事情”。

而一旦模型参与执行，问题就完全不一样了。

上下文会不断增长，工具结果会不断进入历史记录，Agent 可能重复调用工具，也可能在中途偏离目标，甚至任务还没有完成就提前结束。

企业流程还会进一步增加权限、审批、状态、重试、恢复和审计等要求。

客服退款、发票核验、员工入职、订单处理，这些事情都不是简单的一问一答。

所以 Agent 真正的难点已经从：

“怎样让模型多答对几次？”

变成了：

“怎样让一条由模型参与的业务流程稳定跑完？”

这也是我认为 Google ADK 2.0 值得关注的地方。

---

一、Prompt、Agent Loop、Graph，到底有什么区别？

很多人现在讨论 Agent，容易把 Prompt、Agent Loop 和 Workflow 混在一起。

其实它们解决的是三个不同层次的问题。

Prompt 解决“理解”

Prompt 告诉模型：

你要做什么、应该怎么做、输出什么格式、有哪些限制。

如果任务本身比较简单，例如翻译、摘要、分类、改写，那么 Prompt 往往已经足够。

Agent Loop 解决“行动”

当模型拥有工具以后，它可以：

理解目标 → 制定下一步 → 调用工具 → 读取结果 → 再决定下一步。

这就是典型的 Agent Loop。

它特别适合开放式任务。

比如搜索资料、代码修复、复杂数据分析。

因为你很难提前写死每一步，模型需要根据现场结果动态调整计划。

Graph Workflow 解决“执行”

Workflow 关注的是：

整个流程到底应该怎么跑。

哪些步骤必须执行？

哪些任务可以并行？

什么情况下进入分支？

什么时候必须人工审批？

失败以后从哪里重试？

哪些状态需要保存？

这些问题不能全部交给模型临场决定。

它们更适合写进程序。

所以可以把三者简单理解成：

Prompt 负责理解，Agent Loop 负责行动，Workflow 负责约束执行。

三者不是互相替代，而是可以叠加。

能用一次模型调用解决的问题，不需要强行建 Workflow。

单 Agent 已经能够稳定完成的任务，也没有必要为了“Agentic”而拆成多个 Agent。

---

二、Prompt 到底什么时候开始失效？

Prompt 最大的问题，不是它不够强。

而是当业务流程越来越复杂以后，流程本身开始藏在 Prompt 里面了。

比如一个退款流程：

用户提出退款 → 查询订单 → 判断政策 → 决定是否退款 → 执行退款 → 发送确认邮件 → 更新工单。

如果把这些全部交给一个 Agent，让模型自己决定下一步，看起来非常灵活。

但生产环境很快就会出现问题。

开发者很难确定：

这一步是不是每次都会执行？

退款前有没有完成权限检查？

工具失败以后会不会重复退款？

邮件发送失败以后应该从哪里继续？

数据库更新失败以后，前面的操作需要不要回滚？

这些都已经不是 Prompt 问题。

而是软件工程问题。

所以真正可靠的系统通常会采用一种更现实的分工：

模型负责不确定性，代码负责确定性。

例如：

投诉内容的理解和分析，可以交给模型。

订单查询、退款执行、数据库更新，则应该由程序控制。

---

三、Agent Loop 很灵活，但生产环境必须“戴上缰绳”

Agent Loop 的魅力就在于它不需要提前知道所有路径。

模型可以根据工具返回结果不断调整计划。

比如：

“帮我调查这家公司最近的融资情况。”

Agent 可以自己搜索网页、查询数据库、整理资料，然后发现信息不足时继续搜索。

这种任务如果完全写死流程，反而会很笨重。

但 Loop 也有一个天然风险：

它不知道什么时候应该停。

因此生产环境中的 Agent Loop 通常需要明确设置：

• 最大执行步数
• 总超时时间
• Token / API 预算
• 成功条件
• 失败条件
• 人工升级路径

否则一次错误判断，就可能变成：

调用工具 → 得到错误结果 → 再调用 → 再失败 → 继续尝试。

最后的结果就是：

成本上涨，延迟增加，任务却没有完成。

所以：

路径不确定的时候，让模型做决定。

路径确定的时候，就不要让模型猜。

这其实是 Agent 工程里非常重要的一条原则。

---

四、Graph Workflow真正解决的是什么？

Graph Workflow 做的事情其实很简单：

把原本藏在模型决策里的流程，变成开发者能够看到、测试和修改的软件结构。

例如一个退款流程，可以设计成：

查询订单
↓
分析用户投诉
↓
判断退款条件
↓
├── 满足条件 → 执行退款
│
└── 不满足 → 关闭工单
↓
生成确认邮件
↓
更新工单状态

这样一来，每一个节点都变得清晰。

哪些步骤必须执行？

哪些步骤可以并行？

哪里需要人工确认？

失败后从哪里恢复？

哪些结果需要持久化？

都可以明确表达。

这也是 Workflow 最大的价值：

它不是让 Agent 更聪明，而是让 Agent 更可控。

---

五、Google ADK 2.0为什么值得关注？

Google ADK 2.0 的一个重要变化，就是把 Workflow Runtime 正式放到了 Agent 开发的核心位置。

Python 2.0 在 2026 年 5 月 19 日进入 GA，Go 2.0 在 6 月 30 日进入 GA。

从官方设计来看，Agent、工具和函数都可以成为工作流中的节点，再通过执行关系控制整个流程。

顺序执行、条件路由、并行任务、循环、动态工作流、嵌套流程以及人工介入，都可以被纳入统一的运行模型。

更重要的是，它开始关注长任务的状态和恢复。

因为一个真正的企业任务，可能不是几秒钟就完成。

它可能运行几十分钟，甚至更久。

中途可能暂停。

可能等待人工审批。

可能某个外部系统暂时不可用。

这时候系统必须知道：

之前到底执行到哪里了？

如果没有检查点和状态恢复能力，Agent 一旦中断，就只能重新开始。

这也是为什么企业级 Agent 最终一定会越来越像传统的软件系统。

它需要：

状态。

事件。

检查点。

重试。

权限。

日志。

审计。

恢复。

---

六、长上下文不等于可靠记忆

这里还有一个非常容易被忽略的问题：

Context Rot。

很多人认为，只要把历史记录全部塞进上下文，Agent 就“记住了一切”。

实际上，事情没有这么简单。

随着输入越来越长，模型从上下文中准确找到真正重要信息的能力可能下降。

而 Agent 比普通聊天更容易遇到这个问题。

因为每一次工具调用，都可能带来新的数据。

搜索结果、网页内容、数据库记录、API 返回值、中间推理……

如果所有东西都不断追加到上下文里，最终会形成一个巨大的信息垃圾场。

上下文越长，不一定越聪明。

有时候反而越容易出错。

所以 Workflow 可以从三个方向缓解：

第一，节点隔离上下文。

每个节点只读取自己真正需要的信息。

第二，使用结构化状态。

不要每次都把完整聊天记录重新塞给模型。

第三，建立检查点。

一个节点完成以后保存确认结果，下一个节点从已经确认的状态继续。

但这里还有一个重要区别：

保存聊天记录，不等于具备恢复能力。

真正的恢复机制还需要考虑：

检查点、事件记录、幂等操作，以及外部系统的重放策略。

---

七、多 Agent不是越多越先进

现在还有一个很容易被误解的趋势：

似乎 Agent 越多，系统就越先进。

其实完全不是这样。

多 Agent 真正有价值的地方，是职责分工明确。

例如：

一个 Agent 负责检索。

一个 Agent 负责分析。

一个 Agent 负责执行。

这样每个 Agent 可以拥有不同的工具、权限和上下文。

问题也随之出现：

调用更多了。

通信更多了。

状态同步更复杂了。

故障排查更困难了。

并发以后还会出现限流、资源竞争和一致性问题。

NeurIPS 2025 的 MAST 研究分析了 1,600 多条多 Agent 执行轨迹，并归纳出 14 类故障。

其中很多问题并不是 Prompt 写得不好。

而是：

任务分工不合理、Agent 协作失败、状态管理混乱、结果无法验证。

所以我非常认同一个简单原则：

没有清晰职责边界，就不要为了“多 Agent”而多 Agent。

能用一个 Agent 稳定解决的问题，就先用一个。

只有当任务真的出现清晰的角色分工、权限隔离或者复杂协作，再考虑拆分。

---

八、Agent评测不能只看“答对没有”

传统 LLM 应用，很容易做一个准确率测试。

Agent 就不一样了。

因为它不仅要“回答正确”，还要“把事情做完”。

比如一个客服退款 Agent。

它最终回答：

“已经为您完成退款。”

这句话说得再漂亮都没有意义。

真正需要验证的是：

退款有没有真的执行？

退款金额对不对？

有没有重复退款？

有没有越权操作？

工单有没有更新？

用户有没有收到通知？

整个过程有没有留下完整记录？

所以企业评测 Agent 时，我建议拿一批真实、脱敏的历史任务进行对比。

例如 20～50 个任务。

至少比较三种实现：

1. 单次模型调用
2. 带工具的单 Agent
3. Graph Workflow 或多 Agent

并且使用同一套任务和验收标准。

重点记录：

• 首次完成成功率
• 最终任务成功率
• 人工修改时间
• 端到端延迟
• 模型和工具总成本
• 重试次数
• 失败发生在哪个节点
• 未经授权的操作次数
• 来源和执行轨迹是否完整

尤其对于高风险业务，不能只记录“成功 / 失败”。

还应该保留：

评分依据、原始证据、执行轨迹和人工复核记录。

因为真正上线以后，你需要回答的不只是：

“它做对了吗？”

还要回答：

“为什么这么做？”

---

九、企业落地Agent，最好的起点不是“造一个超级Agent”

如果让我现在做企业 Agent，我不会先考虑：

“我们要不要做一个多 Agent 系统？”

我会先问：

公司有没有一条已经存在、边界清晰、结果可验证的人工流程？

比如：

发票核验。

客服退款。

合同审核。

员工入职。

销售线索整理。

先把人工流程跑清楚。

需要多长时间？

成本是多少？

最常见的错误在哪里？

哪些步骤最浪费人工？

哪些步骤属于确定规则？

哪些步骤需要人的判断？

有了这个基准之后，再决定哪里应该使用模型。

然后：

能用一个 Agent 解决，就不要急着拆多个。

能用代码解决，就不要让模型决定。

只有当流程出现明确的：

分支、并行、审批、重试、恢复

需求时，再引入 Workflow。

如果涉及付款、数据库写入、发邮件、提交工单等不可逆动作，则需要提前设计：

权限校验、幂等键、人工确认、回滚路径。

这时候你会发现：

Agent 的工程化，本质上和传统软件工程越来越接近。

---

最后：Agent真正的下一阶段是什么？

过去两年，我们一直在研究：

怎样让模型更聪明？

怎样让 Prompt 更有效？

怎样让 Agent 更会使用工具？

但接下来，企业真正关心的问题可能会变成：

怎样让 Agent 稳定地完成一项工作？

这两件事完全不同。

一个模型偶尔表现惊艳，并不意味着它可以进入生产环境。

一个 Agent 能完成一次任务，也不意味着它能够每天稳定完成一万次任务。

企业真正需要的，是：

稳定成功。

可控成本。

可追踪过程。

可恢复状态。

最小权限。

可靠重试。

完整审计。

人工介入。

持续评测。

所以我更愿意把 Agent 看成一种新的软件系统，而不是一个会调用工具的聊天窗口。

Prompt 让模型理解任务。

Agent Loop 让模型根据结果行动。

Graph Workflow 约束整个执行过程。

三者放在正确的位置，才能同时获得 AI 的灵活性和传统软件的确定性。

而 Google ADK 2.0 真正值得关注的地方，也许并不是它增加了多少 API。

而是它释放出了一个非常明确的信号：

Agent 正在从“会调用工具的聊天机器人”，变成“可以被工程化、运营和审计的软件系统”。

Graph Workflow，只是这条路上的一步。

最终决定一个 Agent 能不能上线的，仍然不是 Demo 有多惊艳，而是：

成功率、人工返工、延迟、成本，以及安全记录。

这可能才是 Agent 真正进入企业生产环境之后，最值得关注的竞争力。