MXC 将工作负载意图与运行工作负载的平台机制分开。 主机应用使用 .NET、TypeScript 或 Rust SDK 来描述资源权限和请求执行。 MXC 将请求转换为当前主机上容器后端的操作。
此设计为应用提供了一致的集成接口面，并不意味着每个后端都提供相同的功能或隔离属性。
体系结构层
MXC 集成有四个主要层：
| 层 | 责任 |
|---|---|
| 主机应用或代理运行时 | 对任务进行分类，选择受信任的策略默认值，提供输入，并处理输出和审批 |
| MXC SDK 和策略协定 | 检测支持情况，将工作负荷意向转换为经过版本控制的配置，启动沙盒，并公开生命周期和诊断信息 |
| MXC 执行层 | 验证配置、解析后端并将支持的协定转换为平台操作 |
| 包含后端 | 创建执行环境并强制实施平台和后端支持的策略功能 |
主机应用仍负责策略决策。 编码代理可以建议模型或资源授予，但如果没有受信任的逻辑或人工批准，它不得选择或扩展自己的权限。 主机在 MXC 外部运行的代码仍位于工作负载的隔离范围之外。
策略、配置和运行时设置
该策略描述了工作负荷可以访问的内容。 执行请求将添加要运行的内容、运行位置以及要使用的隔离环境。 运行时设置提供执行所需的值，例如已运行的代理的终结点。
V1 SDK 将这些设置放入一个 ContainerRequest 中。 其文件系统、网络和 UI 属性描述访问，以及其命令、工作目录、环境、超时和包含属性描述执行。 SDK 将请求转换为稳定的 1.0.0 架构协定，因此无需指定架构版本。
JSON 执行配置不能与序列化的 SDK 对象互换。 例如，请求的 ui.allowInputInjection 和 timeoutMs 属性对应于配置的 ui.injection 和 process.timeout 设置。 使用 SDK 类型或你创作的配置版本的架构。
一次性和状态感知生命周期
MXC 支持两种生命周期模式。
一次性执行 创建沙盒，运行一个工作负荷，并销毁沙盒。 将其用于独立的编码代理工具、生成的命令、构建、测试和脚本。 为每个操作使用新的受限沙盒可以限制保留状态，并减轻创建单一宽泛策略的压力。
状态感知执行包括五个阶段：预配、启动、执行、停止和取消预配。 预配将返回一个不透明的 ContainerId，调用方将其原样传递给后续阶段，并且调用方可以在拆解之前执行多个命令。 仅当工作负荷依赖于持久性状态（例如代理配置文件、已安装的工具、配置或操作系统环境）时，才使用此模式。 在 MXC 1.0 中，V1 SDK 生命周期 API 支持 IsolationSession 和 WSLc。
状态感知执行不会使 MXC 成为状态所有者。 后端拥有沙盒资源，调用方存储其标识符并管理其生命周期。 停止执行和取消预配资源是不同的操作；具体哪个状态能在停止后得以保留，取决于后端。
运行、派生和 PTY 执行 描述主机如何与正在运行的进程交互，而不是环境存在多长时间。 执行完成后，运行调用将返回捕获的输出。 spawn 调用可在工作负荷运行期间为主机提供实时的标准输入、输出和错误流。 PTY 调用将工作负荷连接到由主机控制（包括其大小）的伪终端。 检查所选 SDK 和后端支持的组合。
主持人职责
设置执行超时并单独处理工作负荷失败、启动失败和取消。 取消 SDK 等待不一定与终止工作负荷相同。 遵循 SDK 的终止和处置协定，并完成所需的等待时间，以便执行和可选的拒绝结果捕获最终完成。
对于状态感知执行，即使后续阶段失败，也要安排清理。 停止失败不应阻止尝试取消预配应用拥有的资源。
沙盒销毁通常不会撤消对已授予权限的主机目录的写入，或通过允许的网络服务执行的操作。 审慎地选择输出位置，并决定在后续任务使用结果之前保留哪些结果。
选择容器类型
从工作负载的目标和约束开始，例如：
| 工作负荷需求 | 起始类型 | 为什么 |
|---|---|---|
| 需要所选主机工具和路径且启动成本低的命令 | 进程隔离 | 在紧邻主机环境的位置运行，且权限范围仅限该任务 |
| 需要单独Windows配置文件或交互式会话的工作负荷 | 会话隔离 | 将工作负荷的用户和会话状态与交互式用户环境分开，且不进行 MXC 文件、网络或 UI 筛选 |
| 需要单独的内核或来宾操作环境的工作负荷 | 虚拟化环境 | 使用 VM 或微 VM 边界，受所选后端功能的约束 |
在 Windows 上，进程隔离是一种常见类型，因为它适用于许多需要部分主机资源且启动成本低的工作负荷。
会话隔离分隔用户和会话，但它不会限制工作负荷可以访问的内容。 在 Windows 上，IsolationSession 拒绝使用文件系统和 UI 策略。 其请求还必须将出口、入口和主机环回设置为 allow，且不包含网络规则或代理。 如果工作负荷需要这些限制，请选择可以强制实施这些限制的后端。 有关详细信息，请参阅 后端选择和设置。
抽象意图（例如 process）可让 MXC 解析特定于平台的后端。 如果需要特定的操作环境或生命周期，请选择具体的后端。 请注意，无论是抽象意图还是更强大的隔离机制，都无法保证支持每一项文件、网络或 UI 控制。
有关选择指南和指向详细后端文档的链接，请参阅 MXC 包含选项和平台支持。
体系结构中的学习模式
学习模式有助于 Windows ProcessContainer 工作负载的策略编写和诊断。 请参阅 使用学习模式创建和优化 MXC 策略。
编码代理的设计指南
使用编码代理帮助选择包含类型时，请要求其评估：
- 应用必须支持哪些操作系统和处理器体系结构？
- 工作负载需要哪些文件、网络路径、用户界面功能、设备和主机工具？
- 每个命令是独立的，还是必须在命令之间保留标识和状态？
- 哪些启动时间、资源使用、部署和交互约束适用？
- 工作负荷是否需要Windows、Linux、完整桌面或其他操作环境？
- 哪个隔离边界适用于工作负荷的信任假设和数据？
- 每个可用后端可以强制实施哪些请求的策略功能？
智能体应比较可行的包含类型，说明其假设和权衡，并确定不受支持的需求。 然后，可以选择适当的包含类型并生成策略。
