谁做什么？代理平台的团队拓扑结构

代理型平台定义了需要提供哪些服务。团队拓扑结构则明确了由谁来提供这些服务，以及各团队如何相互协作以实现这一目标。

这是第二版，采用更贴近人类语言的表述。第一版大致是人工智能完成的翻译版本。本版由人工编辑而成，希望能让读者读起来更加顺畅、易于理解。

在系列文章的第一篇中，我们提出了一个核心问题：“究竟需要哪些系统性能力（如上下文、
监管机制、工具体系）才能在规模化场景下打造可靠的应用？
”答案是：代理型平台，而其核心则是“代理型工厂”——一个让代理们负责规划、
编码、测试并最终交付应用的机制。

然而，平台本身并不会自动构建，更重要的是，它并非以与构建时完全相同的方式被使用。一个根本性的问题依然存在：“到底是谁在做什么？”

真正的难题：认知负荷的压缩

在追问“谁来做什么”之前，我们需要先弄清楚，为什么这一次的问题表述有所不同。

开发一款软件应用，本质上是在时间维度上协调各方角色：设计师、架构师、测试人员和运维工程师。
整体复杂度确实很高，但这种复杂性是分散在多人之间，并且随着时间推移不断延展。
每个角色都会依次提出自己的问题。

AI代理改变了这一局面。它们不再局限于回答孤立的问题，而是能够持续生成输出。
由于代理能够即时执行任务，传统的顺序式问题解决流程被彻底打破。
所有这些问题如今都必须由指挥决策的人类提前预判，并在短短几秒的提示窗口内予以回应。
如果提示框架设计得不够周密，代理不仅不会放慢速度，反而会产出快速却偏离目标的解决方案。

认知负荷并不会随着AI的出现而消失——相反，它发生了转变。
它变成了“预期负担”（即人类在启动流程前必须预先预见的一切），同时又叠加了一项“认知吞吐量问题”（即如何维持高效率的决策流）。
在规模化代理化生产中，真正的挑战并不在于复杂度的增加，而在于这种复杂度会集中到一个人身上，
而这个人却无法独自承受如此庞大的工作量。

平台正是为此而生。它通过将部分预期负担“交由代理自行查询”，实现了对认知负荷的吸收：
当告诉代理“不用担心安全问题”时，代理便会向平台请教该如何继续推进，而确定性的管控措施则会确保后续环节的顺利落地。
平台并不会消除思考的过程，而是“缩小了人类需要处理的问题范围”，使他们得以专注于真正重要的事情：
那些充满争议、具有结构性意义的决策，而人类的判断力在这些决策中依然不可或缺。

因此，认知负荷不再仅仅是斯凯尔顿和派斯所描述的那种“需要在团队间分配的‘数量’”。
在代理型世界中，它还是一种“需要在时间维度上加以调控的‘吞吐量’”。
团队拓扑结构为我们提供了分配方案；我们仍需弄清如何将其“吸收”掉。
而这正是本文要探讨的核心议题。

团队拓扑结构：应对认知负荷的答案

为了破解这一瓶颈，我们可以借助团队拓扑结构1——一种组织模型，它划定了四种团队类型和三种互动模式。

“所有的模型都是错的，但有些模型很有用。”——乔治·博克斯

这一框架在工程组织中有着丰富的实践案例。其创立之初的理论依据正是“认知负荷”：只有当一个团队所承载的复杂度不超过其所能承受的范围时，才能真正发挥效能。

斯凯尔顿和派斯曾从“结构性”负荷的角度进行思考，这种负荷是分散在各个团队之间的。
而我想要将这一视角延伸至代理化生产的“动态”负荷。
该模型为我们提供了一个框架，用于合理分配可分配的资源，并明确平台内部（如前一篇文章中所定义的）需要承担的职责。

