四层 Agent 架构:不是一个工具,而是一个系统

Uber 的 AI 开发体系分为四层:内部 AI 平台层、上下文数据源层、行业工具集成层,以及面向特定任务的专用 Agent 层(比如测试 Agent 和代码审查 Agent)。

为什么要分这么多层?想想看——如果你只是给工程师一个 Claude Code 或 Cursor,它对你的代码仓库一无所知,对内部 API 规范一无所知,对部署流程一无所知。它能写出代码,但写出的代码很可能不符合项目规范,无法通过 CI,甚至调用了根本不存在的内部服务。

所以 Uber 做了几件关键的事:

  • MCP Gateway:一个统一的网关,让所有 AI Agent 都能安全地访问内部上下文——代码仓库、文档、服务目录等
  • Uber Agent Builder:内部的 Agent 搭建框架,让团队可以快速构建面向特定场景的 Agent
  • AIFX CLI:命令行工具,降低开发者使用 AI 工具的门槛

这个思路对独立开发者同样适用:与其直接让 AI 写代码,不如先想清楚怎么把你的项目上下文喂给它。

从"写代码"到"调度 Agent":开发者工作方式的转变

最有意思的发现是,工程师的工作方式正在从"在 IDE 里单线程写代码"转变为"同时调度多个并行 Agent"。工程师们会自然而然地启动多个 Agent 同时处理不同任务——一个写功能代码,一个写测试,一个处理迁移。

Claude Code 的使用率在三个月内几乎翻倍——从 2025 年 12 月的 32% 飙升到 2026 年 2 月的 63%,而基于 IDE 的工具(Cursor、IntelliJ 插件)增长已经趋于平缓。这说明什么?开发者正在从"AI 辅助补全"走向"AI 自主执行",CLI 类 Agent 工具更适合这种多任务并行的工作模式。

84% 的 Uber 开发者已经是 Agent 编程用户——要么使用 CLI Agent,要么在 IDE 中更多地发起 Agent 式请求而非仅仅依赖 Tab 补全。

Minion:后台 Agent 大规模运行平台

Uber 内部构建了一个叫 Minion 的平台,专门用于在后台大规模运行 Agent。它具备 monorepo 访问权限和优化过的默认配置,本质上是一个抽象层,让 Agent 能够在受控环境中自主完成任务。

这对一人公司有什么启发?你不需要构建 Uber 级别的平台,但你完全可以用类似的思路:让 Agent 在后台帮你跑任务。比如用 n8n 编排一个工作流,让 AI Agent 定期扫描代码库、自动生成测试、自动提交 PR。核心理念是一样的——把重复性工作交给 Agent,你只负责审查和决策。

围绕 AI 生成代码的配套工具

更多的 AI 生成代码意味着更多的代码审查压力和更多的噪音。Uber 为此构建了一系列配套工具:

  • Code Inbox:智能 PR 路由,把需要你审查的 PR 按优先级排好
  • uReview:AI 驱动的代码审查,只给出高信号的评论,过滤掉噪音
  • Autocover:自动生成单元测试,每月产出超过 5000 个测试用例
  • Shepherd:端到端管理大规模代码迁移

注意这个模式:AI 写代码只是第一步,你还需要 AI 来审查代码、AI 来写测试、AI 来管理迁移。这是一个 Agent 协作链,而不是单点工具。

落地比想象的难:成本和采纳率的现实

即使在 Uber 这样技术文化激进的公司,AI 的实际采纳速度也比预期慢。他们发现,自上而下的强制推行效果不如工程师之间互相分享成功经验。

另一个现实问题是成本。Uber 的 AI 相关开销自 2024 年以来增长了 6 倍,Token 成本优化已经成为一个专门的优先事项。当你的 Agent 并行运行时,Token 消耗是爆炸式增长的。

这对独立开发者来说是个重要提醒:AI Agent 不是免费的生产力。你需要在效率收益和 API 成本之间找到平衡点。

给独立开发者的实操启示

Uber 的案例虽然是大公司的实践,但核心思路完全可以降维应用:

  • 先搭上下文层:用 MCP 协议把你的项目文档、代码规范、API 定义喂给 AI,而不是裸跑 Agent
  • 用 CLI Agent 而非仅 IDE 补全:Claude Code 这类工具更适合"分配任务"式的工作方式
  • 构建 Agent 协作链:写代码的 Agent、审查代码的 Agent、写测试的 Agent,形成流水线
  • 关注成本:监控你的 Token 用量,对大型任务考虑使用更便宜的模型做初步处理

Uber 的实践证明了一件事:AI 在软件开发中的价值不在于替代程序员,而在于改变程序员的工作方式——从"亲手写每一行代码"变成"设计和调度 Agent 来完成工作"。那么问题来了:作为一个独立开发者,你现在的工作流里,有多少环节其实可以交给 Agent 去并行处理?