全新 Agents CLI 扩展系统的端到端演示，包含一个完整的 LangChain 示例和自定义部署策略
引言
当我们在 Google Cloud Next '26 上推出 Agents CLI 时，我们围绕一个坚定的理念来构建它：在 Google Cloud 上从想法走向生产级智能体，应当只需一个统一的命令界面。对于使用 Agent Development Kit（ADK）构建的团队来说，这条有明确主张的路径一直行之有效。你运行 agents-cli create，编写智能体逻辑，然后部署到 Cloud Run，可观测性和评估均已接好，整个过程大约三十分钟。
此后数月间，智能体框架的格局变得更加多样。除了 ADK，开发者如今还会在 LangChain 与 LangGraph, 以及像 Deep Agents, 这样的专业新秀，或针对特定业务领域量身定制的内部框架之间做选择。不同团队偏好不同的框架，而适合全新原型的框架选择，很少也适合生产迁移。企业管理员可能还希望在整个 ADLC 中对其所有开发团队强制执行治理策略，例如：合规扫描、SSO 关卡、模型风险管理环节。
团队能否在不被迫采用 ADK、也不被迫接受每条命令默认行为的前提下，受益于 Agents CLI 中的部署、评估和可观测性工作？从 1.5.0 版本开始，答案是肯定的。 Agents CLI 现在内置了 扩展系统 ，让开发者无需 fork 工具即可覆盖或新增命令。 1.8.0 版本内置了第一方 LangChain 扩展，它将与框架耦合的命令替换为对应的 LangChain 实现，而生命周期的其余部分保持不变。
下面我们将介绍两条路径。首先，为了向你展示使用 LangChain 智能体的 ADLC，我们将演示如何借助第一方扩展，通过 Agents CLI 生命周期来搭建、运行、部署和评估一个 LangChain 智能体。然后，我们构建一个自己的小型扩展，用软件物料清单（SBOM）扫描来包装 deploy 命令，展示企业平台团队可用于在每个项目中强制执行自身策略的模式。两条路径使用相同的机制。
框架锁定问题
当今大多数可用的智能体开发工具链都有一个共同的局限：它们对某个特定框架有明确主张，而周边能力（部署目标、CI/CD 流水线、评估框架、可观测性接入）都假定开发者已采用该框架。当你的框架与工具的假设一致时，这条有明确主张的路径就能奏效。当不一致时，你就只剩下三个糟糕的选项。
第一个是 fork CLI，维护一份分叉副本，并在每次上游发布时重新同步。你要承担永久的维护成本，而且每一项上游改进都必须手动合并进分叉。第二个是用自定义脚本包装 CLI，构建一套并行的命令界面来调用底层工具。问题在于，开发者（以及他们的编码助手）会忘记这层包装，直接调用底层工具，从而绕过预期的抽象层。第三个是彻底放弃、从零构建一切，这可能消耗团队未曾计划的数个工程师月的工作量，而且很少能产出像上游项目那样精良的工具。
这个问题体现在两种场景中。其一是采用 Agents CLI 的企业客户：在受监管行业中，中央平台团队常常要求每次 deploy 调用都包装合规检查、要求 login 通过企业单点登录，或要求评估流经模型风险管理流水线。这些需求若在今天实现，都意味着要么 fork CLI，要么构建包装层。其二是大部分时间使用 ADK、但需要在特定项目上运行非 ADK 框架的团队。在 Agents CLI 的命令界面中，有六条命令假定使用 ADK 运行时： playground, run, 以及四个 eval 子命令。其余约十八条（scaffold, infra, deploy, publish, login, 等）与框架无关。在没有扩展的情况下，为单个项目选择非 ADK 框架就意味着失去全部二十四条命令。
扩展系统用一个机制同时解决这两个问题。
什么是 Agents CLI 扩展？
Agents CLI 扩展是 Git 仓库中的一个目录，其中包含一个名为 agents-cli-extension.yaml的文件。该文件声明扩展覆盖哪些内置命令，以及新增哪些命令。根据 官方文档:
，扩展是你在不 fork 工具的情况下，让 agents-cli 适配它并未内置的工作流的方式——无论是不同的智能体框架、组织的部署策略，还是你自己的命令。
扩展有两种形态，详见 使用扩展 页面。命令覆盖会替换内置命令（如 playground, deploy, 或 eval generate）的行为。被覆盖的命令会原样接收用户的参数，因此用户体验与原生命令保持一致。新命令则以 agents-cli <your-command>的形式暴露 CLI 当前未提供的工作流。两种形态可以在同一个扩展中共存，大多数非平凡的扩展都会组合使用两者。
扩展通过 Git 仓库分发，而非通过专门的包注册表。该设计借鉴了 gemini-cli 项目所使用的扩展模型。没有需要发布到的中央索引，没有需要维护的包格式，也没有需要申请的归属名册。任何 Git 仓库中的任何目录都可以作为扩展，而 Git 负责版本管理、固定和分发。对于企业平台团队而言，这意味着创建一个内部 platform-extensions 仓库并让开发者指向它，无需与任何外部注册表协调。
引用形式
扩展可以通过多种方式引用，具体取决于它所在的位置以及开发者希望如何使用它：
# First-party shorthand, which resolves to the google/agents-cli repository
agents-cli extension add <name>
# Any organization or repository on GitHub, including self-hosted Git servers
agents-cli extension add acme/platform-extensions
agents-cli extension add acme/platform-extensions#soc2-deploy
# A local path, which is typically used during extension development
agents-cli extension add local@../my-extension这种 #<name> 语法允许单个 Git 仓库容纳多个扩展，并通过片段标识符选择其中之一。企业平台仓库通常会将一组相关的扩展（一个用于 deploy，一个用于 login，一个用于 scaffold create）打包在同一个仓库下，共享所有权和发布节奏。
作用域
扩展可在两个作用域下安装。默认是项目作用域，此时扩展及其锁文件条目会被提交到项目自身的仓库中。队友和 CI 流水线在检出时即可获取。另一种是用户作用域，通过 --global flag启用，此时扩展存储在用户的主配置目录中，并应用于该机器上的每个项目。当你需要扩展在任何项目存在之前就可用时，例如一个用于配置 agents-cli create 本身的框架引导扩展，就会选择用户作用域。
当两个作用域定义了相同的命令时，项目作用域优先，并且 agents-cli info 会显示每个活动命令的来源。作用域划分是刻意显式的：扩展系统不会静默合并或覆盖扩展，任何冲突都会在安装时或 extension list 输出中呈现给开发者。
锁文件与生命周期
扩展系统遵循 uv 或 npm等包管理器的规范：它在安装时将 Git 引用解析为确切的提交 SHA，把解析后的 SHA 记录到锁文件中，并使用锁文件在每次全新检出时重新生成经过审查的确切代码。 agents-cli install 命令会从固定的 SHA 恢复 vendored 工作副本，而不会推进该固定点，从而保证 CI 和本地开发运行逐位完全相同的代码。要将固定点推进到所跟踪引用上的最新提交，开发者需运行 agents-cli extension update，它会重新解析该引用并重新提示第三方信任。完整生命周期见 使用扩展 → 生命周期 一节。
扩展系统在 v1.8.0 中被标记为实验性。在系统最终确定之前，清单模式和命令接口仍可能发生破坏性变更，因此依赖它的团队应固定其 Agents CLI 版本。
通过 Agents CLI 运行 LangChain
LangChain 第一方扩展是一个项目模板：一条命令即可搭建一个接入 Agents CLI 生命周期的可运行 LangChain 智能体。生成的项目不依赖 google-adk ，并通过与 ADK 项目相同的代码路径部署到 Cloud Run。该模板自身的描述为：
通过 agents-cli 生命周期运行 LangChain 智能体、LangGraph 图和 Deep Agents。
在现代 LangChain（1.0 及更高版本）中，状态管理层由 LangGraph 提供，因此这三个框架共享一种通用的图表示。该模板用同一份代码服务这三个社区。
前提条件
在开始之前，我们需要：
Python 3.11 or later
uv package manager
Google Cloud SDK (gcloud)还需要一个已启用计费的 Google Cloud 项目。如果还没有，可以在 console.cloud.google.com.
如果开发机器上尚未安装 Agents CLI，可以通过一条命令完成安装：
uvx google-agents-cli setup最后，我们使用 Google Cloud 进行身份验证，并启用智能体在运行时依赖的 API：
gcloud auth application-default login
gcloud config set project YOUR_PROJECT_ID
gcloud services enable aiplatform.googleapis.com run.googleapis.com artifactregistry.googleapis.com第 1 步：搭建项目脚手架
搭建脚手架与安装扩展是同一个操作。我们无需先安装扩展再搭建项目，而是将 agents-cli create 直接指向扩展的模板，并固定到特定的发布标签：
agents-cli create my-agent \
--agent google/agents-cli/extensions/langchain/template@v1.8.0 \
-d cloud_run
cd my-agent && agents-cli install输出确认脚手架搭建成功：
Agents CLI v1.8.0
Fetching remote template: google/agents-cli/extensions/langchain/template@v1.8.0
> Verifying GCP credentials...
> ✓ Connected to project: your-project
✅ Success! Your agent project is ready.搭建好的项目根目录下已经包含一个 agents-cli-extension.yaml ，下次调用任何命令时它会在项目作用域内自动加载。无需手动安装任何内容，因为项目本身就是该扩展的安装。搭建 LangChain 项目的开发者无需知道扩展系统的存在。该命令的外观和体验就像一次原生的 agents-cli create 调用，只不过生成的是 LangChain 项目而非 ADK 项目。
第 2 步：检查生成的结构
以下是脚手架生成的内容：
my-agent/
├── agents-cli-extension.yaml # auto-loaded project-scope overrides
├── agents-cli-manifest.yaml # project configuration (deployment target, etc.)
├── GEMINI.md # project's coding-agent guide
├── langgraph.json # LangGraph dev-server configuration
├── pyproject.toml # langchain, langgraph, langchain-google-genai
├── Dockerfile # identical CMD to any ADK project
├── app/
│ ├── agent.py # exports root_agent: CompiledStateGraph
│ ├── fast_api_app.py # exposes `app: FastAPI` on A2A
│ └── app_utils/
│ ├── a2a.py # LangGraphAgentExecutor and A2A routes
│ └── telemetry.py # Cloud Trace and GenAI logging
├── scripts/
│ ├── run.py # drop-in replacement for `agents-cli run`
│ ├── eval_generate.py # drop-in replacement for `agents-cli eval generate`
│ └── publish.py # Agent-Runtime-aware refusal wrapper
├── tests/
│ └── eval/datasets/basic-dataset.json
├── deployment/ # Terraform infrastructure modules
├── uv.lock
└── .agents/skills/agents-cli-langchain/ # the project's own coding-agent skill该结构看起来与 ADK 项目相似：相同的 app/、相同的 tests/、 deployment/下相同的 Terraform、根目录下相同的清单文件。两处差异在于 agents-cli-extension.yaml 顶部的文件（包含 LangChain 覆盖配置）以及 langgraph.json 文件（配置本地 playground 所使用的 LangGraph 开发服务器）。
主智能体定义位于 app/agent.py:
"""LangChain agent: a Gemini ReAct agent with a sample tool."""
import os
from dotenv import load_dotenv
from langchain.agents import create_agent
from langchain_google_genai import ChatGoogleGenerativeAI
from langgraph.graph.state import CompiledStateGraph
load_dotenv()
if not (os.environ.get("GOOGLE_API_KEY") or os.environ.get("GEMINI_API_KEY")):
import google.auth
_, project_id = google.auth.default()
os.environ["GOOGLE_CLOUD_PROJECT"] = project_id
os.environ["GOOGLE_CLOUD_LOCATION"] = "global"
os.environ["GOOGLE_GENAI_USE_VERTEXAI"] = "True"
LLM = "gemini-3.8-flash"
llm = ChatGoogleGenerativeAI(model=LLM, temperature=0)
def get_weather(query: str) -> str:
"""Simulates a web search. Use it get information on weather."""
if "sf" in query.lower() or "san francisco" in query.lower():
return "It's 60 degrees and foggy."
return "It's 90 degrees and sunny."
root_agent: CompiledStateGraph = create_agent(
model=llm, tools=[get_weather], system_prompt="You are a helpful assistant"
)该智能体通过 langchain.agents.create_agent 辅助函数创建，该函数会编译为 LangGraph CompiledStateGraph。 root_agent 上的类型注解使这一点变得明确。现代 LangChain 使用 LangGraph 作为其状态管理层，因此该模板被定位为通过同一生命周期支持 LangChain 智能体、LangGraph 图和 Deep Agents：这三者都会编译为相同的底层图。
脚手架生成的项目不包含对 Agent Development Kit 的任何依赖。我们可以直接验证这一点：
$ grep -r "google.adk\|google-adk" pyproject.toml app/
$ echo "exit: $?"
exit: 1grep 未返回任何匹配项，退出码 1 证实不存在 ADK 引用。确实出现的 google-* 包是任何 Google Cloud Python 项目都会包含的那些： pyproject.toml 、 google-cloud-aiplatform[evaluation], google-cloud-logging, langchain-google-genai以及 OpenTelemetry Google Cloud 导出器。
agents-cli run "what's the weather in San Francisco?"该命令输出：
WARNING:root:agents-cli: applying 6 extension command(s): eval.dataset [langchain/project], eval.generate [langchain/project], eval.optimize [langchain/project], playground [langchain/project], publish.gemini-enterprise [langchain/project], run [langchain/project]
The weather in San Francisco is currently 60°F and foggy.在幕后，Vertex AI 上的 Gemini-3.8-flash 已在进程内调用了编译后的图，并调用了 get_weather("San Francisco")，收到了模拟的雾天响应，并将最终句子推理回传给用户。警告行告诉我们哪些扩展命令处于活动状态，每个被覆盖的命令对应一个条目。该警告是有意为之：覆盖会悄然改变原生行为，因此加载器始终会宣告哪些命令被拦截以及由谁拦截。
对于本地检查器， agents-cli playground 会在 8080 端口启动 LangGraph Studio，取代原本会出现的 ADK Web UI。
要确认扩展修改了哪些命令，我们可以检查帮助输出：
$ agents-cli --help | grep -E "playground|run "
playground Start the local LangGraph dev server. [↑ langchain]
run Run the compiled agent graph with a single prompt. [↑ langchain]该 [↑ langchain] 后缀是扩展系统用来表示某条命令已被覆盖的方式，同时还会给出负责该覆盖的扩展名称。无论是阅读终端的真人开发者还是编码助手，都能一眼看出这个项目里哪些命令的行为有所不同。
如需完整清单， agents-cli info 会列出每个处于活动状态的扩展及其执行的确切命令向量：
Extensions (experimental):
eval.dataset (override, project) <- langchain: uv run python scripts/unsupported.py eval dataset
eval.generate (override, project) <- langchain: uv run python scripts/eval_generate.py
eval.optimize (override, project) <- langchain: uv run python scripts/unsupported.py eval optimize
playground (override, project) <- langchain: uv run langgraph dev --no-browser --port 8080
publish.gemini-enterprise (override, project) <- langchain: uv run --with pyyaml python scripts/publish.py
run (override, project) <- langchain: uv run python scripts/run.py共有六处覆盖，分为三类：四个与框架耦合的替换（playground, run, eval.generate, 以及 publish.gemini-enterprise），两个明确的拒绝（eval.dataset 和 eval.optimize 需要 ADK 智能体对象才能进行内省，因此 LangChain 项目会干净利落地拒绝它们，而不是产生无效结果），以及那个 publish.gemini-enterprise 此外，该覆盖仅在 Agent Runtime 部署目标上拒绝执行，而在 Cloud Run 和 GKE 上则委托给原生命令。 第一方框架 页面提供了官方分类说明。
第 4 步：部署到 Cloud Run
该 deploy 命令不会被 LangChain 扩展覆盖。将 LangChain 项目部署到 Cloud Run 所使用的代码路径与部署 ADK 项目完全相同：
agents-cli deploy底层机制会针对项目的 Dockerfile 调用 gcloud run deploy --source .，其中包含：
CMD ["uv", "run", "uvicorn", "app.fast_api_app:app", "--host", "0.0.0.0", "--port", "8080"]该 CMD 与 ADK 项目 Dockerfile 中的 CMD 完全相同。LangChain 模板通过 FastAPI 处理 A2A（Agent-to-Agent）协议流量，并在 app.fast_api_app:app部署路径无需知道是哪个框架在驱动智能体，因为 uvicorn ，以及 gcloud run deploy 基于 FastAPI 契约运行。
这一点同样适用于 infra, scaffold enhance, scaffold upgrade, install, info, setup, lint，以及 login在 LangChain 项目中，所有内容均保持不变。针对这些命令长达一年的 Agents CLI 工作成果将免费落地到 LangChain 项目中，且无需在 ADK 与 LangChain 代码路径之间维护任何差异。
第 5 步：运行评估
LangChain 项目中的评估遵循 ADK 演练中熟悉的模式，只有一处不同： eval generate 步骤被覆盖以驱动 LangChain 图，而后续的评估步骤则使用原生命令：
agents-cli eval generate --dataset tests/eval/datasets/basic-dataset.json \
-o tests/eval/output/
agents-cli eval grade --traces tests/eval/output/basic-dataset.json \
--config tests/eval/eval_config.yaml
agents-cli eval compare tests/eval/output/run_1.json tests/eval/output/run_2.json被覆盖的 eval generate 命令会以标准 EvaluationDataset 格式，而原生 eval grade, eval compare，以及 eval analyze 命令知道如何消费。评估服务和评分标准与框架无关。
如果开发者调用某个被拒绝的 eval 子命令，扩展会给出明确的解释，而不是静默失败：
$ agents-cli eval dataset synthesize
agents-cli eval dataset is not supported by the langchain extension:
it runs the agent through ADK's user simulator, which needs google-adk
in this project's venv.明确的拒绝比静默失败更有用，尤其是当编码助手正在驱动终端时，否则它会在放弃之前多次重试一条已损坏的命令。
编写你自己的扩展
LangChain 模板是扩展系统的官方演示，但同样的机制也向任何希望自定义 Agents CLI 命令界面的团队开放。企业平台团队可以在内部编写和分发扩展，将策略编码为代码，并通过他们已用于其他所有事务的 Git 基础设施进行分发。随后，团队中的每位开发者默认都会遵循相同的检查。
为了说明这一模式，我们将构建一个小型扩展，名为 sbom-deploy ，它封装了 deploy 命令，并执行软件物料清单（SBOM）扫描，一旦发现任何严重漏洞就拒绝部署。清单模式的权威参考是 编写扩展 页面。
第 1 步：定义扩展清单
我们首先为扩展创建一个目录，并在其根目录下添加清单文件：
# agents-cli-extension.yaml
# yaml-language-server: $schema=https://raw.githubusercontent.com/google/agents-cli/main/schemas/agents-cli-extension-v1alpha1.schema.json
schema: agents-cli-extension/v1alpha1
name: sbom-deploy
description: Scan the project SBOM, then run the native agents-cli deploy.
requires:
agents_cli: ">=1.5,<2"
on_incompatible: warn
commands:
override:
deploy:
run: ["bash", "scripts/sbom_then_deploy.sh"]
description: SBOM scan via syft+grype, then the built-in deploy.
add:
sbom-report:
run: ["bash", "scripts/sbom_report.sh"]
description: Produce an SBOM for the current project (no deploy).清单包含五个顶层键，不允许出现其他键。该模式采用严格校验，因此像 reqires: 会安装失败，并给出“您是不是想输入……”的建议，而不是静默丢弃该覆盖项。
“ schema 字段标识清单架构版本。 name 该字段是单个路径组件（拒绝斜杠和父目录引用），并成为存放 vendored 副本的目录。该块声明扩展支持哪些版本的 Agents CLI，以及一个策略（或），用于控制版本不匹配时的行为。该块是实际覆盖和新增内容所在之处。编写文档中的“重要规则”部分列举了其他值得了解的约束。其中特别有两条：你可以覆盖特定的子命令（例如），但不能覆盖顶层命令组（例如整体），并且是一个命令向量 extensions/ 其中存放 vendored 副本。该 requires 块声明该扩展支持哪些版本的 Agents CLI，以及一个策略（warn 或 error），用于控制版本不匹配时的行为。“ commands 该块是实际覆盖和新增内容所在之处。
The 重要规则 编写文档中的“重要规则”部分列举了其他值得了解的约束。其中特别有两条：你可以覆盖特定的子命令（例如 eval.generate），但不能覆盖顶层命令组（例如 eval 整体），并且 run: 是一个命令向量，而不是 shell 命令，因此任何命令的串联都必须在包装脚本内部完成，而不是在清单内部完成。
第 2 步：编写包装脚本
因为 run: 是一个命令向量，在没有 shell 的情况下执行，因此串联多个操作意味着要编写一个包装脚本，显式地对它们进行排序：
#!/usr/bin/env bash
# scripts/sbom_then_deploy.sh
set -euo pipefail
cd "$(dirname "$0")/.."
echo "[sbom-deploy] generating SBOM..."
syft dir:. -o cyclonedx-json > /tmp/sbom.cdx.json
echo "[sbom-deploy] scanning for criticals..."
grype sbom:/tmp/sbom.cdx.json --fail-on critical
# AGENTS_CLI_DISABLE_OVERRIDES=1 is already set by the loader,
# so this call hits the built-in deploy. No infinite recursion.
echo "[sbom-deploy] SBOM clean; running native deploy..."
exec agents-cli deploy "$@"AGENTS_CLI_DISABLE_OVERRIDES=1 正是这一点让整个机制得以运作。Agents CLI 会把它设置到任何通过覆盖项调用的脚本的环境中。当我们的包装脚本调用 agents-cli deploy 递归地，调用会落到原生 deploy 命令，而不是循环回我们自己的覆盖项。无需特殊语法，也无需递归。
我们可以直接验证这一点。为作演示，我们把 SBOM 扫描替换为几条 echo 语句，用来确认环境和参数：
$ agents-cli deploy --project foo
[sbom-deploy] (demo) would scan SBOM here...
[sbom-deploy] AGENTS_CLI_DISABLE_OVERRIDES=1
[sbom-deploy] would then shell to: agents-cli deploy --project foo正是这一点让整个机制得以运作。 --project foo 标志会原样传递给包装脚本，而环境变量已由加载器在我们的脚本开始执行前设置好。包装脚本已具备委托给原生命令所需的一切。
第 3 步：安装并验证
在清单和包装脚本就位后，我们就可以安装该扩展了。在开发期间，指向本地路径：
agents-cli extension add local@../my-sbom-extension一旦扩展被推送到 Git 仓库，同样的语法也适用于远程引用：
agents-cli extension add acme/platform-extensions#sbom-deploy --ref v1.0.0安装完成后，我们通过列出已安装的扩展并检查帮助输出来验证该扩展是否已启用：
$ agents-cli extension list
Extensions:
langchain project (commands: eval.dataset, eval.generate, eval.optimize, playground, publish.gemini-enterprise, run)
sbom-deploy project (commands: deploy, sbom-report) requires: >=1.5,<2
$ agents-cli --help | grep -A1 -E "deploy|sbom-report"
deploy SBOM scan via syft+grype, then the built-in deploy. [↑
sbom-deploy]
sbom-report Produce an SBOM for the current project (no deploy). [↑
sbom-deploy]
$ agents-cli deploy --help
Usage: agents-cli deploy [OPTIONS] [EXTRA_ARGS]...
Overrides `deploy` via extension 'sbom-deploy' (project scope).
SBOM scan via syft+grype, then the built-in deploy.
Runs: bash scripts/sbom_then_deploy.sh
Argv after the command name passes through to the script verbatim.
To bypass extension overrides and run the built-in:
AGENTS_CLI_DISABLE_OVERRIDES=1 agents-cli deploy每个被覆盖命令旁边的标签是扩展系统面向用户的信号，表明该行为已被修改。 [↑ sbom-deploy] 每个被覆盖命令旁边的标签是扩展系统面向用户的信号，表明该行为已被修改。
锁文件纪律
在幕后， extension 将我们的 Git 引用解析为确切的提交 SHA，并将解析结果记录在项目根目录的锁文件中：
# agents-cli-extensions.yaml (lockfile; commit this to version control)
extensions:
- name: sbom-deploy
source: acme/platform-extensions#sbom-deploy
ref: v1.0.0
sha: a1b2c3d4...
scope: project锁文件和位于以下路径的 vendored 工作副本 extensions/ 应被提交。在全新检出时， agents-cli install 会从固定的 SHA 重新物化出经过审核的确切代码，方式与 uv sync 恢复固定依赖的方式相同。该命令永远不会推进固定点，因此扩展无法在同一提交的两次部署之间改变其行为。要将固定点推进到所跟踪引用（分支、标签或 SHA）上的最新提交，开发者需运行 。要切换到其他标签或分支，请使用新的 重新运行 。完整生命周期详见“使用扩展 → 生命周期”一节。下一步Agents CLI 最初是一条在 Google Cloud 上交付 ADK 智能体的既定路径。Wi npm install 恢复固定依赖。该 install 该命令永远不会推进固定点，因此扩展无法在同一提交的两次部署之间改变其行为。
要将固定点推进到所跟踪引用（分支、标签或 SHA）上的最新提交，开发者需运行 agents-cli extension update sbom-deploy。要切换到其他标签或分支，请使用新的 重新运行 。 agents-cli extension add 新的 --ref完整生命周期详见 使用扩展 → 生命周期 一节。
下一步
Agents CLI 最初是一条在 Google Cloud 上交付 ADK 智能体的既定路径。随着扩展系统的引入，这些既定做法现在可以由你覆盖、替换或增强。
开始使用
安装 Agents CLI，并用两条命令搭建一个 LangChain 智能体：
uvx google-agents-cli setup
agents-cli create my-agent --agent google/agents-cli/extensions/langchain/template@v1.8.0 -d cloud_run然后浏览官方文档： 扩展概览, 使用扩展, 编写扩展，以及 第一方扩展Agents CLI 的完整源代码（包括第一方模板）位于 github.com/google/agents-cli.
发布于： 上一篇 下一篇 相关文章
AI
教程
公告
EmbeddingGemma 2：开发者指南
2026年10月6日
AI
云
公告
最佳实践
将 TorchTPU 集成到 TorchTitan 并为 TPU 优化模型
2026年10月20日
移动端
AI
案例研究
学习
借助 Model Explorer 为自定义 Edge 编译器带来可视化图调试
2026年10月20日
AI
云
教程
案例研究
加速 TPU 上视频扩散的时空注意力
2026年9月30日