上一篇停在出发搬钛之前。母星已经能生产红糖，机甲也研究完了飞出母星所需的升级，接下来得让伊卡洛斯真的离开地面，到另一颗星球上找矿，再带着材料回来。
这篇回顾 9 月 1 日的首次航行，接着写黄糖（结构矩阵）、行星物流和星际物流，直到 9 月 5 日发布 v0.3.3。下面的航行和运输都在同一个恒星系统内。长期推进的仍是同一个存档；等物流跑通、做出发行包之后，才另外用独立新档验证普通 Agent 能不能接手。
工具名继续省略 spherewright_ 前缀。下面把新增入口、已有工具的参数或行为修正，以及 MCP 资源分别记清楚，便于把每次工程改动和游戏里遇到的问题对上。
飞出去之后，先别急着对准目的地
第一趟出发前，先通过游戏的正常保存流程建立了独立检查点。飞行出问题时，只能恢复这一次出发前的同一个世界。
为这趟出发补上的工具分成三部分：
get_local_star_system提供同星系的星球身份、距离和按主题推断的潜在资源，供 Agent 选择目标；它不提前生成或读取未访问星球的工厂。prepare_interplanetary_flight/commit_interplanetary_flight负责一趟航行。准备阶段检查目标、驱动升级、能量与燃料，提交后先建立检查点，再走原生起飞、航行和着陆流程。prepare_reload_flight_checkpoint/commit_reload_flight_checkpoint负责失败后的恢复，只认这次飞行绑定的检查点。重试可以回到相同起点，不会另开世界，也不用让 Agent 指定保存文件。
真正起飞时，先碰到的是飞行状态切换。地表飞行和太空航行是不同阶段，要满足游戏原本的高度、速度和推进器条件。进入航行状态以后，也不能立刻把方向指向目的星球。
因为目的地可能在母星的另一侧。第一版这样转向，伊卡洛斯反而朝母星表面落回去了。
后来把离场单独做成一段：先向外飞，必要时沿切向绕开母星，确认直线路径不再穿过身后的星球，再转向目的地。结构化读数里，离地高度从一百多米增长到三百多、四百多米，随后离开本地星球，目的地距离才开始持续下降。
落到钛星上以后，又回到了地表移动。钛矿离落点还有两百多米，路线拆成沿球面的短段，每段走完都等速度稳定，再继续下一段。最后在矿点附近正常采到 1000 个钛矿，矿脉减少和背包增加相互对应。为了返航，还得另找煤矿补燃料。
返程更折腾。早期的着陆判断把某一帧出现步行状态当成了成功，实际复读时，伊卡洛斯仍有速度；五秒之后又变成漂浮状态，燃料继续下降。这次“到家了”必须撤回，重新从返航检查点开始。
最后把完成条件改成连续 600 个游戏 tick，也就是正常速度下约十秒：一直处在目标星球、一直是步行状态，而且速度足够低。中间只要重新漂浮或加速，稳定计时就清零。修复后的返航通过了这个窗口，随后又连续复读位置、速度和能量，才正常保存带回 1000 钛矿的母星主档。
离场绕行和稳定着陆，改的都是 commit_interplanetary_flight 后面的执行状态机：把离开母星、巡航、减速和落地等待分开处理，再把实际终态交给 get_action_result。Agent 仍然只提交一个目标星球；Plugin 必须持续证明这趟飞行已经完成，瞬间出现一次步行状态还不够。
这趟终于证明了 Agent 能跨星球取资源。运输工作还全压在伊卡洛斯身上。
钛带回来了，黄糖还隔着一串工厂
钛矿要先冶炼成钛块。黄糖需要的钛晶石，还要用到有机晶体；有机晶体又要吃塑料、精炼油和水。另一条线从高能石墨加工出金刚石，最后才一起送进研究站。
于是回到母星之后，又开始补化工、抽水和冶炼。能提前准备的空设备、仓库和分拣器先建好，多种原料共用仓库时先把过滤配齐；配方还没解锁，就等正常科研完成，再启用生产。
上一篇留下的红糖供料也在这时补上。红糖输出仓到科研区铺了 196 格传送带，沿途分段施工，末端再用分拣器送进研究站。读到红糖真正进入科研缓冲、高分子化工研究开始推进，才把这条长线算作接通。
研究过程中，炼油又停过几次。这次缺的不是原油：精炼油仓满了，精炼厂排不出共同产物，氢也跟着停产，红糖和下游研究便一起停下来。通过正常转移把油送去有机晶体备料仓或新的缓冲仓，给输出腾出位置，精炼、红糖和科研才恢复。
这种腾位能解燃眉之急，但仓库仍然会满。后面还得把精炼油接到持续消耗它的下游。
等结构矩阵科技正常完成，预建的黄糖研究站才启用配方。备料仓里的钛晶石和金刚石各从 40 降到 23，输出仓的黄糖从 7 增加到 10，Journal 记录了首次产线产出，随后正常保存。
这个阶段完成的是黄糖的最后转换段。钛来自刚才的跨星球搬运，投入研究站的两种成品原料也还经过了玩家中转。只要这一批用完，就得继续补。
存档能恢复，记录也要接得上
9 月 1 日，第一条黄糖转换线完成之后，先补了一次保存和恢复机制的修复。成功返航后，旧飞行检查点不能一直保留回档能力，否则几小时之后还可能把新进度退回起飞前。修复后，稳定落地先撤销恢复入口，主档保存覆盖这次飞行后再持久化退役状态。
逐存档 Journal 也有类似的问题：事件已经进了内存，不等于它已经写进磁盘。接口开始分别报告已落盘的记录序号、是否还有记录等待写入，以及写入错误，保存里程碑时也要检查这些状态。否则游戏进度留下了，下次接手时却可能找不到刚才发生过什么。
正常重启则只载入恢复票据绑定的那份精确主档，不去猜哪个自动存档更新。票据用过之后还要留下持久记录，避免文件清理失败时，旧票据又被拿来恢复一次。保存、日志和下次接手，到这里才有了各自明确的检查条件。
对应到接口上：检查点的生命周期改在 prepare_reload_flight_checkpoint / commit_reload_flight_checkpoint 的可用条件里，并联动 get_session_state 的恢复能力和 commit_save 的收尾；正常重启走的是 prepare_resume_owned_game / commit_resume_owned_game；Journal 的落盘状态由 get_gameplay_journal 补出的 durableThroughSequence、persistencePending 和 persistenceError 三个字段报告。问题不只在游戏会倒退：Journal 已经记下后续事件，旧检查点却可能把工厂退回过去，两份时间线就分开了，所以失败重试与成功后的旧票据必须有不同的生命周期。
研究在推进，准备却一直过期
要把搬运交给物流系统，还得继续生产处理器、石墨烯、推进器、粒子容器、物流运输机和站体。每解锁一层，就补一层上游，有些旧蓝糖线路也在这个过程中反复暴露缺料。
9 月 2 日推进粒子磁力阱研究时，准备追加科研队列却连续遇到 81 次“状态过期”：一次常规准备，加上 80 次有界重试，全都在提交前被拒绝，没有生成动作，也没有发生写入。游戏里的研究还在自然推进，每次校验却把刚增加的科研进度当成了计划失效。
这里真正要守住的是队列、当前科技、解锁、等级和前置条件。修复后，队列选择只校验这些相关状态，排除自然增长的已上传科研进度，追加操作才得以继续。会变化的数据都是真的，但并不是每一项变化都应该让这次操作作废。
具体实现是返回值增加 selectionStateHash：get_progression_state 仍报告完整进度，prepare_select_research 的参数则从 expectedProgressionStateHash 改为 expectedSelectionStateHash，只绑定当前科技、队列、解锁与前置条件，排除每 tick 增长的上传进度。完整进度仍可观察，真正换了队列或解锁状态也仍会使计划失效。
同一阶段，背包里的蓝糖还从 293 个变成了 42 个，少了整整 251 个。后来顺着机甲科研缓冲查下去，才发现自动管理研究已把它们收进 MechaLab，仍在等待消耗。只看背包，就会把这批待用材料误记成丢失或已消耗。
这次扩展的是已有 get_player_state 的只读返回：新增 mechaResearchItemBuffer，并同时报告 autoManageResearchItems 和 mechaResearchPower。缓冲项给出原生点数、可折算的完整物品数和余数，让背包里的 42 个与缓冲里的 251 个能一起核账。
先让两座行星物流站互相送一次货
两座行星物流站是在母星上先做的练习。一座设供应，一座设需求，站体通过正常施工完成，接电充能，再把正常生产出来的运输机装进去。
物流塔先补观察，再补配置。已有的 list_factory_entities 增加 componentKind=station 的详细读取，inspect_factory_entity 增加 logisticsStation 数据，能看到仓储槽、供需、库存、机队、订单、端口和能量。配置仍走 prepare_configure_building / commit_configure_building，新增 logistics-station-storage 模式，选择物品、数量上限和本地／远程供需。这样同一栋建筑的普通信息和物流状态能一起核对，配置过程也能明确证明没有改写库存。
装运输机和运输船则新增了 prepare_logistics_station_fleet_transfer / commit_logistics_station_fleet_transfer。它们检查玩家背包与塔内空闲机队，提交后核对两边数量一增一减、在途机队保持原样。塔内运输机是独立的机队计数，不能把它当普通仓库货格来处理，更不能直接填一个数量就声称装好了。
源端接入了 120 个钛块，需求端的目标是 100 个。随后能读到真实订单和无人机工作状态，四批各 25 个钛块送达；最终需求塔有 100 个，供应塔剩 20 个，源仓清空，无人机归队，订单归零，再保存。
这期间还修过“塔建好了却读不出来”：原生行星物流站会用 planetId=0 表示本地站，旧校验把它误判成外星实体。修复是在观察、配置和机队转移等入口共用身份判断：本地站接受这个哨兵值或当前星球，星际站继续要求精确星球身份。否则后续工具都拿不到合法的操作对象。
这比“塔里装了无人机”多证明了一件事：货物确实经过游戏自己的调度，到达了另一座塔。
第二趟去建矿场
第二次资源航行开始在钛星上留下能工作的设备。缺的矿机、风机、仓库和输送部件，用本地采来的材料加上随身铜，按正常配方手搓。第一条钛矿线接通后，仓里的钛矿从 6 增长到 26。
硅矿机还被我挑了一次摆放问题：明明周围有更多矿点，它却只覆盖了两个。
原因是选址逻辑找到第一个合法姿态就结束了。合法只是能建，并不代表这个角度合适。后来改为比较候选姿态中的矿点覆盖，再通过正常拆除回收、重建，覆盖从两个节点增加到四个。硅矿也开始持续进入仓库。
对应有两处改动：prepare_build 对矿机候选姿态按覆盖矿点数优先选择；另外新增 prepare_dismantle / commit_dismantle，只处理已经完成的资源矿机。拆之前检查精确实体、距离和背包容量，拆之后证明原实体消失，建筑与内部货物正常回到背包。把范围先限在矿机，是因为这次需要的是把摆差了的矿机回收重建，拆除其他建筑还需要各自的回收与连接证据。
这一趟返航带回了 1100 钛矿和 651 硅矿。落点在母星海面上，漂浮状态又暴露了一个新问题：已经抵达目标星球，只是还没上岸。修复后先找附近干燥地形，再下达正常移动订单，上岸后继续等稳定窗口。
把黄糖接进科研，再准备星际物流
9 月 3 日返航后，先补的是母星内部的黄糖配送。原先把黄糖单独送进一座研究站，研究并不推进：这项科技要求的蓝、红、黄三种矩阵，得在同一座科研站里凑齐。于是从黄糖输出仓铺了 35 格传送带，接到已有蓝糖、红糖供料的科研站。三种矩阵同时进入科研缓冲之后，研究才继续往前走。
接着把行星物流需求塔接入钛晶石产线时，又踩了一个出料索引问题。传送带已经从塔上接出来，钛块却不往外走。查 UI 和底层字段之后才知道，端口方向和输出货物是两项配置。内部选择值 0 表示没有选货，第一个仓储槽对应的值实际是 1。修正映射后，钛块才沿带流进钛晶石产线。
这里扩展的是配置工具的 logistics-station-belt 模式，并增加 stationBeltSlotIndex 和 stationBeltStorageIndex 参数，分别指明塔端口和供货槽。接口使用从零开始的槽号，由 Plugin 转成原生选择值；提交前检查端口已连接、没有携货且还未选货，再复读选择结果。这样 Agent 不必猜底层索引，配置也不会在已有货流的中途把端口悄悄换成另一种物品。
对着 UI 点一次很容易，接成接口时就得把这些状态逐个拆清楚。
随后又铺了 86 格钛晶石支线和 94 格金刚石支线，把两种原料从各自的输出仓送到黄糖设备。沿途取放和目标库存的变化证明本地输送接通了，但源仓里的存量仍然有限，金刚石设备当时还因缺石墨停着。此时减少的是伊卡洛斯在母星上的中转，上游持续供料还得接着补。
接着才准备两座星际物流站和两艘运输船。核对完整配方时，还发现钛合金预算漏算了加力推进器，把总数从 100 补到了 120。站和船都得经过原料、加工、输出仓这条路径，没有哪一步能直接生成成品。
把塔和船也带过去
安装远端星际站的那趟飞行，又碰上了挡在路线中间的气态巨行星。前两次直飞被它捕获，只能回到同一个飞前检查点。控制器补上中间天体的绕行之后，才稳定抵达。
物流塔的充电负载也远大于早期矿场。母星建塔充电时，电网供电比例一度只剩约 20%；远端几台风机更撑不住。把充电上限调到当时原生允许的最低值，再逐台补风机、检查矿机和分拣器实际供电，站内库存才开始增长。
这里用到配置工具新增的 logistics-station-charge 模式和 stationMaximumChargePowerWatts 参数。首次做行星站充电配置时，还曾把实时充电请求误当成设定上限，塔一充电，配置哈希就不断变化。后来在读取和哈希里分开这两个值，修改只按游戏 UI 允许的步进设置最大功率。降低的是塔的充电负载，实际能充多少仍取决于电网，机队起飞所需的能量也照常积累。
钛和硅分别达到供货量之后，出现了运输订单，源端库存随取货下降。回到母星复读，两种矿物各有 100 个到站，订单清空，运输船归队。跨星球物流到这里才真正发生了。
货到了母星，还得接进最后一台机器
母星物流塔里的硅矿接入高纯硅熔炉以后，临时用石矿制硅的入口才停用。长线中间又有一只分拣器没电，补电后读到它实际携硅，成品仓从 2806 增加到 2820。正常关闭、恢复同一存档之后，塔的供需配置还在，运输订单继续，熔炉也还在工作。
但黄糖仍然没有达到这个版本想要的状态。有机晶体需要的塑料、油和水，还要靠伊卡洛斯在本地搬。
于是又给这三种原料铺长线，沿着越来越拥挤的旧工厂绕行、跨带、补电。最后接到目标仓，等了五十秒却只有塑料增长，油和水仍然是零。
这次卡在中间的分拣器桥。塑料先把有限的通行能力占满，后加入的油和水过不来。给三个瓶颈分别补上并行分拣器之后，目标仓才同时出现三种原料，有机晶体、钛晶石和黄糖设备接着恢复工作。
最后的观察窗口里，三种原料继续自动到仓，有机晶体和黄糖出口都能读到携货，金刚石库存随生产下降，玩家没有中转这些材料。确认这条供应链成立，再正常保存，才算结束了这个验收流程里伊卡洛斯亲自搬货的阶段。
整理旧线还用到了物流阶段补过的分拣器配置修正。旧入口要求设备完全空闲，空载返程的分拣器也可能因为阶段和进度一直变化而无法改过滤。于是配置工具的 sorter-filter 模式改用独立 configurationStateHash，保留实体、两端连接、过滤和携货状态，排除空载返程进度；准备和提交仍各自确认没有携货。这样能在安全窗口改过滤，而一旦它又拿起货，计划就失效。像停掉旧石转硅入口这类调整，就不必为了改一次过滤而重建分拣器了。
这里仍然有矿脉储量和金刚石缓存等普通游戏限制。以后原料用尽，工厂照样会停，不能因为这次跑通了就把它写成永远不用管。
这些工作形成了 v0.3.0 — Logistics Towers。发布前除了 119 项自动测试，还把最终压缩包真正安装进游戏，逐文件核对运行组件，验证 MCP 调用、正常关闭和同档恢复。最初甚至抓到过包版本已经变了、Plugin 仍报告旧版本的问题，修正后重新打包、重新安装验证，才发布。
长期开发档已经能继续往下玩，接下来要验证的是：换一个没有开发记忆的 Agent，拿到压缩包以后能不能自己开始。
0.3.1：让玩家自己的存档也能接进来
长期开发可以一直用 Spherewright 创建的那一局，其他玩家却不一定想从头开档。于是 v0.3.1 补了一个明确的导入入口。
这版新增 prepare_save_import / commit_save_import，公开工具数从 v0.3.0 的 48 个增加到 50 个。已有的恢复工具只认识 Spherewright 登记过的世界；玩家手动载入的世界需要一次新的认领，所以导入有自己的准备与提交流程。
流程从玩家在游戏里手动载入目标存档开始。Agent 先做无副作用预检，展示三个约定：原档保持不变，创建新的 owned 副本，Journal 从导入点开始。然后在对话里单独询问，等用户在后续消息中明确同意，才能提交。
提交只对这次预检绑定的当前世界有效，计划短时、单次使用。之后调用游戏正常保存流程另存副本，保存和文件头复读成功，才取得副本的控制权限。Agent 不负责挑原档，也不接受任意存档名。
具体到工具，prepare 返回要向用户展示的 confirmationPrompt；commit 必须声明后续对话已确认，并明确接受“原档不变”和“Journal 从导入点开始”。计划还绑定进程、会话、revision 和精确 GameData。这些约束防的是预检完以后玩家切了世界，或者 Agent 把先前一句“接着玩”误当成对当前导入方案的同意。
导入前发生的历史仍然未知。已经研究过科技、已经建好黄糖线，也不能把导入那一刻记成它们的第一次。
这版最初带着 127 项自动测试和包体检查发布，原档不变、导入后保存与恢复等实机边界还需要继续验证。它没有把开发中的 v0.4 诊断能力一起带进来。
0.3.2：只给发行包，Agent 还能不能玩
另一个问题是，开发时的 Agent 读过源码和整份经验账本，知道过去在哪儿卡过。真正下载 Mod 的人没有这些上下文。
v0.3.2 把新建世界和导入副本的命名区分开，保留旧档的受保护恢复兼容；同时把开局移动经验整理成包内说明和可从 MCP 读取的资源。移动失败结果也开始直接返回卡住的类型和有界恢复提示。
这次没有新增动作工具，公开数量仍是 50 个。新增的是 MCP resource：spherewright://agent/playbooks/opening-movement-v1，Host 能用标准 resources/list、resources/read 发现和读取；它随 MCP Server 一起打包，不必先连上游戏，也不要求 Agent 能访问源码仓库。
已有的 get_action_result 则扩展了移动失败返回：包含 failureKind、stalledGameTicks、remainingDistance、doNotRetrySameTarget，以及短距离恢复建议。位置卡死、路线没有进展和总时限到达，开始有不同的结构化分类。建议最多尝试四个正交短目标，每个方向一次，执行仍走已有的 prepare_move / commit_move。原因是此前“知道该绕开着陆舱”的经验只留在开发账本里，普通 Agent 拿到一个失败句子，很容易再撞同一个目标。
这样 Agent 遇到着陆舱或建筑基座，不必先读仓库才能知道该换一个短目标、侧向绕行，而不是对着原来的位置一直撞。文件名只是帮助辨认，存档归属仍由受保护登记和当前世界身份来证明。
随后分别让 Sol Max 和 Luna Max 只拿同一份 v0.3.2 发行包，从独立新档开始。它们不能读仓库源码、测试、历史账本或旧坐标，只能用包内说明和实时 MCP 状态。目标是从原矿一路自动生产蓝糖，送进专用仓，并正常保存。
两轮最后都通过了，但走法不一样。Sol 先用临时供料验证研究站和输出，再把上游替换成完整自动链；Luna 先铺原矿和冶炼，逐层接到研究站。
| 这两次运行的记录 | Sol Max | Luna Max |
|---|---|---|
| 完整原料链首次蓝糖，本局时间 | 03:03:05 | 04:31:51 |
| 整体验收的现实耗时，含初始化、规划和保存 | 03:17:48 | 05:04:46 |
| 最终冻结玩家输入后的成品仓 | 67 → 88 → 106 | 144 → 146 → 149 |
| 上述观察窗口 | 约 118 秒 | 20 秒 |
| 正常保存及写入健康检查 | 通过 | 通过 |
Sol 更早的临时供料蓝糖没有被拿来当完整链的完成时间；两次观察窗口长度不同，也不能只用这几次整数计数判断长期产能。两个随机世界的资源和布局不同，各自只有一次运行，耗时也不足以给模型排出高下。它们证明的是，在这两个独立世界里，只依赖公开发行能力也能完成这段开局。更多过程和限制放在双模型黑盒验收记录里。
Sol Max 的工厂。由玩家在验收后取景，来自独立的 v0.3.2 黑盒验收新档。
Luna Max 的工厂，同样由玩家在验收后取景。两张图均为独立验收档的现场；前文长期开发档的钛、硅和黄糖进度不计入这些记录，产量与时间以上表为准。
0.3.3：让更多和平存档接得进来
到 v0.3.3，调整的重点是沙盒状态和资源倍率。
早期开发档固定为和平、非沙盒、1×，这些条件也曾一起被写进运行检查。结果一个和平存档只要倍率不同，或者开启过沙盒，就可能在导入、普通动作或恢复阶段被挡下来。
这版把沙盒状态和倍率保留为如实报告的信息，取消了它们对这些流程的阻止。新建世界的默认设置仍是和平、非沙盒、1×；已有和平存档的设置可以不同。Spherewright 提供的操作仍然走正常游戏机制，沙盒里的物品注入、瞬建、直接解锁科技等能力没有开放。
工具层面仍沿用这 50 个入口，修改集中在普通动作、prepare_save_import / commit_save_import、prepare_resume_owned_game / commit_resume_owned_game 和飞行检查点恢复的共同准入策略。代码把模式判断收拢到 GameplayModePolicy，继续要求能确认和平模式，同时移除沙盒和倍率的拒绝条件。若只放开导入入口，存档可能刚认领成功，第一次采矿或下次恢复又被同一条件挡住；这些入口必须保持一致。
发布时做了三类本机实测：
| 世界来源 | 设置 | 已记录的结果 |
|---|---|---|
| Spherewright 新建 | 非沙盒、1×、和平 | 正常采集、手搓、科研、首座电塔施工与保存 |
| 玩家载入后授权导入 | 非沙盒、100×、和平 | 同样完成上述流程，原档保持不变 |
| 玩家载入后授权导入 | 沙盒、1×、和平 | 同样完成上述流程，原档保持不变 |
同时，Mod README 补了中英文使用说明、可以直接发给 Agent 的简短提示词，以及新档和旧档的进入流程。包内 playbook 也扩展到会话入口、超时与幂等、能量、采集接近、施工、产线和飞行恢复。
写操作默认关闭，需要启用 Safety.AllowWrites；导入还需要单独启用 Safety.AllowUserSaveImport，并保留预检后的对话确认。具体安装与操作可以看 v0.3.3 使用说明。
v0.3.3 发布记录中，158 项自动回归、完整 Release 构建、手动安装包和 Thunderstore 包的完整性与 MCP 检查均已通过。支持版本是 Windows x64、DSP 0.10.34.28529 和 BepInEx 5.4.17。这批证据来自本机，仍不声称完成独立异机验证。
还有一个明确限制：采集动作内部的自动接近，尚未具有普通 Move 的短窗口看门狗。在着陆舱或密集设备旁，仍需要先用短路点绕出障碍，再开始采集。黑雾、战斗、多人和跨恒星曲速自动化也不在这版的支持范围内。
从第一趟把 1000 钛矿背回家，到运输船把钛和硅送进母星工厂，再到只给发行包也能重新开局，0.3 这一段终于有了可以交给别人使用的形态。至于更多星球上的产线出了问题，该怎样更快找到原因，留给后面的版本继续处理。
本文游戏进度与事故数据整理自存档日记 001和经验账本，补丁版本状态以各版本公开发布记录为准。
接口变化可对照 v0.3.0 工具定义和 v0.3.3 工具定义。施工、科研、物流与恢复的修复原因见问题与代码修复记录，包内资源见 v0.3.3 Agent playbook。