需要明确的是：以下内容是一种基于前瞻性的信念。
这正是我所坚信的、面向AI驱动的应用生产方向的组织目标。
此时的问题已不再是“工厂需要什么”，而是“谁来运营这个工厂”。

这正是我心目中代理型平台的初衷：它能够“吸收技术上的复杂度”，从而让业务团队只需承担各自特定领域的认知负荷。
开发者的角色也随之转变：他们不再只是单纯地构建平台，而是为他人创造条件，
助力他们完成应用的生产。镜像效应在于：应用开发得以向业务团队敞开大门，而这些团队则在基于AI的代理化开发团队的赋能下，
获得了全新的发展机会。

我们保留的与我们适应的

将团队拓扑结构应用于AI驱动的场景，需要明确我们究竟应遵循该模型的哪些部分，又有哪些方面需要做出调整。我们的目标是保留核心机制，而非简单地借用那些时髦的术语。

保持不变的部分：

• 核心重点始终在于管理认知负荷。

• 四种团队类型和三种互动模式。

• 从紧密协作迈向成熟期的X-as-a-Service模式。

变化之处及其原因：

• Stream-aligned团队可以是非技术型的（由业务主导）：平台负责处理技术层面的繁重工作，让领域专家得以直接推动生产进程。

• 无需承担端到端的运维责任：平台——而非Stream-aligned团队——负责“运行”与事件管理。

• 赋能是长期的，而非短暂的：由于主要的生产者是业务专家，而非软件工程师，平台的赋能便成为一项结构性、持续性的需求。

• 认知负荷转变为吞吐量指标：它不再仅仅是一个需要在团队间分配的静态总量，而是一种需要在时间维度上持续调节的决策流。
平台会在代理开始生成之前，就已将前期的“预期负担”悉数吸收。

这些调整并未违背斯凯尔顿和派斯最初的意图。它们只是将这一理念投射到了他们未曾预料到的现实之中：一种由人类与AI共同协作、且不会受到认知负荷困扰的工作模式。

四种团队类型，一个目标

这些团队共有的目标十分清晰：在规模化场景下，生产出可靠且标准化的应用。
然而，它们的角色却依然截然不同。以下是它们互动方式的综合图示，以“地图”的形式呈现（向西蒙·沃德利致歉，
我知道这并不是一张真正的地图）。

四种团队拓扑结构的团队类型，应用于代理型平台。每个团队都在生产链中扮演着特定的角色。

现在，让我们逐一了解各个团队及其角色。

Stream-Aligned团队：推动生产

Stream-aligned团队是负责交付核心业务价值的产品团队。
在这一模式中，它们负责驱动AI编排器（即前一篇文章中所描述的工厂引擎），
明确业务意图，并提供动态上下文：规格说明、产品专属的监管规则以及领域知识。

AI代理的引入从根本上改变了这些团队：它们不再需要由软件工程师来组成。
取而代之的是由业务专家（领域专家、产品经理、分析师）构成，他们通过代理直接生成应用。
传统上，业务需求与开发者实现之间的翻译层被彻底消除；
业务团队“构建”应用。虽然这使得生产过程离用户需求更近了一步，但也带来了重大风险：
非技术型团队往往难以理解将代码推向生产所带来的深远影响。
这也正是其他团队类型不可或缺的原因。

与原始模型的偏差：在经典的团队拓扑结构中，Stream-aligned团队负责从头到尾掌控价值流，
包括运维与事件管理（“你构建它，你运行它”）。
而在这一代理型模型中，平台承担了运维责任（部署、监控、回滚）。
Stream-aligned团队负责what（业务意图与质量）；
平台则保障how（安全、可靠的执行）。
这种分工要求平台具备高度成熟的架构。
值班制度随之发生相应调整：平台团队负责处理系统性故障（基础设施、管道崩溃、
监管规则违规），而业务决策（功能回滚、内容问题）则仍由Stream-aligned团队负责。

