许多 Agent 项目并不是模型效果不够，而是卡在从本地脚本走向生产环境的路上：开发者需要在代码编辑器、IAM 控制台、部署平台、评测系统和企业应用之间来回切换。Agents CLI 的定位正是把这些生命周期能力作为技能交给编码助手，让开发、部署、安全治理、评测和发布能够在同一个 coding agent 对话里完成。
本文以一个“行业观察员”Agent 为例：它跟踪半导体公司公开声明与 SEC 8-K 披露之间的差异，输出可追溯的行业情报，而不是让模型凭记忆编造上周发生的新闻。
真正的产品是确定性对账，而不是一段更长的 Prompt
“NVDA 和 AMD 上周有什么变化？”看上去像一个普通问答问题，实际上至少包含三项必须实时完成的工作：
- 获取公司发布的新闻、投资者关系公告等公开声明。
- 获取 SEC EDGAR 中对应时间范围的 8-K 文件。
- 将两类数据按公司标识和日期窗口关联，并明确区分已匹配、仅披露、仅声明三类记录。
这里最关键的设计是：模型负责解释，函数负责判断。
如果让模型直接阅读新闻文本、猜测 filing 日期或补全 8-K Item 编号，输出再流畅也无法审计。更稳妥的架构是用两个数据获取工具拉取实时信息，用第三个确定性工具完成 join、去重和重要性评分，最后让模型依据工具输出生成简报。
这种边界还直接改善了安全性。新闻标题、公告正文和外部网页都是不可信输入；其中即使包含“忽略前面指令”之类文字，也只能作为数据进入工具结果，不能改变 Agent 的行为规则。
先给编码助手补上平台知识
通用 coding agent 能写 Python，但未必知道 ADK Agent 类、托管运行时的部署参数、安全模板的绑定方式。更麻烦的是，这类平台接口变化很快，依赖模型训练记忆容易产生过期命令。
Agents CLI 提供了面向完整生命周期的技能，例如项目脚手架、部署、评测和发布；Developer Knowledge MCP 则让 coding agent 查询当前平台文档。可以先在目标项目环境中执行：
uvx google-agents-cli setup
随后向 coding agent 明确配置目标。例如，代码执行沙箱限定在 us-central1 时，应把项目和区域一次性固定下来：
Install the Agents CLI lifecycle skills and the Developer Knowledge MCP.
Authenticate with my existing gcloud ADC, pin my project, and set the
region to us-central1.
这一步的价值不只是省几条命令，而是把“请根据最新文档完成平台操作”变成编码助手的默认工作方式。对于快速演进的 Agent 平台，这比把一批 CLI 参数硬编码进团队 Wiki 更可靠。
把数据能力拆成可验证的 FunctionTools
可以这样实践：先让 coding agent 只生成 ADK 项目结构，再逐步增加工具。典型的三工具划分如下：
fetch_company_disclosures：查询 SEC EDGAR 的 8-K 文件。fetch_public_claims：获取 GDELT 新闻和公司 IR feed 中的公开声明。reconcile_claims_vs_disclosures：按 CIK、ticker 和日期窗口完成确定性关联，产出matched、filing_only、claim_only三个桶。
下面是一个可直接改造的 SEC 查询函数。运行前请将 SEC_UA 中的邮箱替换为团队可联系的地址；SEC 对没有描述性 User-Agent 的请求可能返回 403。
import requests
SEC_UA = "IndustryWatch Lab engineering@example.com"
def fetch_company_disclosures(
ticker_or_cik: str,
start_date: str,
end_date: str,
) -> dict:
"""Fetch SEC 8-K filings for one company in a date window."""
response = requests.get(
"https://efts.sec.gov/LATEST/search-index",
params={
"q": ticker_or_cik,
"forms": "8-K",
"startdt": start_date,
"enddt": end_date,
},
headers={"User-Agent": SEC_UA},
timeout=30,
)
response.raise_for_status()
return response.json()
if __name__ == "__main__":
filings = fetch_company_disclosures("NVDA", "2025-01-01", "2025-01-31")
for hit in filings.get("hits", {}).get("hits", []):
source = hit.get("_source", {})
print(source.get("file_date"), source.get("file_type"), source.get("file_num"))
真正需要重点测试的是第三个工具。它不应调用模型，而应使用明确规则：同一 CIK 或 ticker、落在允许日期窗口内、主题或事件标识相符，才可以进入 matched。无法匹配的新闻必须保留在 claim_only，而不是被模型“合理推断”为已有 filing 支持。
重要性评分也应该落在函数侧。例如可以让 8-K Item 4.02 和 5.02 的权重高于 Item 7.01。权重本身是业务策略，可以调整；但评分输入、规则和结果应可复现。
从本地 Playground 到有状态的托管服务
本地运行能证明工具链可用，却不能保证它能在每周简报时稳定提供服务。部署到 Agent Runtime 后，Agent 可以获得托管、自动扩缩容的运行环境，并在闲置时缩容。
可以向已配置技能的 coding agent 发出类似指令：
Deploy this to Agent Runtime. Add the deployment target, start the deploy
without blocking, and poll until it reports ready.
生产形态通常还需要区分两类状态：
- 会话状态：保存一次或多轮对话内的上下文。
- 跨会话记忆：保存用户的关注列表、所属行业和固定简报格式。
摘要中提到可使用 Agent Platform AI Sessions 处理多轮状态，并用 Memory Bank 保存跨会话信息。与此同时，建议将 join、去重和物料性评分放进托管代码执行沙箱，继续保持“模型叙述、代码裁决”的边界。
需要注意：跨会话记忆不应默认保存所有原始对话和外部数据。对于金融、合规或企业内部场景，应该明确记忆字段、保留周期、读取主体和删除机制。
治理不是上线后的补丁
一个能访问实时外部内容的 Agent，至少需要同时处理身份、网络和提示注入三条控制线。
身份方面，应为单个 Agent 使用专属身份，并只授予必需的 Agent Platform 权限，而不是复用一个带管理员权限的项目服务账号。网络方面，可通过 Agent Registry 和 Agent Gateway 配置出站 allow-list，仅允许访问 sec.gov、GDELT API 和经过审核的 IR feed。
提示注入防护则要覆盖三个方向：用户输入、模型响应、工具返回的非可信文本。摘要中的 Model Armor 模板可以通过以下命令创建：
gcloud model-armor templates create iw-shield --location=us-central1 \
--pi-and-jailbreak-filter-settings-enforcement=enabled
这不是对工具边界的替代。Model Armor 用于识别注入与越狱尝试；确定性工具、最小权限身份和网络 allow-list 则限制攻击内容即使进入系统后能够造成的影响。三者缺一不可。
用可判定的评测替代“看起来不错”
Agent 最常见的质量陷阱是：在 Playground 中读起来不错，但引用并不来自工具结果。对于行业观察员，这可以转化为一个硬性评测规则：回答中出现的每个 accession number 和 8-K Item code，都必须逐字出现在当次工具输出中。
可以这样定义评测集：构造分析师跨多轮询问多家公司“本周变化”的场景，同时评估任务完成度、工具使用质量和幻觉情况。除通用 LLM 评判外，再加入上述确定性校验，作为发布门槛。
每次改 Prompt 后，应该将失败样本按模式聚类，例如：漏调工具、错误引用、将 claim_only 误写成已确认事件、未遵守简报格式。只针对 Prompt 驱动的问题优化，并与基线结果对比，确认没有让 grounding 回归。将这些评测接入 CI，才能避免一次看似无害的措辞调整悄悄破坏事实可追溯性。
发布前的采用清单
当 Agent 通过评测后，可借助 ADK 注册发布到 Gemini Enterprise，让业务分析师直接在已有企业应用中使用它。发布前建议逐项确认：
- 工具是否只返回可追溯的实时数据，模型是否只基于工具结果下结论。
- 对账逻辑、去重和重要性评分是否全部在确定性代码中完成。
- Agent 是否拥有独立的最小权限身份和受限的出站网络访问。
- 不可信新闻文本是否经过提示注入检测，并且不会被当作系统指令执行。
- 每个引用的 accession number、链接和 8-K Item 是否能在工具输出中验证。
- 跨会话记忆是否符合组织的数据保留与访问控制要求。
Agents CLI 的意义不在于让 Agent 开发只靠自然语言完成，而在于把开发者原本分散在多个控制台中的操作，收束成可以由编码助手执行、审查和重复的生命周期流程。对需要实时数据、可审计结论和严格工具边界的业务 Agent 来说，这种工程化路径比“换一个更大的模型”更接近生产答案。