核心发现
方法论
论文提出“生成—验证”策略发现循环：LLM根据系统提示、示例策略和历史反馈生成Python调度器；Eudoxia在固定工作负载上确定性执行；上下文管理器汇总吞吐量、p99延迟、错误及接口失败，再反馈给下一轮。算法1执行50次迭代，并保留中位吞吐量最高的策略。
关键结果
- 在Eudoxia生成的6条标准化轨迹上，相对FIFO基线，GPT5最佳策略吞吐量提升371.1%，Sonnet 4.5提升313.2%，Opus 4.1提升263.2%；GPT5-mini提升为0%。
- 三次独立运行取最佳结果：Sonnet成本4.587美元、2785秒；Opus成本37.27美元、2158秒；GPT5成本9.92美元、8292秒；结果显示性能、成本与耗时存在明显权衡。
- 实验并非泛化基准或模型排行榜，而是可行性验证。模型能力差异很大，说明可读代码加确定性模拟器能区分有效策略与语法或语义失败。
研究意义
研究把分布式系统策略设计从专家手写规则转化为可搜索的程序空间。它缓解了B2B云系统中客户差异大、人工调参昂贵、策略难以迁移的问题，并保留Python代码的可检查性。对学术界而言，这是将LLM推理、神经符号验证和系统模拟结合的具体范例；对工业界而言，模拟器可在真实部署前筛选候选调度器，降低实验风险。但收益依赖模拟器真实性，不能直接等同于线上性能。
技术贡献
技术核心不是训练新模型，而是定义模块化的LLM—模拟器接口。Policy generator负责代码采样与语法检查，Eudoxia负责确定性执行和可选安全监控，context manager负责结构化反馈与上下文压缩。输入输出契约允许替换模型、模拟器或反馈机制。策略以可执行Python文件记录，支持人工审查、异步调试和后续演化，形成比单次提示更稳定的搜索闭环。
新颖性
新颖性在于把已有的重复推理采样具体化为分布式调度器程序搜索，并把领域模拟器从开发工具改造成机器生成方案的验证器。相较仅用强化学习、监督学习或人工启发式的方法，该框架无需策略训练数据，也不直接控制生产系统；它通过代码可解释性和确定性轨迹实现低风险探索。
局限性
- Eudoxia只近似Bauplan，若资源竞争、尾延迟或故障模型不准确，模拟器中的371.1%吞吐量提升可能无法迁移到真实集群。
- 仅使用6条轨迹、50轮采样和吞吐量目标，未系统报告p99延迟、安全约束、跨客户泛化或统计置信区间。
- 成本和耗时差异显著，GPT5-mini未改进FIFO，说明采样质量、提示设计和预算仍是瓶颈。
未来方向
作者建议改进提示演化、上下文管理和细粒度日志利用，引入进化搜索及RL训练的小模型；同时增强模拟器的统计校准与现实代表性。更长远的方向是让AI协助构建新的模拟器，扩展至多租户、Lambda式Serverless和更复杂并发系统。
AI 总览摘要
云系统调度往往依赖专家编写规则：规则易解释，却难以适应不同客户、工作负载和资源规模。Bauplan这一面向数据的FaaS运行时尤其棘手，因为调度器必须在短交互查询与长批处理之间分配有限VM资源，同时遵守DAG依赖和延迟要求。
论文提出一个“重复LLM采样+确定性模拟器”的闭环。Policy generator生成Python策略，Eudoxia在固定轨迹上运行并计算吞吐量等指标，context manager把代码错误、运行日志和性能结果整理为下一轮提示。策略始终以可读文件保存，因此模型搜索并未牺牲人工审查能力。六条轨迹、每模型50轮实验中，GPT5相对FIFO最高提升371.1%，Sonnet 4.5提升313.2%，Opus 4.1提升263.2%，而GPT5-mini为0%。
结果证明的是方法可行性，而非线上性能或模型排名。GPT5耗时8292秒、成本9.92美元；Opus成本37.27美元但耗时2158秒，揭示价格、速度和质量的权衡。论文的关键警告是：模拟器若不能代表真实系统，优异分数可能只是仿真幻觉。未来需校准验证器、测试更多轨迹与指标，并探索AI自动构建模拟器。
深度分析
研究背景
传统分布式系统依赖人工启发式，如Kubernetes自动扩缩容；学习方法如FaaSRank和LAVA可优化部分参数，但通常仍在既定策略空间内搜索。Bauplan把SQL和数据管道统一表示为函数DAG，调度复杂性来自客户间资源差异、工作负载跨度和交互延迟要求。Eudoxia提供可重复的FaaS调度实验环境。
核心问题
目标是为Bauplan生成比FIFO更高吞吐量的调度策略，同时处理函数到达、资源池、抢占、依赖和失败。人工设计难扩展，真实部署又昂贵且风险高；单纯让LLM写代码还会产生语法错误、错误API调用和不可验证的性能承诺。
核心创新
第一，将LLM代码生成视为黑盒策略采样，而非一次性问答。第二，将Eudoxia作为确定性验证器，连接生成结果与可量化指标。第三，使用结构化上下文记录策略、分数、轨迹和错误，促使模型进行定向改进。第四，模块接口解耦LLM、生成器、模拟器和上下文管理器，便于替换。
方法详解
- �� 初始化：系统提示介绍Bauplan、Eudoxia和指标，用户提示要求从FIFO策略开始改进。
- �� 生成：LLM通过LiteLLM采样Python调度器，随后执行解析、语法和接口检查。
- �� 验证：合法策略在固定参数和6条轨迹上运行；Eudoxia模拟Generator、Scheduler、Executor循环。
- �� 反馈：收集吞吐量、p99延迟、失败DAG及错误日志，生成结构化反馈；可监控无超额分配和有界等待。
- �� 迭代：更新上下文，超过token限制时压缩；重复50轮，返回中位吞吐量最高策略。
实验设计
研究用Eudoxia API生成三组参数、每组两条不同随机种子的轨迹，共6条。基线是可运行且易解释的FIFO策略。比较Sonnet 4.5、Opus 4.1、GPT5和GPT5-mini；前两者temperature为0.7，后两者采用高推理强度。每模型进行三次独立实验，每次50轮，以六轨迹中位吞吐量选优，并记录LiteLLM成本和总时长。
结果分析
GPT5达到相对FIFO的371.1%提升，但耗时8292秒；Sonnet达到313.2%，成本最低，为4.587美元；Opus达到263.2%，耗时2158秒但成本37.27美元；GPT5-mini成本1.65美元、7669秒，却无提升。结果说明重复采样确有搜索能力，但模型质量并不随价格或推理时间单调增加。
应用场景
云平台可在部署前用历史轨迹筛选调度器，降低生产实验风险；FaaS、Serverless数据处理、批流混合任务和多资源池系统均可采用。前提是存在可信模拟器、清晰策略接口、代表性工作负载和安全监控。运营团队仍需人工审查代码并进行线上灰度验证。
局限与展望
当前验证器与真实Bauplan之间存在模型偏差，且实验规模小、只优化吞吐量，缺少延迟—成本—公平性的多目标分析。LLM还可能误解API、重复局部策略或耗费大量推理预算。后续应加入更多客户和故障场景，报告统计置信度，采用提示演化、进化搜索、小模型RL，并扩展到多租户Serverless系统。
通俗解读 非专业人士也能看懂
把云端调度想成一家外卖厨房。订单不断进来，有的顾客只等几分钟，有的订单要连续加工数小时；厨房只有有限灶台，不能让大订单堵住所有小订单。过去通常由厨师长手写排队规则。论文让一个会写程序的助手提出新菜单，再交给“厨房模拟器”反复试做。模拟器使用完全相同的订单记录，因此可以公平比较每种安排，告诉助手出餐量、等待时间和失败订单。助手看到结果后修改下一版菜单，循环50次。
关键是，助手不是直接控制真实厨房，而是在沙盒里实验；每份菜单都是人能读懂的Python代码。实验中，GPT5找到的方案比FIFO排队的吞吐量高371.1%，Sonnet 4.5高313.2%。但模拟厨房不一定等于真实厨房：如果它没模拟突发订单或设备故障，纸面上的好成绩可能不可靠。这项工作因此更像一台自动试菜机，而不是已经能独立管理云平台的机器人。
简单解释 像给14岁少年讲一样
想象学校食堂只有几位厨师，却同时收到几十个订单：有人只要一杯饮料，有人要做一大锅汤。如果按先来后到处理，长订单可能把所有人都堵住。论文研究的是怎样写出更聪明的排队规则，让更多任务更快完成。
研究者没有直接把AI放进真实云系统，而是先造了一个叫Eudoxia的“游戏地图”。AI每次写一段Python规则，模拟器就用同一批订单测试它，并告诉它完成了多少任务、有没有等太久、代码哪里出错。AI把这些反馈记住，再写下一版；这就是“生成—验证”循环。
他们测试了Sonnet 4.5、Opus 4.1、GPT5和GPT5-mini。GPT5找到的规则比最简单的FIFO规则高371.1%的吞吐量，Sonnet高313.2%，但GPT5-mini没有进步。注意，这不是说AI已经证明能让所有服务器快371.1%，因为测试只用了6条模拟轨迹。
真正有趣的是方法：先在安全的虚拟世界里让AI大量试错，再由人检查它写出的代码，最后才考虑真实部署。就像游戏里先练习新战术，而不是直接拿排位赛冒险。
术语表
Large Language Model（大语言模型，LLM）
能根据上下文生成文本或代码的模型。本文把它当作黑盒策略生成器，而不是重新训练一个调度模型。
LLM通过LiteLLM反复生成Eudoxia兼容的Python调度策略。
Function-as-a-Service（函数即服务，FaaS）
用户提交函数，平台按需分配计算资源并执行。调度器负责函数排队、资源分配、依赖和抢占。
Bauplan用FaaS统一执行SQL和数据管道。
Eudoxia
面向FaaS调度的确定性模拟器。它模拟任务到达、资源池、执行时间和完成状态。
作为LLM生成策略的验证器。
FIFO
First-In, First-Out，即先到先服务。它简单、透明，但不一定适合交互任务和长短任务混合。
实验中的基线策略。
Throughput（吞吐量）
单位时间内完成的任务量，是系统处理能力指标。本文按多条轨迹的中位吞吐量选择最佳策略。
主要优化目标，GPT5相对FIFO提升371.1%。
Generate-and-verify（生成—验证）
先生成候选程序，再用可重复执行的验证器检查正确性和性能。反馈会影响后续生成。
论文的核心搜索循环。
开放问题 这项研究留下的未解疑问
- 1 模拟器与真实集群之间的偏差如何量化？需要线上回放、统计校准和多场景验证，才能判断371.1%的提升能否迁移。
- 2 策略是否能跨客户、跨工作负载泛化仍未知。现有实验只有6条轨迹，尚未比较训练样式与未见场景。
- 3 吞吐量提升是否牺牲p99延迟、公平性或成本尚不清楚，需要多目标安全优化。
应用场景
近期应用
部署前调度器筛选
云平台团队可把历史任务轨迹输入Eudoxia，让多个LLM生成并比较Python调度器。需要稳定的模拟器、策略接口和安全监控；通过后再进行小流量灰度，而不是直接替换生产策略。
FaaS工作负载调优
数据湖、Serverless ETL和批流混合平台可针对不同客户生成专属策略，重点测试资源池分配、抢占和优先级。预期收益是减少人工规则维护，但必须同步检查延迟和失败率。
远期愿景
AI辅助构建系统模拟器
未来LLM可能从系统规范、日志和代码中协助生成新的模拟器，使同一方法扩展到多租户Lambda式平台。关键障碍是验证模拟器本身，避免模型在错误世界中自我优化。
原文摘要
We explore AI-driven distributed-systems policy design by combining stochastic code generation from large language models (LLMs) with deterministic verification in a domain-specific simulator. Using a Function-as-a-Service runtime (Bauplan) and its open-source simulator (Eudoxia) as a case study, we frame scheduler design as an iterative generate-and-verify loop: an LLM proposes a Python policy, the simulator evaluates it on standardized traces, and structured feedback steers subsequent generations. This setup preserves interpretability while enabling targeted search over a large design space. We detail the system architecture and report preliminary results on throughput improvements across multiple models. Beyond early gains, we discuss the limits of the current setup and outline next steps; in particular, we conjecture that AI will be crucial for scaling this methodology by helping to bootstrap new simulators.