Uber 的智能体 SDLC：从编码智能体到可治理的软件工厂

简要描述Brief Description

Uber 工程师 Uday Kiran Medisetty 和 Adam Huda 介绍了支撑公司新兴智能体软件工厂的基础设施与工作流。他们首先讲解六个共享构建模块——模型和 MCP 网关、云开发环境、托管技能、上下文图谱以及 Cortana 助手——随后详细介绍了一个世界杯接送功能如何从构想和设计，经过自主编码、内循环验证、CI、代码评审，最终进入持续维护。演讲表明，扩展智能体开发的关键并不只是增加一个编码助手，而是构建安全、可观测且上下文丰富的系统，以支持整个软件生命周期。Uber engineers Uday Kiran Medisetty and Adam Huda describe the infrastructure and workflows behind the company’s emerging agentic software factory. They first explain six shared building blocks—model and MCP gateways, cloud development environments, managed skills, a context graph, and the Cortana assistant—then walk through a World Cup pickup feature from idea and design to autonomous coding, inner-loop validation, CI, review, and ongoing maintenance. The talk shows that scaling agentic development is less about adding a coding assistant and more about creating secure, observable, context-rich systems that can support the entire software lifecycle.

目录Table of Contents

• Uber 的智能体工程规模
  The Scale of Agentic Engineering at Uber
• 安全且可观测的模型网关
  A Secure and Observable Model Gateway
• 通过 MCP 网关让内部工具可访问
  Making Internal Tools Accessible Through an MCP Gateway
• 为长期运行的智能体打造的云环境
  Cloud Environments Built for Long-Running Agents
• 代理技能的托管生命周期
  A Managed Lifecycle for Agent Skills
• 在上下文图中统一公司知识
  Unifying Company Knowledge in a Context Graph
• Cortana 作为全公司范围的 AI 界面
  Cortana as a Company-Wide AI Interface
• 将世界杯功能从创意变为原型
  Taking a World Cup Feature from Idea to Prototype
• 使用 Minion 构建功能
  Building the Feature with Minion
• 将验证与审查移入内循环
  Moving Validation and Review into the Inner Loop
• 托管式维护与持续改进
  Managed Maintenance and Continuous Improvement
• 智能体驱动的软件开发生命周期中的新瓶颈
  The New Bottlenecks in an Agentic SDLC

Uber 的智能体工程规模The Scale of Agentic Engineering at Uber

Uday Kiran Medisetty：早上好。我是 Uday，今天和我的同事 Adam 一起参加。首先，我会介绍我们在迈向托管式软件工厂的过程中重点投入的关键构建模块。随后，Adam 将演示这些模块如何组合成面向工程师的端到端解决方案。Uday Kiran Medisetty: Good morning. I’m Uday, and I’m here with my colleague Adam. I’ll begin by explaining the key building blocks we are investing in as we move toward a managed software factory. Adam will then show how those blocks come together as an end-to-end solution for engineers.

Uber 在全球十二个技术中心拥有数千名工程师。在过去一年中，我们对智能体 AI 的投入使得超过 70% 的拉取请求由本地智能体或云端智能体创建。我们还看到，平均每位工程师每年编写的代码行数同比增加了一倍。其影响远不止于编码，并且在工程生命周期的每个环节都清晰可见。Uber has a few thousand engineers across twelve global technology sites. Over the last year, our investments in agentic AI have led to more than 70 percent of pull requests being created with either local or cloud agents. We have also seen twice as many lines of code per engineer year over year. The effect extends far beyond coding and is visible in every part of the engineering lifecycle.

我们也在以极快的速度加速减少繁琐工作。我们已经完成了 250 多次自动化迁移，为工程师覆盖了 900 万行代码。这一进展建立在过去六年所打下的基础之上，其中包括迁移到 monorepo 和 Bazel。早期的这些投入使我们如今能够加速代理式开发。We are also accelerating toil reduction at a massive pace. We have handled more than 250 automated migrations, covering nine million lines of code for our engineers. This progress rests on foundations built over the previous six years, including our move to monorepos and Bazel. Those earlier investments made it possible to accelerate agentic development now.

软件工厂由六个构建模块组成。它们在 Uber 内部处于不同的成熟度和推广阶段，但合在一起展现了我们正在采取的方向。The software factory has six building blocks. They are in different stages of maturity and rollout inside Uber, but together they show the direction we are taking.

