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

Google Developers Blog

Google Developers Blog2026年10月21日

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

8.5内容质量

TL;DR · AI 摘要

Google Cloud推出Agents CLI扩展系统，支持多种框架如LangChain，并允许自定义部署策略。

核心要点

Agents CLI 1.5.0引入扩展系统，支持LangChain等框架的集成。
企业可通过自定义扩展（如SBOM扫描）实施治理政策。
无需采用ADK框架即可使用Agents CLI的部署和评估功能。

结构提纲

按章节快速跳转。

§引言
介绍Agents CLI的背景及其从ADK框架扩展到支持多框架的演进。
·框架锁定问题
分析现有工具对单一框架的依赖导致的局限性及解决方案。
›扩展系统机制
详细说明Agents CLI 1.5.0扩展系统的核心设计与实现方式。
·LangChain集成示例
演示如何通过官方扩展实现LangChain代理的全生命周期管理。
›自定义扩展案例
展示SBOM扫描扩展的实现，说明企业治理策略的落地方法。
·未来方向
讨论扩展系统对多框架生态和企业治理的长期影响。

思维导图

用一张图看清主题之间的关系。

查看大纲文本（无障碍 / 无 JS 友好）

Agents CLI扩展系统
- 核心能力
  - 多框架支持（ADK/LangChain）
  - 自定义命令扩展
- 应用场景
  - 企业治理（SBOM扫描）
  - 开发流程自动化

金句 / Highlights

值得收藏与分享的关键句。

Agents CLI 1.5.0引入扩展系统，允许开发者自定义命令而无需fork工具。
— 第 2 段
⬇︎ 下载 PNG 𝕏 分享到 X
LangChain扩展将框架耦合命令替换为LangChain等价命令，保留其余生命周期功能。
— 第 2 段
⬇︎ 下载 PNG 𝕏 分享到 X
SBOM扫描扩展可作为企业级治理模板，强制所有项目通过合规检查。
— 第 3 段
⬇︎ 下载 PNG 𝕏 分享到 X

#Agents CLI#LangChain#Google Cloud#ADK#扩展系统

打开原文

使用任意框架（从 ADK 到 LangChain 及其他）赋能代理开发全生命周期 - Google Developers Blog

Google Tag Manager (noscript)

End Google Tag Manager (noscript)

HTML

使用任意框架（从 ADK 到 LangChain 及其他）赋能代理开发全生命周期

2026 年 10 月 21 日

Pier Paolo Ippolito

产品经理

Elia Secchi

解决方案专家

Facebook

Twitter

LinkedIn

邮件

全新代理 CLI 扩展系统端到端演示，包含 LangChain 示例和自定义部署策略

介绍

在 Google Cloud Next '26 上发布 Agents CLI 时，我们围绕一个核心理念构建：从创意到 Google Cloud 生产代理，应通过统一的命令界面完成。对于使用代理开发工具包（ADK）构建团队，这种理念路径已取得成功。您只需运行 agents-cli create，编写代理逻辑，约 30 分钟即可通过 Cloud Run 部署，同时集成可观测性和评估功能。

在随后的几个月中，代理框架生态系统变得更为多样化。除了 ADK，开发者如今需在 LangChain 和 LangGraph 之间选择，或采用新兴的垂直领域框架（如 Deep Agents），或使用针对特定业务领域的内部框架。不同团队偏好不同框架，且绿色原型的最佳选择往往不适用于生产环境迁移。企业管理员可能还希望在整个 ADLC（代理开发生命周期）中对所有开发团队实施治理策略，例如：合规扫描、SSO 验证、模型风险管理流程。

团队能否在不强制采用 ADK 或接受所有命令默认行为的前提下，利用 Agents CLI 的部署、评估和可观测性功能？从 1.5.0 版本开始，答案是肯定的。Agents CLI 现在内置扩展系统，允许开发者在不 fork 工具的前提下覆盖或添加命令。1.8.0 版本将发布官方 LangChain 扩展，该扩展将框架绑定命令替换为 LangChain 对应实现，同时保留其余生命周期功能不变。

下文将展示两个使用场景。首先，我们将通过官方扩展演示如何使用 Agents CLI 生命周期搭建、运行、部署和评估 LangChain 代理。然后，我们将构建一个自定义扩展，在部署命令中封装软件物料清单（SBOM）扫描，展示企业平台团队可用于在所有项目中实施策略的模式。两个场景均使用相同机制。

