文章

对话

方形资料图片
Uber EngineeringUber 工程团队
@UberEng@UberEng
图像
Running a Software Factory Efficiently at Uber Scale在 Uber 规模下高效运行软件工厂
178万178万
Post author:
@udaykiran
文章作者：@udaykiran

Introduction
简介

AI tools are now embedded in every phase of software development at Uber. More than 70% of pull requests are attributed to local or cloud agents. Engineers have built over 3,600 agent skills across the software development life cycle, and executed more than 30K agent skill executions per day.如今，AI 工具已嵌入 Uber 软件开发的各个环节。超过 70% 的拉取请求（Pull Request）由本地或云端智能体完成。工程师们已围绕软件开发生命周期构建了超过 3,600 项智能体技能，每天执行超过 3 万次技能调用。
At the AI Engineer 2026 conference, we shared
our vision
for the Software Factory and the building blocks and managed agents we are building across the lifecycle. As we progress on that vision, a growing share of sessions aren’t initiated by humans, but by automated managed agents handling code review, self-healing CI failures, completing E2E PRs with visual validation, triaging on-call alerts, debugging incoming bugs, and handling a variety of code maintenance tasks with human reviews/escalations.在 2026 年 AI 工程师大会上，我们分享了关于“软件工厂”的愿景，以及我们在整个生命周期中构建的构建块和托管智能体。随着愿景的推进，越来越多的会话不再由人类发起，而是由自动化的托管智能体处理，例如代码审查、修复 CI 故障、通过视觉验证完成端到端 PR、分流值班警报、调试传入的 Bug，以及在人类审核/介入下处理各种代码维护任务。
As shown in Figure 1, from February to Aug 2026, weekly active users across all agentic offerings across all our employees (engineers & non-engineers) grew 7x, and weekly agentic requests grew 9.4x. Meanwhile, our total AI spend has relatively stabilized since April due to optimizations across the board.如图 1 所示，从 2026 年 2 月到 8 月，我们所有员工（包括工程师和非工程师）对各类智能体产品的使用周活跃用户数增长了 7 倍，周智能体请求量增长了 9.4 倍。与此同时，得益于全面的优化措施，我们的 AI 总支出自 4 月以来已相对趋于稳定。
图像
Since adoption, workload mix, and model upgrades are all continuously changing, isolating our own optimization gains means holding one model fixed, since behavior shifts with every upgrade and model family. We did that from February to July: cost per 1,000 model requests is down almost 34% from its peak, and cost per session is down 52% from its June peak. 由于采用率、工作负载组合和模型升级都在持续变化，为了准确衡量我们的优化成果，我们选择固定使用某一款模型进行对比，因为每次升级和模型系列的更替都会改变行为模式。我们对 2 月到 7 月的数据进行了对比：每 1,000 次模型请求的成本较峰值下降了近 34%，单次会话成本较 6 月峰值下降了 52%。
图像
This blog walks through how we think about our software factory: the four layers agent sessions run in, the cost equation we use to decompose spend, how we measure each term, and how we optimize those terms across every layer.本文将介绍我们对软件工厂的构思：智能体会话运行的四个层级、我们用于分解支出的成本公式、衡量各项指标的方法，以及我们在每一层如何进行优化。
All pricing and vendor metrics in this comparison are based on publicly available information, with cost efficiency gains driven by routing our internal Uber workloads more intelligently within standard tier-pricing. While specific cost reductions we measure are unique to our environment and your mileage may vary depending on your codebase, team size, and agent workflows, the methodology of benchmarking real work and optimizing for accuracy and cost is universally applicable.本比较中提到的所有定价和供应商指标均基于公开信息。我们的成本效率提升主要源于在标准分级定价范围内更智能地路由 Uber 内部工作负载。虽然我们测得的具体成本削减仅适用于我们的环境，且具体成效会因代码库、团队规模和智能体工作流的不同而异，但这种对真实工作进行基准测试并针对准确性和成本进行优化的方法论是普遍适用的。

The Software Factory and Its Cost Equation
软件工厂及其成本公式

