全栈 AI 应用开发者，终于等来了一个”省心”的接口。据 InfoQ 报道，谷歌近日为开源框架 Genkit 推出预览版 Agents API，将消息历史、工具执行循环、流式传输、状态持久化以及前端协议全部封装在一个 chat() 接口背后——无论智能体是在进程内运行，还是部署在 HTTP 端点之后，接口的工作方式完全一致。预览版现已支持 TypeScript 和 Go，Python 和 Dart 的支持也在计划之中。

一句话概括：以前做 Agent 要自己拼装的一堆”基建零件”，现在谷歌给你打包好了。开发者的注意力，终于可以从”怎么让 Agent 跑起来”转移到”让 Agent 干什么活”。

为什么是 Genkit？谷歌的全栈 AI 开源底牌

先认识一下主角。Genkit 是谷歌用于构建全栈式 AI 应用的开源框架，定位介于模型 API 和业务应用之间，提供提示词管理、检索增强生成（RAG）、评估、可观测性等开箱即用的能力。它的特点是把 AI 能力嵌入传统开发流程，让 TypeScript、Go 开发者不用切换语言生态，就能把大模型接进自己的应用。

这次推出的 Agents API，是 Genkit 向”智能体原生”方向迈出的一大步。过去，开发者用 Genkit 或类似框架做 Agent，往往要自己处理会话状态、工具调用循环、流式输出等琐碎逻辑；现在，Agents API 把这些全部收敛进一个 chat() 接口，一次调用就能获得完整的智能体交互体验。

chat() 接口到底封装了什么？

按 InfoQ 报道，这个统一的 chat() 接口背后，封装了四层能力：

第一层：消息历史。 多轮对话的上下文管理由框架托管，开发者不再需要手动维护”哪句话是第几轮说的、哪些消息要回传给模型”。

第二层：工具执行循环。 Agent 调用工具、拿到结果、再决定下一步的完整循环，由框架自动编排。这解决了 Agent 开发中最麻烦的部分——工具调用的状态机管理。

第三层：流式传输。 无论是流式多轮对话还是长耗时任务的进度反馈，接口都原生支持流式输出，用户侧可以实时看到智能体的”思考过程”。

第四层：服务端会话快照与状态持久化。 会话状态由服务端托管，应用重启、网络中断都不怕丢上下文。工具还能通过当前会话实时更新数据，并流式推送至客户端。

更关键的是，无论智能体是在进程内运行，还是部署在 HTTP 端点之后，接口的工作方式完全一致。这意味着开发者可以先用最简单的方式在本地跑通逻辑，再无缝部署到远程服务，代码几乎不用改。

一个抽象层，覆盖四种任务形态

Agents API 的核心设计原则，按 InfoQ 的说法是：“一个抽象层即可实现扩容，无需更换底层基础组件。” 同一个智能体对象，可以处理四种截然不同的任务形态：

  • 一次性应答：最简单的”问一句答一句”，适合客服机器人、FAQ 助手
  • 流式多轮对话：像 ChatGPT 一样边想边说的对话体验
  • 等待人工确认的暂停工具调用：Agent 执行到需要人拍板的环节，会暂停等待——比如订机票前先问用户”确认这个航班吗”
  • 独立运行的长耗时任务：后台挂机执行的任务，比如批量生成报告、定时跑数据分析

这四种形态，覆盖了从”聊天机器人”到”自主智能体”的完整进化路径。当产品功能从简易聊天机器人迭代为多智能体协同工作流时，开发团队无需切换框架内其他组件——同一个 Agent 对象，同一套 API，只是用法的深度不同。

对于创业团队来说，这意味着巨大的成本节约：不用为了不同场景维护多套 Agent 基础设施，一套抽象层通吃。

自定义状态 vs 产物：谷歌厘清了两类数据

这次发布还有一个值得关注的细节——Genkit 对两种大多数框架都会混淆的智能体数据进行了明确区分：

自定义状态（State）： 驱动下一轮对话的强类型应用数据，例如工作流状态、任务列表或已选择的实体。它决定 Agent”接下来该干什么”。

产物（Artifact）： 可供用户单独查看、下载或版本管理的生成输出，例如报告、代码补丁或旅行行程。它是 Agent”干出来的成果”。

区别在哪里？状态是”过程中的变量”，产物是”交付的成果”。过去很多框架把这两类数据混在一起存，导致 Agent 逻辑混乱、状态回溯困难；Genkit 把它们分开管理，工具可以通过当前会话更新任意一类数据，且 Genkit 会实时将数据变更流式推送至客户端——用户能看到 Agent 干活的全过程，而不是最后甩给你一个黑盒结果。

这个设计看似简单，实则是 Agent 工程走向成熟的标志：当数据边界清晰了，调试、版本管理、多人协作才成为可能。

人机协同：Agent 干到一半，喊你来拍板

InfoQ 报道的标题点出了一个关键能力——分离式任务轮次与人机协同。这是 Agents API 区别于普通聊天框架的核心设计：Agent 在执行任务时，可以主动“暂停”，把决定权交还给人类。

举个具体例子：一个订机票的 Agent，查到航班后不会直接下单，而是把价格、时间、舱位信息整理好，暂停在“等待用户确认”状态，等用户拍板后才继续执行支付。再比如企业里审核报销单的 Agent，遇到超出预算的申请，会停下来等财务人员人工复核，而不是自作主张。这种“干到一半喊人”的能力，是 Agent 真正进入生产环境的前提——完全自主的 Agent 现阶段没人敢用，但“该自主时自主、该请示时请示”的 Agent，企业愿意买单。