框架锁定问题

目前大多数代理开发工具链存在一个共同限制：它们对特定框架有偏见，其配套能力（部署目标、CI/CD 管道、评估框架、可观测性集成）均假设开发者已采用该框架。当您的框架与工具假设匹配时，这种偏见路径有效。但若不匹配，您将面临三个糟糕选择：

第一种方式是分叉 CLI，维护一个分支版本，并在每次上游发布时重新同步。这种方式需要付出永久的维护成本，且每次上游改进都需要手动合并到分支中。第二种方式是通过自定义脚本包装 CLI，构建一个并行的命令接口来调用底层工具。问题是开发人员（及其编码助手）可能会忽略包装层，直接调用底层工具，绕过预期的抽象层。第三种方式是完全放弃现有 CLI，从零开始构建所有功能。这可能需要消耗团队未计划的数月工程师工作量，且很少能产出与上游项目一样完善的工具。

该问题体现在两种场景中。一种是企业客户采用 Agents CLI 时：在受监管的行业中，中央平台团队通常要求每次部署调用都必须包裹合规性检查，登录流程必须通过企业单点登录，评估流程必须通过模型风险管理管道。目前实现这些需求的方式，要么是分叉 CLI，要么是构建包装层。另一种场景是团队平时主要使用 ADK，但某个特定项目需要运行非 ADK 框架。在 Agents CLI 的命令接口中，有六个命令假设 ADK 运行时：playground、run 和四个 eval 子命令。其余约十八个命令（scaffold、infra、deploy、publish、login 等）与框架无关。在没有扩展的情况下，为单个项目选择非 ADK 框架意味着将失去对所有 24 个命令的访问权限。

扩展系统通过一种机制同时解决这两种情况。

什么是 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 仓库，并将其指向开发人员，无需与外部注册表协调。

code

# 第一方简写方式，指向 google/agents-cli 仓库
agents-cli extension add <name>

# 任何组织或 GitHub 上的仓库，包括自托管的 Git 服务器
agents-cli extension add acme/platform-extensions
agents-cli extension add acme/platform-extensions#soc2-deploy

# 本地路径，通常在扩展开发期间使用
agents-cli extension add local@../my-extension

纯文本

已复制

#<name> 语法允许单个 Git 仓库包含多个扩展，通过片段标识符选择其中一个。企业平台仓库通常会将一组相关扩展（如部署、登录、生成创建）打包到一个共享所有权和发布节奏的仓库中。

作用域

扩展可以安装在两个作用域下。默认是项目作用域，扩展及其锁文件条目会提交到项目自己的仓库中。队友和 CI 管道在检出时会自动获取。另一种是用户作用域，通过 --global 标志启用，扩展存储在用户的主配置目录中，并适用于机器上的所有项目。当需要在任何项目存在之前就可用时（例如配置 agents-cli create 的框架引导扩展），通常会使用用户作用域。

当两个作用域定义了相同命令时，项目作用域具有优先级，agents-cli info 会显示每个活动命令的来源。作用域设计是明确的：扩展系统不会静默合并或覆盖扩展，任何冲突都会在安装时或扩展列表输出中向开发者提示。

锁文件与生命周期

扩展系统遵循类似 uv 或 npm 等包管理器的规范：在安装时将 Git 引用解析为确切的提交 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 提供，因此这三个框架共享相同的图表示。该模板通过相同代码服务于这三个社区。

先决条件

开始之前，我们需要：

code

Python 3.11 或更高版本
uv 包管理器
Google Cloud SDK (gcloud)

Python

需要启用计费功能的 Google Cloud 项目。如果没有现成的项目，可以在 console.cloud.google.com 创建。

如果开发机尚未安装 Agents CLI，可以通过以下命令一键安装：

code

uvx google-agents-cli setup

最后我们使用 Google Cloud 进行身份验证，并启用代理运行时依赖的 API：

code

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 指向扩展模板，并固定到特定版本标签：

code

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

cd my-agent && agents-cli install

输出确认框架搭建成功：

code

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.

