智能体软件交付的新原语

AI 优先（AI-first）的软件开发的承诺非同寻常：描述你想要什么，智能体就会把它变成可运行的软件。但这种说法把中间过程当成了一个黑箱。意图进去，软件出来，中间发生的一切都被默认为“只是变得更快了”。

事情并没有那么简单。软件开发生命周期（SDLC）的每个阶段都在改变，但并不均衡——有些阶段转型得更快、更早；而随着能力不断提升，瓶颈也在移动。

这就是为什么那些试图一次性转型整个 SDLC 的雄心勃勃的团队往往举步维艰：当所有东西同时改变时，很难看清什么有效、什么失败了、又该修什么。这个问题是可以解决的，但前提是我们从“原语”（primitives）出发——每个阶段要完成的任务（jobs to be done）、每个阶段产出的工件（artifact），以及连接它们的知识。

当我们围绕这些原语达成一致，新的软件交付系统就成形了。

工作变了，任务还在

软件工程一直要求我们定义目标、创造软件、验证并交付它，还要理解人们使用它时会发生什么。智能体改变了人类注意力需要投向的地方，但底层流程保持不变。

SDLC 始终遵循一个共同的工作流——由若干阶段构成一个循环：规划（Plan）、构建（Build）、验证（Validate）、部署（Deploy）和观测（Observe）。在过去 20 年里，我们引入了种类繁多的工具和自动化，帮助优化在每个阶段投入的时间和精力，但这些阶段本身始终保持稳固、历久弥新。

新的软件交付系统保留了这些核心阶段，但有一个关键变化：每个阶段现在都从（并向）一个共享的知识基础中汲取养分。阶段本身是熟悉的，但贯穿整个生命周期的人类工作任务正在发生巨大变化。

对于每个阶段，我们都可以通过识别“人类的待完成任务”（human job-to-be-done）和“推动工作向前推进的产出工件”（output artifact），让这种转型变得具体可感。信任在生命周期的每个阶段建立，并向前传递该阶段产出的一切、其背后的证据，以及悬而未决的问题。这种理解进而指导下一阶段的决策。

规划（Plan）

定义并管理目标：我们想达成什么、必须遵守哪些约束、如何衡量成功。人类注意力投向选择有价值的问题、消解歧义与权衡取舍。产出是一组能够指导构建与验证的目标和验收标准。

构建（Build）

把那些目标转化为可运行的系统。智能体承担更多实现工作，而人类负责指导关键的设计决策、解决需要人类判断的问题。产出是候选实现（以 PR 的形式），以及理解其选择所必需的上下文。

验证（Verify）

判断实现是否满足既定目标，并在就绪后把它交到真实用户手中。智能体跨多个维度（正确性、性能、安全性等）测试和验证代码，并产出离散的、可审计的证据。人类精力转向一个核心问题：“我们构建出的东西，是我们本意要构建的东西吗？”——而不再纠结于验证实现正确性。

观测（Observe）

运营系统、观察其行为并运行实验。人类解读信号、形成洞察，并决定何时以及以何种方式让用户体验变化。这个阶段产出信号与数据，为下一轮目标、实验和运营改进提供依据。

居于中心的知识

数据和上下文是 SDLC 不可或缺的一部分。从历史上看，这些知识中的大部分都储存在单个开发者的头脑中，而非共享的记录里。在一家初创公司里，甚至可能只掌握在一个人的脑子里！这个人把客户需求、设计决策、实现、发布和系统运营串连在一起。随着产品和团队复杂度的增长，知识库在更多人之间碎片化，无缝连接数据的能力也随之瓦解。

在新的软件交付系统中，知识层成为新的黏合剂——它连接目标、设计决策、实现上下文、验证证据、发布历史、生产环境信号、详细的智能体行为日志，以及从它们中提炼出的经验教训。它保存每一项内容的来源与版本，区分“观察”与“解读”，并按每个任务被允许使用的范围为任务提供上下文。