一个安全且可观测的模型网关A Secure and Observable Model Gateway

第一个构建模块是模型网关，这是我们最早投入建设的领域之一。我们确立了三项重要要求。默认情况下，个人身份信息绝不能离开我们的安全边界并发送给供应商。任何防护措施引入的延迟都必须严格受限。此外，每个请求都必须能够追溯到具体的用户、项目和团队。The first building block is the model gateway, one of our earliest investments. We established three important requirements. By default, personally identifiable information must never leave our perimeter for a vendor. The latency introduced by any guardrail must be strictly bounded. Every request must also be attributable to a user, project, and team.

所有内部用例、编码测试框架和外部用例都通过一个兼容 OpenAI 和 Anthropic 的端点。其背后是一系列中间件层。身份与身份验证使用 SPIRE。数据匿名化器会对二十多种个人身份信息（PII）进行编辑隐藏。AI 防护系统使用五个专用模型来执行我们所关注的安全与策略要求。所有这些控制措施的运行时间都不到 100 毫秒。我们还在这一层投资于缓存和令牌优化策略。All internal use cases, coding harnesses, and external use cases go through one OpenAI- and Anthropic-compatible endpoint. Behind it is a series of middleware layers. Identity and authentication use SPIRE. A data anonymizer redacts more than twenty types of PII. An AI guard uses five specialized models to enforce the safety and policy requirements we care about. All of these controls run in under 100 milliseconds. We are also investing in caching and token-optimization strategies at this layer.

每个请求都可以归因于我们目录中的具体项目，并实时以及在数据湖中追溯到其调用方、用户和团队。这样一来，我们就能跨整个项目组合，以整体视角创建支出视图并设置防护措施。同一层还会捕获审计日志和会话跟踪记录，为基准测试和自我改进闭环提供数据。Every request can be attributed to a specific project in our catalog and traced to its caller, user, and team, both in real time and in our data lake. That lets us create spend views and guardrails holistically across our portfolio. The same layer captures audit logs and session traces, which feed benchmarking and self-improvement loops.

对于 Uber 工程师来说，使用体验很简单：采用标准客户端，设置项目 ID，平台会处理其余所有事项。目前已有 800 多个内部项目使用该网关，每天模型请求总量超过 1 亿次。这些模型包括前沿模型和开源模型，无论它们托管在 Uber 的基础设施中，还是由供应商提供。For an Uber engineer, the experience is simple: take a standard client, set the project ID, and the platform handles everything else. More than 800 internal projects now use the gateway, collectively making over 100 million model requests per day. This includes frontier and open-source models, whether they are hosted in Uber infrastructure or by vendors.

通过 MCP 网关让内部工具可访问Making Internal Tools Accessible Through an MCP Gateway

模型可用后，还需要访问工具。当我们去年开始这一历程时，Uber 拥有数千个内部 API，但这些 API 都无法开箱即用地供智能体访问。我们还使用了许多 SaaS 产品，而每种产品都有不同的身份验证和设置要求。这给用户带来了阻力，同时安装足够多的独立 MCP 服务器也会造成大量的令牌开销。Once models are available, they need access to tools. When we began this journey last year, Uber had thousands of internal APIs, but none were agent-accessible out of the box. We also used many SaaS products, each with different authentication and setup requirements. That created friction for users, while installing enough independent MCP servers imposed a substantial token tax.

我们构建了一个 MCP 网关，与模型网关一样，为工程师处理通用中间件。自动化爬虫会检查内部 API，并通过一次配置变更将其映射为 MCP 服务器。Google、Slack 和 Jira 等 SaaS 集成也会经过该网关。Uber 负责托管这些集成并执行令牌交换，因此工程师和其他员工可以通过一个入口和一种安装方式使用任何 MCP 集成。We built an MCP gateway that, like the model gateway, handles common middleware for engineers. An automated crawler examines internal APIs and projects them into MCP servers with a single configuration change. SaaS integrations such as Google, Slack, and Jira also pass through the gateway. Uber hosts them and performs token exchange, so engineers and other employees use one entry point and one installation method for any MCP integration.

