谷歌给AI Agent造了把"瑞士军刀"

「通常搭建一个AI Agent需要写大量胶水代码——那些把大模型连到外部工具或数据库的杂乱脚本。」谷歌Agentic CLI的产品思路，就藏在这句话里。

为什么开发者需要专门工具？

AI Agent的开发流程正在标准化。从想法到上线，一个Agent要经历创建、评估、部署、监控多个环节。每个环节都有特定工具，但工具之间的衔接一直是手工活。

谷歌的解法是：把Agent开发生命周期（ADLC）的七个关键步骤，打包成可编程的"技能"。

Agentic CLI是谷歌官方推出的命令行工具，专为基于Agent Development Kit（ADK）构建的Agent设计。它既是人类开发者的控制台，也是编码Agent可直接调用的程序化接口。

这种双重设计很有意思——同一个工具，既服务人，也服务AI。

安装：现代Python工具链的实战

CLI对运行环境有明确要求。需要Python 3、Node.js与NPM（用于界面和部署功能），以及UV——一个高速Python包安装器，CLI底层依赖它。

安装路径如下：

创建虚拟环境隔离项目 → 通过UV分发安装 → 自动识别gcloud凭证或手动配置Gemini API密钥。

一个细节：CLI支持macOS和Linux，原生Windows不支持，需用WSL 2。这个选择反映了谷歌对开发者主力机型的判断。

凭证管理的设计值得注意。CLI继承shell环境的认证状态，无需把密钥硬编码进代码。这对编码Agent尤其重要——减少了敏感信息泄露的风险。

七项技能与两种模式

CLI的核心是七项技能，覆盖ADLC全流程：

创建（Create）、评估（Evaluate）、部署（Deploy）、运行（Run）、测试（Test）、打包（Package）、发布（Release）。

每项技能都对应一个可调用接口。编码Agent安装后可直接调用；人类开发者也能手动执行——官方称之为"Human Mode"。

快速启动的命令很简洁：

agent-cli create my-first-agent

一行命令生成模板项目，包含基础目录结构和配置文件。这种"约定优于配置"的思路，降低了Agent项目的启动门槛。

产品逻辑：谁在驱动这个设计？

Agentic CLI的架构透露了谷歌的判断：未来的软件开发是人机协作，而非人替代机器或机器替代人。

七项技能的标准化，意味着Agent开发正在从"手工作坊"走向"流水线"。当编码Agent能直接调用这些技能时，人类开发者的角色会向更高层迁移——定义目标、审查输出、处理异常。

CLI的双重模式设计（Agent调用 vs 人工执行）也暗示了过渡期的现实：完全自动化的Agent开发尚未到来，但基础设施必须先准备好。

另一个信号是ADK的绑定策略。CLI专为ADK构建的Agent优化，这强化了谷歌Agent生态的闭环。选择ADK，就自然接入这套工具链；要用CLI，最好先拥抱ADK。

对开发者的实际影响

对于已经在谷歌云生态内的团队，Agentic CLI减少了工具切换成本。gcloud凭证自动识别、Gemini API原生支持，这些设计降低了集成摩擦。

对于独立开发者或跨云用户，绑定深度可能成为考量。UV依赖、WSL 2要求、ADK专用，这些选择构成了明确的准入门槛。

更深层的变化是开发范式的转移。当CLI同时面向人和AI设计，代码仓库的结构、版本控制的方式、CI/CD的流程，都可能需要重新思考。

一个具体场景：如果编码Agent能自动调用evaluate和deploy技能，那么"提交代码→人工审核→部署上线"的传统流程，会不会变成"Agent自评→人类抽检→自动发布"？

CLI本身不回答这个问题，但它提供了基础设施。

数据收束

Agentic CLI目前处于早期发布阶段，七项技能覆盖完整ADLC周期，支持macOS/Linux双平台，通过UV分发安装。谷歌未披露具体下载量或采用率数据，但工具的定位很清晰：成为Agent Development Kit的标准化操作界面。

这个产品的真正价值，或许不在于当下能做什么，而在于它预设的未来——当编码Agent成为开发团队的标配成员，人类与AI共享同一套工具链，会是怎样的协作图景？