MCP 不是概念，是基础设施
Uber 内部搭建了一个 MCP Gateway（MCP 网关），作为所有 AI Agent 访问内部服务的统一入口。这不是一个实验性项目，而是整个 AI 工具链的生命线。
为什么要建网关而不是让每个 Agent 直连服务？原因很现实：大公司内部有几十上百个服务，权限、认证、数据格式各不相同。MCP Gateway 做的事情是把这些复杂性收敛到一层，Agent 只需要跟网关对话，不用关心后面接的是代码仓库、CI 系统还是监控平台。
对独立开发者的启示是：如果你在搭建自己的 Agent 工作流，当接入的工具超过三四个时，中间加一层统一的 MCP 服务来管理上下文和权限，会比让 Agent 直接调用各种 API 干净得多。
四层 Agent 架构
Uber 的 AI 开发体系分为四层：
- AI 平台层：底层基础设施，负责模型调用、Token 管理、成本控制
- 上下文源：代码仓库、文档、内部知识库等，通过 MCP 协议统一接入
- 行业工具层：Cursor、IntelliJ、Claude Code 等 IDE 和 CLI 工具
- 专用 Agent 层：针对测试、代码审查、迁移等场景的定制化 Agent
这个分层的关键判断是：通用工具（Cursor、Claude Code）负责日常编码，专用 Agent 负责高价值的重复性任务。两者不是替代关系，而是协作关系。
Minion：后台 Agent 的规模化运行
Uber 内部建了一个叫 Minion 的平台，专门用来在后台大规模运行 Agent。它的核心设计是：
- 直接访问 monorepo（单体代码仓库），不需要开发者手动提供上下文
- 预设了优化过的默认参数，开箱即用
- 支持并行运行多个 Agent 任务
这反映了一个正在发生的工作流变化：开发者从"在 IDE 里单线程写代码"转向"同时编排多个并行 Agent"。工程师的角色正在从执行者变成调度者。
这个趋势对一人公司尤其重要。一个人能同时跑五六个 Agent 处理不同任务，产出能力的上限被彻底改变了。
四个值得关注的内部工具
Uber 围绕"AI 生成更多代码"带来的新问题，造了一批工具：
- Code Inbox：智能 PR 路由。AI 生成的代码越多，代码审查的压力越大，这个工具负责把 PR 精准分配给合适的审查者
- uReview：AI 代码审查，只生成高信号的评论，过滤掉噪音。这一点很关键——AI Review 最大的问题不是不能用，而是废话太多
- Autocover：自动生成单元测试，每月产出超过 5000 个测试用例
- Shepherd：端到端管理大规模代码迁移。迁移是大型项目里最痛苦的工作之一，用 Agent 来跑迁移是一个非常聪明的切入点
这几个工具的共同逻辑是：AI 带来的效率提升会在下游制造新的瓶颈，然后用更多的 AI 工具去解决这些瓶颈。这个循环一旦转起来，不投入 AI 工具链的团队会越来越跟不上。
落地没那么容易
即使在 Uber 这样技术文化强势的公司，AI 的推广也比预期慢。他们发现：自上而下的强制推行效果不如工程师之间口口相传。一个人在团队里展示了 Agent 帮他省了两小时，比任何管理层邮件都有说服力。
另一个现实问题是成本。Uber 的 AI 相关开支自 2024 年以来增长了 6 倍，Token 成本优化已经成为优先事项。11% 的 PR 由 Agent 发起，这意味着 Agent 不只是在辅助人类，它们已经在独立产出代码——而每一次产出都在烧 Token。
对独立开发者意味着什么
Uber 的实践验证了几件事：MCP 作为 Agent 连接外部服务的协议层，已经在生产环境中证明了价值；Claude Code 在实际使用中正在快速替代 IDE 内的 AI 工具；Agent 的最佳应用场景不是"帮你写一个函数"，而是测试生成、代码审查、大规模迁移这类结构化、重复性强的任务。
独立开发者不需要复刻 Uber 的整套体系，但可以借鉴它的分层思路：用 MCP 管理你的工具接入，用 Claude Code 做日常开发，用专用 Agent 跑测试和审查。一个人加上这套工作流，产出能力可以逼近一个小团队。唯一需要盯紧的是 Token 成本——Uber 都在头疼这件事，说明目前整个行业还没有找到成本结构的最优解。