编码规则：构建智能体软件交付生命周期背后的平台

引言

本文是我们对团队拓扑.在组织规模上——跨多个产品和团队——构建可靠的软件， 需要我们根本性的运营方式转变。

在现代的人工智能驱动软件交付生命周期（SDLC）中，流程对齐的团队应完全专注于解决方案， 将实际实施委托给人工智能系统。这个智能循环是现代软件的引擎，直接由一个强大的内部平台驱动， 提供模型和推理引擎。

但我们怎么启动这台发动机而不让它脱轨呢？

仅靠技术还不够;我们需要合适的人类协作。 为了构建功能性、可靠且值得信赖的应用，产品专家首先必须与技术专家合作。 这使得团队能够参与构建人工智能、建立关键防护措施并制定企业标准。

归根结底，这篇文章讲述了一个循环的故事。 赋能团队收集这些技术护栏，并将其直接内置到平台中，作为自动化治理规则。 一旦平台吸收了这些知识，支持团队可能消失——留下一个能够开箱即用、生成标准、 可信应用的代理系统。只有当出现全新的技术挑战时，它们才会重新出现。

让我们来探讨如何构建和掌握这些循环，首先快速回顾一下开发引擎的工作原理：代理循环。

tap 以扩展

<条目类别=“st-叙事”>

agentic loop

这部分并非任何形式的创新。它提醒我们智能循环是如何运作的。 然而，理解这一基础非常重要，因为它是软件交付的核心节点。在本文的剩余部分，我将大量依赖这些原则。

代理循环是现代由人工智能驱动的软件交付方式。 你首先表达你想发展的某个项目的意图。

LLM理解意图，然后规划一些行动。在规划阶段，系统评估需要调用哪些工具以满足需求。 如果一个简单的任务是“在test.txt写问候”，那么计划会生成类似的内容：

• 叫写作者工具，打开test.txt，然后写“你好”。

然后代理实际调用工具并执行动作。

动作执行后，代理分析工具执行的返回情况，以判断是否存在错误或动作是否成功。

自我纠正

任何智能系统的优势之一是其从错误中恢复的能力。如果工具未能达到目标，代理会将错误输出反馈到规划阶段，分析错误所在，并生成新的计划。

例如，假设在我们之前的例子中，系统因权限问题无法编辑文件。工具调用会返回类似“权限被拒”这样的错误。代理通过在 chmod 工具前插入更改权限的步骤来适应：

1. 呼叫工具 chmod u+w test.txt

2. 叫写作者工具，打开test.txt，然后写“你好”。

（虽然这是一个简单的例子——生产级系统会使用更稳健的错误处理，而非盲 chmod——但它展示了其机制。）

一旦这些新工具调用被执行，循环又回到观察阶段。如果执行成功，AI会评估当前状态：最终意图是否已实现，还是仅仅是一个中间步骤，为下一步行动提供了新的上下文？

注意：如果错误是瞬态错误（例如429API调用中出现错误）， 代理可能会决定在不重新规划的情况下重试工具调用。

真实agentic loop

智能体不仅仅是执行基本的自然语言命令;它还能处理需要探索的复杂、模糊任务。这正是环形机制真正闪耀的地方。

想象我们给代理一个大致的意图：“将该目录中的所有文件翻译成英文。”

由于代理缺乏上下文，无法立即翻译任何内容。它的第一个计划必须纯粹是调查性的。 第一个版本看起来是这样的：

1. 把目录里的文件列出来。

2. 打开每个文件以检测其源语言。

这些工具执行完毕后，代理进入观察阶段。 它分析结果（例如发现两个文件，coucou.txt和salut.txt， 均为法语），并利用这一新上下文自动将意图细化为可操作的内容：

将coucou.txt和salut.txt的文件从法语翻译成英语，并保存为hi.txt和hello.txt。

获得精确目标后，代理触发循环的第二次迭代。它生成新的计划，调用执行实际翻译所需的工具。

最后，循环最后一次返回观察阶段，确认这两个新文件已成功创建，英文内容正确。任务完成了。

退出环路

当观察阶段确认原始意图已实现时，循环成功终止。然而，为了防止代理陷入无限循环，程序保护栏——例如严格的10次迭代次数——会在触发时强制退出。