Four Layers of Agent Usage智能体使用的四个层级
We organize AI usage into four layers, from the most specialized to the most general. As shown in Figure 3, the higher the layer, the more control we have over cost, quality, and model selection.我们将 AI 使用情况分为四个层级，从最专业化到最通用化。如图 3 所示，层级越高，我们在成本、质量和模型选择方面的控制力就越强。
图像
The Cost Equation成本公式
Across any of the layers above, we can decompose the cost of an agentic session into the following terms, which we could measure and optimize independently.在上述任何层级中，我们都可以将智能体会话的成本分解为以下几项，从而能够独立地对其进行衡量和优化。
图像
The first two terms represent adoption & engagement, which we want to keep growing across our overall user base, whether users use it interactively or agents handle tasks on their behalf. The three middle terms provide opportunities for optimization: the work the agent does on its own behalf, on top of the request an engineer actually made. That is where most of our effort goes. This includes mechanisms that help agents plan faster, reduce unwanted turns or errors, optimize input tokens, and more.前两项代表采用率和参与度，我们希望在整个用户群体中持续提升这两项指标，无论用户是进行交互式使用，还是由智能体代为处理任务。中间三项则提供了优化机会：即智能体在工程师发起的请求之外所做的额外工作。这是我们投入精力最多的地方，包括帮助智能体更快速地规划、减少不必要的轮次或错误、优化输入 Token 等机制。

How We Measure
衡量方法

Below is the full set of metrics we track weekly and monthly that enable us to forecast & plan our efforts short-term and long-term.以下是我们每周和每月跟踪的全套指标，这些指标使我们能够对短期和长期工作进行预测与规划。
图像

Optimization Levers
优化手段

In the following sections, we detail the key levers we used to optimize each part of the cost equation. Some of these levers affect one or more rows in the cost equation.在接下来的章节中，我们将详细介绍用于优化成本公式各部分的关键手段。其中一些手段会影响成本公式中的一行或多行。
图像

Optimizing Price / Token
优化价格/Token

The vendor sets the token price. We pick which model runs which workload. Across all our managed agents’ layers, we pick the model that’s most Pareto efficient for that workload. For us, Pareto efficient means cost/completed task, output quality, and model reliability.Token 价格由供应商设定。我们负责选择哪种模型运行哪种工作负载。在所有托管智能体层级中，我们都会选择在该工作负载下具有最高帕累托效率（Pareto efficient）的模型。对我们而言，帕累托效率意味着成本/已完成任务、输出质量和模型可靠性之间的最佳平衡。
Benchmark-Driven Model Selection基于基准测试的模型选择
Model selection happens in four steps, the same for every managed agent we run.模型选择分为四个步骤，适用于我们运行的每一个托管智能体。
  • Build a benchmark out of the agent’s real work.
    利用智能体的真实工作构建基准测试。
  • Run the agent on a harness that serves any model, frontier or open-weight, behind one interface.
    在支持统一接口、兼容任何模型（前沿模型或开源权重模型）的测试框架上运行智能体。
  • Move to whatever is Pareto optimal, and keep moving. The frontier shifts every few weeks.
    迁移至帕累托最优模型，并持续迭代。前沿模型每几周就会更新一次。