我们一直在持续优化这些工具使用上下文的方式。起初，客户端会直接连接到各个独立的 MCP 服务器。今年早些时候，我们创建了 Omni MCP，这是一个单独安装的 MCP，可以发现并调用通过网关提供的任何 MCP。几个月后，我们将 MCP 转换为 CLI 模式，使大型响应不会直接占用代理的上下文。最近，我们又添加了一项自动安装的代码模式技能，可即时创建 Python 脚本，以优化一些消耗 token 最高的 MCP 使用场景。We have steadily optimized how these tools consume context. At first, clients connected directly to individual MCP servers. Earlier this year, we created Omni MCP, a single installed MCP that can discover and invoke any MCP available through the gateway. A few months later, we projected the MCPs into a CLI pattern so that large responses would not consume the agent’s context directly. More recently, we added an automatically installed code-mode skill that creates Python scripts on the fly to optimize some of the highest-token MCP use cases.

该网关目前已提供超过一千个 MCP 工具。这些优化工作使整个工具集群节省了超过 40% 的资源。The gateway now exposes more than a thousand MCP tools. These optimization efforts have delivered fleet-wide savings of more than 40 percent.

为长期运行的代理构建的云环境Cloud Environments Built for Long-Running Agents

模型和工具需要一个运行场所。多年来，Uber 一直使用 Devpod 云开发环境，因为我们的工程师在包含数百万行代码的大型单体代码库中工作。如今，我们已让该环境支持智能体。智能体需要长时间运行、快速启动、保持隔离、扩展到大量并发实例，并可在全球所有站点使用。Models and tools need somewhere to run. For years, Uber has used Devpod cloud development environments because our engineers work in large monorepos containing millions of lines of code. We have now made that environment agent-ready. Agents need to run for long periods, start quickly, remain isolated, scale to many concurrent instances, and be available across all global sites.

为提供这种能力，我们维护了预先配置好的 Kubernetes 气球 Pod。当代理需要一个全新的环境时，它会认领一个已经包含代码仓库快照和已构建搜索索引的 Pod。这样，代理可以在几秒钟内开始工作，而不必等待完整环境组装完成。To provide that capacity, we maintain pre-provisioned Kubernetes balloon pods. When an agent needs a fresh environment, it claims a pod that already has repository snapshots and a built search index. The agent can begin working in seconds instead of waiting for a complete environment to be assembled.

我们还看到，工程岗位之间的界限变得不再那么分明。过去，Uber 会针对每种语言或平台提供一种 Devpod，例如 Go、Java 或 Android。如今，智能体需要跨代码库协作，工程师也越来越需要这样做。因此，我们创建了一个超级 Devpod，将所有代码库纳入同一个通用环境。它既支持我们的自主编码智能体，也让非工程员工能够在几秒钟内以简单的方式开始使用智能体工具框架。We also saw engineering roles becoming less sharply separated. Previously, Uber offered a Devpod flavor for each language or platform, such as Go, Java, or Android. Agents now need to work across repositories, and engineers increasingly do as well. We therefore created a mega Devpod that brings all repositories into one common environment. It supports our autonomous coding agents and gives non-engineering employees a simple way to start using an agent harness within seconds.

智能体技能的托管生命周期A Managed Lifecycle for Agent Skills

下一个构建模块是以技能形式打包的知识。今年早些时候，我们看到工程师在许多代码仓库中创建了大量技能。由此出现了三个问题：不同工程师重复创建相同的技能，技能的发现与配置十分困难，而且许多技能未达到可接受的质量标准。The next building block is knowledge packaged as skills. Earlier this year, we saw engineers creating many skills across many repositories. Three problems emerged: different engineers duplicated the same skills, discovery and configuration were difficult, and many skills did not meet an acceptable quality bar.

我们通过围绕技能构建完整的生命周期来应对这一问题。核心技能和领域特定技能会发布到一个托管市场中，该市场目前包含 2,500 项技能。每次提交都必须通过代码检查和自动化审查，以确保达到基本的质量标准。安装和发现均可通过单条命令完成，还可以根据工程师的角色自动安装默认技能，使代理能够选择合适的能力，而无需手动设置。We responded by building an entire lifecycle around skills. Core and domain-specific skills are published to a managed marketplace that currently contains 2,500 skills. Every submission passes lint checks and automated reviews that enforce a baseline level of quality. Installation and discovery are available through a single command, and default skills can be installed automatically according to an engineer’s persona, allowing an agent to select the right capability without requiring manual setup.