这种“what/如何”的界限其实比听起来要更加灵活。
例如，品牌一致性是业务关注的重点（“what”），但通过平台实现自动化验证（“how”）却同样可行。
归根结底，平台会强制执行安全与标准的基准；
它并不能保证业务的卓越表现。

平台团队：打造引擎

平台团队必须以自助服务的形式，提供四大核心支柱：

• 全局上下文：系统提示、角色、共享的业务知识、内存、示例以及架构模式。

• 确定性监管规则：安全策略、可靠性约束、品牌一致性以及编码规范。

• 代理工具：MCP（模型上下文协议）服务器、CI/CD流水线、评估框架以及共享的代理“技能”。

• 执行引擎：用于实际运行AI引擎（推理引擎）。

交互模式严格以自助服务为主：一切内容均经过记录、版本控制，并且可以顺畅地被消费。工程投入由平台团队一次性完成，并在所有代理驱动的项目中持续发挥作用。

平台何时“成熟”?

为了使这一概念更具现实意义，以下是平台在真正赋能AI驱动开发时必须满足的可观察标准：

• 硬编码的监管规则：关键维度（安全、可靠性、合规性）通过标准代码以确定性方式加以执行——而不仅仅是依靠随机的LLM“口头约定”或提示约束。

• 可衡量的可靠性：部署成功率和流水线健康状况均按照内部SLA进行追踪。

• 高自助服务指数：绝大多数部署都无需平台团队的任何干预。

• 代理可读的文档：每项公开的能力都经过完整记录，不仅为人类编写了示例，也为查询这些能力的代理提供了格式化的指南。

• 决策可追溯性：每一次监管规则的干预都会留下清晰的审计轨迹（例如，部署被阻止的具体原因、适用的特定规则，以及突破的阈值）。

在这些标准未达成之前，平台无法安全地从Stream-aligned的业务团队手中接管运维责任。在此期间，组织必须高度依赖赋能团队来弥合这一差距。

赋能团队：弥合差距

赋能团队的存在，旨在连接业务意图与工程严谨性之间的鸿沟。
在经典的团队拓扑结构中，这个团队是临时性的——它的目标是提升产品团队的能力，
然后转而投身其他任务。而在代理化转型中，他们的重点在于：

• 环境配置：搭建工具、权限以及代理的工作空间。

• 代理培训：教导业务用户如何正确地封装上下文、理解监管规则，并熟练操作AI编排器。

• 手动左移：在安全、测试和质量实践上进行手动的强化，直到这些实践能够被完全固化到平台中。

永久的鸿沟？在这个模型中，或许很快就会达到一个极限。
传统上，赋能团队会通过培训提升开发者的技能，直至他们完全自主。
但在代理化的世界里，Stream-aligned团队的非技术型成员正日益增多。
对于领域专家在软件工程方面的“技能提升”而言，存在着一个难以逾越的上限；
仅靠培训，鸿沟永远无法完全弥合。

平台必须为这种技术专长的缺失提供结构性的补偿。
赋能团队的最终使命，不仅是培训业务团队，更是精准识别出业务不能或不应学习的内容，
并授权平台团队将其自动化。这并非模型中的缺陷，而是对现实的一种必要适应——在这样的现实中，
应用的生产者早已不再是软件开发者。

复杂的子系统团队：封装深度技术

复杂的子系统团队负责处理AI基础设施中最具技术挑战的环节。他们的专业领域深邃且高度专业化；若将这些专长分散到各个产品团队中，将会造成人才与专注力的巨大浪费。

这一团队类型是可选的。如果你的组织只是简单地封装外部LLM API，那么你可能并不需要它。然而，一旦你开始托管自己的开放权重模型、优化推理成本，
或面对严格的数据主权限制，这一团队便变得至关重要。
他们负责高级AI工程的繁重工作：红队测试、复杂的RAG架构、微调以及自定义评估框架。