生成的项目根目录已包含 agents-cli-extension.yaml 文件，该文件会在下次调用任何命令时自动加载。无需手动安装，因为项目本身即代表扩展安装。搭建 LangChain 项目的开发者无需了解扩展系统，该命令看起来和感觉上都像原生的 agents-cli create 调用，只是生成的是 LangChain 项目而非 ADK 项目。

第 2 步：查看生成的目录结构

以下是框架生成器创建的结构：

code

my-agent/
├── agents-cli-extension.yaml      # 自动加载的项目级覆盖配置
├── agents-cli-manifest.yaml       # 项目配置（部署目标等）
├── GEMINI.md                      # 项目的编码代理指南
├── langgraph.json                 # LangGraph 开发服务器配置
├── pyproject.toml                 # langchain, langgraph, langchain-google-genai
├── Dockerfile                     # 与任何 ADK 项目相同的 CMD
├── app/
│   ├── agent.py                   # 导出 root_agent: CompiledStateGraph
│   ├── fast_api_app.py            # 在 A2A 上暴露 `app: FastAPI`
│   └── app_utils/
│       ├── a2a.py                 # LangGraphAgentExecutor 和 A2A 路由
│       └── telemetry.py           # 云追踪和 GenAI 日志记录
├── scripts/
│   ├── run.py                     # `agents-cli run` 的即插即用替代
│   ├── eval_generate.py           # `agents-cli eval generate` 的即插即用替代
│   └── publish.py                 # 带有 Agent-Runtime 拒绝包装的发布脚本
├── tests/
│   └── eval/datasets/basic-dataset.json
├── deployment/                    # Terraform 基础设施模块
├── uv.lock
└── .agents/skills/agents-cli-langchain/   # 项目的编码代理技能

该结构与 ADK 项目类似：相同的 app/ 目录，相同的 tests/ 目录，部署目录下的 Terraform 也相同，根目录都有 manifest 文件。两个主要区别是顶部的 agents-cli-extension.yaml（包含 LangChain 覆盖配置）和 langgraph.json 文件（配置本地游乐场使用的 LangGraph 开发服务器）。

主代理定义位于 app/agent.py 中：

code

"""LangChain 代理：一个带有示例工具的 Gemini ReAct 代理"""

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:
    """模拟网络搜索。用于获取天气信息。"""
    if "sf" in query.lower() or "san francisco" in query.lower():
        return "气温60华氏度且有雾。"
    return "气温90华氏度且晴朗。"

root_agent: CompiledStateGraph = create_agent(
    model=llm, tools=[get_weather], system_prompt="你是一个乐于助人的助手"
)

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

该项目的框架中不包含对代理开发工具包（ADK）的依赖。我们可以直接验证这一点：

code

$ 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 导出器。

code

agents-cli run "旧金山的天气如何？"

该命令的输出为：

code

WARNING:root:agents-cli: 应用 6 个扩展命令：eval.dataset [langchain/project], eval.generate [langchain/project], eval.optimize [langchain/project], playground [langchain/project], publish.gemini-enterprise [langchain/project], run [langchain/project]
旧金山当前天气为 60 华氏度且有雾。

在幕后，Vertex AI 上的 Gemini-3.8-flash 已调用编译后的图进行处理，执行了 get_weather("San Francisco")，接收到了模拟的雾天响应，并推导出最终的回复返回给用户。警告行告诉我们哪些扩展命令处于活动状态，每个被覆盖的命令都有一个条目。该警告是刻意为之：静默覆盖会改变原生行为，因此加载器始终会宣布哪些命令正在被拦截以及由谁拦截。

对于本地检查者，agents-cli playground 会在 8080 端口启动 LangGraph Studio，替换原本会出现的 ADK Web 界面。

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

code

$ agents-cli --help | grep -E "playground|run "
  playground      启动本地 LangGraph 开发服务器。  [↑ langchain]
  run             使用单个提示运行编译后的代理图。  [↑ langchain]

code

[↑ langchain] 后缀是扩展系统用来表明某个命令已被覆盖的方式，同时会标明负责的扩展名称。无论是人类开发者还是阅读终端的编码助手，都可以一目了然地看出哪些命令在此项目中的行为有所不同。

要获取完整清单，可以使用 agents-cli info 命令列出每个活动扩展及其执行的精确命令向量：

