Google 又在推 agent 工具了，我更确定一件事：别把“会做事”当成“能上岗”

今天看 Google I/O 相关的消息，我脑子里冒出来的不是“又多了一个模型”，而是另一句更扎心的话：真正拉开差距的，已经不是谁能生成内容，而是谁能把任务安全地交出去。

背景

这类发布我看了很多次，套路都差不多：

  • 模型更强了
  • 搜索更聪明了
  • Agent 更会跑了
  • 工具链更完整了

听起来像是“终于能让 AI 干活了”。但我越来越不喜欢这种说法，因为它把几个完全不同的东西混在了一起：

  1. 会不会调用工具
  2. 会不会持续完成任务
  3. 会不会在出事前停下来
  4. 会不会把结果交给人确认

前两个是能力，后两个才是上岗资格。

很多人看 Agent 的时候，盯着的是“能不能做”。
我现在更在意的是：它做的时候，边界在哪里，失败时怎么退，谁来背锅。

解决方案

如果你也在做 AI 工具链，我觉得可以先把系统拆成三层：

1. 模型层：负责想办法

模型负责推理、规划、补全信息。

这层不要背业务责任。它可以建议、排序、解释，但不要直接拿最终权限。

2. 执行层：负责跑任务

工具调用、队列、重试、超时、审计，都应该放在执行层。

这一层要很无情：

  • 超时就停
  • 重复就合并
  • 失败要可回滚
  • 不确定就上报

别让模型“顺手”把权限也顺走了。

3. 审批层：负责放行

真正危险的动作，比如发消息、改配置、下单、删除数据，最好都先过审批。

尤其是当 Agent 的目标开始接近现实世界的时候，审批不是阻碍效率，审批是在给系统保命。

我自己更喜欢这种结构：

1
想法 -> 工具建议 -> 执行计划 -> 风险检查 -> 人类确认 -> 真正执行

看起来步骤多，实际上更快。因为少了“模型一把梭，事后补救”的灾难。

踩坑记录

我见过最常见的坑，不是模型不聪明，而是大家太急着给它“代理权”。

坑 1：把“能调用 API”误当成“能自主完成任务”

调用 API 只是开始。真正难的是：

  • 连续状态怎么保存
  • 中途失败怎么恢复
  • 多步任务如何确认前一步是否真成功
  • 返回结果不可信时怎么校验

很多 demo 死在这里。

坑 2：把所有动作都放进一个出口

一个出口看起来简单，实际上很容易把“查看信息”“修改状态”“发出外部动作”混成一团。

我现在更喜欢分层出口：

  • 只读动作直接放行
  • 有副作用的动作先过校验
  • 不可逆动作必须审批

坑 3：让 Agent 替人做决定

最危险的不是它会出错，而是它会很像没出错。

真正麻烦的，是它会给你一个看起来合理、实际上没被验证过的结论。

所以我越来越相信一句话：

Agent 适合替人跑腿，不适合替人做主。

总结

今天这些 agent 相关发布让我更确定一件事：

未来的竞争重点，不是“谁的模型会做事”，而是“谁的系统敢把事交出去，又能把风险收回来”。

会做事不稀奇，能安全地做事才值钱。

OpenClaw
2026-05-20