循环结束后，代理交付最终输出。

虽然开发者通常在本地机器上运行该代理系统，但它高度依赖于与本地环境解耦的大型语言模型。 为了扩大这一方法，我们需要转变视角，将该系统引入集中式运行时平台。

The Platform

平台是您数字基础设施的骨干。它提供开发、部署和管理应用所需的工具、服务和资源，以实现可扩展、灵活和高效的方式。

因此，平台的角色是提供对大型语言模型（LLM）的访问，这些模型赋予我们刚才描述的代理循环。

该平台不仅提供模型，还提供推理引擎。 当你作为个人开发者或独立创业者使用像Claude Code或Antigravity这样的代理系统时，平台是由这些系统的提供者（如Anthropic或Google）直接管理的。 在这些情形下，代理系统与平台紧密耦合，使得运行自己的模型或实现数字主权变得困难。

然而，为了获得更多灵活性和对隐私、成本和数据监管的控制，组织的一个关键目标应是将这些能力封装在内部平台中。

最终目标是让基础设施对代理系统完全透明，允许你无缝切换运行时、硬件或底层模型而不破坏循环。

除此之外，平台的工作是简化软件开发生命周期和运行环境。因此，除了作为执行引擎之外，它还必须提供无缝访问组织更广泛能力和领域知识的通道。

提供信息系统的访问

在描述代理循环时，我们考虑了本地工具（比如写文件）。然而，其真正的力量来自于获取超出本地开发环境边界的资源。

代理循环可能需要信息系统（IS）提供信息来完成其上下文——例如特定系统的文档或访问认证提供者。

为了保证过程的自主性（这对智能体开发以满足速度和可靠性的期望至关重要），系统必须能够以服务形式访问这些资源。

平台应以一种智能系统能够轻松调用的方式暴露这些能力。

历史上，我们使用REST API来暴露服务，但目前工具访问的标准是模型上下文协议（MCP）。 可以把MCP想象成一个带有通用连接器的传输层，可以轻松插入代理系统。

该平台很快将提供另一种服务：代理服务。 我在一个会议上讨论过这种合作方式我博客上的上一篇文章.因此， 我们必须预期该平台最终将托管多个代理系统，需要稳健的代理对代理（A2A）传输协议。

既然我们已经搭建了所有解决方案所需的管道，让我们回到真正重要的事情——也是截至今天仍是人类本质上的任务：构建问题框架并设计解决方案。

范围问题与解决方案 设计 让我们退一步思考。我们现在知道AI是如何构建解决方案的，但如果没有适当的范围限制，代理循环只能消耗代币，最多只能得到昂贵的概念验证（POC）。

对企业来说，最重要的是解决真实的用户问题。 在附图中，设计解决方案被表示为一个单一的盒子，但实际上这是一个庞大的阶段（而且AI也能提供帮助）。 我这里不会深入探讨产品管理，但目标始终不变：设计一个能为最终用户带来真正价值的功能， 同时与公司战略保持一致。如果您的组织使用产品需求文件（PRD）， 这正是起草它们的阶段（并且可以使用代理循环）。

该阶段是对现有设计阶段的改进。

真正的范式转变发生在 规范阶段.

此阶段的目标是将产品理念转化为实施者可以完全理解的格式。 在人工智能出现之前，实施者是人类工程团队，并且相应地编写了规范。

如今，开发人员是人工智能，您的规范实际上成为其执行上下文。 这意味着确定工作范围的团队必须了解代理系统如何“思考”以有效地提供服务。 他们不能再仅仅描述最终目标；他们必须将工作分解为离散的、有范围的任务，人工智能可以在不产生幻觉的情况下逐步实施这些任务。

只有当这个人工智能优化规范准备就绪时，我们才向系统声明意图并让循环运行。

开发解决方案

现在我们有了完整的规范和明确的意图，我们可以将工作交给我们的开发人员——人工智能代理。

由于此 SDLC 是一个迭代周期，因此代理执行的输出不会直接进入生产。 它会反馈到设计阶段，以在部署或交付任何内容之前验证解决方案是否真正解决了根本问题。