他们与平台团队密切合作，解决诸如KV缓存优化、主权推理流水线以及计算效率等棘手的工程问题。
至关重要的是，他们的工作从未直接触及Stream-aligned的产品团队。
这些工作被完全封装，并通过平台以服务的形式进行分布式处理。

三种互动模式

团队拓扑结构为这些团队之间定义了三种核心互动模式。在代理化时代，无需过多调整；该模型大多可以直接照搬使用。以下是这张地图：

• 促进式互动：赋能团队促进Stream-aligned团队。
这是一种临时性的、以实践为导向的互动，完全以能力提升为目标。
赋能团队会指导业务团队如何安全地与平台及AI编排器互动。

• X-as-a-Service：平台团队通过自助服务的方式，将自身能力严格传递给Stream-aligned团队。
这是目标状态，也是规模化发展的唯一驱动力。
它消除了阻塞工单和手动交接，为产品团队提供了真正的自主权（有效运用标准化工具），
而非独立性（在孤立环境中构建影子IT）。

• 协作式互动：复杂的子系统团队与平台团队紧密协作,以整合深层的技术能力。
这是在初始建设阶段所必需的高带宽、同步互动。
然而，随着系统的逐渐成熟，这一模式也必须演变为X-as-a-Service：
AI效率与基础设施终将变成可消费的API，而非永久性的施工工地。

让模型真正落地

定义团队及其互动关系只是第一步。静态的蓝图注定会失败。
正如任何框架一样，根据自身的实际情况进行调整，总是比盲目照搬更佳（根据我的经验，
盲目照搬往往是“Dire Straits”的反面典型：白花钱）。
为了让这一组织结构能够真正适应现实，它绝不能只是一次性的重组。
它必须被视为一条通往成熟目标的持续旅程。

通往自主的旅程

赋能团队的角色被明确设计为逐步缩减。这正是系统运转的终极标志。

三种互动模式彼此协同演化：促进式互动逐渐淡出，协作式互动让位于X-as-a-Service，后者最终成为主导模式。

这一演化遵循两条平行的轴线，两者必须仔细区分：团队成熟度与平台成熟度。它们彼此强化，但进展的速度并不完全一致。

起步阶段：

• 团队侧：产品团队刚刚开始探索上下文的封装方式，以及如何操作AI编排器。赋能团队无处不在，常常直接嵌入产品团队之中。

• 平台侧：能力尚处于基础阶段（少数监管规则、部分文档、脆弱的部署流水线）。平台尚未达到先前所定义的成熟度标准。

成熟期：

• 团队侧：产品团队已经掌握了基本功。赋能团队开始解耦并构建自身的目标。他们的干预变得更加精准（例如，针对特定监管规则提供建议，或对复杂提示进行故障排除）。

• 平台侧：监管规则的覆盖范围不断扩大，自助服务的普及程度不断提高，文档也愈发完善。与复杂子系统团队的深度协作开始逐渐结晶为集成且稳定的服务。

全面自主：

• 团队侧：产品团队完全自主。赋能成为可选，更多地扮演起边缘案例的按需咨询服务角色。

• 平台侧：自助服务全面覆盖，确定性的监管规则涵盖了所有关键维度，完整的审计追溯也已落实。X-as-a-Service成为绝对主导的互动模式。

赋能团队会消失，因为它们成功了，而不是因为它们失败了。

一个具体的例子：目标状态

让我们来看看，当组织达到全面自主时，这一过程是如何展开的。

市场部希望创建一个新的落地页。他们提供了动态上下文（营销活动的意图、关键信息）。
平台会自动注入系统上下文（品牌规范、UI组件、无障碍规则），而其确定性的监管规则则确保了品牌的一致性和安全性。

请注意角色是如何演进的：赋能团队在早期曾大力支持市场部，如今他们已经完成了核心培训，距离培训结束已有三个月。如今，他们只会在偶尔的边缘案例支持中偶尔出现。

与此同时，复杂子系统团队的深厚技术专长则在幕后默默运作。

