如何构建确定性的云基础设施 RL 环境

AI 模型正越来越多地被要求设计、部署、保护并恢复生产级基础设施——而不只是编写能通过单元测试的函数。这一转变也改变了训练环境应有的形态。如今，仅仅检查输出“看起来是否正确”已经不够了。你需要一套黄金参考方案、一套确定性的验证测试，以及一组刻意制造缺陷的变体，用来准确探测模型在故障情境下的推理究竟会在哪里失效。

过去几个月，我一直在这个问题的另一端工作——根据结构化 rubric 评估 Agent 式编码输出、设计程序化验证检查，并记录 rubric 作者未曾考虑到的边界情况。在此之前，我花了七年时间构建和调试这类环境试图模拟的系统：采用行级安全策略的多租户 SaaS 平台、支撑高流量电商业务的 AWS 基础设施，以及处理数万并发请求的数据管道。本文要讨论的，正是这两类经验的交汇点：要构建一个可复现、评估公平且难以钻空子的基础设施 RL 环境，究竟需要做些什么。

黄金方案的质量取决于它容许多少歧义

构建任何评估环境时，第一个常见错误，都是对场景定义不足，却对解决方案规定过度。如果任务只说“部署一个容错的队列消费者”，却没有明确投递语义、重试策略，以及“容错”在实际运维中究竟意味着什么，那么最终得到的黄金方案只会是多个合理解释中的一种——而模型可能会因为做出了规范从未明确规定的决策而受到惩罚。

这与为编码评估编写 rubric 时遵循的是同一种原则：每一个含义模糊的术语，都会成为未来争议的来源。在实践中，这意味着，在编写任何一行基础设施代码之前，就要先定义：

• 范围内的确切故障模式（节点丢失、网络分区、消息重复、时钟偏移）

• 无论采用何种实现都必须成立的不变量（至少一次投递与恰好一次投递、幂等性保证、RTO/RPO 目标）

• 什么才算“已经恢复”——不能只看“服务已经启动”，还要确保状态一致

确定性验证意味着要针对非确定性进行设计

分布式系统本质上具有非确定性——而这恰恰是它们难以评估的原因。如果一套验证测试只是反复执行相同的 API 调用序列，然后对输出做 diff，那么一旦涉及重试、超时或最终一致性，它就会立刻产生不稳定且不公平的结果。

对我而言真正有效的模式，是验证不变量，而不是验证执行轨迹。最近，我在编写一套安全测试时也采用了这种方法：直接连接真实的 Postgres 实例来验证行级安全策略，而不是使用 mock。

# Anti-pattern: asserting on the exact sequence of events
assert events == [
    "consumer_started",
    "message_received",
    "message_processed",
    "ack_sent",
]

# Better: assert the invariant the system must uphold,
# regardless of retries, ordering, or timing
def test_no_duplicate_side_effects(env):
    env.inject_fault("redeliver_message", count=3)
    env.run_until_settled(timeout=30)
    assert env.side_effect_count("charge_customer") == 1
    assert env.final_state_is_consistent()

应当使用真实、可随时销毁的依赖实例进行测试——真实的队列、真实的 Postgres、真实的 IAM 策略引擎——而不是使用 mock。这样才能捕获一类 mock 从结构上就无法发现的缺陷：你所假设的契约，与实际得到的行为并不一致。我曾经定位过一些生产环境问题，比如某个依赖的小版本升级悄无声息地导致整个 monorepo 中的 TypeScript 类型退化为 never，以及一种只有在真实 API 限流条件下才能复现的 OAuth token 刷新边界问题。使用 mock 的测试套件会让这些问题轻易蒙混过关。同样的原则也适用于基础设施层，只不过每次失败带来的风险更高。

缺陷变体必须因为正确的原因而失败

刻意制造缺陷的变体，其目的不只是测试“模型能不能注意到出了问题”，而是测试“模型能不能正确诊断问题的原因”。如果一个 IAM 策略配置错误的变体碰巧还存在网络配置问题，那么模型学到的可能只是根据错误信号进行模式匹配。

要构建出高质量的缺陷变体，就必须把每个缺陷都当作一个独立、隔离的假设：

• 每个变体只包含一个故障。不要为了所谓的“效率”，把错误的重试策略和资源配置不足的 autoscaling group 塞进同一个场景。否则，你永远无法知道模型究竟对哪一个问题进行了真正的推理。

• 失败要明显到足以被观测，又要隐蔽到必须经过诊断才能定位。一个会让部署立刻崩溃的缺陷，只能算 smoke test，而不是评估。真正能检验推理能力的，是那种只在特定时序条件下悄无声息地破坏数据的缺陷——但它必须能够稳定复现，否则你评估的就只是运气。

• 记录预期的诊断路径。如果你无法预先写清楚一系列应当如何引导正确推理者找到根因的可观测性信号（日志、指标、链路追踪），那么这个变体就还没有准备好。

这些经验具体来自哪里

对我而言，以上内容都不是理论。下面是我在生产环境中的一些实际经历，它们可以直接映射到这类环境设计上：

• 编写并持续维护一套包含 14 项测试的安全测试套件，连接真实的 Postgres 数据库验证行级安全策略——这是“可复现环境优于 mock”原则的实际应用。

• 定位过一次悄无声息的依赖解析故障：某个小版本升级导致整个 monorepo 中的 TypeScript 类型退化为 never——这类缺陷非常值得被编码为训练场景，因为它既真实，又极难诊断。

• 为一个高流量电商平台构建并运维 AWS 基础设施（EC2、S3、Lambda），其中包括通过性能分析和查询优化将延迟降低 30% 的工作——这让我直接经历了这些环境试图模拟的可观测性与性能诊断闭环。

• 目前，我的专业工作是根据结构化 rubric 评估 Agent 式编码输出，包括设计 rubric、设计对抗性 prompt，以及判断哪些检查确实能够通过程序验证、哪些必须依赖人工判断——这正是设计“黄金参考方案 + 确定性测试”环境所需要的技能组合。

令人不太舒服的事实：大部分工作是在写文档，而不是写代码

对于一个优秀的 RL 环境来说，基础设施代码往往是相对容易的部分。真正困难的是文档：你必须足够精确地写清楚每个场景在测试什么、“正确”意味着什么、考虑过并排除了哪些边界情况，以及为什么排除它们，确保其他人能够复现你的推理过程。

这并不是一项附带任务。对于那些旨在训练生产系统推理能力的环境而言，文档就是黄金方案接受评估时所依据的规范。把文档当成事后补充，最终只会得到一个内部自相矛盾的环境，而且在模型利用其中的漏洞之前，可能根本没有人会注意到问题。

如果你正在构建或评估这一领域的环境，我很乐意与你交流经验——尤其是如何在避免测试不稳定的前提下验证分布式不变量，以及如何确保黄金方案如实面对规范中究竟有哪些部分真正不存在歧义。

如需采取进一步措施，你可以考虑屏蔽此人和/或举报滥用行为。