为智能体开发生命周期提供动力，支持任意框架，从 ADK 到 LangChain 及更广泛生态

2026年10月21日

新 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 现在附带一个 扩展系统，让开发者无需分叉工具即可覆盖或添加命令。1.8.0 版本发布了第一方 LangChain 扩展，它用 LangChain 等效命令替换了与框架耦合的命令，其余生命周期保持不变。

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

框架锁定问题

当今可用的大多数智能体开发工具链都有一个共同的局限：它们对某个特定框架持有固化的观点，而周边功能（部署目标、CI/CD 流水线、评估工具、可观测性接线）都假设开发者已经采用了该框架。当你的框架与工具的假设一致时，这条固化的路径就能奏效。当不一致时，你只剩下三个糟糕的选择。

第一个是分叉 CLI，维护一个有差异的副本，并在每次上游发布时重新同步。你将付出永久的维护税，而且上游的每项改进都必须手动合并到分叉中。第二个是将 CLI 包装在自定义脚本之后，构建一个调用底层工具的并行命令界面。问题在于，开发者（以及他们的编码助手）会忘记包装器，直接调用底层工具，绕过了预期的抽象。第三个是放弃并从头开始构建一切，这可能消耗数个工程师月的工作量，而团队并未为此做计划，且很少能产出与上游项目一样完善的工具。

该问题出现在两种场景中。其一是企业客户采用 Agents CLI：在受监管的行业中，中央平台团队通常要求每次 deploy 调用都需包裹合规检查、要求 login 经由企业单点登录，或要求评估流程通过模型风险管理管道。这些要求若按当前方式实现，都意味着要么分叉该 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 适配到其未自带的工作流的方式——无论是不同的智能体框架、组织的部署策略，还是你自己的命令——而无需分叉该工具。}

扩展有两种形态，在使用扩展页面中有描述。命令覆盖会替换内置命令（如 playground、deploy 或 eval generate）的行为。被覆盖的命令会原样接收用户的参数，因此用户体验与原生命令保持一致。新命令则暴露 CLI 目前未作为 agents-cli <your-command> 提供的工作流。两种形态可以在同一扩展中共存，大多数非平凡的扩展都会结合使用两者。

扩展通过 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 输出中向开发者暴露。

Lockfile 与生命周期

扩展系统遵循 uv 或 npm 等包管理器的规范：它在安装时将 Git 引用解析为精确的提交 SHA，将解析出的 SHA 记录在 lockfile 中，并使用 lockfile 在每次全新检出时重新物化经过审查的精确代码。agents-cli install 命令从固定的 SHA 恢复 vendored 工作副本而不推进固定版本，这保证了 CI 和本地开发运行的是逐位相同的代码。要将固定版本推进到所跟踪引用的最新提交，开发者运行 agents-cli extension update，它会重新解析引用并重新提示第三方信任。完整生命周期见 Using Extensions → Lifecycle 部分。

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

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

$ 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 中的完全相同。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 命令知道如何消费它。评估服务和评分标准与框架无关。

如果开发者调用被拒绝的评估子命令之一，扩展会给出清晰的解释，而不是静默失败：

$ 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 的小型扩展，它用软件物料清单（SBOM）扫描包装 deploy 命令，如果发现任何严重漏洞则拒绝部署。清单模式的权威参考是编写扩展页面。

第 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 字段是单个路径组件（斜杠和父目录引用会被拒绝），并成为 extensions/ 下存放 vendored 副本的目录。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 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 命令，而不是循环回到我们自己的覆盖。无需特殊语法，也不会无限递归。

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

$ 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] 标签，是扩展系统向用户发出的信号，表明该行为已被修改。

Lockfile 纪律

在幕后，extension add 将我们的 Git 引用解析为一个精确的 commit SHA，并将该解析结果记录在项目根目录的 lockfile 中：

# 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

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

要将固定版本推进到被跟踪引用（分支、标签或 SHA）的最新 commit，开发者运行 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/template@v1.8.0 -d cloud_run

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