转载说明：本文转载并精译自 Aaron Levie 于 2026-03-10 发布在 X 长文中的文章 Building for trillions of agents。StaticFlow 导入日期为 2026-03-10。为万亿 Agent 构建软件 作者：Aaron Levie 过去几个月，Agent 领域开始出现一件非常重要的变化。到去年年底前后，我们已经逐渐来到这样一个拐点：编码 Agent 可以独立完成更长周期的任务，不再需要人在整个开发过程中持续手把手地盯着。 这些 Agent 已经不再是只带着几个基础工具的聊天机器人。它们往往拥有自己的沙箱计算环境，遇到问题时可以自己写代码、跑代码，能够直接调用 API 和 CLI，拥有自己的文件系统以及长期记忆等等。这组核心能力、Agent harness 最佳实践的整体进展，以及模型在工具使用和软件开发上的惊人提升，已经让我们看到了这样一类 Agent 的雏形：几乎任何被交给它们的任务，它们都有能力接住。 虽然这种架构最早主要由 Claude Code、Devin、Codex、Factory、Cursor、Replit 等编码 Agent 定义出来，但最近我们已经跨过了那道分界线，进入了更广泛的个人工作流与知识工作场景。Claude Cowork、Perplexity Computer、Manus，当然还有把未来感又往前推了一大步、能在持久化环境里 24/7 运行的 OpenClaw，都说明了这件事。 随着能力快速演进，Agent 会被带入几乎所有工作领域。它们会参与审核每一份合同，接管大多数客服工单的一线处理，审计公司的财务数据，梳理海量医学研究以辅助药物发现，生成几乎所有会被写出来的代码，制作大多数销售和咨询演示材料，为消费者在网上完成交易，并总体上进入社会中几乎所有具有经济价值的任务。 而且这件事绝不只是把今天已经在做的任务自动化。我们会用 Agent 做远比以前更多的事情，比如运行过去算不起的大规模模拟，用许多不同方案去快速原型化每一个想法，因为启动成本极低而大幅增加尝试项目的数量，也会从“抽样看信息”转向“审视更多完整数据”。 把这一切加总起来看，未来企业里几乎每个员工都会有许多 Agent 为自己工作。一个企业里 Agent 的数量比员工多 100 倍甚至 1000 倍，并不难想象。随着万亿级 Agent 四处运行，Agent 将会成为未来软件的主要使用者。 过去的大多数软件都是为人类使用而构建的。这意味着，我们将看到软件未来形态发生一次重大转向。那接下来会发生什么？做出 Agent 想用的软件 Paul Graham 曾用一句极其简洁的话概括软件该怎么做：做出人们想要的东西。 这条建议催生了 21 世纪许多最成功的软件公司，也推动了行业形成一整套共识：工具应该简单易用、容易采用、能清晰解决问题、少一些术语负担、定价也足够直接。 现在，新的方向是：做出 Agent 想要的软件。今天最重度使用 Agent 的往往仍然是开发者，或者至少是技术能力很强的用户，他们通常对工具还有自己的偏好。但在一个 Agent 将承担各种知识工作的世界里，这种“人的工具偏好”会慢慢弱化。除非企业已经预先规定了标准，否则 Agent 会越来越多地坐到驾驶位上，决定某条工作流到底采用什么工具。 这意味着，从它们注册什么产品、写什么代码、使用什么库、调用什么技能开始，到整个工作流程里的工具选择，都会越来越由 Agent 主导。对 Agent 来说更容易接入、又能更好解决 Agent 及其背后用户问题的平台，会比其他产品更快拉开差距。Agent 不会去参加你的线上宣讲会，也不会被广告打动；它们只会直接使用最适合完成任务的工具，而你当然希望那个工具是你的。 这条判断带来的最大含义，是你构建的一切都必须变成 API-first。一个功能如果没有 API，对 Agent 来说几乎就等于不存在；如果它不能通过 CLI 或 MCP Server 暴露出来，你就已经处于劣势；如果你的 API 很混乱、给 Agent 留下多条相互冲突的路径去探索，那你本质上是在削弱自己对 Agent 的可用性。Levie 提到，Box 现在正把自己定位成“Agent 的文件系统”，因此他们正在重新审视 API 的每一个细节，思考在 Agent 世界里什么地方会崩掉，并且把原本只在 UX 设计里投入的那种可用性打磨，同样投入到 API 设计里。 就像过去为用户设计软件，需要站在用户的处境里思考一样，今天为 Agent 设计软件，也必须站到 Agent 可能遭遇的路径里去想。Y Combinator 的 Jared Friedman 最近就提醒所有人：“即使是最好的开发者工具，大多数也仍然不支持通过 API 注册账号。这在 C…