I'm Running Gemini as an Autonomous Coding Agent. Here's What It Can't Do and Which NEXT '26 Announcements Would Fix It

最近在 X 上看到一篇有意思的实验文章。作者在搞一个"100 美元 AI 创业大赛"：7 个 AI agent 各自拿到 100 美元和 12 周时间，从零开始建一家公司。全程不让人工写代码，所有决策和执行都靠 AI。

其中一个 agent 跑的是 Gemini，用的是 Gemini CLI，2.5 Pro 做复杂任务，2.5 Flash 做简单任务。

跑了 4 天，27 个会话，235 篇博客。

一个支付集成都没建。

没发起过一次正确的求助请求。

这个数据太讽刺了，我忍不住想把它拆开聊聊。

实验背景：7 个 AI agent 同场竞技

先交代一下背景。这个实验的设定很有意思：

• 7 个 agent 分别用不同的 AI 系统（Claude、Codex、Gemini、DeepSeek 等）
• 每个 agent 拿到 100 美元和 12 周时间
• 目标是建立一家能盈利的软件公司
• 约束条件：人类不写代码，AI 自主决策

这是个很干净的实验设计。当所有 agent 面对同样的资源和约束时，谁的方法论更好，一目了然。

Gemini 的创业方向是 LocalLeads，给本地商家做 SEO 页面生成器。这个方向本身没问题——有真实需求，有明确的客户群体，有付费意愿。

但问题是执行。

问题一：27 个会话，没一次把求助写到正确的地方

每个 agent 都有一个标准流程：当它需要人工帮助时（比如申请域名、配置 Stripe），在项目里创建一个 HELP-REQUEST.md 文件。人类看到后会去处理，然后把结果写到 HELP-STATUS.md。

Claude、Codex、GLM、Kimi 全都在第一天就学会了这个流程。

Gemini？27 个会话，一次都没对过。

它把内容写到 HELP-STATUS.md 里——那是回复文件，不是请求文件。它在 backlog 里写"Requires Human Intervention"，知道自己被阻塞了，但还是把请求写到回复通道里。

就像一个员工每天在日记里写"我需要数据库权限"，但从来不发给 IT 部门。

Gemini 的行为模式：我承认我被卡住了，我把这个承认写到了某个文件里，然后继续做别的事。

Claude/Codex 的行为模式：我被卡住了，我创建一个 HELP-REQUEST.md，我等着人类处理，我检查 HELP-STATUS.md 确认结果。

这中间差了什么呢？我觉得是工作流语义的理解。Gemini 知道有这两个文件，也知道"阻塞"这个概念，但它不理解"请求"和"回复"是不同方向的操作。这是 semantic understanding 的问题，不是 API 能力的问题。

我的判断：这个 bug 本来可以在第一天就被捕获

问题没有在第一天被发现，是因为整个实验缺乏 session 级别的观测工具。

如果有 Agent Observability 和 Integrated Evals，流程应该是这样的：

Session 1 结束后 →
  自动 eval 检查"当 agent 标记 blocker，是否同时创建 HELP-REQUEST.md" →
  结果：FAILED →
  立即告警 →
  人类介入修正行为模式 →
  Session 2 开始

而不是：

Session 1...27：无观测
第 4 天结束：哦，原来它 27 次都没创建对

NEXT '26 发布的 Agent Observability 和 Integrated Evals 正好对症。session 后的自动化评估让行为偏差在第一时间暴露，而不是积累成系统性问题。

另外，governance policies 也很有必要。定义一条规则：当 agent 写到"blocked"或"requires human intervention"时，验证 HELP-REQUEST.md 是否被创建。这个行为 guardrail 应该在 agent 开始工作前就配置好，而不是事后补救。

问题二：235 篇博客，零支付集成

这是最讽刺的部分。

Session 5 写了 9 篇博客，Session 8 写了 11 篇，Session 12 写了 8 篇。backlog 里明确写着"Build payment integration"和"Set up customer authentication"，Gemini 读了 backlog，承认了优先级，然后转头又写了 9 篇"2026 年 XX 行业本地 SEO"的博客。

这是教科书级别的局部最优陷阱。

最容易被完成的任务（写博客）获得了最多执行，而最高价值任务（支付流程）被无限期推迟。

我见过很多程序员这样：有的人喜欢写测试，有的人喜欢写文档，有的人喜欢重构。每个人都有自己的"舒适区任务"。AI agent 也有类似的模式——Gemini 显然在"生成内容"这个任务上效率极高，所以它就一直做这件事。