扩展（实验性）： eval.dataset (覆盖，项目) <- langchain: uv run python scripts/unsupported.py eval dataset eval.generate (覆盖，项目) <- langchain: uv run python scripts/eval_generate.py eval.optimize (覆盖，项目) <- langchain: uv run python scripts/unsupported.py eval optimize playground (覆盖，项目) <- langchain: uv run langgraph dev --no-browser --port 8080 publish.gemini-enterprise (覆盖，项目) <- langchain: uv run --with pyyaml python scripts/publish.py run (覆盖，项目) <- langchain: uv run python scripts/run.py

code


总共6个覆盖项，分为三类：4个与框架耦合的替换项（playground、run、eval.generate 和 publish.gemini-enterprise），2个明确拒绝项（eval.dataset 和 eval.optimize 需要 ADK 代理对象进行内省，因此 LangChain 项目会干净地拒绝而不是生成无效结果），以及 publish.gemini-enterprise 覆盖项在 Agent Runtime 部署目标上额外拒绝，但在 Cloud Run 和 GKE 上会委托给原生命令。第一方框架页面有官方分类说明。

### 第4步：部署到 Cloud Run

LangChain 扩展未覆盖 deploy 命令。将 LangChain 项目部署到 Cloud Run 使用与部署 ADK 项目完全相同的代码路径：

agents-cli deploy

code


底层机制会调用 gcloud run deploy --source . 来针对项目中的 Dockerfile 进行部署，其中包含：

CMD ["uv", "run", "uvicorn", "app.fast_api_app:app", "--host", "0.0.0.0", "--port", "8080"]

code


该 CMD 与 ADK 项目 Dockerfile 中的命令完全相同。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

code


JSON

覆盖的 `eval generate` 命令会以标准 `EvaluationDataset` 格式生成输出，而原生的 `eval grade`、`eval compare` 和 `eval analyze` 命令能够正确解析这种格式。评估服务和评分标准与框架无关。

如果开发者调用被拒绝的 `eval` 子命令，扩展模块会返回清晰的解释，而不是静默失败：

$ agents-cli eval dataset synthesize agents-cli eval dataset 不被 langchain 扩展支持：它会通过 ADK 的用户模拟器运行代理，需要项目虚拟环境中安装 google-adk

code


与静默失败相比，清晰的拒绝更有价值，尤其是在编码助手控制终端时，否则它可能会在放弃前多次重试损坏的命令。

## 编写你自己的扩展

LangChain 模板是扩展系统的一线演示，但同样的机制也向任何希望自定义 Agents CLI 命令界面的团队开放。企业平台团队可以内部编写和分发扩展，将策略编码为代码，并通过他们已用于其他所有工作的 Git 基础设施进行部署。团队中的每个开发者默认都会遵循相同的检查流程。

为了说明这一模式，我们将构建一个名为 `sbom-deploy` 的小型扩展，它通过软件物料清单（SBOM）扫描包装 `deploy` 命令，如果发现任何关键漏洞则拒绝部署。清单模式的权威参考是“编写扩展”页面。

### 第一步：定义扩展清单

我们首先为扩展创建一个目录，并在其根目录下添加清单文件：

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: 扫描项目 SBOM，然后运行原生 agents-cli deploy。 requires: agents_cli: ">=1.5,<2" on_incompatible: warn

commands: override: deploy: run: ["bash", "scripts/sbom_then_deploy.sh"] description: 通过 syft+grype 执行 SBOM 扫描，然后执行内置的 deploy。 add: sbom-report: run: ["bash", "scripts/sbom_report.sh"] description: 为当前项目生成 SBOM（不执行部署）。

code


清单包含五个顶级键，不允许添加其他键。模式使用严格的验证，因此像 `reqires:` 这样的拼写错误会提示 "did-you-mean" 建议，而不是静默忽略覆盖。

`schema` 字段标识清单模式版本。`name` 字段是一个单一路径组件（斜杠和父目录引用会被拒绝），并成为 `extensions/` 下存储第三方副本的目录名称。`requires` 块声明扩展支持的 Agents CLI 版本，以及在版本不匹配时控制行为的策略（`warn` 或 `error`）。`commands` 块是实际覆盖和新增功能的存放位置。