最近，我们开始收集执行轨迹和评论，并持续开展评估。这些信号可以反馈给技能作者，以指导改进，因此这是当前重点投入的领域。整个技能集群中，2,500 个受管理的技能每天执行次数超过 20,000 次。More recently, we began collecting execution traces and comments and running continuous evaluations. These signals can be returned to skill authors to guide improvements, making this an important area of current investment. Across the fleet, the 2,500 managed skills are executed more than 20,000 times per day.

在上下文图中统一公司知识Unifying Company Knowledge in a Context Graph

仅靠技能无法解决上下文问题。执行跟踪显示，智能体花费了大量时间，甚至只是为了在 Uber 庞大的单体代码库中查找基本信息：某个服务位于何处、哪些组件依赖它、由谁负责维护，以及应遵循哪些既有模式。所需的上下文分散在二三十个系统中，而每个系统都需要单独的技能或 MCP 集成。收集这些信息消耗了 token、增加了延迟，也使结果变得更加难以预测。Skills alone do not solve the context problem. Execution traces showed that agents spent substantial time finding even basic information in Uber’s large monorepos: where a service lives, what depends on it, who owns it, and which established patterns should be followed. The required context was scattered across twenty to thirty systems, each of which needed its own skill or MCP integration. Gathering it burned tokens, added latency, and made outcomes less predictable.

我们构建了一个上下文图谱，用于捕捉 Uber 的运营信息。它包含 150 种不同的节点和边类型，目前有 4000 万条记录。该图谱覆盖移动应用、后端系统和数据湖，连接设计文档、Jira 条目、事件、漏洞以及其他内部知识。智能体可以利用这些连接快速找到正确的上下文。We built one context graph that captures information about how Uber operates. It has 150 distinct node and edge types and currently contains forty million entries. It spans mobile applications, backend systems, and the data lake, connecting design documents, Jira items, incidents, bugs, and other internal knowledge. Agents can use those connections to find the right context quickly.

我们正在将全公司的技能和用例连接到这一图谱中，包括值班根因分析、规划、数据分析和安全扫描。在这些评估中，由图谱提供支持的上下文显著提升了这些技能的表现。We are connecting skills and use cases throughout the company to this graph, including on-call root-cause analysis, planning, data analysis, and security scanning. Across those evaluations, graph-backed context substantially improves the skills.

考虑一个看似简单的问题：印度有多少次出行是以现金支付的？回答这个问题需要理解相关业务概念、识别正确的数据表、选定涉及的城市，并构建 SQL。在我们的评估中，与不使用上下文图谱而收集相同信息相比，使用上下文图谱在令牌使用量、智能体交互轮次和延迟方面都取得了显著改善。Consider a seemingly simple question: how many mobility trips in India are paid in cash? Answering it requires understanding the relevant business concepts, identifying the right tables, selecting the cities involved, and constructing the SQL. In our evaluations, using the context graph produced major improvements in token usage, agent turns, and latency compared with gathering the same information without the graph.

作为全公司的 AI 界面 CortanaCortana as a Company-Wide AI Interface

最后一个构建模块将这些能力打包，供公司所有人使用。Uber 的 AI 助手 Cortana 将技能、MCP 工具和上下文图谱整合到 Slack、CLI 和 Web 中。员工可以从这些界面中的任意一个提出问题，而 Cortana 可以查询上下文图谱、调用技能、检查任何代码库中的代码，并返回答案。The final building block packages these capabilities for everyone in the company. Uber’s AI assistant, Cortana, brings together skills, MCP tools, and the context graph across Slack, the CLI, and the web. An employee can ask a question from any of those surfaces, and Cortana can consult the context graph, invoke a skill, inspect code in any codebase, and return an answer.

员工还可以通过自定义技能和提示词来个性化助手，然后将该角色连接到团队 Slack 频道。它可以学习与团队相关的上下文，表现得更像一名队友。多人可以在共享频道中与同一个角色协作。在过去一个月里，员工创建了 300 个独特的角色，而 Cortana 的日均会话数已增长到 20,000 多次。Employees can also personalize the assistant with custom skills and prompts, then connect that persona to a team Slack channel. It can learn the relevant context for the team and behave more like a teammate. Multiple people can collaborate with the same persona in a shared channel. In the last month, employees created 300 unique personas, and Cortana has grown to more than 20,000 sessions per day.

