跳到正文
Google Developers Blog·· 22 小时前精选AI 评分63

Google Agents CLI 推出扩展系统并发布 LangChain 官方扩展

Powering the Agent Development Lifecycle with any framework, from ADK to LangChain and beyond

AI 导读

Google 为 Agents CLI 推出 Extension System，从 1.5.0 起允许开发者通过 Git 仓库中的 agents-cli-extension.yaml 覆盖或新增命令。

推荐理由

官方给出扩展系统的清单格式、锁定机制与 LangChain 模板，可看清框架无关的智能体开发链路如何落地。

正文 · AI 翻译

2026年10月21日

全新 Agents CLI 扩展系统的端到端演示，包含一个完整的 LangChain 示例和自定义部署策略

简介

当我们在 Google Cloud Next '26 上推出 Agents CLI 时，我们围绕一个坚定的理念构建了它：在 Google Cloud 上从想法到生产级 agent 应该只需一个统一的命令界面。对于使用 Agent Development Kit (ADK) 构建的团队来说，这条有明确主张的路径一直行之有效。你运行 agents-cli create，编写 agent 逻辑，然后部署到 Cloud Run，可观测性和评估都已配置好，整个过程大约三十分钟。

此后几个月里，agent 框架的格局变得更加多样化。除了 ADK，如今的开发者还会在 LangChain 和 LangGraph、像 Deep Agents 这样的专业新秀，或针对特定业务领域定制的内部框架之间做选择。不同团队偏好不同的框架，而适合全新原型的框架选择，很少也适合生产迁移。企业管理员可能还希望在整个 ADLC 中为所有开发团队强制执行治理策略，例如：合规扫描、SSO 门禁、模型风险管理环节。

团队能否在不被迫采用 ADK、也不被迫接受每条命令默认行为的情况下，从 Agents CLI 的部署、评估和可观测性工作中获益？从 1.5.0 版本开始，答案是肯定的。Agents CLI 现在附带一个 扩展系统，让开发者无需 fork 工具即可覆盖或添加命令。1.8.0 版本附带了官方 LangChain 扩展，它用 LangChain 的对应实现替换了与框架耦合的命令，其余生命周期保持不变。

下面我们将演示两个流程。首先，为了向你展示使用 LangChain agent 的 ADLC，我们将展示如何通过官方扩展，在 Agents CLI 生命周期中搭建、运行、部署和评估一个 LangChain agent。然后，我们构建自己的小型扩展，用软件物料清单 (SBOM) 扫描包装 deploy 命令，演示企业平台团队可以用来在每个项目中强制执行自身策略的模式。两个流程使用相同的机制。

框架锁定问题

如今大多数可用的 agent 开发工具链都有一个共同局限：它们对某个特定框架有明确主张，而周边能力（部署目标、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 的文件。该文件声明扩展覆盖哪些内置命令，以及新增哪些命令。来自官方文档：

扩展是你让 agents-cli 适配它未内置的工作流的方式——不同的 agent 框架、组织的部署策略，或你自己的命令——而无需 fork 该工具。

扩展有两种形态，在使用扩展页面中有描述。命令覆盖会替换 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，它会重新解析引用并重新提示第三方信任。完整生命周期见 Using Extensions → Lifecycle 一节。

扩展系统在 v1.8.0 中标记为实验性。在系统最终确定之前，清单 schema 和命令接口仍可能以破坏性方式变更，因此依赖它的团队应固定其 Agents CLI 版本。

通过 Agents CLI 运行 LangChain

2 (2)

LangChain 第一方扩展是一个项目模板：一条命令即可搭建一个可运行的 LangChain agent，并接入 Agents CLI 生命周期。生成的项目对 google-adk 零依赖，并通过与 ADK 项目相同的代码路径部署到 Cloud Run。该模板自身的描述为：

通过 agents-cli 生命周期运行 LangChain agents、LangGraph graphs 和 Deep Agents。

在现代 LangChain（1.0 及更高版本）中，状态管理层由 LangGraph 提供，因此这三个框架共享共同的图表示。该模板用同一份代码服务这三个社区。

前置条件

在开始之前，我们需要：

Python 3.11 or later
uv package manager
Google Cloud SDK (gcloud)

Python

Copied

还需要一个已启用计费的 Google Cloud 项目。如果还没有，可以在 console.cloud.google.com 创建。

如果开发机器上尚未安装 Agents CLI，可以用一条命令安装：

uvx google-agents-cli setup

Python

Copied

最后，我们向 Google Cloud 进行身份验证，并启用 agent 在运行时将依赖的 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

Plain text

Copied

第 1 步：搭建项目

搭建项目和安装扩展是同一个操作。我们不是先安装扩展再搭建项目，而是将 agents-cli create 直接指向该扩展的模板，并固定到特定发布标签：

agents-cli create my-agent \
    --agent google/agents-cli/extensions/langchain/[email protected] \
    -d cloud_run

cd my-agent && agents-cli install

Plain text

Copied

输出确认搭建成功：

Agents CLI v1.8.0
Fetching remote template: google/agents-cli/extensions/langchain/[email protected]
> Verifying GCP credentials...
> ✓ Connected to project: your-project
✅ Success! Your agent project is ready.