Looking ahead, we continually refine our workload performance by leveraging aggregated insights from our managed agents to test and deploy various model routing strategies.展望未来，我们将通过利用托管智能体汇总的洞察来测试和部署各种模型路由策略，从而不断改进工作负载性能。
For example, we use uReview, which handles AI code review for all pull requests. We built its benchmark from real pull requests with known bugs and graded them easy, medium, and hard. We score precision, recall, and F1 against those bugs, plus cost per review, latency, timeouts, and noise. As shown in Figure 5, switching models improved our F1 while dramatically reducing cost/PR. In the figure, the dashed line is the Pareto frontier. Everything below and left of it is beaten by something cheaper or better.例如，我们使用 uReview 来处理所有拉取请求的 AI 代码审查。我们利用带有已知 Bug 的真实拉取请求构建了基准测试，并将其分为简单、中等和困难三个等级。我们针对这些 Bug 对精确率、召回率和 F1 分数进行评分，同时评估每次审查的成本、延迟、超时和噪声。如图 5 所示，切换模型在提高 F1 分数的同时，大幅降低了单次 PR 的成本。图中虚线为帕累托前沿线，位于该线左下方的一切配置均被更便宜或更好的方案所取代。
图像
Using thousands of real-world PRs across our large monorepos, we internally also have an Uber SWE Benchmark that runs frontier and open-weight models across different task types. We use it to inform model selection across all our SDLC-managed agents.利用大型单体代码库中的数千个真实 PR，我们在内部还拥有一个 Uber SWE 基准测试，用于在不同任务类型中运行前沿模型和开源权重模型。我们利用它为所有 SDLC 托管智能体的模型选择提供依据。
Default Model Selection默认模型选择
In the interactive interface, token unit costs remain fixed; however, you can strategically manage token distribution across models. Two default settings primarily govern this distribution: the initial session model and the subagent model.在交互式界面中，Token 单位成本是固定的；但你可以策略性地管理各模型间的 Token 分配。主要有两个默认设置控制这种分配：初始会话模型和子智能体模型。
The subagent default setting has proven to be the most impactful lever, and its significance continues to grow. The proportion of sessions initiating subagents has steadily increased as the latest model capabilities enable more effective multi-agent orchestration. Because subagents perform well-defined tasks with specified inputs that often do not require frontier-level reasoning, we default them to a weaker, more cost-effective model while still allowing manual overrides. The primary model handles task decomposition and evaluation while subagents execute the work.子智能体默认设置已被证明是最具影响力的手段，且其重要性与日俱增。随着最新模型能力支持更有效的多智能体编排，发起子智能体的会话比例稳步上升。由于子智能体执行的是具有明确输入且通常不需要前沿级推理的特定任务，我们将其默认设置为更弱、更具成本效益的模型，同时也允许手动覆盖。主模型负责任务分解和评估，而子智能体负责执行工作。

Optimizing Tokens / Request
优化 Token/请求

Every turn re-sends the full conversation history, project context, and tool results. Anything that reduces the per-request payload compounds across the session.每一次对话轮次都会重新发送完整的对话历史、项目上下文和工具结果。任何能够减少单次请求负载的操作，都会在整个会话中产生累积效应。
Defaults默认配置
All interactive harnesses use a unified wrapper for installation management, configuration, authentication, and cost visibility. Two standardized default configurations directly reduce token consumption per request:所有交互式测试框架都使用统一的封装层来管理安装、配置、身份验证和成本可视化。两种标准化的默认配置直接减少了单次请求的 Token 消耗：
  • Automatic compaction is triggered at 400k tokens even for 1M context window models: This threshold balances model performance against cache bursts and repeated input token costs. Our measurements show a meaningful reduction in fleet-wide input tokens per request.
    自动压缩：即使对于拥有 100 万 Token 上下文窗口的模型，也会在达到 40 万 Token 时触发自动压缩。该阈值在模型性能与缓存突发及重复输入 Token 成本之间取得了平衡。我们的测量结果显示，全公司范围内的单次请求输入 Token 数量显著减少。
  • Reasoning effort defaulted to Medium: Output tokens, including internal reasoning tokens, are billed at multiples of the rate of input tokens on primary models; this policy adjustment directly reduces spend in the highest-cost token category. For a large category of tasks, Medium reasoning hits a good balance between cost vs quality.
    推理工作量默认设为中等：输出 Token（包括内部推理 Token）在主模型上按输入 Token 费率的倍数计费；这一政策调整直接降低了最高成本 Token 类别的支出。对于大量任务而言，中等推理在成本与质量之间达到了良好的平衡。