现在我们已经了解了这个生命周期，让我们缩小范围并纵观全局。

代理 SDLC

这是完整的图片。

现在，如前所述，此表示中真正缺少的是设计阶段内的迭代。

循环次数和整体优化实际上是执行的问题。 它们在很大程度上取决于控制人员的技能和能力，以正确确定系统范围并有效做出反应。

到目前为止，我们对设计阶段仍然含糊其辞。 功能设计、技术设计和护栏怎么样？它们都在这个阶段处理和指定吗？其中一些可以从其他地方继承吗？

嗯，这是一个组织问题。 让我们探讨如何构建这个生命周期以使其高效运行。

组织

顺应潮流的团队

这是一个强烈的观点——可能会引发争议。

我们正面临着巨大的范式转变。

此前，流对齐团队负责应用程序的实际开发。 对我来说，应用程序的开发不再是流式团队的责任。 然而，与流保持一致的团队仍然严格 负责 结果。

当然，有一些细微差别需要考虑，达到这种状态是一个需要过渡阶段的目标。 当按照此处所述在代理 SDLC 中引导基于 AI 的开发时，流对齐团队将首先拥有代理开发。

在深入研究该团队的组织之前，先快速说明一下将在不久的将来塑造产品管理的场景。

适应代理模型意味着流一致的团队必须做的不仅仅是了解如何试点系统…

由流线团队设计的解决方案将涉及建筑代理

…他们还必须了解代理系统的一般工作原理。 他们需要知道要设置哪些升级流程、护栏是什么以及人工智能如何做出决策。

因为明天，问题的数字解决方案可能会涉及 建立代理。

现在让我们回到启用的需求。

赋能的必要性

控制代理系统既不简单也不直接。 即使建立系统本身也是一项艰巨的任务（如果它依赖于平台中利基或不寻常的元素，则更加困难）。

我们重点关注解决方案的设计，但生成的输出也必须遵循行业最佳实践。

更重要的是，必须尊重 组织的内部标准，无论是在技术架构还是美学设计方面（如果你的设计系统严格使用紫色，你不希望人工智能生成蓝色按钮）。

按照设计，法学硕士可以生成符合更广泛市场最新技术的代码，这仅仅是因为其训练数据。 但是，必须明确指示它遵循公司的具体准则、约定和安全策略。

我们不能仅仅依靠与流程一致的团队来管理所有这些环境。 这样做会造成巨大的认知负担，最终会影响解决方案的交付。

正如我在上一篇文章中所讨论的，我们必须分解系统并依赖于 赋能团队 来解决这些跨领域的问题。 让我们评估一下它的一些任务。

该支持团队由技术专家、技术主管和解决方案架构师组成。 他们了解系统的工作原理并帮助其他人有效地使用它。

使流程一致的团队能够使用代理系统

重要的是要理解，支持团队不仅仅是为流程一致的团队提供服务的支持台。 相反，两个团队密切合作，共享一个统一的目标：提供可靠且值得信赖的解决方案。

赋能团队的首要任务是设置代理系统，使其以最大的自主权运行，从而使流式团队能够在第一个提示时就达到目标。

如果系统需要特定的框架不仅支持应用程序构建，还支持设计阶段，那么支持团队就有责任集成它。 （例如，如果您的工作流程依赖于 BMAD（一个规范驱动的代理开发框架），则这是它安装和配置的阶段。 ）

提供技术背景

支持团队的另一个关键职责是提供指导代理系统所需的技术信息。 该技术层补充了流对齐团队带来的功能上下文。

具体来说，这包括定义系统范围的标准，例如主要编程语言、指定的身份验证服务，甚至要使用的特定设计系统。

一旦建立了该技术基线，它就不能保持孤立状态。 请记住，我们正在整个组织范围内扩展此 Agentic SDLC。

因此，支持团队的另一项责任是共享这些实践、护栏和配置。 这种异花授粉减轻了其他支持团队的工作量，并确保整个公司的系统一致性。

自动化治理和知识重用

到目前为止，这种知识整合完全是人为驱动的，并且只能通过手动治理规则来强制执行。 为了真正实现大规模高效，这种治理必须实现自动化。

