谁做什么？面向代理型平台的团队拓扑

# 谁做什么？面向智能体平台的组织拓扑 来源：https://blog.owulveryck.info/2026/06/22/who-does-what-team-topologies-for-the-agentic-platform.html > *智能体平台定义了需要提供什么。组织拓扑则定义了谁来提供，以及团队如何协作以实现目标。* --- 在本系列的第一篇文章（https://blog.owulveryck.info/2026/06/19/vibe-coding-at-scale-engineering-strikes-back.html）中，我们提出了**什么**的问题：要大规模生产可靠的应用，需要哪些系统性能力（上下文、护栏、工具）。答案是智能体平台，其核心是*智能体工厂*：智能体计划、编码、测试和交付的机制。 但平台不会自己构建，更重要的是，它的消费方式与构建方式并不相同。一个根本问题依然存在：**谁做什么？** ## 真正的问题：智能体生产的认知负荷 *在问谁做什么之前，我们需要理解为什么这次的问题有所不同。* 过去，构建应用意味着随时间编排角色：一个人设计，另一个人挑战架构，第三个人测试，第四个人部署。复杂性是真实的，但它是**分布式的**——分散在多人身上，且随时间推移。每个角色依次提出自己的问题。 智能体改变了规则。它们不问问题，而是立即给出答案。它们从不疲倦，从不休息，从不等待。速度是它们的优势，也是它们的陷阱。过去角色们*顺序*提出的所有问题，现在操控智能体的人必须*提前、并行、在短暂的提示窗口内*预见。如果框架不当，智能体不会减速：它只会快速产出，但偏离目标。 认知负荷不会随着AI消失——它会转化。它首先成为一种**预见负担**：人类在启动智能体之前必须预见的一切，否则输出将达不到要求。而且由于智能体连续生产，没有人类节奏，它还会成为一个**认知吞吐量**问题：随着时间的推移，持续不断的决策流。大规模智能体生产的真正挑战不是复杂度增长，而是复杂度**压缩**到单个人身上，并且压缩到他们无法独自吸收的时间范围内。 这正是平台要解决的问题。它通过使自身**可被智能体查询**来吸收部分预见负担：“不用担心安全问题”意味着智能体会向平台询问如何操作，确定性控制会在下游强制执行结果。平台并没有消除思考——它**缩小了人类必须携带的问题集**，让他们专注于真正重要的事情：那些有争议的、结构性的决策，其中人类判断仍然不可替代。 因此，认知负荷不再仅仅是 Skelton 和 Pais 所描述的*要跨团队分配的数量*。在智能体世界中，它也是*需要随时间调节的吞吐量*。组织拓扑告诉我们如何分配；我们还需要说明如何吸收。这就是本文的主题。 ## 组织拓扑，应对负荷的答案 为了解决这个负荷问题，我们借鉴了*组织拓扑*¹ (https://blog.owulveryck.info/2026/06/22/who-does-what-team-topologies-for-the-agentic-platform.html#fn:1)，这是一种定义了四种团队类型和三种互动模式的组织模型。这并非巧合：**其核心论点正是认知负荷**——一个团队只有在承载的复杂度不超过其吸收能力时才能有效运作。Skelton 和 Pais 考虑的是要跨团队分配的*结构性*负荷；我们将其扩展到上述智能体生产行为的*动态*负荷。该模型为我们提供了分配可分配之物的网格，以及识别平台必须吸收之物的网格。 让我们先明确我们的立场：以下内容是**前瞻性的信念**，是我们认为应用生产通过智能体发展的组织目标。问题不再是*工厂需要什么*，而是*谁来运营它*。 这正是智能体平台所做的：它**吸收技术复杂度**，使得业务团队只承载其领域的认知负荷。开发者的角色发生了转变：他们构建平台，使他人能够生产。对称地，应用生产通过智能体向业务团队开放。 ### 我们保留什么，适应什么 将组织拓扑应用于智能体环境，需要明确我们的偏离之处。为了避免在借用其名时掏空模型，以下是界限。 **我们完整保留的内容：** 指导原则**认知负荷**；**四种团队类型**；**三种互动模式**；**从协作转向*X-as-a-Service***的成熟路径。 **我们调整的内容及原因：** - *流对齐*团队可以是**非技术性**的（业务团队），因为平台吸收了技术负荷； - 他们不承担**端到端的运营责任**（运行、事件），这由平台吸收； - *赋能*不仅仅是暂时的：它由平台**结构性补偿**，因为生产者不再是开发者； - **认知负荷**不再只是跨团队分配的数量，而是**需要随时间调节的吞吐量**：平台在智能体生产上游吸收预见负担。 这些调整并未违背 Skelton 和 Pais 的本意：它们是将模型应用到一个他们未曾预料到的环境——智能体生产，人类编排。 ## 四种团队类型，一个目标 目标是共享的：大规模生产可靠的应用，符合组织标准。但角色是不同的。 智能体平台的组织拓扑 *应用于智能体平台的四种组织拓扑团队类型。每个团队在生产链中扮演特定角色。* ### 流对齐团队：生产应用 流对齐团队是产品团队。他们驱动 AI 编排器（第一篇文章中描述的智能体工厂引擎），定义业务意图，并提供**动态上下文**：规格、产品特定的护栏、领域知识。 这种转变影响深远：这些团队不再需要由开发者组成。越来越多地，他们是**业务团队**（领域专家、产品经理、分析师），通过智能体直接驱动生产。这种转变使生产更贴近需求，但也带来了风险：这些团队可能并不总是理解将应用投入生产的含义。这正是其他团队类型存在的原因。 这里需要严谨一点。在经典的组织拓扑中，流对齐团队对一个价值流负有**端到端**责任，包括运营和事件。在这里，**平台吸收运营责任**（部署、监控、回滚）。流对齐团队仍然对*什么*（意图、业务质量）负责；平台保证*如何*（可靠的生产部署）。这种分离需要一个足够成熟的平台 (https://blog.owulveryck.info/2026/06/22/who-does-what-team-topologies-for-the-agentic-platform.html#a-platform-is-mature-when)。**值班职责**相应分配：平台团队处理**系统性事件**（基础设施、护栏、流水线）；**业务决策**（内容移除、产品回滚）仍由流对齐团队负责。 这个什么/如何的界限**比看上去更易渗透**。例如，品牌一致性是一个业务关注点（*什么*），但其验证由平台自动化处理（*如何*）。平台保证*最低标准*；它不保证业务卓越。 ### 平台团队：工业化能力 平台团队将三个系统性支柱作为 X-as-a-Service 提供： - **系统性上下文**：指令、角色、共享业务知识、记忆、示例和模式 - **系统性护栏**：安全、可靠性、品牌一致性、惯例 - **工具和技能**：MCP 服务器、CI/CD 流水线、评估、共享技能 该模型是自助式的：有文档、有版本管理、可无摩擦消费。设计工作投入一次，然后应用于每个项目。 #### 平台“成熟”的标志是…… 为了防止这个词成为空洞的承诺，以下是可观察的标准： - **护栏覆盖范围**：关键维度（安全、可靠性、品牌一致性）自动覆盖，而非通过口头协议 - **流水线可靠性**：部署成功率可衡量并可追踪（内部 SLA） - **自助服务比例**：大多数部署无需平台团队介入 - **文档完整性**：每个公开的能力都有文档记录并附带示例 - **决策可追溯性**：护栏产生审计轨迹（为何阻止部署、应用了哪条规则、违反了哪个阈值） 在达到这些标准之前，平台无法吸收流对齐团队的运营责任，模型依赖于赋能来弥补。 ### 赋能团队：弥合差距 赋能团队**本质上是临时的**。其目标不是变得不可或缺，而是使产品团队变得自主。在实践中： - **环境配置**：工具、访问、配置 - **培训**：关于上下文打包、护栏、编排器操作 - **左移**实践（安全、测试、质量），直到它们被平台封装 它弥合了业务意图与质量要求之间的差距。随着产品团队能力提升和平台成熟，其作用逐渐减弱。 一个重要细微差别：在智能体世界中，流对齐团队通常仍然是**以非技术性为主的**。因此，差距永远不会仅通过技能提升而完全弥合——它由平台**结构性补偿**。这不是模型的失败，而是对应用生产者不再是开发者这一环境的适应。 ### 复杂子系统团队：掌握技术复杂性 *复杂子系统*团队负责 AI 基础设施中技术要求最高的部分。他们的专业知识深入且专业化：不应被稀释到产品团队中。 **这种团队类型并非通用。** 一个只消费模型 API 的组织可能不需要。然而，一旦它管理自己的模型、优化推理成本或面临主权约束，这种团队类型就变得至关重要——对于评估、红队测试、高级 RAG 工程或微调也是如此。 他们与平台团队在模型效率、KV 缓存、主权推理、成本优化和评估方面协作。他们的工作永远不会直接到达产品团队：它通过平台流动。 ## 三种互动模式 组织拓扑定义了团队之间的三种互动模式： **促进**：赋能团队*促进*流对齐团队。一种临时的互动，面向自主性：赋能者教产品团队自己做。 **X-as-a-Service**：平台以自助方式提供其能力。这是目标互动模式——使规模化成为可能的模式。 **协作**：复杂子系统团队与平台团队*协作*。一种深度互动，在构建阶段有其合理性。成熟时，它演变为 X-as-a-Service：AI 效率能力成为可消费的服务，而非永久性的施工场地。 --- ## 让模型持久 仅仅定义团队及其互动是不够的。一个组织模型只有在其启动后仍然有效才有价值。 ### 通向自主的旅程 赋能团队的角色被设计成逐渐缩小：这是系统正常运作的标志。 互动模式的演变 *三种互动模式共同演变：促进逐渐消失，协作让位于 X-as-a-Service，后者成为主导模式。* 这种演变遵循两个需要区分的并行轴：**团队成熟度**和**平台成熟度**。它们相互加强，但进步速度不同。 **启动时：** - *团队方面*：产品团队正在学习上下文打包和编排器操作。赋能无处不在。 - *平台方面*：能力很基础（少数护栏、部分文档、仍然脆弱的流水线）。平台尚未达到上述定义的成熟度标准。 **成熟过程中：** - *团队方面*：产品团队已掌握基础知识。赋能变得有针对性（关于特定护栏的建议、对复杂提示的反馈）。 - *平台方面*：护栏扩展、自助服务推进、文档成型。与复杂子系统的协作开始转化为集成服务。 **自主时：** - *团队方面*：产品团队已实现自主。赋能是可选的，仅限于偶尔的专业知识。 - *平台方面*：自助服务完备，护栏覆盖关键维度，可追溯性到位。主导互动模式是 X-as-a-Service。 **赋能消失是因为它成功了，而不是因为它失败了。** **一个具体例子。** 营销团队想要制作一个着陆页。他们提供动态上下文（活动意图、关键信息）。平台注入系统性上下文（品牌指南、UI 组件、可访问性规则），护栏验证品牌一致性和安全性。赋能团队三个月前培训过营销团队——今天，只是偶尔检查一下。复杂子系统团队优化了 KV 缓存：品牌上下文已经被标记化，从缓存中提供，而不是每次迭代重新计算，从而降低了每次生成的成本。结果：一个合规、安全、已部署的着陆页——营销团队无需知道什么是 CI/CD 流水线。 另一面：一个从未“看到”保护机制的团队会失去判断其相关性的能力。护栏必须在**决策上透明**，即使在实现上不透明。 ### 应用治理：在规模上防止影子 IT 如果非技术的业务团队可以生产应用并投入生产，**谁来决定一个应用有存在的权利？** 谁管理其生命周期（技术债务、停用、累积成本）？ 没有治理，你最终会得到工业化的影子 IT。平台是实现这种治理的杠杆：通过集中部署、监控和使用指标，它提供对应用组合的**系统性可见性**。平台的产品负责人可以跟踪活跃的应用，识别那些不再维护的应用，并触发其停用。一个不再通过安全检查的应用会被自动标记，而不是默默被遗忘。 原则很简单：**易于生产必须与易于监督相匹配**。如果平台使创建应用变得轻而易举，那么它必须使知道有多少应用、谁在使用它们以及它们花费多少也同样容易。 ### 演进路径：从特定到系统 平台讨论中经常缺失的一个机制：**什么时候一个“产品”护栏会变成一个“平台”护栏？** 例如：营销团队实现了一个 WCAG 对比度护栏。三个月后，人力资源团队遇到了同样的需求。然后是电商团队。这就是演进的信号：一个被至少三个团队重复使用的护栏成为系统化的候选——*三原则*² (https://blog.owulveryck.info/2026/06/22/who-does-what-team-topologies-for-the-agentic-platform.html#fn:2) 应用于护栏。平台的产品负责人将候选护栏通用化，使其可配置，记录文档：所有团队受益。 流对齐团队发现重复出现的需求。平台团队评估并集成。赋能者发现跨领域