Prompt Caching Strategy提示词缓存策略
Our prompt caching strategy is driven by the economics of provider prompt cache reads and writes. Since each turn re-transmits the full conversation history, caching the preceding context avoids paying the full cost repeatedly, reducing subsequent reads to just 0.1x the standard input token rate. However, write premiums vary: 5-minute cache entries cost 1.25x, while 1-hour entries cost 2x. Choosing an optimal TTL (Time-to-Live) therefore depends on the duration of gaps between turns. Available TTL options include 5 minutes and 1 hour from Anthropic®, alongside 30 minutes from OpenAI®.我们的提示词缓存策略由供应商提示词缓存的读写经济性驱动。由于每一轮对话都会重新传输完整的对话历史，缓存之前的上下文可以避免重复支付全额成本，从而将后续读取成本降低至标准输入 Token 费率的 0.1 倍。然而，写入溢价各不相同：5 分钟缓存条目成本为 1.25 倍，而 1 小时条目成本为 2 倍。因此，选择最佳 TTL（生存时间）取决于对话轮次之间的间隔时长。可用的 TTL 选项包括 Anthropic® 的 5 分钟和 1 小时，以及 OpenAI® 的 30 分钟。
图像
Because engineers often leave interactive sessions idle for more than 5 minutes, we transitioned from the default 5-minute TTL to a 1-hour window. These frequent idle gaps previously invalidated the prefix cache, forcing costly full-price context rebuilds. Sub-agents, by contrast, retain a 5-minute cache TTL because their execution focus is limited to single, short-lived tasks.由于工程师经常将交互式会话闲置超过 5 分钟，我们将默认的 5 分钟 TTL 调整为 1 小时。这些频繁的闲置间隙此前会导致前缀缓存失效，从而被迫进行昂贵的全价上下文重建。相比之下，子智能体保留了 5 分钟的缓存 TTL，因为它们的执行重点仅限于单一、短期的任务。
Executing MCP Tools via the Shell通过 Shell 执行 MCP 工具
At Uber, all MCP (Model Context Protocol) interactions are routed through a unified gateway. This single entry point encompasses more than 1,000 MCP servers across internal and third-party SaaS MCP, enabling centralized authentication and policy enforcement.在 Uber，所有 MCP（模型上下文协议）交互都通过统一网关进行路由。该单一入口点涵盖了超过 1,000 个内部及第三方 SaaS MCP 服务器，实现了集中式身份验证和策略执行。
However, standard MCP loads all tool schemas directly into every session, regardless of whether an engineer will ever invoke them in that session or not. For example, with over 100 tools installed, this pre-loading added approximately 50K-70K tokens of schema overhead to the initial prompt, which was subsequently re-sent on every context turn.然而，标准 MCP 会将所有工具模式（Schema）直接加载到每个会话中，无论工程师在该会话中是否会调用它们。例如，安装 100 多个工具后，这种预加载会在初始提示词中增加约 5 万至 7 万 Token 的模式开销，且随后在每次上下文轮次中都会被重复发送。
图像
To address this context bloat, we introduced two complementary optimization mechanisms:为了解决这种上下文膨胀问题，我们引入了两种互补的优化机制：
  • CLI tool resolution: Replaces direct MCP integration by allowing the model to execute a shell command. The CLI resolves and invokes the required tool against the gateway dynamically at call time, eliminating Uber MCP schemas from the session context. All 1K+ MCP tools from our internal MCP gateway are projected as CLI commands.
    CLI 工具解析：通过允许模型执行 Shell 命令来替代直接的 MCP 集成。CLI 在调用时动态解析并向网关发起工具调用，从而消除了会话上下文中的 Uber MCP 模式。我们内部 MCP 网关中的 1,000 多个 MCP 工具均被映射为 CLI 命令。
  • Tool search: Scales to thousands of tools by allowing the model to search the tool catalog and load only required tools on demand. This approach mitigates context bloat, typically reducing token usage for tool definitions, and maintains high selection accuracy even as the available tool library expands, preventing degradation associated with large tool sets.
    工具搜索：通过允许模型搜索工具目录并仅按需加载所需工具，从而扩展至数千个工具。这种方法减轻了上下文膨胀，通常能减少工具定义的 Token 使用量，并在工具库扩展时保持高选择准确性，避免了大型工具集带来的性能下降。
