Google agents-cli发布，Claude Code新增7项超能力

上周四晚上，躺在沙发上刷 GitHub Trending，突然看到一个仓库在两天内涨了 3000 个 star，名字叫 google/agents-cli。

第一反应是什么？Google 又搞了什么东西？Gemini CLI 刚刚宣布个人账号停服、过渡到 Antigra vity CLI，这会儿又推个新的 CLI？

点进去看完 README，愣了一下——这玩意不是编程助手，它是给编程助手「装技能」的。

什么意思？你用 Claude Code 写代码，它帮你写。但如果你要开发一个 AI Agent——从脚手架搭建、到代码生成、到评估测试、到云端部署——Claude Code 默认不具备这些能力。agents-cli 就是往 Claude Code（或者 Gemini CLI、Codex）里塞了 7 个 Skill，让它瞬间变成 Agent 开发专家。

花了一个周末把 7 个 Skill 全部实测了一遍，这篇文章就是一份完整的体验报告。

先搞清楚：这东西不是竞争关系

很多人看到标题会误以为：Google 出了个 CLI 工具要跟 Claude Code 抢市场。

不是的。

打个比方：Claude Code 是一把锤子，agents-cli 是一套电动螺丝头。你把螺丝头装上去，锤子就变成了电动螺丝刀。螺丝头本身不能独立工作，它需要一个宿主。

看 GitHub README 里的兼容列表就清楚了：

支持的宿主（Host）:
- Gemini CLI
- Claude Code
- Codex（OpenAI）
- Antigra vity CLI

它不挑宿主。不管是 Google 自家的还是 Anthropic、OpenAI 的编程助手，只要支持 Skill 协议，都能装。

那问题来了，它到底往宿主里塞了什么？

7 个 Skill 的全景拆解

agents-cli v0.5.1（2026-06-22 刚发布）一共提供 7 个 Skill。按使用顺序分成三个层次：

开发层（日常高频使用）：

验证层（开发中期使用）：

运维层（最后才用）：

先别急着装，一个一个拆给你看，到底哪些值得现在就用。

adk-code：最核心的 Skill，也是设计最巧的

这 7 个 Skill 里，adk-code 是实测最多、也觉得设计得最巧妙的一个。

它的作用：你用自然语言描述你要什么 Agent，它帮你生成符合 Google ADK（Agent Development Kit）规范的代码。

但关键不在「生成代码」——Claude Code 本身就能生成代码。关键在「符合 ADK 规范」。

什么是 ADK 规范？看一个最小 Agent 的结构：

# my_agent/agent.py
from google.adk import Agent
from google.adk.models.lite_llm import LiteLlm

root_agent = Agent(
    name="weather_agent",
    model=LiteLlm(model="anthropic/claude-sonnet-4-20250514"),
    description="查询天气信息的 Agent",
    instruction="你是一个天气查询助手，使用提供的工具获取天气数据。",
    tools=[get_weather],
)

就这几行？对，就这几行。但这个结构背后的设计决策很重要：

1. model 字段支持 LiteLlm 中间层。 这意味着你可以用 Claude Sonnet 跑、也可以换 Gemini Flash 跑，甚至同一套代码在不同环境用不同模型。Google 没有把自己绑死在 Gemini 上。

2. tools 字段是标准 Python 函数列表。 不是特殊格式、不是装饰器魔法，就是一个普通函数。ADK 框架通过类型提示和 docstring 自动提取工具描述。

3. instruction 和 description 分开。instruction 是给模型看的系统提示，description 是给其他 Agent 看的能力描述。这个分离在多 Agent 协作时特别关键——外层编排 Agent 通过 description 决定把任务分给谁。

adk-code Skill 的作用就是：你说「我要一个能查天气、能订机票的 Agent」，它帮你生成完整项目，包括 agent.py、tools/ 目录、配置文件，全按上面的规范来。

如果之前用过 ADK 手动搭 Agent，你就会明白这个 Skill 的价值。ADK 的初始化配置挺繁琐的——pyproject.toml、__init__.py 的导出、工具函数的签名要求，少一步都会报莫名其妙的错误。adk-code 全帮你包好了。

scaffold：脚手架工具，但不是你想的那种

scaffold 看名字像是一个简单的项目生成器，类似 npx create-react-app。

但它比一般的脚手架聪明在哪？

# 用法：在 Claude Code 里直接说
# "帮我创建一个多 Agent 协作的旅行规划 Agent"
# Claude Code 会调用 scaffold Skill

它生成的不只是文件，而是一个可运行的多 Agent 拓扑。比如你说「旅行规划 Agent」，它不会给你一个单 Agent 加一堆工具函数的平铺结构，而是给你：