在建设阶段，他们与平台团队协作，设计了一套主权AI架构（优化GPU分配并处理并发访问）。
他们还帮助平台准确识别出庞大品牌上下文中的哪些部分应该被冻结。
正因为如此，上下文现在可以直接从KV缓存中获取，而不再每次提示迭代时都重新计算，
从而大幅降低了每轮生成的成本。

结果：一个合规、安全、完全部署的落地页——甚至无需市场部知道CI/CD流水线究竟是什么。

反面：一个从未“看见”底层保护机制的团队，会失去判断其相关性或报告误报的能力。
因此，监管规则必须在决策过程中保持透明（提供清晰的错误提示和审计轨迹），
即便在实施过程中它们仍然完全不透明。

应用治理：防止大规模的影子IT

稳固的团队结构还不够。如果我们真的想赋能业务团队进行应用的构建与部署，就必须解决治理这一根本性问题：
谁来决定一个应用是否拥有存在的权利？
又由谁来管理其生命周期（其技术债务、累积成本，以及最终的停用）？

如果没有治理，代理化生产只会催生工业化的影子IT。
平台充当了这一治理的执行引擎（类似于Data-Mesh中的计算治理概念）。
通过集中部署、监控以及使用指标，平台为整个应用组合提供了系统性可视性。

通过平台，我们可以追踪活跃的应用，识别废弃的应用，并触发自动化的停用。如果某个旧应用突然因新近更新的安全监管规则而失效，它会被立即标记出来，而不会被悄然遗忘。

生产效率的提升，必须与监督的便捷性相匹配。如果平台让创建一个应用变得轻而易举，那么它也必须让审计现有应用的数量、归属主体以及成本变得同样轻松。

从具体到系统化：毕业之路

具体的监管规则将在商品化后走向现成的产品。但关于平台生命周期，还有一个至关重要的问题：何时本地的“产品”监管规则会演变为全球性的“平台”监管规则？

三原则：假设电商团队在将个人身份信息（PII）监管规则（一种安全过滤器，
旨在自动清理敏感客户数据，如送货地址或信用卡部分信息）发送至外部LLM之前，
就已经将其实施（例如，在欧洲运营时，这是一个非常重要的议题）。

三个月后，忠诚度计划团队又构建了类似的过滤器，用于在处理反馈日志时屏蔽客户姓名和出生日期。
随后，门店运营团队又对点击&收集订单中的电子邮件地址采取了同样的措施。

