9 月底以来，各家大厂都在补「开发智能体」的官方工具链。谷歌这边对应的是 ADK（Agent Development Kit）：一套 Python 框架，配合云上的 Agent Engine，可以把本地调试好的智能体直接托管成一个带日志、可扩展的线上服务。相比自己在服务器上拼 Flask 加队列，这套组合把「造完 → 上线」的工程摩擦压到最低。
一条最小链路
本地用 pip install google-adk 装套件，然后按它的原语组织代码：一个 Agent 带 instruction，挂上 tools，可以嵌套子 Agent。本地调试时用 adk run 你的agent 在命令行里对话，快速改提示词。
调通之后，用 adk deploy agent_engine 把它推到谷歌云的 Agent Engine，平台会分配一个 HTTP 端点，自动带上会话持久化与调用日志。后续要改提示词，本地改完再部署，不用碰服务器。
两个设计要点
- 工具即函数：ADK 里一个 Python 函数加装饰器就是一个工具，模型自动获得调用它的能力。把读数据库、调内部 API 的动作封装成函数，比手写 JSON Schema 直观得多。
- 可观测先于优化：部署后先在 Agent Engine 控制台看每一步的轨迹——模型调了哪个工具、花了多少 token、在哪一步卡住。没有轨迹就谈优化，都是猜。
判断
框架之争的下半场，比的不是谁的抽象更优雅，而是谁把「本地 → 托管 → 观测」的链路做顺。ADK 加 Agent Engine 的组合，对已经在谷歌云上的团队是顺理成章的选择；跨云团队则可以把它当一个参照系，去衡量其他框架的托管体验。
补一个省钱细节：本地调试时用便宜模型快速迭代，部署到 Agent Engine 后再切到 Gemini 旗舰模型做正式推理。因为代码与模型解耦，这个切换只改一行配置，不用重写逻辑。另外，把成本敏感的工具调用加上缓存——读同一份配置文件，别让 Agent 每次都重复读、重复计费。
说到底，框架之间真正的差距不在抽象多优雅，而在「从写到上线」这一段少踩多少坑。托管和观测顺了，精力才能留在业务上。