10月21日，Google Developers Blog公布了Agents CLI Extension System的一篇端到端技术说明：用LangChain模板创建Agent，复用原有部署和部分评测命令，再写一个部署前检查软件物料清单（SBOM）的扩展。文章明确说扩展系统从Agents CLI 1.5.0开始提供，1.8.0包含第一方LangChain扩展，仍标为实验性。[1] 这件事的实用之处不在于又能安装一种框架，而在于平台团队是否能把不同Agent项目的交付动作集中到一个可审计的入口。
设想一家企业的客服试验项目使用ADK，研发知识检索使用LangGraph，还有一个自研编排器。三个团队都能运行自己的Agent，却分别维护镜像构建、评测数据格式、日志接入和部署审批。到了要复现一次线上故障，平台人员先要弄清哪个脚本代表“正式部署”、哪一套指标是真实生产版本。Google这次给出的答案是：允许框架相关的少数命令被替换，其余命令沿用同一工具链。这是架构选择，不是不同框架的运行语义从此一致。
扩展到底改了哪一层
扩展可以是Git仓库中的一个目录，内含agents-cli-extension.yaml；它声明要覆盖现有命令，或增加新命令。覆盖命令收到用户原样传入的参数。项目根目录也能放这份清单，作为项目级配置自动加载。采用项目级扩展时，同一仓库的开发者与CI看到的替换行为一致；全局扩展则作用于当前机器上的所有项目。两者覆盖同一命令时项目级优先，agents-cli info可查活动命令的来源。[1][2][3]
Google的LangChain示例很具体：模板生成的app/agent.py使用langchain.agents.create_agent，输出可执行的LangGraph图，不依赖Google ADK；本地run改为执行该图，playground改为启动LangGraph开发服务。对生产发布，Cloud Run的deploy仍走原有命令路径，容器由FastAPI提供A2A接口，评测生成结果转成标准数据格式，后续eval grade照旧执行。[1][3] LangChain自己的文档也把create_agent定义为可组合模型、工具和中间件的入口，把LangGraph解释为较低层的编排框架；这里共享的是项目交付接口，不是把LangChain改造成ADK。[6]
发布博客列出六项项目级命令覆盖，并指出其中eval dataset synthesize和eval optimize在这个模板中会明确拒绝执行，因为它们依赖ADK对象；不是“支持所有评测命令”。官方框架文档还说明，模板部署至Cloud Run或GKE的路线与Agent Runtime不同：后者虽可运行容器并传送Cloud Trace轨迹，但依赖ADK的控制台会话/轨迹界面和部分发布集成不可用。[1][3] 验收表上如果只写“LangChain支持部署、评测与可观测”，这些重要限制就消失了。
一份命令清单会把风险带到哪里
部署策略的示例采用另一类覆盖：平台团队让deploy先运行SBOM扫描，发现严重漏洞就停止，然后再调用原生部署命令。清单中的run字段是一组命令参数，不直接执行shell串联；要先扫描再部署，检查逻辑必须放在脚本中。CLI为覆盖脚本设置AGENTS_CLI_DISABLE_OVERRIDES=1，使脚本再次调用agents-cli deploy时落到原生部署，避免递归。[1][4] 这种入口能让默认检查更容易执行，但它自身不是不可绕过的服务端策略。开发者如果有权限直接调用底层云部署接口，仍可能绕开本地扩展；正式的阻断还要依托CI权限、云平台IAM与审批门禁。
扩展从Git分发，安装时解析为确定的提交SHA并写入项目锁文件；install恢复该版本，extension update才会推进引用。第三方仓库在安装前会提示信任，项目根目录的自动加载清单则因属于当前仓库而不会再次弹出信任提示。[2][4] 于是代码审查不能只盯应用逻辑：要审查扩展清单、脚本、锁定提交和更新记录。一个看似普通的run命令可能运行仓库里的脚本，而不是开发者以前熟悉的原生命令。审查一个新项目时，先在运行任何覆盖命令之前阅读根目录清单；这和检查仓库的构建脚本、CI工作流是同一类供应链审查。Google文档特别提醒，项目根的自动加载清单因被视为仓库自身代码，不会像外部扩展那样再次征求信任。[4] 若项目来自外部，把它直接放进带云账号凭证的开发机运行会增加不必要的暴露面。运行时警告与--help上的扩展标记可以提醒人，但隔离执行还需独立的权限边界。另一个容易错过的点是优先级：两份同级扩展争夺同一命令时，官方作者文档说先加载的生效，后来的会被忽略；项目级与用户级冲突时则是项目级优先。[2][4] 审核时不能只看“已安装”列表，必须查正在执行的那一条命令究竟来自哪个扩展。
对“统一可观测”的理解也应保守。模板包括Cloud Trace和日志相关代码，框架文档也指出Agent Runtime的控制台视图有差别。[1][3] 所以不能只对比有没有追踪ID，应检查每次模型请求、工具调用与A2A任务是否能跨端关联，失败重试是否重复记账，敏感字段是否受控。不同框架对中间状态和工具异常的定义不同，同名仪表板也可能统计出不同的分母。统一命令面减少重复接线，指标解释仍需要项目负责人与平台组共同签字。
用同一命令跑出的结果，还需要同一把尺
统一评测流水线最容易制造一种错觉：两个项目都生成了EvaluationDataset，后续也都能调用eval grade，所以它们的分数可以直接排在同一张榜单上。实际上，数据格式只规定了评分器能读什么，没保证Agent在生成数据时经历了同样的任务路径。一个框架可能把工具错误原样暴露给模型，另一个框架可能自动重试；两者最终答案相同，调用次数和越权风险却不同。Google文章明确区分被覆盖的eval generate与沿用原生实现的eval grade。[1] 企业自己得规定任务边界：输入是否含历史对话，工具返回是否固定，评分器能否看到工具轨迹，超时算失败还是可重试。
拿十几条熟悉的演示题当迁移证明也不够。选取一批脱敏的真实请求，另做一批专门针对权限拒绝、检索结果过期和服务超时的边界用例。先人工标注允许的行为和禁止的操作，再用两套框架分别运行，保存每条任务的模型版本、提示版本、工具参数、最终动作与失败原因。评分应拆开看：答案能否满足用户、实际是否调用了受限工具、达到结果花了多少时间和调用成本。分母不同就分开报，不把一次自动重试算成新的用户请求。新流程若提升答案分数却多出一次未授权写入，应先处理权限问题。
还有性能账。为每个迁移候选记录本地启动耗时、预发环境冷启动、单轮执行的P50与P95时长以及每次任务的模型调用量；如果A2A入口只是把框架差异藏在容器内部，线上延迟不会凭空消失。观察日志时按任务ID串联CLI构建结果、服务请求、工具调用和评测轨迹，避免误把“Cloud Trace有数据”当成“每条业务动作都能追溯”。这些指标是企业建议，不是Google发布文章提供的性能基准。
一次迁移验收应怎么安排
先把试验范围缩到一个有代表性的低风险Agent。固定输入样本、工具模拟器、调用预算和依赖版本；分别用原项目和新模板运行，比较结果正确性与失败类型。把评测生成、评分、比较分成独立阶段，不要让同一份自动生成的数据兼作最终业务验收依据。特别检查eval dataset synthesize、eval optimize这样的明确不支持项是否按预期报错。若业务流程依赖它们，记录迁移阻塞，而不是悄悄绕到另一套脚本。[1][3]
再核查运行目标。Google文章中的示范部署是Cloud Run，不能推断所有Google运行环境享有相同的控制台体验。平台团队应把目标环境写进决策记录：如果日常排障依赖Agent Runtime的控制台会话视图，就不能因为Cloud Run示例能跑便批准迁移。先让值班工程师在预发环境独立完成一次故障定位，确认需要的轨迹在哪个界面可见、谁有权限读。若只能通过Cloud Trace查到原始数据，操作手册和培训也要随之更改。[3]用一条含工具调用的真实链路，在本地、预发和部署后比对A2A响应、身份凭证、超时与轨迹。文档要求模板保留app.fast_api_app:app入口；团队自己重构应用目录后，要在构建和部署前跑接口契约测试。[1][3] 评测样本要包含工具拒绝访问、返回空数据和超时，平台人员还要验证生产服务账号没有被示范项目的宽权限替代。
最后测试政策扩展的“拒绝路径”。让测试用的SBOM出现一项模拟的严重问题，确认部署真的中止，CI把失败状态记录下来；再由具备审批职责的人修改测试策略并运行回归。在项目中同时存在全局和项目级扩展时，检查哪个版本实际生效。审核报告保留CLI版本、扩展仓库SHA、评测数据版本、部署镜像摘要及审批记录。对于自研框架，先列出不得覆盖的CLI维护命令、应用必须提供的服务入口，以及评测输出格式，再决定哪些命令确实需要改写。若自研框架需要自己的发布目标，不应硬把官方Cloud Run示例说成天然适配；交付团队要维护对应模板，并指定谁负责跟进上游接口变动。如果是已有生产Agent迁移，先约定回滚版本和流量切换方式，再把一小部分非关键任务转到新链路；出现轨迹丢失或权限变化时，回到旧服务比“热修”一份部署脚本更稳妥。哪天升级CLI或框架，只要其中一个版本变了，就重跑最小验收集合。扩展机制被标成实验性，依赖它的生产流程更不能让工具版本自动漂移。回归失败时要能判断是CLI命令契约变了、扩展覆盖脚本失效，还是模型输出波动；因此每次测试都保留一份不调用模型的接口契约检查。比如验证生成项目里存在预定入口、agents-cli info显示预期覆盖来源、被拒绝的命令确实拒绝，以及部署前检查失败会返回非零状态。它们比自然语言回答稳定，能先把基础设施问题与模型问题分开。等这些检查通过，再用固定样本跑一次真实模型调用；不要在每次排查部署失败时都花钱重做整套开放式评测。平台组把失败日志交给相应的框架维护者，也比一句“Agent不工作”更容易定位责任。[1][2]
Google的演示也解释了“框架无关”的边界：deploy可以只依赖容器服务的接口，eval grade可以只依赖统一数据格式；生成轨迹、本地交互、控制台集成却仍要理解框架实现。采购或平台选型时，与其数可用框架的名字，不如要求供应商拿出一条从创建到故障回放都可复现的链路，并把不能用的命令明写出来。CLI是操作入口。谁能批准部署、谁能读日志、哪个框架的失败算严重，这些决定还在企业自己手里。尤其要留意第三方扩展的供应链：锁定提交能保证下次安装拿到相同代码，却不能证明该代码本来就安全。审查者需要看清清单能执行哪些程序、脚本是否读取部署凭证、依赖是否从受控源安装。升级前比对新旧提交，必要时在没有生产凭证的环境先运行。这样才能把“用Git分发很方便”和“值得信任”分开。
一手来源
[1] Google Developers Blog, “Powering the Agent Development Lifecycle with any framework, from ADK to LangChain and beyond”, 2026-10-21, https://developers.googleblog.com/powering-the-agent-development-lifecycle-with-any-framework-from-adk-to-langchain-and-beyond/
[2] Google Agents CLI, “Using Extensions”, 持续更新文档，发布日期未标，2026-10-22核查，https://google.github.io/agents-cli/guide/extensions/using/
[3] Google Agents CLI, “First-party frameworks”, 持续更新文档，发布日期未标，2026-10-22核查，https://google.github.io/agents-cli/guide/extensions/first-party/
[4] Google Agents CLI, “Authoring Extensions”, 持续更新文档，发布日期未标，2026-10-22核查，https://google.github.io/agents-cli/guide/extensions/authoring/
[5] google/agents-cli, Release v1.8.0, GitHub发布记录2026-09-30，https://github.com/google/agents-cli/releases/tag/v1.8.0
[6] LangChain, “LangChain overview”, 持续更新文档，发布日期未标，2026-10-22核查，https://docs.langchain.com/oss/python/langchain/overview
配图为概念示意。