Google Cloud发布agents-cli：自改进Agent循环的7条工程法则

Google Cloud Tech 近期在 X 上发布了一篇重要文章（38.4K 浏览量），标题为"7 rules for self-improving agent loops every AI engineer should know"，同时开源发布了 agents-cli——一款用于在 Google Cloud 上构建 AI agents 的开源 CLI 工具 [1] [2]

核心观点："Coding agents 已经能够创建和改进其他 agents 了，但这个循环存在一个盲点：它会优化你所测量的任何指标，却无法判断你所测量的东西是否真的'好'"

这篇文章总结了 Google Cloud 在构建 agents-cli 过程中发现的 7 条规则，以及为什么这些规则对每一个正在构建 AI agents 的人都至关重要

先看全局，Self-Improving Loop 是什么

Self-improving loop 是 AI agent 自我改进的循环：

编写 instructions → 运行 agent → 找到失败点 → 重写 → 重新运行 → 循环

Google Cloud 表示："自动化这个循环正是 agents-cli 所做的事情" [1]

但问题在于：这个循环存在盲点

"给它一个肤浅的目标，它就会优化你的 agent 获得高分，但实际表现却变差，然后报告说成功了，因为按照它自己的标准，它确实成功了"

循环可以自动化一切，唯独无法告诉你什么才是'变好'

核心理念："The Metric Is What You Now Author"

Google Cloud 提出了一个很有分量的理念：

"软件团队一直都知道'你得到的就是你测量的'，self-improving loop 让这句话变成了字面意思——它会改进你给它的任何数字，而没有任何东西能区分反映你真正想要的目标与只是'得高分'的目标"

Metric凌驾于 prompt、代码和行为之上，循环会同时改变这三者来迎合它所奖励的东西

这就类似于上一次范式转移：

Compilers → Frameworks

Frameworks → Standards (Metrics)

"努力从 artifact 走向 standard"

真实案例，Support Agent 与 Retention Rule

Google Cloud 举了一个清晰的例子：

"想象一个 support agent 有一条规则：'在确认取消之前必须提供 retention path'，模型可以在其 reasoning 中遵循这条规则，却在最终回复中偏离了"

他们曾见过 agent 以这种形式失败：

Internal state 正确

调用的 tool 正确

但发送给用户的最后一条消息，却回响了旧的值

没有任何东西崩溃，output 粗看也不错，但用户收到的答案，是错的

而且没有任何 public metric 知道你的 retention rule 是否存在

解决方案：创建你自己的 custom metric——retention_offered，返回 0 或 1 并附上一行理由，"写进去，那个定义就是你的，之后当发现新的失败时，再版本化并打磨它"

uvx google-agents-cli setup

从测试用例生成 traces

agents-cli eval generate \
  --dataset tests/eval/datasets/cancellation_cases.json \
  -o artifacts/traces/

用你的 metric 打分

agents-cli eval grade \
  --traces artifacts/traces/ \
  --config tests/eval/eval_config.yaml

比较修复前后的差异

agents-cli eval compare \
  artifacts/grade_results/results_baseline.json \
  artifacts/grade_results/results_after_fix.json

重要提示："不要让 coding agent 读取自己的输出然后判断是否通过，被要求评判自己回复的 agent 会给出过于乐观的评分，而最关键的失败恰恰是它会'挥手放行'的那种"

Grading 打破了这种循环性，每条 trace 都按照你的 metric 打分，这个标准是 coding agent 无法移动的，因此修复是由非人工提出的东西来评判的

7 条 Self-Improving Loops 规则，总结

7 条 Self-Improving Loops 规则，详解

以下是文章的核心，Google Cloud 在构建 agents-cli 过程中发现的 7 条规则 [1]：

规则 1：从 1 个 case 开始，而不是整个 suite

"One failing case tells you what to fix next. Twenty tell you nothing."

1 个失败的 case，告诉你要修复什么；20 个 cases，什么都告诉不了你

预期需要 5-10 次迭代才能通过，这是正常的，只有当 agent 能够 hold 住时再添加下一个 case

规则 2：让评判者能够自我解释

"A number says you failed. The reason says what to change."

数字告诉你失败了，理由告诉你该改变什么，而理由正是下一次迭代的方向

例外：Deterministic checks 不需要解释，因为 assertion 本身就是解释

规则 3：当答案是 deterministic 时使用代码