Plain text

Copied

搭建好的项目根目录已包含一个 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

Plain text

Copied

结构看起来与 ADK 项目相似：相同的 app/、相同的 tests/、deployment/ 下相同的 Terraform、根目录下相同的 manifest。两处差异在于顶部的 agents-cli-extension.yaml（承载 LangChain 覆盖配置）和 langgraph.json 文件（配置本地 playground 使用的 LangGraph 开发服务器）。

主 agent 定义位于 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"
)

纯文本

已复制

该 agent 通过 langchain.agents.create_agent 辅助函数创建，它会编译为 LangGraph CompiledStateGraph。root_agent 上的类型注解明确了这一点。现代 LangChain 使用 LangGraph 作为其状态管理层，因此该模板被定位为通过同一生命周期支持 LangChain agents、LangGraph graphs 和 Deep Agents：三者都编译为相同的底层图。

脚手架生成的项目不包含对 Agent Development Kit 的依赖。我们可以直接验证：

$ grep -r "google.adk\|google-adk" pyproject.toml app/
$ echo "exit: $?"
exit: 1

纯文本

已复制

grep 未返回任何匹配项，退出码 1 确认不存在 ADK 引用。pyproject.toml 中确实出现的 google-* 包是任何 Google Cloud Python 项目都会包含的：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。

3 (1)

要确认扩展修改了哪些命令，我们可以检查帮助输出：

$ 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 agent 对象才能进行内省，因此 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 中的完全相同。LangChain 模板通过 FastAPI 提供 A2A（Agent-to-Agent）协议流量，在 app.fast_api_app:app 下暴露应用。部署路径无需知道是哪个框架在驱动该 agent，因为 uvicorn 和 gcloud run deploy 都基于 FastAPI 契约运行。

4 (1)

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

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.

Plain text

已复制

清晰的拒绝比静默失败更有用，尤其是当编码助手在驱动终端时，否则它可能会在放弃之前多次重试一条损坏的命令。

编写你自己的扩展

LangChain 模板是扩展系统的第一方演示，但同样的机制对任何想要自定义 Agents CLI 命令面的团队都是开放的。企业平台团队可以在内部编写和分发扩展，将其策略编码为代码，并通过他们已用于其他一切事务的 Git 基础设施进行分发。团队中的每位开发者随后默认遵循相同的检查。

为了说明这一模式，我们将构建一个名为 sbom-deploy 的小型扩展，它用软件物料清单（SBOM）扫描包装 deploy 命令，如果发现任何严重漏洞就拒绝部署。清单 schema 的权威参考是 Authoring Extensions 页面。

第 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).

Plain text

已复制

清单包含五个顶层键，不允许有其他键。该 schema 使用严格校验，因此像 reqires: 这样的拼写错误会导致安装失败并给出“您是不是想输入”的建议，而不是静默丢弃该覆盖项。

schema 字段标识清单 schema 版本。name 字段是单个路径组件（斜杠和父目录引用会被拒绝），并成为 extensions/ 下存储 vendored 副本的目录。requires 块声明扩展支持哪些版本的 Agents CLI，以及一个控制版本不匹配时行为的策略（warn 或 error）。commands 块是实际覆盖和新增内容所在之处。

编写文档中的 Rules that matter 部分列举了其他值得了解的约束。特别是两条：你可以覆盖特定的子命令（例如 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 会在通过 override 调用的任何脚本的环境中设置它。当我们的包装脚本递归调用 agents-cli deploy 时，该调用会落到原生的 deploy 命令中，而不会循环回我们自己的 override。无需特殊语法，也不会递归。

5 (1)

我们可以直接验证这一点。为便于演示，我们把 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 add 将我们的 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

纯文本

已复制

锁文件和 extensions/ 下随附的工作副本都应提交。在全新检出时，agents-cli install 会从固定的 SHA 重新生成经过审查的确切代码，就像 uv sync 或 npm install 恢复固定依赖那样。install 命令永远不会推进固定版本，因此扩展无法在同一提交的两次部署之间改变其行为。

要将固定版本推进到所跟踪引用（分支、标签或 SHA）上的最新提交，开发者需运行 agents-cli extension update sbom-deploy。要切换到其他标签或分支，请用新的 --ref 重新运行 agents-cli extension add。完整生命周期详见使用扩展 → 生命周期一节。

下一步

Agents CLI 最初是一条在 Google Cloud 上交付 ADK 智能体的有主见路径。有了扩展系统，这些主见现在可以由你来覆盖、替换或增强。

开始使用

安装 Agents CLI 并用两条命令搭建一个 LangChain 智能体：

uvx google-agents-cli setup
agents-cli create my-agent --agent google/agents-cli/extensions/langchain/[email protected] -d cloud_run

纯文本

已复制

然后浏览官方文档：扩展概览、使用扩展、编写扩展以及第一方扩展。Agents CLI 的完整源代码（包括第一方模板）位于github.com/google/agents-cli。

上一页

下一页

来源：Google Developers Blog · developers.googleblog.com

Google / GeminiAgent 智能体部署工程产品更新#产品更新#Agent#部署/工程#Google