Marico's space

听起来没有新模型那么耀眼，但这恰恰是它重要的原因。模型是发动机，托管代理却是底盘、变速箱、仪表盘、维修团队和紧急制动的集合。它把"模型能思考、能调用工具"变成了"我的应用可以让一个代理完成任务、观察执行过程、保存状态、收集产物，然后继续干"。

这是完全不同的产品。对开发者来说，可能也是更重要的那个。

真正的瓶颈从来不是智力

过去几年，代理（Agent）演示的剧本都差不多：

1. 模型收到任务
2. 调用需要的工具
3. 规划、写代码
4. 运行代码、检查结果
5. 修正自己的错误

看的人都点头。但等开发者真正想在生产环境复现这个的时候，问题就来了。

难点不只是让模型思考。难点是给它一个工作空间。一个正经的代理需要运行时、沙盒、文件管理、工具边界、内存或状态管理。它需要可观测的中间步骤，需要控制网络访问、凭证、费用、清理，还需要良好的开发体验——而不是让每个团队都从头造一套 orchestration（工作流编排）层。

这才是托管代理要填补的坑。

Google 的发布不只是在说"Gemini 可以用工具"。更有意思的是：Google 把整个代理循环本身打包成了一个托管的开发原语（Managed Developer Primitive）。

借助托管代理，Antigravity 托管代理可以运行在 Google 托管的 Linux 环境里，执行代码、管理文件、使用网络访问、保持环境状态，并通过 Interactions API（交互式 API）返回可观测的执行轨迹。这把开发者的工作从"构建整个运行时"变成了"从托管的代理环境出发，把精力集中在产品边界上"。

而那个边界，才是真正考验工程能力的地方。

Google 实际交付了什么

I/O 2026 上，Google 发布了 Gemini API 里的托管代理，Antigravity 代理作为公开预览可用。这个代理由 Gemini 3.5 Flash 驱动，通过 Interactions API 和 Google AI Studio 对外暴露。

整个产品有几个关键组件：

重要的是，这不是一个单次无状态的请求响应 API。无状态调用适合生成、分类、提取、摘要、单次推理。但托管代理更适合需要状态、工具、文件和迭代的工作。

想想数据分析、代码仓库审计、研究综合、报告生成、基准测试运行、文档更新、内部工作流自动化——所以托管代理不只是又一个 AI 功能，更像是一个执行底座。

架构：提示词进去，工作出来

简化版的托管代理流程是这样的：

开发者通过 Interactions API 发送任务，托管代理接收任务、理解任务、使用可用工具、在远程环境里读写文件，最后返回最终输出和结构化的执行信息。

关键在于状态管理。

Google 给开发者两个主要的句柄：

第二个句柄尤其重要。没有环境持久化，每个代理任务都变成一次性的。有了环境持久化，代理可以在之前的文件和结果上继续构建。

第一轮可以创建分析，第二轮改进图表，第三轮打包输出，第四轮审计最终文件。

这不像在和一个聊天机器人对话，更像在监督一个带 shell 权限的远程员工。

一个最小化的 API 模式

最清晰的心智模型是：

一个基础的 Python 工作流大概长这样：

from google import genai client = genai.Client() first_run = client.interactions.create( agent="antigravity-preview-05-2026", input=( "Read revenue.csv, identify the top three trends, " "and save a short report as report.md." ), environment="remote",
) print(first_run.output_text)
print(first_run.environment_id) second_run = client.interactions.create( agent="antigravity-preview-05-2026", previous_interaction_id=first_run.id, environment=first_run.environment_id, input=( "Now create a chart for the strongest trend " "and save it as chart.png." ),
) print(second_run.output_text)