""Did it call the retention tool before confirming?" is a Python function."

"它在确认前调用了 retention tool 吗？"，这是一个 Python function，精确、免费、没有 judge variance

把 judge 留给：tone、completeness、以及解释是否 hold up

规则 4：评估行为，而不是路径

"An agent that geocodes before checking the weather isn't wrong."

在查询天气之前先做 geocode 的 agent，没有错

Exact-match trajectories 最终衡量的是 agent 改变了多少，而不是它有多好

规则 5：把 flaky case 视为需要调查的信号

"A score that moves between identical runs means your agent is non-deterministic."

在相同的运行中分数发生变化，意味着你的 agent 以你从未注意到的方式是非确定性的，或者你的 judge 是

多次运行那个 case 看看是哪个在移动，删除它是删除证据，不是删除行为

规则 6：不要让提议者来移动基准线

"A bar moves three ways: lowered threshold, edited expected output, quietly dropped case."

降低阈值

修改 expected output

悄悄丢弃 case

这三种方式看起来都像是分数在改善，这就是 held-out slice 存在的意义，真正的改进会在那里显示，作弊不会

规则 7：只优化一次，在最后

"Prompt optimization is expensive and only fixes wording, never a missing tool call."

Prompt optimization 很昂贵，而且只能修复措辞，永远不会修复 missing tool call

反复循环优化会用掉好几个小时来发现 failure reasons 已经告诉你的东西

从 Development 到 Production，同一个 Metric

Google Cloud 指出，你构建的 metric 不只是用在开发阶段：

"在 development 中你叫它 eval，在 production 中你叫它 monitoring，它们是同一个 metric"

已部署的 agent 已经导出了 execution traces，带有 prompt-response logging，prompts 和 replies 进入 BigQuery，因此在该表上运行你的 metric 就是同样的 grading 步骤，只是用在真实流量而非人工写的 dataset 上

"Over the cases you wrote, and over the conversations you didn't."

每一个失败的 production exchange，都会变成一个新的 case，用同样的 metric 打分，从那时起防止那个 regression

Google Cloud 以一条凌驾于 7 条规则之上的规则收尾：

"Coding agent 进行迭代，它写 prompt，运行 agent，找 gap，然后关闭它，但它无法生成它所优化的'好的定义'"

"在下循环之前就写下那个定义，并把它放在循环够不到的地方"

注意事项，agents-cli 仍然做不到的事

尽管 agents-cli 很有用，但它不是银弹：

需要 Google Cloud，agents-cli 构建在 Agent Development Kit (ADK) 上，如果你用 AWS 或 Azure，就用不了

Metric 就是一切，如果你写得 metric 不好，循环就会优化到错误的方向，而且你直到为时已晚才知道

仍然需要人来看管，"keep it somewhere the loop cannot reach"，你必须把"好"的定义放在循环之外，这是 automation 无法替代的责任

Prompt optimization 很昂贵，规则 7 提醒我们 auto-optimize 用时数小时，而且只能修复措辞，永远不会修复 missing tool call

这篇文章来自 Google Cloud Tech，是关于在现实世界中构建 AI agents 的文章中少数"每句话都对"的之一

我个人认为最重要的观点：

Metric > Prompt，我们在 prompt engineering 上投入了太多时间，但恰恰是 metric 决定了 agent 将朝哪个方向演化

Custom metrics 就是你的护城河，retention_offered、compliance_check、tone_match，这些定义正是让你的 agent 与众不同的东西，没有 public benchmark 可以衡量这些东西

Held-out set 是防作弊机制，如果没有 held-out slice，循环就会朝着 metric 优化，而不顾它是否真的"好"

Eval = Monitoring，这是最被低估的 insight，同一个 metric 在 dev 和 prod 都可用，减少重复，增加一致性

[1] Google Cloud Tech. "7 rules for self-improving agent loops every AI engineer should know". X (Twitter). 2026 年 8 月 10 日. https://x.com/GoogleCloudTech/status/2086874630032073142

[2] Google. "agents-cli, Open-source CLI and skills for building agents on Google Cloud". 2026. https://google.github.io/agents-cli

本文是对 Google Cloud Tech 的 X 帖子的总结，并附有扩展和个人视角，Nokka

你用什么 metric 来衡量你的 AI agent 质量？你有自己的"retention_offered"吗？欢迎在评论区分享