AstroReason-Bench：评估统一智能体规划在异构空间规划问题上的表现 AstroReason-Bench: Evaluating Unified Agentic Planning across Heterogeneous Space Planning Problems
首个评估LLM智能体在物理约束空间规划问题上能力的统一基准测试套件
前置知识
Agentic LLM
智能体大语言模型是指能够整合自然语言推理、规划、工具使用和迭代决策能力的大语言模型系统。与传统的静态问答模型不同，智能体LLM可以主动调用外部工具（如API、模拟器）、制定多步骤计划并根据执行反馈调整策略。本文评估的智能体采用ReAct范式，即在推理（Reasoning）和行动（Acting）之间循环迭代，通过Model Context Protocol（MCP）与环境交互。
本文的核心研究对象就是这类智能体，理解其工作原理是理解实验设计和结果分析的基础。
空间规划问题（SPP）
空间规划问题是一类涉及卫星任务调度的高风险优化问题家族，包括深空网络（DSN）通信调度、敏捷地球观测规划、立体成像、区域覆盖和延迟优化等子问题。这些问题共同具有异构目标函数、严格的物理和时间约束、大规模组合动作空间以及长时程决策等特点。历史上，每个子问题都由高度专业化的优化技术独立解决，如混合整数规划（MILP）、启发式搜索或强化学习。
SPP是本文基准测试的问题来源，理解其复杂性和异构性有助于理解为什么这是一个有挑战性的测试平台。
SGP4轨道传播模型
简化通用扰动4号模型（Simplified General Perturbations 4）是一种标准的解析轨道传播器，用于根据两行轨道根数（TLE）数据计算地球轨道物体的位置和速度。该模型考虑了地球非球形引力、大气阻力、太阳和月球引力摄动等因素。在本文中，SGP4为整个物理仿真引擎提供基础，确保轨道计算与真实世界数据的一致性。
SGP4是本文物理引擎的核心组件，所有可见性判断、资源约束计算都依赖于它提供的轨道状态。
Model Context Protocol（MCP）
模型上下文协议是本文为智能体设计的标准化交互接口，将环境状态暴露为人类可读的JSON摘要，优化了LLM的上下文窗口。MCP支持状态检查、动作暂存/取消暂存以及对约束违规的丰富语义反馈。它与Python API形成互补：MCP用于探索和交互调试，Python API用于批量计算和自定义启发式实现，解决LLM的算术限制问题。
MCP是连接智能体与物理引擎的桥梁，理解其设计有助于理解实验中智能体如何与环境交互。
混合整数线性规划（MILP）
混合整数线性规划是一类优化方法，其中部分决策变量被限制为整数值。在卫星调度中，MILP可以精确建模离散的调度决策（如某个时间段是否分配某颗卫星）和连续的资源约束（如能量、存储）。Δ-MILP是本文中SatNet基线使用的一种MILP变体，通过穷举组合优化实现最低的未满足率。
MILP是本文中表现最好的专业化求解器基线，与LLM智能体的对比凸显了零样本通用规划的局限性。
模拟退火（SA）
模拟退火是一种元启发式优化算法，在本文中作为Revisit Optimization等基准的基线。它将解表示为候选窗口上的二进制掩码，通过邻域生成操作（添加/删除/交换）探索解空间，并通过Metropolis准则以概率方式接受更差的解以逃离局部最优。SA在Revisit Optimization上取得了最佳性能（$M_{gap}=13.65$小时），通过迭代优化直接测量间隙统计的适应度函数实现。
SA基线展示了传统元启发式在特定问题上的优势，与LLM智能体形成对比。
研究动机
现有的智能体基准测试主要聚焦于符号化、基于文本或弱接地的环境，如网页导航、代码合成或合成游戏（如PlanBench、TravelPlanner、τ-bench）。这些测试环境抽象掉了硬物理约束、长时程规划需求和不可逆的可行性边界。以网页导航为例，点击错误按钮的后果是可逆的；但在空间规划中，一次错误的卫星调度可能导致能量耗尽或数据存储溢出，造成级联式的约束违规。现有基准中，像SatNet这样的单一问题评估缺乏统一接口，不同SPP子问题之间假设、接口和评估指标互不兼容。此外，现有的高保真模拟器（如STK、Basilisk）主要通过GUI或复杂脚本为人类专家设计，缺乏对自主智能体友好的标准化接口。
本文的目标是本文旨在引入AstroReason-Bench，这是首个用于评估智能体规划在空间规划问题上表现的综合基准套件。具体目标包括：（1）将多个代表性SPP子问题整合到统一的、面向智能体的交互和评估协议下；（2）提供标准化的智能体导向接口和指标，使跨异构SPP任务的一致评估成为可能；（3）对最先进的智能体LLM系统进行全面评估，揭示基于物理约束规划的关键局限性和开放挑战。该基准包含5个不同的规划挑战：SatNet（DSN调度）、重访优化、区域覆盖、立体成像和延迟优化。
与已有工作不同的是，本文的独特切入角度在于将空间规划问题视为一个统一的测试平台，用于评估通用规划器的适应性和鲁棒性。与现有工作不同，AstroReason-Bench不关注单一问题的最优解，而是评估单个智能体系统是否能在多个结构多样的规划环境中自适应其推理和工具使用。这种视角揭示了一个关键发现：智能体的优势不在于原始优化能力，而在于零样本识别和适应新问题结构的能力。通过程序化数据生成确保多样性和物理有效性，包括从40,000+城市数据库采样地面目标、使用存档TLE数据子采样10-100颗卫星、固定的4天规划时程（2025-07-17T12:00:00至2025-07-21T12:00:00）以最小化传播误差。
核心方法
AstroReason-Bench的整体架构采用四层设计，从底层物理引擎到顶层认知层，形成一个完整的智能体评估框架。物理层（Layer 1）是无状态的，集成SGP4轨道传播、姿态动力学的梯形速度模型和资源建模（能量、存储），作为环境的物理定律。场景管理层（Layer 2）是有状态的会话控制器，维护库存数据库（只读注册表）、动作注册表（可变时间线）和文件支持的状态持久化机制（带咨询锁的原子更新）。接口抽象层（Layer 3）提供两种互补的交互模态：语义MCP用于探索和调试，Python API用于批量计算。认知层（Layer 4）是被评估的智能体，采用标准ReAct循环通过Claude Code实现。
本文的核心创新在于建立了一个统一的、面向智能体的交互协议，将原本孤立的、接口不兼容的多个空间规划子问题整合到单一基准下。与传统方法（每个问题使用专用算法）不同，本文允许单个智能体通过标准化工具接口处理所有问题。这种设计的关键优势是能够评估智能体的零样本适应能力：智能体必须从问题描述中理解约束结构，选择合适的工具组合，并制定有效的调度策略，而无需问题特定的训练。此外，Python API与MCP的双模态设计是一个重要创新——MCP提供语义友好的JSON摘要用于探索，Python API允许智能体编写脚本进行算术密集型计算，克服了LLM在精确数值计算上的固有局限。
方法步骤详情
方法的具体实施步骤如下：首先，程序化数据生成阶段采样特定星座原型（如QIANFAN用于通信、SPOT/PLEIADES混合用于立体成像），从这些家族中使用存档TLE数据子采样10-100颗卫星。地面目标从40,000+城市全局数据库中采样，并基于所选星座的平均倾角动态过滤以确保可行性。所有场景跨越固定的4天规划时程。其次，环境构建阶段实现四层架构：物理层使用SGP4模型计算轨道状态和可见性窗口，场景管理层维护状态和动作，接口层暴露MCP工具和Python API。最后，评估阶段在150个完整任务模拟中运行6个前沿LLM智能体（Claude Sonnet 4.5、Gemini 3 Flash、DeepSeek V3.2等），每个模拟限时2小时，限制16GB内存和8个CPU核心。
技术新颖性
本文的技术新颖性体现在多个方面。第一，AstroReason-Bench是首个将多个异构空间规划问题统一到单一智能体评估框架下的基准，之前的SatNet等基准都是孤立设计的。第二，四层架构设计（物理层、场景层、接口层、认知层）将无状态物理计算与有状态会话管理解耦，同时通过原子更新和咨询锁确保并发一致性。第三，MCP+Python API的双模态接口创新性地解决了LLM的两个核心局限：语义理解（通过MCP）和精确计算（通过Python API）。第四，程序化数据生成方法通过控制资源-请求比率（如重访优化约4:1卫星-目标比，立体成像约1:1）来调节难度，确保场景多样性和物理有效性。第五，定性案例研究方法（如RAG增强规划、干预实验）超越了单纯的指标比较，深入分析了智能体的认知失败模式。
实验结果
实验在150个完整任务模拟上评估了6个前沿LLM智能体，揭示了一个清晰的模式。在SatNet（DSN调度）上，所有LLM智能体的$U_{rms}$得分在0.53-0.59之间，显著优于未加权/随机基线（约0.87-0.89），但远落后于Δ-MILP（0.30）和RL PPO（0.32）。在重访优化上，模拟退火取得最佳性能（$M_{gap}=13.65$小时），Claude Sonnet 4.5在智能体中领先（$M_{gap}=18.83$小时），同时保持完整的映射覆盖（$M_{map}=1.00$）。区域覆盖对所有方法都极具挑战性，最佳智能体（Gemini 3 Flash）仅实现11%覆盖率。立体成像中，所有基线实现0%覆盖，而LLM智能体最高达到18%（Qwen3 Coder）。延迟优化是最苛刻的基准，几乎所有智能体在连接覆盖率上完全失败（$M_{avail}=0$），只有Kat Coder Pro例外地实现了$M_{avail}=0.07$和$M_{lat}=58.4$ms。这些结果表明，智能体在需要穷举组合搜索的问题上不如专用求解器，但在基线完全失败的问题上能取得适度但非平凡的成功。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| SatNet（深空网络调度） | Umax（最大未满足率）和Urms（均方根未满足率） | 最佳智能体Gemini 3 Flash: Umax=1.00, Urms=0.53 | Δ-MILP: Umax=0.67, Urms=0.30; RL PPO: Umax=0.77, Urms=0.32 | 相比简单启发式（Urms约0.87-0.89）显著改善，但落后于专用优化器约43%（0.53 vs 0.30） |
| 重访优化 | Mmap（映射目标覆盖率）和Mgap（平均重访间隙，小时） | Claude Sonnet 4.5: Mmap=1.00, Mgap=18.83h | 模拟退火: Mmap=1.00, Mgap=13.65h | 保持完整映射覆盖，但重访间隙比SA长约38%（18.83 vs 13.65小时） |
| 区域覆盖 | Mcov（多边形覆盖率） | Gemini 3 Flash: Mcov=0.11 | 模拟退火: Mcov=0.03; 贪心启发式: Mcov=0.00 | 比SA提升约267%（11% vs 3%），但整体覆盖率仍然很低 |
| 立体成像 | Mcov（立体对覆盖率） | Qwen3 Coder: Mcov=0.18 | 贪心启发式: Mcov=0.00; 模拟退火: Mcov=0.00 | 从基线0%提升到18%，展示了处理复合约束的能力 |
| 延迟优化 | Mmap（映射覆盖率）、Mavail（可用性）和Mlat（平均延迟，ms） | Kat Coder Pro: Mmap=0.18, Mavail=0.07, Mlat=58.4ms | 贪心启发式: Mmap=0.01, Mavail=0.00; SA: Mmap=0.30, Mavail=0.00 | 唯一实现非零可用性的智能体，但连接覆盖率极低 |
局限与改进
作者承认的局限性包括：（1）评估聚焦于Flash类模型和标准ReAct脚手架，可能代表性能下界；更大推理模型（如Gemini 3 Pro或Claude Opus 4.5）和更复杂的智能体工作流可能产生更好结果。（2）LLM工具使用的随机性和每个任务场景数量有限意味着报告的平均值可能未完全捕获工作流固有的方差。（3）通用智能体与专用优化器之间的比较不是计算匹配的——专用求解器受益于大量离线训练，而智能体在固定在线交互预算下运行。（4）基准范围集中在操作调度和资源管理，未扩展到架构系统设计和深空轨迹规划。我的观察还包括：（5）所有基准中智能体的性能方差较大，2小时超时可能不足以让智能体充分探索解空间。（6）Python API与MCP的切换策略未充分优化，智能体往往倾向于从记忆推理而非主动探索环境。（7）程序化数据生成虽然确保了物理有效性，但可能未充分代表真实任务的复杂性和不可预见的约束交互。
独立分析的弱点
本文存在几个值得深入分析的弱点。第一，探索-利用差距问题：智能体表现出强烈的行动偏好，倾向于在不充分探索环境的情况下立即采取行动。在区域覆盖案例中，Claude Sonnet 4.5在查询卫星和地面站后立即注册了5个随机方向的条带，而没有首先查询卫星地面轨迹以理解星座几何。改进方向包括设计强制探索阶段的智能体架构，或在提示中明确要求先查询可用工具。第二，空间推理能力不足：在延迟优化中，几乎所有智能体都试图寻找同时对两个地面站可见的单颗卫星，而忽视了地球曲率使这在几何上不可能。这表明LLM缺乏必要的物理直觉，可以通过引入空间推理模块或物理约束检查器来改进。第三，资源生命周期管理薄弱：贪心基线在重访优化中的$M_{map}$仅为0.32，因为它未能平衡数据获取与下行容量，导致存储耗尽。智能体也表现出类似问题，表明需要更明确的资源管理策略。第四，RAG增强效果依赖工作流：在SatNet实验中，默认模式下注入学术论文反而降低性能（成为噪声），只有在计划模式下才能有效利用知识。这表明单纯提供知识不足，需要结构化的工作流来消费它。
未来方向
作者提出的未来方向包括：（1）将基准扩展到架构系统设计和深空轨迹规划，创建更全面的自主空间系统工程套件。（2）增加情节数量和正式置信区间，更好地表征性能稳定性。（3）评估更大推理密集型模型和更复杂智能体工作流。基于本文成果可延伸的方向包括：（4）开发专门针对空间规划的智能体训练方法，利用基准生成的多样化场景进行微调或强化学习。（5）设计混合架构，将LLM的高层推理能力与专用求解器的精确优化能力结合。（6）实现自适应工具选择机制，让智能体根据问题特征动态选择MCP或Python API。（7）引入多智能体协作框架，允许专门化智能体处理不同子问题（如一个负责轨道计算，一个负责调度优化）。（8）开发物理约束感知的提示工程方法，将关键约束（如能量守恒、存储容量）显式编码到提示中。
复现评估
本文在可复现性方面做了较好准备。代码和数据集将在文档化的上游许可证下发布，GitHub仓库地址为https://github.com/Mtrya/astro-reason。基准使用程序化生成的场景和公开可用的TLE数据，不包含个人身份信息或敏感地理属性。评估设置明确：150个模拟、6个模型、每案例2小时超时、16GB内存和8个CPU核心（AMD Ryzen 7 9700X）。然而，复现面临一些挑战：（1）需要访问多个商业LLM API（Claude、Gemini、DeepSeek等），成本可能较高。（2）物理引擎和场景生成器的完整实现细节未在论文中完全展开，需要依赖开源代码。（3）基线算法的超参数和启发式未针对个别基准精心调优，实现也未针对高通量计算优化。（4）每个基线运行限制在约20分钟，而先前工作中MILP解决方案需要约20小时优化，这使得基线比较不完全公平。总体而言，复现难度中等偏高，主要障碍是API成本和物理引擎复杂性。
论文图表