企业采用 Agent 并非只有一条路径。需要开箱即用部署和治理的团队会选择托管商业平台（如 Gemini Enterprise Agent Platform）；而有定制工作流或自定义执行引擎的开发者，往往会自建轻量级 Agent 中心。Antigravity SDK 就是为后者准备的运行时：它直接内置了 Antigravity 2.0 和 Antigravity CLI 所用的执行引擎，并额外加入声明式安全策略、实时遥测和基于会话的多轮持久化。核心运行时一旦更新，SDK 里的 Agent 会自动获得优化。

整个控制平面由两个关键部件构成。一是 Antigravity SDK Agent Core，负责管理模型交互（如 Gemini 3.1 Pro、Gemini 3.8 Flash）、运行工具、生成思考轨迹、执行 Skills。二是可观测性中间件，它基于 SDK 的 Lifecycle Hooks，以事件驱动方式拦截步骤开始、思考更新和工具调用，并通过 WebSocket 把遥测流式送到仪表盘，让操作员实时看到每个 Agent 在做什么。

典型场景是自定义 Agent Hub 的多 Agent 监控。运维工程师要同时盯多个 Agent（如 gemini-pro-agent、github-agent、email-agent）做后台研究、文档总结和任务调度。传统做法要么在多个终端里跟踪碎片化日志，要么手动翻 JSON 转录来诊断卡住的工具调用，而且看不到当前会话加载了哪些 Skill 或 MCP 连接器，也没法方便地统计累计 token 用量和执行延迟。SDK 给出的解法是：流式 API 负责实时观察，生命周期钩子负责遥测和中间拦截，策略引擎负责方向约束，Skills 负责能力管理，会话状态负责持久化。

在后台，运行时通过五个机制协调执行。会话初始化与状态附加：指定 save_dir 和 conversation_id，多轮轨迹、工具回执和工件统一存到 traj- 目录，供后续审计。技能解析：通过 skills_paths 指向文件系统里的 SKILL.md 包，动态增强系统提示词，不需要外部注册表。并发流生成：ChatResponse 同时暴露三个异步迭代器——response（可见文本）、response.thoughts（内部思维链增量）、response.tool_calls（类型化的 ToolCall 事件，含 .name 和 .args）。声明式沙箱：内置工具如 list_directory、find_file、search_directory、view_file、create_file、edit_file 只能在配置的 workspace 目录内运行，受 policy.workspace_only() 这类安全策略约束。钩子拦截：@hooks.on_session_start、@hooks.pre_tool_call_decide、@hooks.post_tool_call、@hooks.on_session_end 等装饰器可以实时接管 Agent 状态转换，在工具执行前校验或修改参数，并通过 WebSocket 广播事件。

落到工程上，SDK 把能力组织成四个构建块：Skills 是文件系统路径下的可复用指令包，运行时可加载；沙箱内置工具省去手写文件系统包装；save_dir 与 conversation_id 提供会话隔离和轨迹持久化，无需外部数据库；生命周期钩子让仪表盘和监控引擎能观察并干预执行全程，比如在工具运行前插入人工审批。这套设计的目标很明确：让自建 Agent Hub 的团队获得可控、可观测、可追溯的执行环境。