Code-Mode代码模式（Code-Mode）
When tools call functions directly as shell commands, models can batch multiple actions within a single script. This batching is particularly advantageous for chatty tool protocols. Under standard MCP workflows, each action requires a separate model turn to emit a request, load the raw response into the context window, and process the results sequentially. For instance, executing a single SQL query requires submitting the request, polling status 2 to 5 times, and retrieving the output. Code-mode streamlines this entire flow into an automated Python loop, keeping intermediate polling out of the model’s active context. As shown in Figure 8 on the left, the model participates in the polling loop, and every response lands in its context. On the right, the loop runs in a subprocess, and only the summary comes back.当工具直接将函数作为 Shell 命令调用时，模型可以在单个脚本中批量处理多个操作。这种批处理对于高交互频率的工具协议尤为有利。在标准 MCP 工作流下，每个操作都需要单独的模型轮次来发出请求、将原始响应加载到上下文窗口并按顺序处理结果。例如，执行单个 SQL 查询需要提交请求、轮询状态 2 到 5 次并检索输出。代码模式将整个流程简化为一个自动化的 Python 循环，将中间轮询排除在模型的活跃上下文之外。如图 8 左侧所示，模型参与轮询循环，且每次响应都会进入其上下文。在右侧，循环在子进程中运行，仅返回摘要。
图像
We measured this by running 5 identical SQL queries through both paths in the same session:我们通过在同一会话中通过两种路径运行 5 个相同的 SQL 查询来衡量这一效果：
图像
The initial three rows highlight the main finding: even for minimal result sets far below response-size limits, code-mode reduces token usage by more than 50%. Rather than bypassing large data payloads, these efficiencies stem from eliminating unnecessary overhead, including schema initialization, multi-turn polling, and redundant step-by-step reasoning.前三行突显了主要发现：即使对于远低于响应大小限制的极小结果集，代码模式也能将 Token 使用量减少 50% 以上。这些效率提升并非源于绕过大数据负载，而是源于消除了不必要的开销，包括模式初始化、多轮轮询以及冗余的逐步推理。
Bulk workflows compound the effect, because the loop that would have been N model turns becomes one script and the savings compound to more than 90%. By deploying more than 25 pre-built code-mode skills for our most-accessed MCP servers, we ensure standard workflows default to the most cost-effective path.批量工作流放大了这一效果，因为原本需要 N 个模型轮次的循环现在变成了一个脚本，节省幅度累积超过 90%。通过为我们访问频率最高的 MCP 服务器部署超过 25 项预构建的代码模式技能，我们确保了标准工作流默认采用最具成本效益的路径。
SaaS MCPsSaaS MCP
Managing third-party software proved significantly more challenging than our internal servers. Vendors design MCP servers to expose full product capabilities because they can't anticipate specific customer usage. For instance, a workspace suite bundles 49 tools into a single server, requiring ~22K tokens of schema, while messaging and project tracking vendors ship 34 and 46 tools, respectively. Loading two or three vendor servers makes the agent carry more schema overhead than the file being edited before a user even enters a prompt.事实证明，管理第三方软件比我们的内部服务器更具挑战性。供应商设计的 MCP 服务器旨在暴露完整的产品功能，因为他们无法预见特定客户的用法。例如，一个工作区套件将 49 个工具捆绑在一个服务器中，需要约 2.2 万 Token 的模式，而消息传递和项目跟踪供应商分别提供了 34 和 46 个工具。加载两三个供应商服务器会导致智能体在用户输入任何提示词之前，就携带了比正在编辑的文件还要大的模式开销。
To address this, we route SaaS MCP servers through our MCP gateway using the same mechanism we do for our internal MCPs. We also expose all these MCPs as CLIs that any agentic surface can invoke. Additionally, we author dedicated skills within our code-mode plugin for each server to encapsulate common workflows. This unlocked efficient agentic workflows across many SaaS vendors.为了解决这个问题，我们使用与内部 MCP 相同的机制，通过我们的 MCP 网关路由 SaaS MCP 服务器。我们还将所有这些 MCP 暴露为任何智能体界面都可以调用的 CLI。此外，我们在代码模式插件中为每个服务器编写了专门的技能，以封装常见工作流。这为许多 SaaS 供应商解锁了高效的智能体工作流。
图像
Optimizing Requests / Turn优化请求/轮次
An ungrounded agent fails slowly rather than cheaply, repeatedly sending an expanding context window to search one more location. Providing richer information upfront remains the single most powerful lever to reduce this search overhead.一个缺乏背景信息的智能体往往会以“缓慢而非廉价”的方式失败，即反复发送不断扩大的上下文窗口去搜索更多位置。提前提供更丰富的信息，仍然是减少这种搜索开销最有效的手段。
Context Engineering上下文工程
Across Uber’s vast codebase and data ecosystem, comprising hundreds of millions of code lines and thousands of tables, agents spend most of their turns locating information rather than generating code. To address this, we engineered the AI Context Graph: a unified network containing 24 million nodes and 80 million edges across 86 nodes and 117 edge types. It integrates data from over 30 internal systems, including services, engineering teams, incident logs, pull requests, architectural design docs, deployments, datasets, and historical table usage queries, and lets any agent query it in natural language.在 Uber 庞大的代码库和数据生态系统中（包含数亿行代码和数千张表），智能体大部分时间都在定位信息而非生成代码。为解决此问题，我们构建了 AI 上下文图谱（AI Context Graph）：一个统一的网络，包含 2400 万个节点和 8000 万条边，涵盖 86 种节点类型和 117 种边类型。它整合了来自 30 多个内部系统的数据，包括服务、工程团队、事故日志、拉取请求、架构设计文档、部署、数据集和历史表使用查询，并允许任何智能体以自然语言对其进行查询。
图像
The grounded agent queried historical usage, identified the specific table used by over 50 analysts, and delivered the answer in 38 seconds. Conversely, the ungrounded agent lacked visibility into that table; it spent 20 minutes inspecting service code, spawning 2 subagents, and hitting 3 errors before incorrectly concluding the dataset was unqueryable.有基础支撑的智能体查询了历史使用情况，识别出 50 多名分析师使用的特定表，并在 38 秒内给出了答案。相反，缺乏基础支撑的智能体无法查看该表；它花费了 20 分钟检查服务代码，生成了 2 个子智能体，并触发了 3 次错误，最后错误地得出结论称该数据集无法查询。