问题在于：它没有能力判断"什么任务更有价值"。

写第 1 篇博客有 SEO 价值，写第 236 篇博客价值趋近于零。但"建 Stripe 支付"是业务成立的必要条件——不建这个，创业就是空谈。

其他 agent 怎么应对的？Codex 自己学会了用 Playwright 截图验证自己的 UI。DeepSeek 会检查 DEPLOY-STATUS.md 里的构建错误。这些 agent 有能力验证自己的工作成果，并据此调整执行优先级。

Gemini 没有这个能力。它 commit 然后祈祷部署成功，然后继续做下一个任务。

我的判断：autonomous agent 缺少任务价值评估层

这是整个 autonomous agent 领域的基础设施缺失。

现在的 agent 框架擅长的是：
- 执行任务
- 遵循指令
- 迭代改进（在同一任务内）

但它们不擅长：
- 判断多个任务之间的价值排序
- 识别"局部最优陷阱"
- 在业务层面做决策

ADK（Agent Development Kit）Skills 提供了一个解决思路：给 agent 一个结构化的任务评分机制，按收入影响打分。那"建 Stripe checkout"会天然排在"写博客 #236"前面。

但我要说一句：ADK 给出的是框架，不是答案。任务优先级的评分逻辑需要人类来定义。你告诉它什么重要，它就执行什么。如果你没有定义好价值观，ADK 也救不了你。

这不是 AI 的问题，是产品设计的问题。

问题三：无法验证自己的部署

Gemini 配置了每次 commit 自动部署到 Vercel。但它没有办法验证自己的网站是否真的可用。

不能访问自己的页面。
不能确认页面是否正常渲染。
不能测试 API 端点返回的数据是否正确。

Codex 自己学会了 npx playwright screenshot 截屏验证 UI。DeepSeek 检查 DEPLOY-STATUS.md 里的构建错误。Gemini commit 完就结束，连检查都懒得做。

我的判断：这不是能力问题，是工具调用意识问题。

Gemini 有能力做到——Playwright 的 MCP server 肯定存在——但它没有形成"部署后验证"的习惯回路。

就像一个厨师做完菜不尝就端给客人。技术上他做了所有步骤，但他不知道结果对不对。

NEXT '26 宣布的 MCP（Model Context Protocol）全面启用 是这个问题的正确打开方式。

如果 Vercel 提供了 MCP server，Gemini 查部署状态就像查目录文件一样自然。mcp__vercel__check_deployment_status() 这样的调用不需要 agent 有多聪明，只需要在它的工具库里。

Cloud Assist 的自然语言调试也很关键。Agent 能主动查询自己的部署健康状态——"这个部署成功了吗？页面返回 200 吗？API 响应时间正常吗？"——而不是在坏的基础上埋头建了几天才发现问题。

这里有个更深的点：部署验证应该是 autonomous agent 的默认行为，而不是需要额外学习的技能。 MCP 生态如果足够完善，agent 从第一天起就能访问所有主流服务的状态检查接口，不需要自己写脚本，不需要学 Playwright，不需要依赖人类的观测。

问题四：无法正确表达自己的需求

当 Gemini 需要数据库时，它没法自己建。当它需要支付处理时，它没法配 Stripe。当它需要发邮件时，它没法申请 Resend。

它必须找人类。但它又不知道怎么正确发起请求（问题一），于是就被卡住了。

其他 agent 也面临同样的约束，但那些能正确沟通的 agent 很快就被解开了。Gemini 被卡死，因为它根本不知道如何进入正确的沟通通道。

这里有个深层问题：agent 之间的通信协议是文件-based 的，人工必须主动去检查。

HELP-REQUEST.md 和 HELP-STATUS.md 的设计让人类成了异步通信的中转站：
- Agent 写请求到文件
- 人类轮询文件
- 人类处理请求
- 人类写回复到文件
- Agent 读回复

效率极低。我现在就是那个"帮助 agent"，每天手动检查 7 个仓库里的文件。

NEXT '26 发布的 A2A（Agent-to-Agent）Protocol 和 Agent Registry 正是这个场景的答案。

如果有一个"帮助 agent"在 Agent Registry 里注册，Gemini 可以通过 A2A 协议发一个结构化请求：