接下来交给 Adam，由他展示这些构建模块如何支持完整的功能交付流程。I’ll now pass to Adam, who will show how these building blocks support the full journey of shipping a feature.

将世界杯功能从构想落地为原型Taking a World Cup Feature from Idea to Prototype

Adam Huda：我们将使用这些构建模块来驱动软件工厂，并从头到尾跟踪一个功能。首先，我们需要一个想法。随着世界杯临近，可以设想这样一种场景：一名骑手正要离开拥挤的体育场。如果能推荐一个远离人群的更佳接载地点，将会很有用。Adam Huda: We are going to use those building blocks to power the software factory and follow one feature from beginning to end. First, we need an idea. With the World Cup approaching, imagine a rider leaving a crowded stadium. It would be useful to recommend a better pickup location away from the crowd.

团队开始在 Slack 中讨论这一想法，并让 Cortana 加入对话。借助对上下文图谱的访问权限，Cortana 可以帮助判断这一想法是否代表一个值得投入的商业机会。随后，可以在 Cortana 的 Web 界面中打开 Slack 讨论，以开展更深入的业务研究，例如考察其他大型场馆活动，并确定哪些体育场可能适合使用这一功能。The team starts discussing the idea in Slack and brings Cortana into the conversation. With access to the context graph, Cortana can help determine whether the idea represents a worthwhile business opportunity. The Slack discussion can then be opened in Cortana’s web interface for deeper business research, such as examining other large-scale venue events and identifying stadiums where the feature might be useful.

从这里开始，团队制定产品需求。由于相关体育场位于北美，初始上线可能应重点面向该地区。Cortana 还可以协助完成 Figma 设计并制作初步原型。在这个示例中，团队创建了两个版本，使用不同的按钮文本，以便开展 A/B 实验并衡量哪个版本的表现更好。From there, the team develops product requirements. Because the relevant stadiums are in North America, the initial rollout should likely focus there. Cortana can also help with Figma designs and produce initial mockups. In this example, the team creates two variants with different button text so they can run an A/B experiment and measure which performs better.

随后，Cortana 会帮助确定实现该设计所需的代码更改。它可以判断哪些现有应用屏幕能够复用，以及哪些后端功能已经具备。过去可能需要数周才能协调所有参与者的流程，如今可以压缩到很短的时间内，使团队能够迅速完成原型。Cortana then helps identify the code changes needed to implement the design. It can determine what existing app screens can be reused and which backend capabilities already exist. A process that once might have taken weeks to align all the participants can be compressed into a short period, allowing the team to reach a prototype quickly.

使用 Minion 构建功能Building the Feature with Minion

完成规划和原型设计后，工作会从 Cortana 移交给 Uber 的云端编码代理 Minion。Minion 既可以交互式运行，也可以自主运行。它由 Devpod 构建模块提供支持，拥有完整的构建环境，并能够修改多个代码仓库。在这个示例中，它同时对后端和前端进行了修改。After planning and prototyping, work is handed from Cortana to Minion, Uber’s cloud coding agent. Minion can run interactively or autonomously. It is powered by the Devpod building block, giving it a complete build environment and the ability to modify multiple repositories. In this example, it makes both backend and frontend changes.

Minion 会持续推进，直到创建一个拉取请求草稿，但不会立即将更改发送到 CI。对于以繁琐重复工作为主的任务，自主代理运行良好；但更高级的端到端功能在进入 CI 之前需要进行有意义的验证。尽早进行验证可以避免给共享 CI 基础设施增加不必要的负载。Minion progresses until it has created a draft pull request, but it does not immediately send the change to CI. Autonomous agents worked well for toil-oriented tasks, but more advanced end-to-end features require meaningful validation before CI. Validating earlier avoids putting unnecessary load on shared CI infrastructure.

将验证与审查移入内循环Moving Validation and Review into the Inner Loop

软件开发生命周期包含内循环和外循环，而两者都可以实现智能体化。我们正在将更多检查移入内循环。静态分析已经在内循环中运行，检测到的问题可以立即修复。现在，我们还可以引入更丰富的检查，包括视觉验证。某项技能可以启动模拟器、截取屏幕截图，并将其与 Figma 规范进行比较。它还可以在后端预发布环境中启动服务，并验证前端与后端的集成。The software development lifecycle has an inner loop and an outer loop, and both can become agentic. We are moving more checks into the inner loop. Static analysis already runs there, and detected problems can be fixed immediately. We can now bring in richer checks as well, including visual validation. A skill can launch a simulator, take a screenshot, and compare it with the Figma specification. It can also start a service in the backend staging environment and validate the frontend and backend integration together.

