Agent 工程终于有脚手架了， Google开源一个开发agent的工具

Google最近开源了一个叫agents-cli的工具，直接把Agent开发从"能跑"推到了"能上线"的层面。这个工具的核心价值在于：它为AI Agent的开发提供了从创建、测试到部署的全流程工程化支持，解决了开发者长期以来工具链断裂的痛点。

Karpathy前段把一个词讲热了：Agentic Engineering。听着抽象，落到项目里其实就是三件事：需求写清楚、评估反复压、补齐工程活——安全、权限、部署、观测，一个不能少。

过去做Agent，最容易卡在中间。写代码在编辑器，起项目在终端，测试得开浏览器，部署要进云控制台，评估还得再接一套框架。每一步都能做，但每换一个工具，脑子里的上下文就断一截。

agents-cli解决的正是这段断裂。它不提供新的聊天机器人，也不替代Claude Code、Codex或Cursor。它更像一套给coding agent装的工程技能包，告诉它们怎么用Google的ADK、Agent Runtime、Cloud Run、Gemini Enterprise去搭、测、发一个企业级Agent。

GitHub上的定位很直白：这是一套CLI和skills，用来把常见coding assistant变成更懂Google Cloud Agent Platform的开发助手。它支持Antigra vity CLI、Claude Code、Codex，也可以配合其他coding agent。安装后，会给coding agent注入7类技能：

• google-agents-cli-workflow
  ：Agent开发生命周期和代码保留规则。

• google-agents-cli-adk-code
  ：ADK Python API、tools、callbacks、state等写法。

• google-agents-cli-scaffold
  ：创建、增强、升级Agent项目。

• google-agents-cli-eval
  ：评估集、指标、LLM-as-judge、rubric。

• google-agents-cli-deploy
  ：Agent Runtime、Cloud Run、GKE、CI/CD、secrets。

• google-agents-cli-publish
  ：注册到Gemini Enterprise。

• google-agents-cli-observability
  ：Cloud Trace、日志和观测接入。

这个设计的关键不只是"又多一个命令行工具"，而是想将Agent项目从demo拉到可交付状态。能创建项目只是第一步，能测试、能部署、能被组织里的人找到，才算走完。

第一步：安装

只要准备好Python 3.11+、uv和Node.js，跑一句命令就行：

uvx google-agents-cli setup

如果只想装skills，让coding agent接管后面的工作，也可以用：

npx skills add google/agents-cli

装完后，打开你常用的coding agent——比如Claude Code、Codex、Cursor或Antigra vity CLI，让它们按自然语言指令去创建项目。

第二步：让coding agent搭一个RAG Agent

一个可复现的起手式是这样的：

Build a RAG agent that ingests documents, retrieves relevant context,
and answers questions with source citations. Use the ADK agentic_rag
template with Gemini 3.5 Flash.

在Akshay的测试中，Claude Code调用了agents-cli的ADK skills，从agentic_rag模板搭出项目，用Vector Search做datastore，还补了citation相关逻辑——回答必须有引用，retriever返回文档时带source ID。

这一步很关键。很多RAG demo只演示"能答"，企业更关心回答有没有资料依据。引用链如果一开始没设计，后面再补会很麻烦。

第三步：本地先测一轮

项目起来后，直接让coding agent启动ADK Web UI：

Spin up a local dev server so I can test this.

本地测试至少要看两类问题。

第一类是资料里能回答的问题。比如"how to merge two dictionaries?"，Agent应该能检索到对应内容，解释|合并和update()方法，并附上类似[source: 1003]的引用。

第二类是资料里没有的问题。比如"who won the FIFA World Cup in 2022?"，Agent应该承认资料不足，不能凭常识硬答。RAG项目上线前，这类拒答测试比"答得很顺"更有价值。

第四步：上线前做评估

很多Agent项目死在这里：demo能跑，评估没有。Karpathy曾提出一个观察：运行Agent的团队里，做observability的比例高于做evals的比例。可没有evals，日志再多，也很难判断改动有没有把系统弄坏。

可以直接让coding agent生成评估集：