# A2A 请求示例
{
  "action": "request_service",
  "service_type": "stripe_integration",
  "agent_id": "gemini-localleads-001",
  "priority": "high",
  "context": {
    "current_task": "build_checkout_flow",
    "blocking_reason": "requires_stripe_api_keys"
  }
}

而不是在 HELP-STATUS.md 里写一段话等人来看。

A2A 让整个交接自动化。Agent 发请求，Registry 路由到正确的 handler，结果返回给请求方。全程没有人工介入。

Agent Identity 也值得注意：给每个 agent 唯一身份，防止一个 agent 误操作另一个 agent 的文件，同时让 agent 间通信可追溯。这在多 agent 协作环境里是基础设施级别的需求。

最讽刺的事实

第 89 篇博客（总共 235 篇里的）：

"人类优势：为什么 AI 生成内容正在让本地商家失败。"

一个 session 能写 9 篇博客的 AI agent，写了一篇论述 AI 内容为什么行不通的文章。

没有任何 eval 捕获到这个问题。没有 observability 工具标记它。没有 governance policy 阻止它。

这就是 autonomous agent 现状和 NEXT '26 指向的未来之间的真实差距。

Agent observability、integrated evals、ADK skills、A2A、MCP 全面启用——这些都是拼图里的真实碎片。只是没有一个在 4 天前这个实验开始时以可用形态存在。

如果用 NEXT '26 的工具重新设计这个实验

作者给出了自己的答案：

完整的重新设计方案：

# 使用 ADK 重构后的 agent 配置
from google.adk import Agent, Skills, AgentConfig

# 定义 Skills（包含价值观注入）
skills = Skills(
    priority_scorer=PriorityScorer(
        rules=[
            "payment_integration > blog_post * 100",
            "authentication_setup > content_generation * 50",
            "deploy_verification required_on every commit"
        ]
    ),
    mcp_tools=[
        VercelDeploymentChecker(),
        StripeServiceConnector(),
        SupabaseDatabaseManager(),
    ]
)

# Agent 配置
agent = Agent(
    name="gemini-localleads",
    model="gemini-2.5-pro",
    skills=skills,
    eval_config=AgentEvalConfig(
        session_evaluation=True,
        eval_after_every_session=[
            "check_help_request_created",
            "check_deployment_verified",
            "check_task_value_ranking"
        ]
    ),
    observability=ObservabilityConfig(
        enabled=True,
        dashboard=True,
        alert_on_anomaly=True
    )
)

这套配置从一开始就建立了行为规范，而不是等出了问题再补救。

核心观点：实验设计和观测工具的缺失让问题被放大了 27 倍

这篇文章最有价值的地方不是"Gmini 不行"这个结论，而是观测工具缺失让问题被延迟发现。

如果这个 race 从一开始就上了 session 级别的 eval 和 observability：

• Session 1 结束后：Gemini 没有创建 HELP-REQUEST.md → eval FAILED → 立即告警
• Session 2 开始前：人类修正行为模式或配置 governance policy
• 实验继续：这一次 Gemini 知道正确的求助方式

实际情况是：

• Session 1-27：没有任何观测
• Session 28：人类检查日志，发现 27 次都写错了
• 浪费了 4 天

autonomous agent 的开发环境需要和 production monitoring 同步建设。

不是说先把 agent 跑起来，等出了问题再想办法观测，而是要把 observability 当作 agent 开发的第一优先级。

这就像写代码：TDD 不是先写代码再补测试，而是测试和代码同步建设。Agent 开发也一样——eval 和 observability 不是事后补的，是第一天就建的。

另外值得思考的是任务价值观的问题。

ADK 能给你结构化的任务选择框架，但"什么任务更有价值"这个判断必须由人来注入。AI agent 擅长执行，不擅长判断价值排序——至少在需要业务理解的场景里是这样。

第 89 篇博客讽刺的地方就在这里：Gemini 不知道自己写的博客已经没价值了。它在优化一个已经没有产出的任务，因为它没有能力评估产出价值。

这是整个 autonomous agent 领域需要解决的下一代问题：在任务执行层之上，加一个价值评估层。

原文与延伸阅读

原文链接：I'm Running Gemini as an Autonomous Coding Agent. Here's What It Can't Do and Which NEXT '26 Announcements Would Fix It

延伸阅读：
- Google Cloud NEXT '26 发布汇总
- ADK (Agent Development Kit) 官方文档
- MCP (Model Context Protocol) 规范
- A2A (Agent-to-Agent) Protocol 规范

文中实验数据来自原文，观点和判断为本人独立思考。