按开发者分配环境曾是目标，代理却改变了游戏规则。
内容提要
多租户架构正从按人隔离转向按变更隔离。传统平台按开发者分配环境，但编码代理使一人可并行处理多个变更，导致容量规划失效。文章主张以“变更”为租户单位，要求环境创建近乎免费、隔离范围仅限变更涉及的服务与数据、生命周期随变更启停。这样可应对代理规模的工作负载，避免资源浪费，并准确计量平台容量。
延伸解读
租户粒度演进的必然性
文章指出，多租户架构的租户粒度经历了从组织、团队到开发者的持续缩小，其背后假设是“一人同时只处理一个工作流”。编码代理的出现打破了这个假设，使得一个开发者可以并行运行多个代理会话，同时处理多个变更。因此，租户粒度必须进一步缩小到“变更”级别，才能适应代理驱动的工作负载。
变更级租户的三大要求
变更级租户要求环境创建近乎免费、隔离范围仅限变更涉及的服务与数据、生命周期随变更启停。文章强调，这些要求并非新概念，而是多租户生产系统早已遵循的规则。将这一套规则应用于开发平台，可以避免资源浪费，并准确计量平台容量。
容量规划的新基准
传统按席位（seat）规划容量已不再适用，因为代理产生的并发变更数量远超人头数。文章建议以“进行中的变更数”作为容量规划的新基准，例如统计最近一天内有活动的开放PR数量。同时，需要评估每个额外变更的边际成本，如果成本过高，说明平台仍停留在人员级租户模式。
代理不是合适的租户单位
虽然代理是新的工作单元，但文章明确指出，代理不是合适的租户单位。代理是可替换的，一个代理可以处理多个变更，多个代理也可以协作完成一个变更。如果按代理分配环境，就会重蹈“隔离工作者”的覆辙。真正需要隔离的是“工作”本身，即变更，因此变更才是稳定的租户单位。
Q&A
多租户架构中，租户单位经历了怎样的演变？
租户单位从大型机时代按组织划分，到虚拟化时代按团队划分，再到容器和Kubernetes时代按开发者划分，现在随着编码代理的出现，租户单位进一步缩小为按变更划分。
为什么编码代理的出现使得按开发者分配环境的方式不再适用？
因为一个开发者可以同时运行多个代理会话，产生多个并行的变更，每个变更都需要独立的环境。按开发者分配环境假设一个人同时只产生一个工作流，但代理打破了这一假设，导致容量规划失效。
为什么不能以代理作为新的租户单位？
因为代理是可互换的工人，多个代理可以协作完成一个变更，一个代理可以轮流处理多个变更，代理崩溃后可以被替换而不影响下游。如果给每个代理分配环境，就重复了按工人隔离的错误，而真正需要隔离的是工作本身。
以变更作为租户单位需要满足哪些要求？
需要满足三个要求：环境创建近乎免费；隔离范围仅限变更涉及的服务和数据；生命周期随变更的启动和结束而自动创建和销毁。
如何实现变更级租户的近乎免费的环境创建？
通过使用数据库分支技术（如Neon和Xata的写时复制分支）和只部署变更涉及的服务，使得创建租户的成本降低到一次部署，从而可以每天创建数百次。
平台团队如何衡量和规划容量以适应变更级租户？
应该统计高峰期的变更数量（例如最近一天有活动的开放PR），而不是座位数；同时评估增加一个并发变更的成本（时间和金钱）。如果成本是一个完整环境和数十分钟，说明平台仍停留在人员级租户。
为什么自动注销（offboarding）对变更级租户至关重要？
因为变更级租户数量大且创建销毁频繁，如果手动清理，孤儿环境会迅速积累，造成资源浪费。自动注销可以确保租户数量准确反映变更数量，使容量规划更准确。