完成内循环验证后，变更会进入通常运行 CI 的外循环。错误仍可能发生，因此 Uber 已实施自愈 CI，可解决在那里遇到的许多问题。After inner-loop validation, the change moves to the outer loop, where CI normally runs. Errors can still occur, so Uber has implemented self-healing CI that can resolve many of the issues encountered there.

代码审查也涵盖这两个循环。一些审查工作已转移到内循环中，在那里，更小、更快速的模型可以提供即时反馈。外循环则可以使用推理能力更强的模型和专门技能来进行更深入的审查。Code review also spans both loops. Some review work has shifted into the inner loop, where a smaller, faster model can provide rapid feedback. The outer loop can use a more powerful reasoning model and a specialized skill for deeper review.

对于 Minion 生成的自主差异代码，人类审阅者需要确信代码已经历了多轮验证和自我改进。因此，拉取请求中包含一张表格，列出已执行的检查，包括屏幕截图。审阅者看到的不只是代理最初生成的代码；他们还可以检查后续验证步骤已经完成的证据。For an autonomous diff produced by Minion, the human reviewer needs confidence that the code has already undergone multiple rounds of validation and self-improvement. The pull request therefore includes a table listing the checks that were performed, including screenshots. The reviewer is not seeing only the agent’s initial generation; they can inspect evidence that the subsequent validation steps have happened.

托管式维护与持续改进Managed Maintenance and Continuous Improvement

随着软件工厂生成的代码越来越多，维护变得更加重要。某个功能或服务可以纳入维护技能中。一个例子是清理功能标志。世界杯模态框实验选出获胜方案后，未使用的变体就不再需要保留在代码库中，因此维护技能可以按计划将其移除。As the software factory produces more code, maintenance becomes even more important. A feature or service can be enrolled in maintenance skills. One example is feature-flag cleanup. After the World Cup modal experiment chooses a winner, the unused variant no longer needs to remain in the codebase, so a maintenance skill can remove it on a schedule.

这些计划作为受管理的循环运行。Uber 不希望公司内部各处独立创建数千个无界循环。团队使用一个受管理的界面来配置它们。清理任务可以在周日运行，此时可用的 CI 容量更大；同时，该平台还会控制工程师们在周一早上会看到多少个自动生成的差异。These schedules run as managed loops. Uber does not want thousands of unbounded loops independently created across the company. Teams use a managed surface to configure them. A cleanup can run on Sunday, when more CI capacity is available, while the platform also controls how many automated diffs engineers will see on Monday morning.

当维护技能创建差异时，该变更会收到评论，随后要么合并，要么被拒绝。这两种结果都会提供带标签的数据，用于改进该技能。团队还可以大约每月检查一次事故复盘，识别可能成为新维护技能的重复性工作，并将该技能应用于各项服务。When a maintenance skill creates a diff, the change receives comments and is either landed or rejected. Both outcomes provide labeled data that can improve the skill. On a roughly monthly cadence, teams can also examine incident reviews, identify recurring work that could become a new maintenance skill, and apply that skill across services.

智能体驱动的软件开发生命周期中的新瓶颈The New Bottlenecks in an Agentic SDLC

相同的构建模块也可以支持生命周期的其他环节，包括监控，但更高的代理吞吐量会带来新的约束。更多代码会给基础设施带来更大压力，因此 Uber 必须预估未来的 CI 容量，并进行相应的基础性投资。实验容量是另一个瓶颈，因为能够有意义地运行的实验数量是有限的。The same building blocks can support other parts of the lifecycle, including monitoring, but higher agent throughput creates new constraints. More code puts more strain on infrastructure, so Uber must anticipate future CI capacity and make the corresponding foundational investments. Experiment capacity is another bottleneck because only a finite number of experiments can be run meaningfully.

最后一个约束是决策。随着智能体让实施变得容易得多，核心问题也发生了变化。问题不再只是组织是否能够构建某种东西——我们越来越清楚，它很可能能够做到——而是组织是否应该构建它。The final constraint is decision-making. As agents make implementation dramatically easier, the central question changes. It is no longer simply whether the organization can build something—we increasingly know that it probably can—but whether it should build it.