这就是毕业的信号。借鉴马丁·福勒的三原则2,一旦监管规则在三个不同的团队中被重复实施，
它便有资格被系统化。平台团队抽象了数据清洗器，使其具备可配置性（例如，确保符合GDPR或CCPA的标准化合规要求），
并对其进行了文档化，同时以统一的“客户数据匿名化”服务在全球范围内对外披露。
(个人笔记：我曾基于这个精确的例子，构建了一个关于A2A沟通的POC；
更多相关内容将在即将发表的文章中详述）

在这种情境下，Stream-aligned的产品团队会发现反复出现的需求。
赋能团队在互动过程中发现了跨领域趋势（实践社区或兴趣小组会议是发现这些趋势的绝佳场所）。
平台团队则进行评估并加以整合。自主并不意味着孤立：产品团队作为前线传感器，
为平台的演进提供源源不断的反馈。平台依然是一个活生生的产品1——拥有自己的待办事项清单、
产品负责人以及迭代周期。

瓶颈悖论：这里出现了一种风险：平台越是成功，平台产品负责人便越会继承三大沉重负担：
技术待办事项、监管规则的毕业流程，以及应用组合的治理。
矛盾的是，如果一个人必须手动仲裁来自数十个代理驱动团队的需求流动，我们实际上又回到了这个模型原本旨在避免的那条认知瓶颈。

答案在于工具，更在于认知自动化。人类无法在代理化规模下手动采集并分类这些数据。
平台必须自动化检测毕业候选、基于使用情况的优先级排序，以及应用组合的跟踪。
产品负责人负责对数据进行仲裁；他们并不承担数据收集的重任。

如果没有这一持续的毕业机制，平台就会陷入停滞。产品团队会不断重复发明相同的解决方案，监管规则仍将停留在局部层面，而系统的可靠性也会在暗中逐渐侵蚀。

运营合成

如今，我们已经具备了所有这些原则，接下来只需将它们转化为切实可行的规则。

谁来拥有什么？

每项能力都应有一个负责人（对结果负责），并且可以有多位贡献者（共同参与建设，但不承担相应的责任）。确立这一严格的边界是不可妥协的。

每项能力都有其负责人和贡献者。空置的单元表示“未参与”。具体事务由产品团队负责，系统性事务则由平台负责。

指导原则很简单：任何具体事务（动态上下文、产品级监管规则、领域知识）都留在Stream-aligned团队中，
因为业务拥有该领域的所有权。任何系统性事务（全局上下文、组织监管规则、核心工具）则由平台团队抽象化并维护。

AI编排器正是这一分工的完美例证：平台提供引擎（系统性工具），但产品团队负责驱动它（具体配置）。

一种信念

代理型平台回答了“什么”的问题。团队拓扑结构为“谁”和“如何”的设定提供了框架。
不要把这看作是僵化的分区，而应将其视为严格的责任分配：业务意图和领域上下文属于产品团队，
而生产可靠性则归属于平台。

其他组织模式当然会不断涌现。但若不清晰界定这些边界与互动关系，构建平台就难免会变成巨大的瓶颈。

这一模型并非现成的框架；它是一种思维模型，用于组织一支由多个团队组成的团队，
同时并行构建多个代理化应用。作为一种经验法则（而非绝对规则），一旦你拥有了三到五个产品团队，
重复发明解决方案（重新构建上下文、重写监管规则、修复局部不一致）的成本，
远远超过了投资于共享平台的代价。

应用于代理化工程，团队拓扑结构提供了一种结构，能够：

• 让业务团队以Stream-aligned团队的身份行动,而不必强迫他们学习如何编写代码。

• 确保系统性能力被抽象化并规模化,而非逐个项目地重新发明。

• 承认业务意图与生产现实之间的差距巨大,通过赋能团队来弥合这一差距——而非寄希望于奇迹。

• 将深层技术复杂度隔离到专门的子系统团队中，这些团队在后台为平台提供动力。

我们行业所发生的变化在于：生产一个应用不再需要编写代码。
相反，它需要掌握一套全新的技能：清晰表达意图、构建动态上下文、引导AI编排器。
而没有改变的是：在生产环境中，你仍然需要监管规则、一致性与可靠性来确保生存。

这又将我们带回最初提出的那个核心问题。
如今，软件工程师肩负着全部的“预期负担”，因为他们清楚地知道代理将无法提出哪些问题。
而明天，当平台以确定性的方式吸收这一负担时，技术门槛将急剧下降。
业务团队可以安全地部署软件，因为平台已经替他们预判了系统性风险。

应用生产者的转变（从软件工程师到业务专家）并非未来主义的假设。它是平台吸收预期负担后，直接且可衡量的必然结果。

开发者并不会消失。他们的角色向上游转移。他们不再单独构建应用：他们构建的是引擎，赋予其他人构建应用的能力。

来源

1.
马修·斯凯尔顿、曼努埃尔·派斯——《团队拓扑结构：为快速流动而组织业务与技术团队》，IT革命，2019年。
↩︎ ↩︎

2.
唐·罗伯茨，引自马丁·福勒——《重构：改进现有代码的设计》，阿迪森-韦斯利出版社，1999年。“三次打击，你就进行重构。”这一原则在这里从代码重构被移植到监管规则的毕业流程。
↩︎