服务扩展、存储与并发

扩展部署要同时考虑 runtime 数量、会话归属、状态位置和同一会话的并发访问。增加服务副本本身不会解决这些问题。

三种部署模式

模式	取舍
每用户独立 CLI	分离进程、身份与会话，资源成本更高；还需为状态目录和工具范围建立实际边界
共享 CLI、不同 session	资源较低，应用必须使用 empty 模式、会话身份和归属校验
多用户共享同一 session	适合协作，但要共同授权并串行化写入

旧 scaling 示例只使用 session 命名规则，部分表格把共享方式限制为 service token；较具体的 multi-tenancy 章节已明确支持会话级用户 token，并要求 mode: "empty"。本页按专门配置规则补全，不把旧简化例子当作完整服务器实现。

同一会话需要并发控制

SDK 不提供内置 session locking。多个用户或请求写同一会话时，应用必须串行化操作，可使用 Redis 等外部协调机制。

官方锁示例用于解释流程；产品实现还需保证锁归属判断与释放不会产生竞态，任务可能超出租约时需处理租约有效性。共享存储也不自动提供 session 写锁。

水平扩展

Sticky sessions 把同一用户路由到同一 CLI，部署简单，不必共享每台机器的会话文件，但负载可能不均。

共享存储 使其他 CLI 能恢复同一 session，便于重新路由；官方文件方案共享 ~/.copilot/session-state/ 或自定义根目录对应位置。使用应用存储时，可评估sessionFs。

不论哪种方式，都需要应用维护 session owner、选择 runtime，并在恢复前验证权限。SDK 没有内置负载均衡器。

活跃会话与持久状态

限制并发数量、释放不活跃会话、定期清理到期状态，可以减轻内存与磁盘压力。示例中的 50 并发是应用调优样例，不是 SDK 固定上限。

disconnect 可释放活动连接并保留可恢复状态；deleteSession 删除会话。命名会话与持久卷解决的是恢复需求，不应把 infiniteSessions 的上下文压缩设置当作存储或访问控制方案。

默认没有 idle timeout。由 SDK 启动 runtime 时设置 sessionIdleTimeoutSeconds；独立 headless 服务用 --session-idle-timeout <seconds>。具体保留时长由产品需求决定。

服务运行检查

监测活跃会话数、响应延迟与错误率，保持 runtime 健康检查；停止前排空在途会话。容器需持久状态时挂载对应目录，秘密信息使用部署平台的凭据管理。进程级隔离、用户身份和文件存储三者都要符合所选部署模式。