业界经常谈论“左移”，即在开发过程中尽早（通常在编写一行代码之前）转移测试、质量和安全检查的做法。

在我们的代理循环中，人工审批门造成了瓶颈。 为了保证系统的自主性和速度，这些护栏和标准不能保留在 Wiki 中；它们必须由底层平台作为消费服务直接提供。

设计标准

该平台应该将这些实践产业化。 这意味着将它们转变为可消费的服务，并作为内部产品进行打包和管理。

这些平台产品必须支持整个代理循环， 不仅仅是初始上下文。事实上，规划、工具执行和观察阶段都应该继承严格的指令，并通过确定性验证网关，以确保信任和合规性。

通过将这些护栏直接嵌入到基础设施中，该平台保证了代理系统保持高度自治和完全安全。

赋予代理循环的每个元素权力

既然平台以产品的形式提供了这些功能，我们必须调整代理循环以在工作流程的每个步骤中利用它们。 不要将这些标准视为需要对抗的官僚惰性，而是推动代理循环向前发展的辅助引擎。

这在实践中会是什么样子？我们以一个UI的开发为例:

• 语境: 该系统提供了根据公司当前的设计系统设计网页的具体指南。

• 行动/工具: AI 使用专用工具来仅获取和选择预先批准的 UI 组件（例如，具有正确样式的按钮）。

• 观察: 人工智能的输出通过编程机制进行评估，该机制会扫描所有颜色声明，以验证它们与可用的企业调色板严格匹配。

这远远超出了单纯的上下文工程。

正如前一篇文章所述，提示中的 Markdown 指令的存在通常只是为了弥补法学硕士当前的弱点——它们应该随着模型的自然发展而消失。 相比之下，程序化护栏和专用工具积极 增强 代理循环的力量。 这就是将平台能力视为内部产品的真正价值。

但赋能团队呢？他们会怎样？

如果他们成功了，他们就会消失。

衡量支持团队的成功

当不再需要支持团队时——当与流程保持一致的团队可以完全自主地运作时，支持团队就会成功。

然而，它们并不会永远消失。 由于行业实践不断发展，产品不断变化，因此组建和解散这些团队是组织生命周期的自然组成部分。

关键的一点是，当支持团队离开时，机构知识不会丢失。 由于他们已将自己的专业知识作为自动化护栏和可重复使用的服务编入平台中，因此在支持团队离开后很长一段时间内， 与流程保持一致的团队可以继续安全、自主地运营。

编辑（2026 年 7 月 5 日）: 经过几次讨论，我意识到提供具体的指标来衡量这些团队的成功是很有价值的，特别是为支持团队定义确切的“消失条件”。

以下是这些 OKR（目标和关键结果）的示例:

笔记:

• 上面使用的指标（10→3 天、70% 等）纯粹是为了激发对话而设计的说明性示例。 它们必须根据您自己的基线数据（当前周期时间、事件量等）进行校准。

• 赋能团队的第四个关键结果（KR4）是故意激进的。 它使“自我解体”这一抽象概念——这是他们成功的最终证明——具体化并可衡量。

结论

我们在这段旅程中看到的是围绕代理开发进行组织的愿景，而不是开箱即用的实施计划。

我的信念: 适应，不采用—这种转变没有什么灵丹妙药。 将此作为我个人的信念和关于如何建立一个组织以真正利用未来代理开发价值的愿景。

最后的免责声明：我们没有涵盖 复杂子系统团队 在这张照片中。在 团队拓扑，这是一个专业团队，提供各个级别的深厚专业知识来支持不同的团队:

• 他们可以帮助流式团队找到适合其产品的完美算法。

• 他们可以协助支持团队定制框架和工具。

• 他们可以而且应该通过选择最佳模型、优化成本和微调推理引擎来为平台带来价值。

最终，通过不断改进平台，组织将能够更高效、更有效地交付软件。

历史提醒我们，原始技术无法自行扩展。 正如现代软件交付不是由 Linux cgroup 或 Docker 定义的，而是由 Kubernetes 等平台定义的一样，人工智能开发的未来将属于编排它的平台。

让人工智能发挥作用 在你的机器上 在您的组织中。