Visibility & Education
可视化与教育

The levers here are visibility and feedback loops that help engineers and agents converge faster.这里的关键手段是可视化和反馈循环，帮助工程师和智能体更快地达成目标。
The Status Line状态栏
We put a live cost counter in the harness status line that tracks live spend per harness and across all harnesses for each user.我们在测试框架的状态栏中加入了一个实时成本计数器，用于跟踪每个测试框架的实时支出，以及每个用户在所有测试框架下的总支出。
图像
Visibility and Spend Tiers可视化与支出分级
To avoid imposing strict caps, we implemented real-time spend tracking and automated nudges:为了避免实施严格的上限，我们实现了实时支出跟踪和自动提醒：
  • Statusline live counter. Running session cost is always visible in the terminal.
    状态栏实时计数器。运行中的会话成本始终在终端可见。
  • Harness pool. One shared tier across all interactive harnesses, not per-tool budgets. And separate tiers for managed agents.
    测试框架池。所有交互式测试框架共享一个分级，而非按工具设置预算。托管智能体则有单独的分级。
  • Slack nudges. Alerts at 50/80/100% of expected spend so engineers have time to plan.
    Slack 提醒。在预计支出达到 50%/80%/100% 时发出警报，以便工程师有时间进行规划。
  • Easy approval flows. Manager sign-off for tier upgrades with quick propagation.
    简便的审批流程。经理可通过快速传播机制对分级升级进行确认。
  • Cost check skill and tips. A dashboard skill for on-demand cost breakdown and live status line coaching.
    成本检查技能与提示。一种用于按需成本分解和实时状态栏指导的仪表板技能。