配合前文提到的状态与产物分离设计，这套机制跑起来很顺：暂停时，Agent 把当前状态（比如已选的航班、待确认的订单）和产物（行程单草稿）都保存好，用户确认后无缝继续。整个过程状态不丢、进度可查、随时可干预——这正是“人机协同”四个字的工程化落地。

谷歌的 Agent 生态拼图：ADK、A2A 与 Genkit 的协同

把视野拉大，Genkit Agents API 只是谷歌 Agent 生态中的一块拼图。据行业资料，谷歌在 2025 年 4 月的 Google Cloud Next 大会上发布了开源的 Agent Development Kit（ADK），这是一款基于 Python 的 AI 智能体开发框架，主打模块化架构和代码优先开发，兼容 Gemini 等大模型及 MCP 协议，面向多智能体系统的构建、管理与部署；而 Genkit 则服务 TypeScript / Go 开发者，两者互补，几乎覆盖了主流开发语言生态。

在协议层面，谷歌还在推进 A2A（Agent2Agent）开放协议——让不同厂商的 AI 智能体通过标准化接口互相发现能力、提交任务、监控进度、接收结果。这意味着谷歌的布局不止于“让你写好一个 Agent”，更在于“让你的 Agent 能和别人的 Agent 对话”。模型层有 Gemini，开发层有 ADK 和 Genkit，协作层有 A2A，谷歌正在搭建一套从模型到协议的完整 Agent 基础设施。

多智能体协同：从“单兵作战”到“军团协作”

Agents API 的设计还有一个容易被忽视的点：它面向的不只是单个智能体，而是多智能体协同工作流。官方明确提到，当产品从简易聊天机器人迭代为多智能体协同工作流时，开发团队无需切换框架内其他组件——同一个智能体对象、同一套接口，可以直接扩展成多个智能体分工协作的架构。

这一点踩中了 2026 年行业的主旋律。据行业观察，就在 Genkit Agents API 发布的同一周，富士通发布自进化 MAAF、阿里云 AgentTeams 正式上线、微软 Agent Framework for Go 公测——一周之内，四家大厂相继亮出多 Agent 编排方案。多智能体协作正在从论文概念走向生产标配：一个 Agent 负责拆解任务，一个 Agent 负责调用工具，一个 Agent 负责质检汇总，像一支团队一样流水线作业。

对开发者而言，这意味着架构选择的时间窗正在收窄：早一点用上统一抽象层，未来向多智能体演进时就不用推倒重来。这或许正是谷歌强调“一个抽象层即可扩容”的深层用意。

这释放了一个明确信号：2026 年，Agent 开发正在从”模型能力竞赛”转向”基础设施竞赛”。 模型再强，如果没有好用的框架把能力落地，开发者还是只能望洋兴叹。谁家的 Agent 框架更简单、更稳定、生态更丰富，谁就能吸引更多开发者，进而绑定更多业务场景。

谷歌的差异化打法，在于”全栈”二字：Genkit 背靠 Google Cloud 的 Vertex AI、Gemini 模型，加上 Firebase 的前端生态，天然能覆盖”从模型到前端”的完整链路；而 Agents API 的”进程内 / HTTP 端点双形态”设计，又让它在本地开发和生产部署之间无缝切换。对于已经使用 TypeScript 或 Go 的团队，上手成本几乎为零。

开发者视角：省下的时间能干什么？

对开发者来说，Agents API 最实在的价值，是把”重复造轮子”的时间还给你。想想做一个生产级 Agent 需要什么：会话管理、工具注册与调用循环、流式协议、状态持久化、前端事件推送……这些逻辑每个项目都要写一遍，而且写不好就是各种隐蔽 bug。

谷歌把这些全部封装进 chat() 接口后，开发者只需要关注三件事：定义 Agent 的能力（工具）、设计业务逻辑（状态流转）、处理交付物（产物）。剩下的框架代劳。这有点像当年 React 把 DOM 操作封装进组件模型——不是让你少写几行代码，而是改变了你思考问题的方式。

当然，预览版也意味着有一些不确定性：API 可能调整、生态还在成长、生产环境稳定性有待验证。但方向已经明确——Agent 开发正在从”手工作坊”走向”标准化流水线”。

未来展望：Agent 基建的”标准化时刻”

回顾 AI 应用开发的历史，每一个爆发期都伴随着一次基础设施标准化：2015 年前后是前端框架标准化，2018 年是微服务与容器标准化，2023 年是大模型 API 标准化——如今，轮到 Agent 了。

Genkit Agents API 的意义，不只是谷歌多了一个开发者工具，而是宣告 Agent 开发的“乐高时代”到来：会话、工具、状态、产物这些积木块被标准化，开发者按需拼装，而不用自己开模。当越来越多的团队用统一的方式构建智能体，Agent 应用的创新速度会被整体抬升一个台阶。

对独立开发者和中小团队来说，这种标准化的红利尤其明显：过去做一个带工具调用的 Agent，从零到上线可能要几周；现在基于统一的 chat() 抽象，加上 Genkit 自带的提示词管理、RAG 和可观测性能力，几天就能跑通一个生产级的原型。省下来的时间，可以用来打磨业务逻辑和用户体验——这才是框架存在的真正意义。

对国内的开发者来说，这件事同样值得关注：一方面，TS/Go 生态是很多团队的主战场，接入成本低；另一方面，这也给国内 Agent 框架（如阿里 AgentScope、字节等）提了个醒——框架之争，拼的是谁能让开发者”省心到极致”。好戏才刚刚开始。

最后留个互动话题：你开发 Agent 时，最希望框架帮你解决什么问题——会话状态、工具循环、还是前端对接？欢迎在评论区聊聊你的看法。