编写扩展文档的“重要规则”部分列出了其他值得关注的约束。特别需要注意两点：你可以覆盖特定子命令（如 `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 已经由加载器设置,

因此此调用会命中内置的 deploy。不会导致无限递归。

echo "[sbom-deploy] SBOM 清洁；运行原生 deploy. .." exec agents-cli deploy "$%"

code


`AGENTS_CLI_DISABLE_OVERRIDES=1` 是使此功能生效的关键。Agents CLI 会在通过覆盖调用的任何脚本的环境中设置此变量。当我们的包装器递归调用 `agents-cli deploy` 时，调用会直接进入原生的 deploy 命令，而不是回退到我们自己的覆盖。无需特殊语法，也无需递归。

我们可以直接验证这一点。为了演示，我们将 SBOM 扫描替换为几个 echo 语句，用于确认环境和参数：

$ agents-cli deploy --project foo [sbom-deploy] (demo) 会在此处扫描 SBOM... [sbom-deploy] AGENTS_CLI_DISABLE_OVERRIDES=1 [sbom-deploy] 然后会执行: agents-cli deploy --project foo

code


传递给包装器的 `--project foo` 标志原样保留，而环境变量在我们的脚本开始执行前已由加载器设置。包装器已具备所有必要信息，可以委托给原生命令执行。

### 第 3 步：安装和验证

在准备好清单和包装脚本后，我们可以安装扩展。在开发过程中，指向本地路径：

agents-cli extension add local@../my-sbom-extension

code


一旦将扩展推送到 Git 仓库，相同的语法也可以通过远程引用使用：

agents-cli extension add acme/platform-extensions#sbom-deploy --ref v1.0.0

code


安装后，我们通过列出已安装的扩展并检查帮助输出来验证扩展是否生效：

$ agents-cli extension list 扩展: langchain project (命令: eval.dataset, eval.generate, eval.optimize, playground, publish.gemini-enterprise, run) sbom-deploy project (命令: deploy, sbom-report) 需要: >=1.5,<2

$ agents-cli --help | grep -A1 -E "deploy|sbom-report" deploy 通过 syft+grype 执行 SBOM 扫描，然后执行内置的 deploy。 [↑ sbom-deploy] sbom-report 为当前项目生成 SBOM（不执行部署）。 [↑ sbom-deploy]

$ agents-cli deploy --help 用法: agents-cli deploy [OPTIONS] [EXTRA_ARGS]...

通过 'sbom-deploy' 扩展覆盖 deploy（项目作用域）。

通过 syft+grype 执行 SBOM 扫描，然后执行内置的 deploy。

执行: bash scripts/sbom_then_deploy.sh

命令名称后的参数会原样传递给脚本。

要绕过扩展覆盖并执行内置命令: AGENTS_CLI_DISABLE_OVERRIDES=1 agents-cli deploy

code


每个被覆盖命令旁边的 [↑ sbom-deploy] 标签是扩展系统向用户发出的信号，表明行为已被修改。

### 锁定文件规范

在幕后，`extension add` 将我们的 Git 引用解析为确切的提交 SHA，并在项目根目录的锁定文件中记录解析结果：

/path/to/project/lockfile

code

agents-cli-extensions.yaml (锁定文件；提交到版本控制中)

extensions:

name: sbom-deploy

source: acme/platform-extensions#sbom-deploy ref: v1.0.0 sha: a1b2c3d4... scope: project

code


锁定文件和 extensions/ 目录下的打包工作副本都应提交到版本库。在全新检出代码后，agents-cli install 会根据锁定的 SHA 值重新生成经过审核的精确代码，这一过程与 uv sync 或 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/[email protected] -d cloud_run

code


随后可以查阅官方文档：扩展概述 、使用扩展 、编写扩展 、官方扩展 。Agents CLI 的完整源代码（包含官方模板）位于 github.com/google/agents-cli 。

发布于:

- AI

- 云原生

- 教程

- 影响力

- CLI

- 代理 CLI

- Langchain

- 技能

- 代理

上一篇

下一篇

相关文章

列表

AI

教程

公告

开发者指南：EmbeddingGemma 2

2026年10月6日

云原生

最佳实践

将 TorchTPU 集成到 TorchTitan 并优化模型以适配 TPU

2026年10月20日

移动开发

案例研究

通过 Model Explorer 为自定义边缘编译器带来可视化图调试功能

在 TPU 上加速视频扩散的时空注意力机制

2026年9月30日

导航点
 /