These enable engineers to evaluate task ROI independently while mitigating runaway expenses.这些措施使工程师能够独立评估任务的投资回报率（ROI），同时减轻失控的支出。
Session Analysis Dashboard会话分析仪表板
While the status line highlights a session's total expenditure, it lacks visibility into cost drivers or actionable efficiency steps. General guidance provides high-level principles, but can’t evaluate individual developer workflows. The session analysis dashboard bridges this gap by inspecting session artifacts directly.虽然状态栏突显了会话的总支出，但它缺乏对成本驱动因素或可操作效率步骤的洞察。通用指南提供了高层原则，却无法评估开发者的个人工作流。会话分析仪表板通过直接检查会话产物填补了这一空白。
Built directly into the runtime, it requires zero setup or opt-in. Executing the cost dashboard skill analyzes all session traces for the user across local and remote cloud sandboxes across all harnesses they use. Rather than producing an aggregate metric, it flags 16 distinct anti-patterns across sessions, pairing each with its financial impact and a targeted remediation. Some of the categories include:它直接构建在运行时中，无需任何设置或加入。执行成本仪表板技能可分析用户在所有测试框架下，跨本地和远程云沙箱的所有会话轨迹。它不仅生成聚合指标，还会标记 16 种不同的反模式会话，并为每种模式提供财务影响分析和针对性的补救措施。部分类别包括：
  • Suboptimal model routing: Executing simple multi-turn sessions on Opus that Sonnet could easily fulfill.
    次优模型路由：在 Opus 上执行本可由 Sonnet 轻松完成的简单多轮会话。
  • Context window bloat: Large MCP payloads (for example, 40KB responses) persisting in context and incurring repeated billing on subsequent turns.
    上下文窗口膨胀：大型 MCP 负载（例如 40KB 的响应）持续存在于上下文中，并在后续轮次中导致重复计费。
  • Cache expiration inefficiencies: Resuming sessions after extended breaks where expired prompt caches force full-price prefix rebuilds.
    缓存过期效率低下：在长时间中断后恢复会话，导致过期的提示词缓存被迫进行昂贵的全价前缀重建。
  • Prompt initialization overhead: Pre-loading 100,000 tokens of system instructions and tool definitions before any user input is provided.
    提示词初始化开销：在提供任何用户输入之前，预加载 10 万 Token 的系统指令和工具定义。
图像
What’s Next?下一步计划？
Current initiatives in progress include:当前正在进行的举措包括：
  • Growing the fleet of managed agents: For every new agent, we follow a consistent roadmap: establish target outcome metrics, assemble evaluation benchmarks, and identify a Pareto-optimal model. This systematic approach aims to elevate each stage of the SDLC higher up the factory maturity model.
    扩大托管智能体阵容：对于每一个新智能体，我们都遵循一致的路线图：建立目标成果指标、组装评估基准，并确定帕累托最优模型。这种系统性方法旨在提升 SDLC 每个阶段在工厂成熟度模型中的水平。
  • Dynamic Model Routing: We’re expanding benchmark coverage across diverse programming languages, code repositories, and agent modalities. Effective model routing relies heavily on comprehensive evaluation, given that model capabilities vary widely.
    动态模型路由：我们正在扩大基准测试在不同编程语言、代码库和智能体模态中的覆盖范围。鉴于模型能力差异巨大，有效的模型路由严重依赖于全面的评估。
  • Deepening context-graph integration: We’re unlocking graph query capabilities across a wider selection of autonomous agents.
    深化上下文图谱集成：我们正在为更广泛的自主智能体解锁图谱查询能力。
  • Evolving session analytics into real-time developer guidance: By shifting from periodic batch detection of anti-patterns to continuous trace monitoring, we aim to deliver personalized, real-time efficiency recommendations directly to engineers.
    将会话分析演进为实时开发者指南：通过从定期的反模式批量检测转向持续的轨迹监控，我们旨在直接向工程师提供个性化的实时效率建议。
  • Continuous Skill Improvement: We are working on an automated way to record papercuts from agent skill executions and auto-generate skill updates from the collected traces.
    持续技能改进：我们正在研究一种自动记录智能体技能执行中的“小痛点”（papercuts），并从收集到的轨迹中自动生成技能更新的方法。

Conclusion
结论

