Google 工程师在《Why we built ADK 2.0》中抛出一个反直觉的命题：在企业生产环境中，LLM 不应该是「编排者」，而应该是「工人」。ADK 2.0（Agent Development Kit 2.0）的核心是一套结构化工作流运行时——开发者把「调用第三方 API」这种确定性步骤直接写成代码节点，把「理解客户投诉」这种需要语义推理的任务交给 LLM 节点，再用图把节点按业务逻辑串起来。 Google 工程师用「客户退款」做了对比：传统 autonomous agent 把 5 个步骤全塞进一个 LLM 循环，token 用 5,152；改成 ADK 2.0 workflow 后，LLM 只负责「判断政策合规」和「起草邮件」两个语义节点，token 直接压到 2,265，省了约 50%，延迟从 7.2 秒降到 5.7 秒。 更重要的是，这种「确定性骨架 + LLM 软组织」的结构天然解决了三个生产痛点：上下文膨胀（每次 tool 输出污染上下文）、执行脱轨（agent 跳过关键步骤或陷入循环）、提示注入（恶意输入劫持 LLM 走错分支）。Workflow 的边和节点是写死的代码，LLM 哪怕被注入攻击，也调不到 workflow 里没有的边。 ADK 2.0 还引入动态工作流：不再强制把复杂逻辑塞进静态路由表，允许直接用 Python asyncio 控制流来表达，再用子 workflow 嵌套。整个框架支持 Python/Java/Go/TypeScript/Kotlin 五种语言，Go 版本刚发布。 这套范式的真正价值在于：把「是否要用 Agent」这个二选一，变成了「哪一步用 Agent」。对工程团队来说，可能是 2026 年最有用的认知校正——能用确定性代码就别浪费 token。