tra vel_agent/
├── agent.py             # 根 Agent（路由器）
├── sub_agents/
│   ├── flight_agent.py  # 订机票子 Agent
│   ├── hotel_agent.py   # 订酒店子 Agent
│   └── weather_agent.py # 查天气子 Agent
├── tools/
│   ├── flight_api.py
│   ├── hotel_api.py
│   └── weather_api.py
├── .env                 # API keys
└── pyproject.toml

注意它默认就用了 sub_agents 结构。这不是偶然——ADK 的设计哲学就是「一个 Agent 做一件事」，通过 Root Agent 做编排。这和在 Claude Code 里自己搭多 Agent 系统的思路完全一致。

不过必须吐槽一下：scaffold 目前内置的模板种类太少了。试了 5 个不同需求，其中 3 个生成出来的结构几乎一样。它更像是一个「单模板脚手架 + 需求解析」的组合，而不是有丰富模板库的 Yeoman 那种。

现在值得装吗？ 装。虽然模板单一，但它生成的结构是符合 ADK 最佳实践的，比你从零手写靠谱。

workflow：多 Agent 编排，概念先行，细节待打磨

workflow 是 7 个 Skill 里概念最超前、但落地最粗糙的一个。

它解决的问题：当你有多个 Agent（比如上面旅行规划那个，flight_agent + hotel_agent + weather_agent），怎么定义它们之间的协作关系？

ADK 提供了几种内置的编排模式：

# 模式一：Sequential（串行）
# 天气查询 → 根据天气选航班 → 根据航班订酒店

# 模式二：Parallel（并行）
# 同时查航班和酒店，合并结果

# 模式三：Loop（循环）
# 反复优化行程方案直到用户满意

workflow Skill 的作用就是让你用自然语言描述这些编排关系，然后它帮你转换成 ADK 的代码结构。

听起来很美好，但实测的时候遇到了一个明显问题：它对中文描述的理解不太稳定。 同样的需求，用英文描述生成的 workflow 比用中文描述的质量高一截。估计训练数据里英文 workflow 描述远多于中文。

而且目前 workflow 只支持简单的 DAG（有向无环图）编排，对有条件分支的复杂场景（比如「如果天气不好就取消旅行」这种带条件判断的），支持还不到位。

现在值得装吗？ 可以装，但别指望它能搞定复杂场景。简单的工作流定义用它省时间，复杂的还是自己手写更靠谱。

eval：第一次跑就报错的评估工具

到了验证层。eval 是让人又爱又恨的一个 Skill。

它设计得确实好——用 Python 代码定义评估用例，自动跑完给评分：

# 评估脚本示例（简写）
from google.adk.evaluation import AgentEvaluator

eval_suite = AgentEvaluator(
    agent=weather_agent,
    test_cases=[
        {
            "input": "北京明天天气怎么样？",
            "expected_tools": ["get_weather"],
            "expected_contains": "北京",
        },
    ],
)
results = eval_suite.run()
print(results.summary())
# pass_rate: 1.0

这比我自己写 pytest 来测 Agent 输出靠谱多了。它不只检查最终回答，还检查中间步骤——调用了哪些工具、工具参数对不对、有没有幻觉。

但坑来了：第一次跑 eval 命令直接报错。

报错信息大概意思是 evaluation module not found。翻了 GitHub Issues 才发现，v0.5.1 的 eval 模块有个依赖冲突，需要手动安装 google-adk[eval] 额外依赖。README 里没写这一步，得自己去翻 Issues。

修好之后倒是能跑了，而且效果确实不错。它内置了几种评估指标：

• Tool Usage Accuracy：工具调用是否正确
• Response Relevance：回答是否切题
• Hallucination Score：幻觉检测（这个最实用）

光冲这个幻觉检测能力，eval 就值得装。自己写一套幻觉检测逻辑太痛苦了。

现在值得装吗？ 装，但做好心理准备——首次配置需要折腾。

publish 和 deploy：生态早期，可以再等等

这两个 Skill 简单说一下：

publish 是把你的 Agent 发布到 Google 的 Agent Garden（类似 Agent 应用商店）。试了一下，发布流程倒是通畅，但 Agent Garden 里的 Agent 数量还很少，更像是个概念验证阶段。你发布了也没什么人用。

deploy 是部署到 Google Cloud Run。这个需要 GCP 账号和 billing 设置。如果你本来就在用 GCP，那挺方便的——一条命令把本地 Agent 变成 API 端点。如果你没有 GCP 账号，专门为此注册一个就不值了。