Managing and curbing rising AI coding expenses is also a tractable engineering challenge. By eliminating wasted, zero-value token consumption rather than relying solely on lower unit prices or downgrading tooling, we scaled usage 7x while simultaneously reducing unit costs across all metrics and improving/maintaining output quality.管理和遏制不断上升的 AI 编码支出同样是一项可行的工程挑战。通过消除浪费的、零价值的 Token 消耗，而不是仅仅依赖更低的单价或降级工具，我们实现了 7 倍的使用量增长，同时在所有指标上降低了单位成本，并提升或保持了输出质量。
The core strategic shift is moving from interactive developer workflows to fully managed agents. Transitioning SDLC workloads into managed environments grants complete control over model routing, execution harnesses, and operational spend. Optimizing a fleet of specialized managed agents, each paired with dedicated evaluation benchmarks and a Pareto-efficient model, is inherently more cost-effective and scalable than optimizing individual terminal sessions across thousands of engineers.核心战略转变是从交互式开发者工作流转向完全托管的智能体。将 SDLC 工作负载迁移到托管环境中，可以完全控制模型路由、执行测试框架和运营支出。优化一系列专门的托管智能体（每个都配有专门的评估基准和帕累托高效模型），在本质上比优化数千名工程师的个人终端会话更具成本效益且更具可扩展性。

Acknowledgments
致谢

This is a collective effort by many engineers who are building the most efficient blocks to implement Software Factory at Uber scale, while ensuring we get ROI for every token we spend. We would like to thank our core team involved in various efforts across Software Factory listed here: Abhishek Bhatia, Adam Huda, Aditya Patel, Alok Srivastava, Ameya Ketkar, Anil Purohit, Atakan Kandemir, Ben Chou, Brandon Barker, Danielle Yim, Deepanshu Mehndiratta, Gaurav Gill, Israel Marban, Jason Varbedian, Karen Xu, Lei Shi, Mager Mager, Meghana Somasundara, Peng Liu, Preet Inder, Qiushen Wang, Rush Tehrani, Shesh Patel, Shiven Tripathi, Shubham Gupta, Stas Khalup, Ting Chen, Tse-Shi Wang, Ty Smith, Vikram Hullukunte, Weiqiang Wang, Will Bond.这是许多工程师共同努力的成果，他们正在构建最高效的模块，以在 Uber 规模下实现软件工厂，同时确保我们支出的每一分 Token 都能获得投资回报。我们要感谢在此处列出的参与软件工厂各项工作的核心团队：Abhishek Bhatia, Adam Huda, Aditya Patel, Alok Srivastava, Ameya Ketkar, Anil Purohit, Atakan Kandemir, Ben Chou, Brandon Barker, Danielle Yim, Deepanshu Mehndiratta, Gaurav Gill, Israel Marban, Jason Varbedian, Karen Xu, Lei Shi, Mager Mager, Meghana Somasundara, Peng Liu, Preet Inder, Qiushen Wang, Rush Tehrani, Shesh Patel, Shiven Tripathi, Shubham Gupta, Stas Khalup, Ting Chen, Tse-Shi Wang, Ty Smith, Vikram Hullukunte, Weiqiang Wang, Will Bond。
Also would like to thank Johannes Gehrke, Mattie Toia, Sumanth Sukumar, and Praveen Neppalli Naga for their leadership. Anthropic® is a registered trademark of Anthropic PBC. Claude Code™ and Claude® are trademarks of Anthropic, PBC. OpenAI® and its logos are registered trademarks of OpenAI®.同时感谢 Johannes Gehrke、Mattie Toia、Sumanth Sukumar 和 Praveen Neppalli Naga 的领导。 Anthropic® 是 Anthropic PBC 的注册商标。 Claude Code™ 和 Claude® 是 Anthropic, PBC 的商标。 OpenAI® 及其徽标是 OpenAI® 的注册商标。
想发布自己的文章？想发布自己的文章？
升级为 Premium升级为 Premium
上午5:02 · 2026年8月29日
178.9万178.9万
查看
查看引用查看引用
SW
发布你的回复

当前趋势

ホロドリ水着イベント開催中！
ホロライブゲーマーズが水着で登場！
Promoted by ホロライブドリームス【ホロドリ】