一个被低估的思路：不造 Agent，造 Agent 的工具
2026 年的 GitHub 上，每天都有新的 Coding Agent 冒出来。但 Google 的 agents-cli 走了一条完全不同的路——它自己不是 Agent，它是让 Agent 变强的工具。
这个项目的核心洞察是：你的 Claude Code 已经很会写代码了，但让它从零搭建一个 ADK（Agent Development Kit）Agent 项目，它得翻文档、猜 API、手动配 eval、手写 Terraform。整个过程充满试错。agents-cli 做的事就是把这个过程压缩成一条命令 + 一套 Skill。
2026 年 4 月创建，3 个月拿到 5300+ Star，Apache 2.0 协议。Google 官方维护。
它到底做了什么
一句话：一个 CLI + 7 套 Skills，让你的 Coding Agent 自动掌握 ADK Agent 的完整开发生命周期。
它不是 Coding Agent 的替代品，而是 Coding Agent 的"外挂知识库"。装上之后，你的 Claude Code / Codex / Antigravity CLI 就知道怎么：
- Scaffold — 一行命令生成 ADK Agent 项目脚手架（含 eval 配置、CI/CD、Terraform）
- Build — 自动参考 ADK Python API 的最佳实践写代码
- Evaluate — 跑 LLM-as-judge 评估，分析失败模式，自动优化 prompt
- Deploy — 部署到 Agent Runtime / Cloud Run / GKE，配好 CI/CD
- Publish — 注册到 Gemini Enterprise Agent Platform
- Observe — 接入 Cloud Trace、BigQuery Analytics、日志监控
7 套 Skills 的分工
| Skill | 作用 | 触发时机 |
|---|---|---|
| workflow | 全流程编排：Phase 0-7 的生命周期管理、代码保护规则、模型选择指南 | 始终激活，入口 Skill |
| adk-code | ADK Python API 速查：Agent、Tool、Callback、State、多 Agent 编排 | 写 Agent 代码前加载 |
| scaffold | 项目脚手架：create / enhance / upgrade，含 eval 样板和 CI/CD 配置 | 新建或改造项目时 |
| eval | 评估方法论：数据集 schema、内置 metric、LLM-as-judge、失败分析 | 跑评估前必加载 |
| deploy | 部署指南：Agent Runtime / Cloud Run / GKE 选型、Terraform 模式、秘钥管理 | 部署前 |
| publish | Gemini Enterprise 注册：发布到 Agent Platform 的完整流程 | 部署后（可选） |
| observability | 可观测性：Cloud Trace、日志、BigQuery Agent Analytics、第三方集成 | 部署后 |
为什么这套设计值得关注
市面上已经有大量 "Agent 开发框架"——LangChain、CrewAI、AutoGen、ADK 本身。但 agents-cli 解决的不是"怎么写 Agent 代码"这个问题，而是"怎么让 AI 助手帮你写 Agent 代码"。
这个区别很关键。传统框架的文档是给人看的，你需要理解 API、读示例、手动组合。agents-cli 的 Skills 是给 AI 看的——它把 ADK 的 API 文档、最佳实践、踩坑经验、评估方法论全部结构化成 SKILL.md 文件，Claude Code 在写代码时自动加载这些知识。
Phase 0：设计对话，不是填表
最让我印象深刻的是它的 Phase 0 设计。不是甩给你一个模板让你填，而是要求 Coding Agent 跟你进行设计对话——一次问一个问题，根据你的回答动态调整后续问题：
- "这个 Agent 要解决什么问题？" → 决定是否需要 RAG
- "需要外部 API 吗？" → 决定工具和认证方式
- "有什么安全约束？" → 决定 guardrail 设计
- "部署到哪？" → 决定 CI/CD 和基础设施配置
这个设计的妙处在于：它把"需求分析"这个最容易被跳过的步骤，变成了 Coding Agent 的强制流程。
评估系统：不是"跑通就行"
agents-cli 的评估系统是我见过最认真的。它内置了 6 种 metric：
| Metric | 测什么 | 适合场景 |
|---|---|---|
multi_turn_task_success | Agent 是否完成了用户目标 | 通用 catch-all |
multi_turn_trajectory_quality | 推理路径是否高效合理 | 复杂多步任务 |
multi_turn_tool_use_quality | 工具选择和调用是否正确 | 有工具的 Agent |
final_response_quality | 最终回答质量（无需参考答案） | 开放域对话 |
hallucination | 是否编造了工具输出中没有的信息 | RAG Agent |
safety | 安全策略合规性 | 面向用户的 Agent |
还支持自定义 metric——用 YAML 写一个 LLMMetric（LLM-as-judge）或 CodeExecutionMetric（确定性 Python 代码），就能评估任何领域特定的行为。
最狠的是 eval optimize 命令——它会用 GEPA（Google 的 prompt 优化算法）自动迭代你的 Agent prompt，直到 metric 达标。这比手动调 prompt 靠谱得多。
跟同类工具比：它在哪个位置
| 维度 | agents-cli | ADK 直接用 | Agent Starter Pack | agentic-awesome-skills |
|---|---|---|---|---|
| 定位 | Agent 开发的 AI 辅助层 | Agent 框架 | 项目模板 | 通用 Skill 库 |
| 需要 Coding Agent | 是（增强模式） | 否 | 否 | 是 |
| 覆盖生命周期 | 完整 7 阶段 | 仅编码 | 编码 + 部署 | 仅编码辅助 |
| 内置评估系统 | ✅ 6 种 metric + 自定义 | ❌ 需自行搭建 | ❌ | ❌ |
| Prompt 自动优化 | ✅ GEPA | ❌ | ❌ | ❌ |
| 可独立使用 | ✅ CLI 命令 | ✅ | ✅ | ❌ 需 Agent |
| Star | 5.3K | — | — | 43K |
选 agents-cli 的理由：你在用 Google Cloud 生态，想让 Coding Agent 帮你端到端构建 ADK Agent，不只是写代码。
选 ADK 直接用的理由：你不需要 AI 辅助，自己对 ADK 很熟。
选 agentic-awesome-skills 的理由：你不在 Google 生态里，需要通用的编码辅助 Skills。
上手指南
安装
# 一行搞定（需要 Python 3.11+、uv、Node.js）
uvx google-agents-cli setup
# 或者只装 Skills，让 Coding Agent 自己处理剩下的
npx skills add google/agents-cli认证
# Google Cloud 认证
agents-cli login
# 或者用 AI Studio API Key（不需要 GCP 项目）
export GEMINI_API_KEY=your-key-here创建第一个 Agent
# 在你的 Coding Agent 里直接说：
# "用 agents-cli 帮我搭建一个天气查询 Agent"
# 或者手动操作：
agents-cli scaffold create my-weather-agent
cd my-weather-agent本地运行和测试
# 快速测试
agents-cli run "北京今天天气怎么样？"
# 打开 Web Playground 手动测试
agents-cli playground
# 跑评估
agents-cli eval run部署
# 先增强项目（添加部署配置）
agents-cli scaffold enhance . --deployment-target agent-runtime
# 部署到 Google Cloud
agents-cli deploy踩坑实录
坑 1：uv 版本要新。 agents-cli 依赖 uv 做 Python 包管理，某些系统的 uv 版本太老会导致安装失败。建议用官方脚本装最新版：curl -LsSf https://astral.sh/uv/install.sh | sh。
坑 2：Skill 加载时机很关键。 Skills 之间有依赖关系——workflow 是入口，eval 必须在评估前加载，deploy 必须在部署前加载。如果 Coding Agent 跳过了 Skill 加载直接写代码，会缺少关键的约束和最佳实践。README 里明确说了"Phase 开始前重新读一遍相关 Skill"。
坑 3：eval 区域限制。 eval grade 和 eval submit 默认用 global 端点，不跟你 manifest 里配的 region 走。如果你的数据驻留要求严格，需要手动指定 --region，或者退回到本地自定义 metric。
坑 4：App name 必须匹配目录名。 ADK 的 App(root_agent=..., name="xxx") 里的 name 必须和 agent 所在目录名一致，否则会报 "Session not found"。这是 eval 和 deploy 的常见失败原因。
坑 5：不要让 pytest 测 LLM 输出。 agents-cli 明确反对用 pytest 检查 LLM 回复内容（比如断言包含某些关键词）。LLM 输出是非确定性的，这类测试必然 flaky。正确做法是用 eval + LLM-as-judge metric。
技术架构：Skills 是怎么工作的
agents-cli 的 Skills 不是传统的"代码插件"，而是结构化的知识文件。每个 Skill 由两部分组成：
- SKILL.md — 主文件，包含完整的指导流程、代码示例、决策表、常见陷阱
- references/ — 参考文件目录，存放详细的 API 文档、配置 schema、示例代码
这些文件被安装到 Coding Agent 的 Skills 目录里（比如 Claude Code 的 .claude/ 目录），Agent 在运行时根据用户请求自动加载对应的 Skill。
CLI 本身是 Python 写的，通过 uv tool 安装为全局命令。它封装了底层工具：
adk— ADK 框架的核心命令pytest— 代码正确性测试ruff— 代码质量检查uvicorn— 本地开发服务器- Google Cloud SDK — 部署和基础设施管理
适合谁
- Google Cloud 用户：已经在用 Vertex AI / Gemini，想快速搭建生产级 Agent
- ADK 开发者：用 Agent Development Kit 开发，需要标准化的开发流程
- 企业团队：需要评估、CI/CD、可观测性这些"生产级"能力，不只是写个 demo
- Coding Agent 用户：已经在用 Claude Code / Codex，想让它们帮你构建 Agent 而不只是写代码
不适合：不在 Google 生态里的开发者。虽然 CLI 可以独立使用（不需要 GCP 项目），但核心价值（部署、评估服务、可观测性）都绑定在 Google Cloud 上。
总结
agents-cli 做的事本质上是：把"构建 Agent"这件事从"查文档 + 手动操作"变成了"对话式 + 自动化"。7 套 Skills 覆盖完整生命周期，评估系统内置 6 种 metric + LLM-as-judge + 自动 prompt 优化，部署一键到位。
5300 Star 不算多，但它的定位跟那些"又一个 Agent 框架"完全不同。它不是在跟 LangChain、CrewAI 抢地盘——它是在帮你已有的 Coding Agent 变得更擅长构建 Agent。这个"元工具"的思路，值得每个做 Agent 开发的人关注。
# 现在就试试
uvx google-agents-cli setup
cd your-project
# 然后在 Claude Code 里说："帮我用 agents-cli 构建一个 Agent"