Uber Engineering 披露了一套更具体的企业级 AI Agent 落地案例。按照 Uber 的说法，AI 工具已经进入公司软件开发生命周期（SDLC）的各个阶段，超过 70% 的 Pull Request（PR）可归因于本地或云端 Agent；员工已经建立超过 3,600 个 Agent Skills，每天执行超过 3 万次 Agent Skill。
这套体系里，AI Agent 的角色已经不只是工程师主动打开 Coding Assistant，请模型协助写几行代码。越来越多任务并非由人手动发起，而是由 Managed Agents 自动接手。人类工程师的职责则逐步转向最终 Review，以及处理 Agent 无法完成时的 Escalation。Uber 把这一愿景称为 Software Factory，即“软件工厂”。
从“工程师使用 AI”转向“AI 直接接收工作”
Uber认为，真正关键的变化，是从 Interactive Developer Workflow 逐步转向 Fully Managed Agents。传统 AI Coding 仍以人为中心：工程师遇到问题后，打开 Claude、GPT 或其他 Coding Agent，输入需求，再等待模型执行。
Managed Agent 的逻辑不同。以 CI Pipeline 出错为例，流程不必再等待工程师先发现问题、复制 Error Message、再拿去询问 AI。Agent 可以直接接收失败事件，自动获取相关 Context，分析问题并尝试修复，最后生成修改结果，交由人类确认。
Code Review 也在被纳入这一流程。Uber 已建立名为 uReview 的 AI Code Review 系统，用于处理公司的 Pull Requests。为了确认 AI 是否真的能识别问题，Uber 采用真实发生过 Bug 的 PR 构建 Benchmark，并按 Easy、Medium、Hard 分级，再评估模型的 Precision、Recall、F1、延迟与错误率。换句话说，AI Code Review 不再只是工程师偶尔询问“这段代码有没有问题”，而是成为软件开发流程中的固定环节。
单一 Agent 不再包办全部任务
Uber 内部的 AI 工作模式，也开始从“一个 AI 完成一切”转向 Multi-Agent。随着新一代模型的 Agent Orchestration 能力提升，Uber 发现，越来越多 Session 会主动创建 Subagents。
这类分工更像一个小团队。主要 Agent 负责理解目标、拆解任务和验收结果；Subagents 则分别执行那些输入明确、边界清晰的子任务。由于 Subagent 接收的工作范围通常更明确，未必需要调用最强的 Frontier Model。Uber 因此默认让 Subagents 使用能力较弱但成本更低的模型，再由主要模型负责更复杂的推理与质量判断。
在这种结构下，AI Agent 更接近“管理者 + 执行团队”，而不只是一个聊天机器人。
真正进入企业环境后，瓶颈先出在找资料
Uber 也提到，AI Agent 融入企业工作流后，最现实的问题并不是写代码本身，而是查找信息。Uber 拥有数亿行代码和数千张数据表，相关信息分散在服务、Pull Requests、Incident Logs、Architecture Documents、Deployment Records 以及不同 Dataset 中。
如果 Agent 缺少公司内部 Context，就可能不断搜索代码、调用工具、创建 Subagents，最后仍得出错误答案。为此，Uber 建立了一套 AI Context Graph。这个企业知识网络整合了超过 30 个内部系统，目前包含约 2,400 万个 Nodes 和 8,000 万条 Edges，覆盖服务、工程团队、事故记录、PR、架构文档、部署、Dataset，以及历史数据表使用记录等信息，并支持 Agent 以自然语言查询。
Uber 给出了同一模型下的一组测试结果。有 Context Graph 的 Agent 能依据历史记录，找到一张被超过 50 名分析师实际使用的正确数据表，只花 38 秒完成任务；没有 Context Graph 的 Agent 则花了 20 分钟检查 Service Code、创建两个 Subagents、遇到三次错误，最后还错误判断该 Dataset 无法查询。
超过 1000 个 MCP Server，但不会一次全部塞给模型
除了知道数据在哪，Agent 还要知道该调用什么工具。Uber 内部已经部署超过 1,000 个 MCP Servers，用于连接大量内部服务和第三方 SaaS。
但 Uber 发现，如果一开始就把所有工具说明都提供给模型，反而会带来额外负担。安装超过 100 个 Tools 时，仅预加载 Tool Schema 就可能占用约 5 万至 7 万 Token。于是，Uber 改变了策略：不要求 Agent 一开始就“知道所有工具”，而是允许 Agent 在需要时通过 CLI 和 Tool Search 查找合适工具，再动态加载。
Uber 用一个更接近企业协作的比喻来解释这种设计：新进员工不需要在第一天背下公司所有内部系统的操作手册，但需要知道，遇到某类问题时，应该去哪里找到对应工具。
让 Agent 自己写程序调用企业工具
在工具使用之外，Uber 还引入了 Code Mode，让 Agent 不只是单次调用某个 Tool，而是可以自己写一段 Python Script，把多个操作串联起来。
以查询公司 Data Warehouse 为例，传统 Agent 的流程可能是先发送 SQL、等待、查询状态、继续等待、再次查询，最后再取得结果。这个过程中，几乎每一步都需要模型介入。使用 Code Mode 后，Agent 可以直接生成 Python Loop，让程序自行完成等待和 Polling，最后只把真正有用的结果回传给模型。
根据 Uber 的测试，即使只是执行 5 个相同的 SQL Query，这种方式也能把 Token 使用量降低超过 50%；在大量批处理任务里，节省幅度还可以超过 90%。Uber 已为最常使用的 MCP Servers 建立超过 25 个 Code-mode Skills，把企业内部高频操作封装成 Agent 可重复调用的能力。
3600 个 Skills，被 Uber 视为可执行的企业 SOP
Uber 已建立超过 3,600 个 Agent Skills，这一点也是其整个实践中最核心的部分之一。企业过去的知识通常保存在 Documentation、SOP，或者干脆掌握在资深员工手里；而 Agent Skill 的思路，是把“遇到这类工作该怎么处理”进一步封装成 AI 可以直接执行的能力。
Uber 还计划推进 Continuous Skill Improvement。按照其设想，未来 Agent 在执行 Skill 时遇到的问题，也就是文中提到的 papercuts，可以被自动记录，再利用这些 Execution Traces 生成 Skill 更新。
从 Uber 公布的数据看，这套方法已经不再停留在单点试验阶段，而是开始把企业知识、工具调用和软件开发流程连接成一套持续运行的 Agent 体系。