代理平台定义了需要提供的内容。团队拓扑定义了谁提供这些内容，以及团队如何互动以实现目标。在此系列文章的第一篇中，我们提出了什么的问题：需要哪些系统能力（上下文、保护绳、工具）来在规模上产生可靠的应用程序。答案是代理平台，核心是代理工厂：代理计划、编码、测试和交付的机制。但平台不会自己构建，更重要的是，使用的方式与构建的方式不一样。一个基本问题依然存在：谁做什么？真正的问题是：代理生产的认知负担。在问谁做什么之前，我们需要理解这个问题为何这次是不同的。构建应用程序过去意味着在时间上协调角色：一个人设计，另一个挑战架构，第三个测试，第四个部署。复杂性是真实的，但分布式的——跨越几个人，并且分散在时间上。每个角色轮流提出其问题。代理改变了这个方程式。它们不问问题：它们立即产生答案。它们永不疲倦，不会休息，不会等待。它们的速度是它们的优势，也是它们的陷阱。每个角色过去依次提出的问题，现在操控代理的人必须在短时间内提前预见，并行处理。在构建不当的情况下，代理不会减速：它快速产生，却偏离目标。认知负担并不会因人工智能而消失——它转变了。它首先变成一种预测负担：人类在启动代理之前必须预见的一切，否则输出将不达标。而且由于代理不断产生，没有人类节奏，它也成为认知处理问题：持续决策的流动。规模化的代理生产的真正挑战并不是复杂性增长——而是复杂性压缩到单个角色，置于他们无法单独承受的时间框架内。这正是平台所解决的问题。它通过使代理能够查询自己来吸收部分预测负担：“别担心安全问题”意味着代理会向平台询问如何进行，确定性的控制将在下游强制执行结果。平台并不消除思考——它缩小了人类必须承担的问题范围，让他们专注于真正重要的内容：人类判断依然不可替代的冲突性结构性决策。因此，认知负担不再仅仅是，正如斯凯尔顿和派斯所描述的，是要分配给团队的量。在代理世界中，它也是一个需要随时间调节的处理流量。团队拓扑告诉我们如何分配；我们仍然需要说出如何吸收。这正是本文的主题。团队拓扑，处理负担的答案。为了解决这个负担问题，我们借鉴了团队拓扑1，这是一种定义四种团队类型和三种互动模式的组织模型。这并非巧合：它的基本论点确实是认知负担——一个团队只有在没有超出其能够承受的复杂性的情况下，才能有效。斯凯尔顿和派斯推理结构负担，需要在团队间分配；我们将其扩展到上面描述的代理生产行为的动态负担。该模型为我们提供了分配可分配内容的网格，并识别平台必须吸收的内容。我们先声明我们的立场：接下来的是一种前瞻性的信念，这是我们认为代理进行应用生产所朝向的组织目标。问题不再是工厂需要什么，而是谁在运营它。这正是代理平台所做的：它吸收技术复杂性，以便业务团队只承担其领域的认知负担。开发人员的角色发生转变：他们构建可以让他人生产的平台。对称地，应用生产通过代理向业务团队开放。我们保留和适应的内容。将团队拓扑应用于代理上下文，需要明确我们的出发点。为了避免在声称其名称的同时削弱模型，以下是底线。我们保持不变的内容：认知负担的指导原则；四种团队类型；三种互动模式；成熟阶段从协作转变为即服务的转变。我们适应的内容及原因：流对齐团队可以是非技术性（业务）的，因为平台吸收技术负担；他们不承担端到端的运营责任（运行、事件），这些由平台吸收；使能不仅仅是短暂的：因生产者不再是开发人员，平台对其进行了结构性补偿；认知负担不再仅仅是要在团队间分配的量，而是需要随着时间调节的处理量：平台在代理生产之前吸收了预测负担。这些调整并不违背斯凯尔顿和派斯的意图：它们将其应用于他们未曾预见的上下文——即一个代理生产正在发生的环境。