谁做什么？面向智能体平台的团队拓扑
1. 引言：智能体平台与团队拓扑的关系
智能体平台（agentic platform）定义了需要提供什么。团队拓扑（Team Topologies）则定义了由谁提供，以及团队如何交互以实现目标。在本系列的第一篇文章中，我们提出了“什么”的问题：为了大规模生产可靠的应用程序，需要哪些系统能力（上下文、护栏、工具）？答案是智能体平台，其核心是智能体工厂（agentic factory）：智能体进行规划、编码、测试和交付的机制。但平台不会自己构建，更重要的是，它的消费方式与构建方式不同。一个根本问题仍然存在：谁做什么？
2. 真正的问题：智能体生产的认知负载
在问谁做什么之前，我们需要理解为什么这次的问题不同。构建应用程序过去意味着随时间协调不同角色：一个人设计，另一个人挑战架构，第三个人测试，第四个人部署。复杂性是真实的，但它是分布式的——分布在几个人之间，并随时间展开。每个角色依次提出自己的问题。智能体改变了这一格局。它们不问问题：它们立即产生答案。它们从不疲倦，从不休息，从不等待。速度是它们的优势，也是它们的陷阱。所有角色过去按顺序提出的问题，现在人类操控者必须在提示的短暂窗口内提前、并行地预见。如果框架不当，智能体不会减速：它会快速生产，但偏离目标。认知负载（cognitive load）不会随着AI消失——它会转变。它首先成为一种预见负担（anticipation burden）：人类在启动智能体之前必须预见一切，否则输出将达不到要求。而且，由于智能体持续生产，没有人类节奏，它也成为一个认知吞吐量问题：随时间持续流动的决策流。大规模智能体生产的真正挑战不是复杂性增长——而是复杂性压缩到一个人身上，并压缩到他们无法独自吸收的时间框架内。这正是平台要解决的问题。它通过使自身可被智能体查询来吸收部分预见负担：不用担心安全意味着智能体会询问平台如何操作，确定性控制将在下游强制执行结果。平台不会消除思考——它缩小了人类必须携带的问题集，让他们专注于真正重要的事情：那些有争议的、结构性的决策，其中人类判断仍然不可替代。因此，认知负载不再仅仅是Skelton和Pais所描述的要在团队间分配的数量。在智能体世界中，它也是一个要随时间调节的吞吐量。团队拓扑告诉我们如何分配；我们仍然需要说明如何吸收。这就是本文的主题。
3. 团队拓扑：应对负载的答案
为了解决这个负载问题，我们借鉴了团队拓扑（Team Topologies）¹，这是一种定义了四种团队类型和三种交互模式的组织模型。这并非巧合：其基本论点正是认知负载——一个团队只有在承载的复杂性不超过其吸收能力时才能有效。Skelton和Pais考虑的是要在团队间分配的结构性负载；我们将其扩展到上述智能体生产行为的动态负载。该模型为我们提供了分配可分配内容以及识别平台必须吸收内容的框架。让我们先明确我们的立场：以下内容是一种前瞻性的信念，是我们认为智能体进行应用程序生产所趋向的组织目标。问题不再是工厂需要什么，而是谁在操作它。这正是智能体平台所做的：它吸收技术复杂性，使业务团队只承载其领域的认知负载。开发者的角色转变：他们构建平台，使他人能够生产。对称地，应用程序生产通过智能体向业务团队开放。
4. 我们保留什么，调整什么
将团队拓扑应用于智能体上下文需要明确我们的偏离之处。为了避免在声称使用该模型时掏空其内涵，以下是界限。我们完整保留的内容：认知负载的指导原则；四种团队类型；三种交互模式；从协作到成熟时X即服务（X-as-a-Service）的转变。我们调整的内容及原因：流对齐团队（stream-aligned teams）可以是非技术性的（业务团队），因为平台吸收了技术负载；它们不承担端到端的运营责任（运行、事件），这由平台吸收；赋能（enabling）不仅仅是暂时的：它由平台结构性补偿，因为生产者不再是开发者；认知负载不再仅仅是团队间分配的数量，而是随时间调节的吞吐量：平台在智能体生产上游吸收预见负担。这些调整并未违背Skelton和Pais的意图：它们将其应用于他们未曾预料到的上下文——一个智能体生产、人类编排的上下文。
5. 四种团队类型，一个目标
目标是共享的：大规模生产符合组织标准的可靠应用程序。但角色是不同的。四种团队拓扑团队类型应用于智能体平台。每个团队在生产链中扮演特定角色。流对齐团队：生产应用程序。流对齐团队是产品团队。它们驱动AI编排器（第一篇文章中描述的智能体工厂的引擎），定义业务意图，并提供动态上下文：规格、产品特定护栏、领域知识。这种转变是深远的：这些团队不再需要由开发者组成。越来越多地，它们是直接通过智能体驱动生产的业务团队（领域专家、产品经理、分析师）。这种转变使生产更接近需求，但它也带来风险：这些团队可能并不总是理解将应用程序投入生产的含义。这正是其他团队类型存在的原因。需要明确一点。在经典团队拓扑中，流对齐团队对价值流端到端负责，包括运营和事件。在这里，平台吸收运营责任（部署、监控、回滚）。流对齐团队仍然对“什么”（意图、业务质量）负责；平台保证“如何”（可靠的生产部署）。这种划分需要一个足够成熟的平台。值班职责相应分配：平台团队处理系统事件（基础设施、护栏、流水线）；业务决策（内容移除、产品回滚）由流对齐团队负责。这种“什么/如何”的边界比看起来更具渗透性。例如，品牌一致性是业务关注点（“什么”），但其验证由平台自动化（“如何”）。平台保证最低标准；它不保证业务卓越。平台团队：工业化能力。平台团队以X即服务的形式提供三个系统支柱：系统上下文：指令、角色、共享业务知识、记忆、示例和模式；系统护栏：安全、可靠性、品牌一致性、约定；工具和技能：MCP服务器、CI/CD流水线、评估、共享技能。该模型是自助式的：文档化、版本化、无摩擦消费。设计工作投入一次，然后应用于每个项目。平台何时成熟？为了不让这个词成为空头承诺，以下是可观察的标准：护栏覆盖：关键维度（安全、可靠性、品牌一致性）自动覆盖，而非口头协议；流水线可靠性：部署成功率可衡量并跟踪（内部SLA）；自助服务份额：大多数部署无需平台团队干预；文档完整性：每个暴露的能力都有文档并附有示例；决策可追溯性：护栏产生审计轨迹（为什么部署被阻止，应用了哪条规则，违反了哪个阈值）。在满足这些标准之前，平台无法吸收流对齐团队的运营责任，模型依赖赋能来补偿。赋能团队：弥合差距。赋能团队本质上是临时的。其目标不是变得不可或缺，而是使产品团队自主。在实践中：环境配置：工具、访问、配置；培训：关于上下文打包、护栏、编排器操作；左移实践（安全、测试、质量），直到它们被平台封装。它弥合了业务意图与质量要求之间的差距。随着产品团队熟练度提高和平台成熟，其角色逐渐减弱。一个重要的细微差别：在智能体世界中，流对齐团队通常仍然主要是非技术性的。因此，差距永远不会仅通过技能提升完全弥合——它由平台结构性补偿。这不是模型的失败；这是对应用程序生产者不再是开发者的上下文的适应。复杂子系统团队：掌握技术复杂性。复杂子系统团队致力于AI基础设施中技术要求最高的方面。他们的专业知识深厚且专业化：绝不能分散到产品团队中。这种团队类型并非普遍适用。一个仅消费模型API的组织可能不需要。然而，一旦组织管理自己的模型、优化推理成本或面临主权约束，这种团队类型就变得至关重要——对于评估、红队测试、高级RAG工程或微调也是如此。他们与平台团队在模型效率、KV缓存、主权推理、成本优化和评估方面合作。他们的工作永远不会直接到达产品团队：它通过平台流动。
6. 三种交互模式
团队拓扑定义了团队之间的三种交互模式：促进（Facilitating）：赋能团队促进流对齐团队。一种临时交互，面向自主性：赋能者教产品团队自己完成。X即服务（X-as-a-Service）：平台以自助服务方式交付其能力。这是目标交互——实现规模化的交互。协作（Collaboration）：复杂子系统团队与平台团队协作。一种深度交互，在构建阶段是合理的。成熟时，它演变为X即服务：AI效率能力成为可消费的服务，而不是永久的建筑工地。使模型持久。定义团队及其交互是不够的。一个组织模型只有在其启动后仍然有效才有价值。走向自主的旅程。赋能团队的角色设计为缩小：这是系统正常运行的标志。三种交互模式共同演变：促进减弱，协作让位于X即服务，后者成为主导模式。这种演变遵循两个必须区分的平行轴：团队成熟度和平台成熟度。它们相互加强，但不会以相同的速度前进。启动阶段：团队方面：产品团队正在发现上下文打包和编排器操作。赋能无处不在。平台方面：能力是基础的（少数护栏、部分文档、仍然脆弱的流水线）。平台尚未达到上述标准。成熟阶段：团队方面：产品团队已掌握基础知识。赋能变得有针对性（关于特定护栏的建议、关于复杂提示的反馈）。平台方面：护栏扩展，自助服务进步，文档成形。与复杂子系统的协作开始转变为集成服务。自主阶段：团队方面：产品团队自主。赋能是可选的，仅限于偶尔的专业知识。平台方面：自助服务完成，护栏覆盖关键维度，可追溯性到位。主导交互是X即服务。赋能消失是因为它成功，而不是因为它失败。一个具体例子。营销团队想要制作一个着陆页。他们提供动态上下文（活动意图、关键信息）。平台注入系统上下文（品牌指南、UI组件、可访问性规则），护栏验证品牌一致性和安全性。赋能团队三个月前培训了营销团队——今天，只是偶尔检查。复杂子系统团队优化了KV缓存：品牌上下文已标记化，从缓存中提供，而不是每次迭代重新计算，降低了每次生成的成本。结果：一个合规、安全、已部署的着陆页——营销团队无需知道什么是CI/CD流水线。另一面：从未看到保护机制的团队失去了判断其相关性的能力。护栏必须在决策上透明，即使它们在实现上不透明。应用程序治理：大规模防止影子IT。如果非技术业务团队可以在生产中生产应用程序，谁来决定应用程序是否有权存在？谁管理其生命周期（技术债务、弃用、累积成本）？没有治理，你最终会得到工业化的影子IT。平台是这种治理的杠杆：通过集中部署、监控和使用指标，它提供对应用程序组合的系统可见性。平台的产品负责人可以跟踪活跃应用程序，识别那些不再维护的应用程序，并触发其弃用。不再通过安全检查的应用程序会自动标记，而不是被默默遗忘。原则很简单：生产的便利性必须与监督的便利性相匹配。如果平台使创建应用程序变得微不足道，它必须使了解有多少应用程序存在、谁在使用它们以及它们花费多少同样微不足道。
7. 升级路径：从特定到系统
平台讨论中经常缺少一个机制：产品护栏何时成为平台护栏？示例：营销团队实现了一个WCAG对比度护栏。三个月后，人力资源团队遇到同样的需求。然后是电子商务团队。这是升级信号：至少三个团队重复的护栏成为系统化的候选——护栏的“三次法则”（rule of three）²。平台的产品负责人将候选者泛化，使其可配置，文档化：所有团队受益。流对齐团队浮现重复需求。平台团队评估并集成。赋能者在其参与期间发现跨领域需求。自主不是沉默：即使在成熟阶段，产品团队仍然是推动升级的传感器。自助服务不会消除反馈循环——它使其更便宜。平台是一个活产品（living product）¹，拥有自己的待办事项列表、产品负责人和迭代周期。必须指出一个风险。这个产品负责人可能承担三个负担：平台的技术待办事项、护栏升级和应用程序组合治理。矛盾的是，这正是模型声称要防止的瓶颈。为什么这个风险会出现。平台越成功，它集中的决策就越多，而单个角色无法手动仲裁来自数十个产品团队的需求流。答案在于工具。平台必须自动化升级候选检测、基于使用的优先级排序和组合跟踪。产品负责人进行仲裁；他们不承担一切。没有这个升级机制，平台就会停滞。产品团队重新发明相同的解决方案。护栏仍然是本地的。系统可靠性侵蚀。
8. 运营总结与信念
原则已就位，还需要将它们具体化为可操作的规则。谁拥有什么？每个能力有一个所有者（对结果负责）和通常的贡献者（共同构建但不负责）。没有这种清晰性，能力就会落空。每个能力都有所有者和贡献者。空单元格表示不参与。特定内容由产品团队负责，系统内容由平台负责。指导原则很简单：特定内容（动态上下文、产品护栏、业务知识）由流对齐团队负责，因为领域知识属于业务。系统内容（系统上下文、组织护栏、工具、编排器）由平台工业化。AI编排器是标志性案例：工具由平台提供；配置由产品团队负责。一个信念。智能体平台回答了“什么”的问题。团队拓扑回答了“谁”和“如何”的问题——不是作为刚性划分，而是作为责任分配：业务意图和领域上下文给产品团队，生产可靠性给平台。没有这些边界，平台要么成为瓶颈，要么成为政治战场。这个模型并非普遍适用：它针对并行生产多个智能体应用程序的组织。在实践中（一个经验启发式，而非绝对阈值），从三到五个产品团队开始，重新发明的累积成本（重新创建的上下文、重新实现的护栏、需要修复的不一致性）超过了共享平台的投资。应用于智能体工程，团队拓扑提供了一个结构，它：使业务团队能够成为流对齐团队，而无需他们成为开发者；确保系统能力被工业化，而不是逐个项目重新发明；承认业务与生产之间的差距是真实的，并用赋能者而非希望来弥合它；将技术复杂性隔离在专门团队中，这些团队为平台提供输入。改变的是，生产应用程序不再需要编码，但需要其他技能：阐述意图、构建上下文、操作编排器。不变的是，你需要护栏、一致性和可靠性才能将其投入生产。这种转变解决了开头提出的问题。今天，是开发者承担预见负担：他们知道智能体不会问哪些问题。明天，随着平台吸收越来越多的份额，操作所需的技能门槛降低：业务团队可以在不独自承担平台代表他们预见的内容的情况下进行生产。生产者的轨迹，从开发者到业务，不是一个假设——它是预见负担逐步吸收的可衡量结果。开发者不会消失：他们转变。他们不再生产应用程序——他们构建平台，使他人能够生产它。来源：Matthew Skelton, Manuel Pais — 《团队拓扑：为快速流动组织业务和技术团队》（Team Topologies: Organizing Business and Technology Teams for Fast Flow），IT Revolution, 2019。 ↩︎ ↩︎ Don Roberts，由Martin Fowler引用 — 《重构：改善既有代码的设计》（Refactoring: Improving the Design of Existing Code），Addison-Wesley, 1999。三次则重构。该原则在此从代码重构转置到护栏升级。 ↩︎
🔗 原文链接：https://blog.owulveryck.info/2026/06/22/who-does-what-team-topologies-for-the-agentic-platform.html