Google recently launched a free Agent course.
The course starts from Prompt and Agent Loop to Graph Workflow, multi-agent and self-evolving systems. At first glance, it looks like introducing a new Agent development method.
But putting together the official information of Google ADK 2.0, Google Cloud architecture guidelines, and several recent Agent evaluation studies, I think what is really worth paying attention to is not a certain API, but a bigger change:
Agent development is moving from "tuning models" to the stage of "designing systems".
In the past, most AI applications looked like this:
Input → Prompt → Model → Output.
Translation, summary, classification, information extraction, and content rewriting can usually be completed in one call.
Development is fast, the cost is easy to estimate, and if something goes wrong, just call it again.
But after tool calls appeared, Agents began to truly enter the business process.
It can search for materials, call APIs, execute code, query databases, and then decide the next step based on the results returned by the tool.
Models are no longer just "answering questions."
It starts to "do things."
Once the model is involved in execution, the problem is completely different.
The context will continue to grow, and tool results will continue to enter historical records. Agents may call the tool repeatedly, deviate from the goal halfway, or even end the task early before it is completed.
Enterprise processes will further add requirements such as authority, approval, status, retry, recovery, and audit.
Customer service refunds, invoice verification, employee onboarding, and order processing are not simple questions and answers.
So the real difficulties for Agents have gone from:
"How to get the model to get the correct answers more times?"
became:
"How to make a business process involving a model run stably?"
这也是我认为 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 问题。
而是软件工程问题。
所以真正可靠的系统通常会采用一种更现实的分工：
模型负责不确定性，代码负责确定性。
For example:
投诉内容的理解和分析，可以交给模型。
订单查询、退款执行、数据库更新，则应该由程序控制。
三、Agent Loop 很灵活，但生产环境必须“戴上缰绳”
Agent Loop 的魅力就在于它不需要提前知道所有路径。
模型可以根据工具返回结果不断调整计划。
For example:
“帮我调查这家公司最近的融资情况。”
Agent 可以自己搜索网页、查询数据库、整理资料，然后发现信息不足时继续搜索。
这种任务如果完全写死流程，反而会很笨重。
但 Loop 也有一个天然风险：
它不知道什么时候应该停。
因此生产环境中的 Agent Loop 通常需要明确设置：
- 最大执行步数
- 总超时时间
- Token / API 预算
- 成功条件
- 失败条件
- 人工升级路径
否则一次错误判断，就可能变成：
调用工具 → 得到错误结果 → 再调用 → 再失败 → 继续尝试。
最后的结果就是：
成本上涨，延迟增加，任务却没有完成。
So:
路径不确定的时候，让模型做决定。
路径确定的时候，就不要让模型猜。
这其实是 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 可以从三个方向缓解：
第一，节点隔离上下文。
每个节点只读取自己真正需要的信息。
第二，使用结构化状态。
不要每次都把完整聊天记录重新塞给模型。
第三，建立检查点。
一个节点完成以后保存确认结果，下一个节点从已经确认的状态继续。
但这里还有一个重要区别：
保存聊天记录，不等于具备恢复能力。
真正的恢复机制还需要考虑：
Checkpoints, event logging, idempotent operations, and replay strategies for external systems.
7. The more multiple agents are not the more advanced they are
There is also a trend that is easily misunderstood:
It seems that the more agents there are, the more advanced the system will be.
This is not the case at all.
The real value of multi-agent isClear division of responsibilities。
For example:
An Agent is responsible for retrieving.
An Agent is responsible for the analysis.
An Agent is responsible for execution.
This way, each Agent can have different tools, permissions, and contexts.
Problems also arise:
Call more.
There is more communication.
Status synchronization is more complex.
Troubleshooting becomes more difficult.
Concurrency will also cause current restriction, resource competition, and consistency issues in the future.
NeurIPS 2025 's MAST research analyzed more than 1,600 multi-agent execution trajectories and summarized 14 types of failures.
Many of these problems are not that Prompt is poorly written.
Instead:
The division of tasks is unreasonable, Agent collaboration fails, state management is chaotic, and results cannot be verified.
So I very much agree with one simple principle:
Without clear responsibility boundaries, don't use multiple agents for the sake of "multiple agents".
If a problem can be stably solved with one Agent, use one first.
Only when the task really has a clear division of roles, authority isolation, or complex collaboration can you consider splitting it.
8. Agent evaluation cannot just look at "No answer"
In traditional LLM applications, it is easy to do an accuracy test.
Agents are different.
Because it must not only "answer correctly", but also "get things done."
For example, a customer service refund Agent.
It finally replied:
"The refund has been completed for you."
No matter how beautiful this sentence is, it is meaningless.
What really needs to be verified is:
Is the refund actually implemented?
Is the refund amount correct?
Are there duplicate refunds?
Did you override your authority?
Has the work order been updated?
Did the user receive any notification?
Is there a complete record of the entire process?
Therefore, when companies evaluate Agents, I suggest comparing a batch of real and desensitized historical tasks.
For example, 20 to 50 tasks.
Compare at least three implementations:
- Single model call
- Single Agent with Tools
- Graph Workflow or Multi-Agent
And use the same set of tasks and acceptance criteria.
Key records:
- Success rate for first completion
- Final mission success rate
- Manual modification time
- end to end latency
- Total cost of models and tools
- number of retries
- At which node did the failure occur
- Number of unauthorized operations
- Whether the source and execution trajectory are complete
Especially for high-risk businesses, you can't just record "success/failure."
It should also retain:
Scoring basis, original evidence, execution track and manual review records.
Because after it's actually online, you need to answer more than just:
"Is it doing it right?"
Also answer:
"Why do you do this?"
9. The best starting point for enterprises to implement Agents is not to "build a super Agent"
If I were to be a corporate Agent now, I would not consider first:
"Should we build a multi-agent system?"
I would ask first:
Does the company have an existing manual process with clear boundaries and verifiable results?
For example:
Invoice verification.
Customer service refunds.
Contract review.
Employees are on board.
Collate sales leads.
Run the manual process clearly first.
How long will it take?
What is the cost?
What are the most common mistakes?
Which steps waste the most labor?
What steps are the determination rules?
What steps require human judgment?
Once you have this benchmark, you can decide where to use the model.
Then:
If you can use one Agent to solve it, don't rush to tear down multiple agents.
If you can solve it in code, don't let the model decide.
Only when the process appears clear:
Branch, parallel, approve, retry, resume
When needed, introduce Workflow.
If irreversible actions such as payment, database writing, sending emails, and submitting work orders are involved, you need to design in advance:
Permission verification, idempotent key, manual confirmation, rollback path.
At this time you will find:
The engineering of agents is essentially getting closer to traditional software engineering.
Finally: What is the real next stage for Agent?
Over the past two years, we have been studying:
How to make models smarter?
How to make Prompt more effective?
How to make agents better use tools?
But then, the real concern for companies may become:
How to make an Agent complete a task stably?
These two things are completely different.
Just because a model occasionally performs amazing doesn't mean it can enter the production environment.
Just because an Agent can complete one task does not mean that it can stably complete 10,000 tasks per day.
What companies really need is:
Stable success.
controllable costs.
Traceable process.
Recoverable state.
Minimum authority.
Reliable retry.
Full audit.
Manual intervention.
Continuous evaluation.
So I prefer to think of Agent as a new software system rather than a chat window that calls tools.
Prompt allows the model to understand the task.
Agent Loop allows the model to act based on results.
Graph Workflow constrains the entire execution process.
Only by putting the three in the right position can we gain both the flexibility of AI and the certainty of traditional software.
What really deserves attention about Google ADK 2.0 may not be how many APIs it has added.
Instead, it sends a very clear signal:
Agents are changing from "chatbots that can call tools" to "software systems that can be engineered, operated, and audited."
Graph Workflow is just one step on the road.
In the end, what determines whether an Agent can be online is still not how amazing the Demo is, but:
Success rates, manual rework, delays, costs, and safety records.
This may be the most noteworthy competitiveness of Agents after they truly enter the enterprise production environment.