因此，尽管知识的概念并不陌生，但访问和使用知识的能力发生了根本性的变化。一个生产环境的发现可以影响验证、影响实现，并改变下一轮规划。每个阶段都在使用并丰富可供智能体和人类在 SDLC 任何阶段利用的知识。

从理论到实践

在微软，我们正在把这些原语付诸行动，把它们构建进我们的开发者产品中：

• Copilot 可以接收一个 issue，自行启动安全的 GitHub Actions 环境，分析仓库、修改代码、运行验证，并生成供人类评审的 PR 草稿。开发者随后可以从 GitHub、VS Code、移动端等界面把任务委派给这个编码智能体。
• Copilot Code Review 现在支持智能体技能（agent skills）和 MCP，让团队能够把仓库特有的规范，以及来自 issue 跟踪器、文档系统和其他系统的外部上下文直接引入评审过程。
• 由于 Copilot 运行壳（harness）会把指令、脚本和配套资源打包成可复用的技能，成功的工作方式变成了可复用的生产资产，而不再被困在单次智能体会话中。

随着智能体软件交付的机制逐渐成熟、成形，我们知道人类的参与在现在也将在未来始终是必不可少的。智能体将帮助我们实现目标，但识别用户需求、定义并验证我们所创造的产品、理解它们的意义，仍然取决于我们。

记忆需要目标

新的中央知识层包含海量的上下文和数据——来自 SDLC 各阶段、用户交互以及智能体行为的信号。然而，海量的原始数据本身并不能改善智能体的行为。只有当数据使智能体能够回答具体问题时，它才真正有用。

在过去一年里，我们开始用“记忆”（memory）和“做梦”（dreaming）这样的词来描述这个领域。抛开名词之争，要点在于：以某种方式把数据汇聚起来，让智能体把工作做得更好——避免重复犯错、识别相关约束，或基于过去的结果改进决策。

这给了我们一个工程上的检验标准和评估方法：智能体在有合成知识的情况下完成一项工作，是否比没有时做得更好？是否更有效？更快？效率更高？类似于数据库索引或物化视图，记忆的目标是让智能体快速访问过去的数据，从而改善未来的表现。

独立、并行地攻克 SDLC 的每个阶段

拆解新的软件交付系统，我们得到了一条切实可行的推进路径。对于每个阶段，定义输入、人类与 AI 各自要完成的任务、产出工件，以及成功的标准。用验证软件本身的同等审慎态度来改进智能体。

这些改进还必须汇聚成一条从想法到客户的更优旅程。如果验证无法为结果建立信任，更快的构建就价值有限。只有当实验的发现能够改进后续决策时，更多的实验才有意义。阶段之间的契约与反馈，也是我们需要工程化的对象。

即使是一个无需人工干预、反复运行的循环，也仍然包含这些职责：它需要目标、一个实现、证明实现满足目标的证据、触达用户的方式，以及从实际结果中学习的方式。自主性并不会消除这个结构。

请不要误解：在新软件交付系统中，生命周期的每个阶段依然存在——即使随着信任的建立，我们不再显式地思考它们。但就目前而言，在搭建我们最初的软件交付系统时，我们必须以持久组件的方式来思考，以此为人类的待完成任务找到立足点。

给人类判断留出更多空间

在当今 SDLC 的每个阶段，都有重要的人类任务。随着这一系统走向成熟，我们的注意力将越来越集中于需要更高层次判断的地方。在短期内，我猜我们最关注的将是验证、运营和规划：判断智能体产出的代码是否可信、改进系统在生产环境中的运行方式，以及重新思考如何为软件交付系统定义目标。

这些任务需要关于价值、意图和客户体验的判断。一个软件交付系统可以自主地循环执行，却并不去确立其目标是否值得追求。人类，以及经过打磨的品味（taste），对于识别并创造持久的价值必不可少。

构建可靠的软件交付系统原语，让我们在持续改进决策质量的同时，得以扩展自动化的范围。随着智能体承担更多工作，我们就赢得了更多时间去定义雄心勃勃的目标，并把不可思议的新体验变为现实。