# deploy 的使用方式（需要 GCP 项目）
# 在 Claude Code 里说："把当前 Agent 部署到 Cloud Run"
# 它会自动处理 Dockerfile 生成、构建、推送、部署

现在值得装吗？ 纯本地开发的话，这两个先不装也不影响什么。等你要上生产了再补。

装之前你要知道的三件事

安装方式

# 方式一：uvx（推荐，如果你有 Python 环境）
uvx google-agents-cli setup

# 方式二：npx（推荐 Node.js 用户）
npx skills add google/agents-cli

安装完之后，它会自动检测你当前环境里有哪些编程助手（Claude Code / Gemini CLI / Codex），然后在对应目录下写入 Skill 配置文件。整个过程不到 30 秒。

API Key 的问题

agents-cli 本身不需要 API Key——它只是往你的编程助手里装 Skill。

但 Skill 生成的 Agent 代码要跑起来，需要模型 API Key。Google 提供了 AI Studio 的免费 API Key，日常开发够用：

# 免费方案：Google AI Studio（不需要 GCP 账号）
export GOOGLE_API_KEY="your-aistudio-key"

# 付费方案：Google Cloud Vertex AI（生产用）
export GOOGLE_CLOUD_PROJECT="your-project"

用 Claude Code 测试的时候，直接用的 Anthropic API Key——ADK 的 LiteLlm 层支持直接走 Anthropic 的 API，不需要经过 Google。

国内访问

安装本身没有墙，GitHub 直接拉。但 Skill 里部分命令（特别是 deploy 和 publish）需要访问 Google Cloud API，这个你懂的。本地开发、代码生成、评估测试这些功能不受影响。

agents-cli vs 直接用 ADK：效率差多少？

这是测试过程中最想回答的问题。

结论：对于新手，agents-cli 能把入门时间从 2 天压缩到 2 小时。对于老手，提升大约 30%。

对比一下：

老手用 agents-cli 主要省在脚手架和评估上——这两个环节用 ADK 手动做太琐碎了。代码生成部分对老手帮助有限，因为老手本来就知道 ADK 的结构长什么样。

但对新手来说，最大的价值是消除了「不知道规范长什么样」的障碍。你不需要先读完 ADK 文档再动手，直接说需求，它帮你生成符合规范的代码，你再读代码学规范。这是典型的「做中学」。

FAQ：你可能想问的几个问题

Q1：我用 Cursor 不用 Claude Code，能装吗？

Cursor 目前不在官方支持列表里。不过理论上，如果 Cursor 支持类似 Skill/Extension 的机制，应该也能接入。目前官方明确支持的是 Gemini CLI、Claude Code、Codex 和 Antigra vity CLI。

Q2：装了 agents-cli 会影响我现有的 Claude Code 配置吗？

不会。它只是在 Skill 目录下加了几个新 Skill 文件，不修改任何已有配置。不想要了手动删掉就行。

Q3：ADK 和 LangChain / CrewAI 比怎么样？

这是另一个话题了，简单说：ADK 是 Google 官方的，和 Google Cloud 生态集成最深（Agent Garden、Cloud Run、Vertex AI）。LangChain 生态最大、社区最活跃。CrewAI 在多 Agent 协作方面概念最先进。三个没有绝对优劣，选哪个取决于你的部署环境。

Q4：agents-cli 的更新频率怎么样？

非常活跃。项目 2026 年 4 月 8 日创建，到现在两个多月，版本号已经到 v0.5.1，最新一版是昨天（6 月 22 日）发的。3000 多 star，Google 内部有人在维护。

核心建议

如果你是 Claude Code 的日常用户，又对 AI Agent 开发感兴趣——装。adk-code + scaffold + eval 这三个 Skill 组合起来，能把你的 Claude Code 从「写代码的助手」变成「帮你搭 Agent 系统的搭档」。

workflow、publish、deploy、observability 这四个可以观望，等社区案例多起来了再上。

Google 在 CLI 工具上的品味一直不错。从 gcloud CLI 到 Firebase CLI 再到现在的 agents-cli，那种「一行命令搞定一件事」的设计哲学一脉相承。这次往 Claude Code 里塞 Skill 的思路也挺巧妙——不造轮子，造零件。

唯一让人担心的是：Gemini CLI 个人账号停服、过渡到 Antigra vity CLI 这件事，说明 Google 内部对 CLI 产品的定位还在调整中。agents-cli 作为配套工具，它的长期路线图会跟着 Google 的 Agent 生态走。如果 Google 某天调整了 ADK 的方向，这些 Skill 的维护质量也会受影响。

不过话说回来，3000 star 的工具，就算 Google 放弃了，社区也会 fork 继续维护。先把好用的 Skill 装上用着，走一步看一步。