Generate 20 test scenarios for this RAG agent covering correct retrieval,
insufficient context where the agent should say it doesn't know,
multi-hop questions, and citation accuracy. Run the full eval suite and
show me the results.

这20个case可以分成四组：6个正确检索问题、5个资料不足时拒答的问题、5个需要多文档推理的问题、4个citation accuracy问题。Akshay的测试结果中，引用准确率20/20，通过。但eval也抓到一个洞：当问题不在语料里时，Agent有时会补一句通用知识。问题来自instruction里的一行宽松规则，大意是"简单问题可以不用工具直接回答"。删掉这行，拒答行为才会稳定。

这就是eval的价值——分数表只是表面结果，最有用的是提前暴露那些容易被忽略的指令漏洞。

第五步：部署到Agent Runtime

评估过后，让coding agent处理部署：

Deploy this to Agent Runtime in us-central1.

agents-cli会把项目补齐为Agent Runtime可部署的形态，加入入口文件和基础设施配置。根据这次测试，部署到Google Cloud大概花了2到3分钟。Cloud Trace默认接入，这一点对团队协作很实用：Agent出问题时，不能只看聊天记录，还要能回到trace、日志、调用链里定位是哪一步坏了。

第六步：注册到Gemini Enterprise

很多内部Agent做完后，只停留在"某个同事机器上能跑"。别人不知道它存在，也拿不到endpoint、权限和使用方式。这样的Agent很快就会被遗忘。

继续让coding agent执行：

Register this agent to Gemini Enterprise.

注册后，它会出现在Gemini Enterprise app里，组织内有权限的人可以发现和使用。IAM控制访问，企业面板负责观测。到这一步，一个RAG Agent才从个人demo变成团队可用的内部知识助手。

可以怎么用在自己的项目里

如果只是想试水，不用一上来就做复杂Agent。更稳的路径是：

1. 先选一个低风险知识库，比如团队FAQ、产品术语表、内部onboarding文档。
2. 用agents-cli scaffold或setup后的coding agent建一个RAG项目。
3. 写15到30个真实问题，里面故意混入资料不足、歧义、多跳问题。
4. 先跑eval，再改instruction，不要只靠手感调prompt。
5. 本地测过后再部署，部署后补trace、权限、成本监控。
6. 最后再考虑注册到企业入口，让团队成员能找到它。

GitHub README里列出的常用命令值得保存：

agents-cli scaffold 
agents-cli eval generate
agents-cli eval grade
agents-cli deploy
agents-cli publish gemini-enterprise

如果已经有一个ADK项目，也可以用：

agents-cli scaffold enhance

它会帮旧项目补上部署、CI/CD或RAG相关能力。

使用前要先想清楚的地方

agents-cli很适合Google Cloud和ADK体系内的Agent工程。如果团队已经在用Vertex AI、Cloud Run、Gemini Enterprise，它能省掉不少胶水工作。

但它也带来一个前提：部署、观测、企业注册这些能力都和Google Cloud绑定得比较深。个人开发者可以本地玩起来，但真要走上云端和企业入口，还是要处理账号、计费、权限、服务条款和区域合规。

另一个提醒是，不要把"coding agent能自动跑完整流程"理解成可以少做验收。脚手架能加速，eval和权限检查不能省。Agent最危险的地方往往不在答不上来，而在资料不足时答得太顺。

判断标准

如果Agent还停留在玩具demo阶段，agents-cli可能显得有点重。直接用ADK或LangGraph写一个本地原型，反而更快。

但如果已经遇到这些问题，它就值得试：

• 每个Agent都要重新搭项目结构。
• 评估集总是上线前才想起来。
• 部署脚本、权限、Cloud Run配置反复复制。
• 内部Agent做完后没人知道入口在哪里。
• 团队希望coding agent不只写代码，还能按工程规范把项目推到可上线状态。

Agent开发接下来的比拼，不会只是模型调用能力。更麻烦的部分在评估、权限、部署、观测、组织分发。Google这次把这些环节塞进一个CLI和一组skills里，方向是对的：让coding agent少当"会写代码的助手"，多承担一点工程交付的脏活。