上一篇结束时，钛和硅已经能坐运输船回母星，黄糖也在本地供上了。9 月 5 日发完 v0.3.3，我以为接下来就是向外走的故事：翘曲器、燃料、物流站、远征物资，准备离开出生星系。
结果这一篇的主要内容，是 Agent 被我按在母星修了一个月厂。
新设备缺料，顺传送带摸回上游，上游明明在生产，料被另一条线分走了；多复制一组机器，产量没跟着翻倍。这局还在不停地保存、换插件版本、恢复、接着施工，上一轮刚修好的地方，下一轮接手又从头做一遍。
时间线写到 10 月 15 日的本地验收，外加之后两天的仓库整理。验收过了，版本就叫 0.4.0——不挂”候选”的名，真有问题就排到后面的版本改。跨恒星是 0.5 的事，这篇只交代出发前这一个月。
0.4 的目标：诊断、建设与扩产
0.4 干三件事：诊断、建设、扩产。Overseer 观察生产、定位问题；Foundry 规划产线、做有限蓝图施工；Governor 比较扩产方案，量实际吞吐的变化。
举个完整流程：诊断发现高纯硅供给不足，Agent 沿着产线找瓶颈，决定是升级输入分拣器、补一台熔炉，还是换一处矿源。选完方案，算材料、接电、施工，再回来测产量，看这次改动堵上了多少缺口。
外部 Agent 选目标、选方案，Spherewright 出观察、计算和操作的入口。这个版本的大部分工作，就是在真实工厂里把诊断、施工、产量验证串成一条线，让一次修厂从发现问题一路走到结果核对。
MCP 从 50 个工具增加到 64 个
v0.3.3 的公开工具是 50 个，0.4.0 加到 64 个，另带一个随包的 Agent 指南资源。工具名照例省略 spherewright_ 前缀。
新增的 14 个入口分五组：
| 能力 | 新增入口 |
|---|---|
| 生产与故障观察 | get_overseer_production、get_overseer_summary、get_overseer_diagnostic_bundle |
| 产线规划与扩产比较 | get_foundry_plan、get_governor_plan |
| 蓝图检查与导出 | inspect_blueprint、export_blueprint |
| 有限施工、进度与取消 | prepare_blueprint_build、commit_blueprint_build、get_blueprint_builds、prepare_cancel_blueprint、commit_cancel_blueprint |
| 原地升级 | prepare_upgrade、commit_upgrade |
缺料、输出堵塞、供电不足、矿源耗尽，在下游看起来都是”没货”。Overseer 把生产读数和电力、物流、科研状态放在一起，就是为了分清到底是哪一种。Foundry 按目标产率拆配方，算设备、材料和工作功率，选定布局后再检查实际场地。Governor 把当前实测产量、目标缺口、升级或新增设备的方案摆在一起比较。
规划返回仍然是 executable=false。一份机器清单不含整条物流网络的全部成本，标称输送能力也不等于货已经送到。真施工，还得补齐连接、供电和材料预算，再走一次新的准备与提交。
工具数量装不下全部变化。实体检查补了真实端点、碰撞几何和物料库存；建造入口加了原生网格、高架跨度和更明确的连接拒绝原因；恢复入口补了精确主档重新授权和版本迁移披露。更多问题最后是在原工具里修参数和返回语义，没有再发明一个新名字。
这些入口和限制可对照当前协议说明。
扩产之前，先解决一个更土的问题：怎么测产量
之前看一条产线，默认开 600 tick 的窗，正常速度下十秒。判断”出不出料”够用，判断”稳不稳”不够。石墨线给我读过一组 36、42、36——十秒差一个成品，折到每分钟就是六个。你说这线稳不稳？窗口这么短，谁也说了不算。
后来给 Governor 加了事前选窗口的能力：600 或 3600 tick，测基线时就把目标、误差和观察时长定死，扩产完按原标准验收。这条规矩主要是拿来防我自己的——结果不好看的时候，谁都会想”要不换个宽松点的目标再测一次”。定了就不许换。
接着就被一个很土的 bug 咬了。基线 31 存完重启，读不回来了，查了才发现序列化器把它读成了 31.0。数学上相等，完整性哈希不认，两种表示算出两份内容，声明直接作废。修法和游戏毫无关系：数值规范化，改序列化路径，原基线和锁定时刻原样保留。一个游戏 Mod 项目，卡在浮点表示上，我都不知道该气还是该笑。
9 月 10 日石墨线扩产过了：基线每分钟 31 个，目标翻倍到 62，误差 ±10%，连续观察 37,128 个 tick，约十分钟十八秒，实测落在 58 到 66。之前那次读到 55 的判了失败，采样断掉的部分没拼回去凑数。所以结论就这么大：这一条线，吞吐翻倍。全厂配平？早着呢。这段过程留在扩产与复制模块记录里。
蓝图要记住已经建好的部分
有了有限蓝图，Agent 不用每次都重新描述每一根带、每一台机器：检查明确提供的蓝图，或者从当前世界选定一组建筑导出，再在新位置提交有限施工。
麻烦在于游戏里的建造会停在中间：材料不够、后续位置被占、无人机还在干活、插件要维护。所以蓝图执行得逐对象记账：未提交、待施工、已完成，还是结果暂时无法确认。取消只能停掉后面的步骤，已经吃掉的材料和建好的机器，都得留在原地。
9 月的六对象模块实验把真实复制、部分取消、重启续建、外部接线全走了一遍，最后才测到持续石墨产出。中途又撞上老问题：炉子有电，挪了位置的输入分拣器没电。模块复制得很漂亮，外围供料没人管。
10 月 14 日再用一个五对象模块验证保存后的续建：先完成一条带和一台制造台，正常保存、关闭、恢复，沿原进度做完剩下三个。最后核对的是同一批实体和扣料，整张蓝图没有重跑。
这次还被自己的调用脚本坑了一回。前两个对象明明已经完工，只因一架建设无人机还在返航，脚本要求”无人机全部空闲”才认账，就把实验停了。动作成功、下一步能不能立刻开始，是两件事，得分开判，不能因为后者没满足就把前者重做一遍。
原地升级也是同样的核法：当前范围先只做制造台、基础分拣器升高速分拣器，检查新设备扣除、旧设备返还、货物、过滤和两端连接。额定速度变快不等于产线增产，真增没增，回 Governor 的观察里看。
紫糖做出来以后，旧工厂的问题逐个显出来
9 月 18 日，主线第一次记录到自动产出的紫糖（信息矩阵）：处理器经新接的高架送进研究站，输出缓冲里躺着 10 个紫糖。
里程碑只能先记到这儿。研究站还没有成品出口，处理器链缺微晶元件，更上游缺高纯硅。10 个紫糖证明这条链能走通一次，证明不了它能一直走。
之后就是没完没了的共享供料。高纯硅不止喂一条线，石墨既要供已有工厂，又要服务石墨烯和远征材料。整颗星球的总产量看着够，分到这条支路上实际能拿多少，是另一个数。
裂解链堵起来更绕。原本指望火电消耗石墨副产物，但火电跟着实际负载烧燃料，额定功率再高，不满载就不满速吃料。发电站确实在发电，裂解厂的石墨出口照样堆满，氢跟着停，一路拖垮重氢和燃料棒。
另一次看着一模一样的停产，原因又不一样：输入输出共用的仓库被重氢占满，送氢的分拣器没位置投料。下游为零这件事，每次都得重新查，照搬上一次的修法迟早翻车。
10 月补燃料和翘曲器，又追出矿源耗尽。一条旧铁矿支路，矿机底下已经没有资源节点了，带和熔炉都还在，仓库剩料让下游看起来还活着。所以查持续供给得一路追到当前矿源和实际物流路径，“仓里还有多少”不算数。
传送带的路比纸上难画
母星越挤，接线越是返工的重灾区。
候选地块中心没建筑，不代表整段路径没碰撞；两栋建筑离得近，不代表真实槽位能用分拣器连上。球面网格随纬度变，纸面坐标不一定是原生吸附后的落点。
紫糖的处理器线要跨过旧带，建造工具为此补了显式高架模式 native_elevated_grid：Agent 给两端高度，Plugin 用游戏原生网格生成一个受限跨度，继续查坡度、平端、碰撞和材料。后来的只读几何接口又补了原生带段点，多段路线的障碍可以先查清再动手。
补的只是明确的单段能力，路线仍由外部 Agent 设计。之前遇到过同一种死法：相同端点、相同拒绝，坐标挪一点点反复试，纯烧时间。后来规则收紧了——同类失败出现，就停掉当前候选，带着实际拒绝原因回去重新设计。
完工判断也翻过车。一次传送带已经正常建好，游戏按实际货物路径重算了朝向，验证代码却还拿预建筑的朝向来比，把成功施工判成了”结果不明”。修复后按真实完工路径认领原对象，已经建好的带保留，才继续后面的步骤。
这类问题有时怪路线设计，有时怪产品缺原生能力，有时只是调用方读错了返回。先分清是哪一层，再决定改方案、改接口，还是只修一处脚本。
暂停几天回来，游戏和恢复条件都变了
9 月 19 日，我让 Agent 正常保存、关游戏。几天后回来，存档还在，恢复票据过期了——有效期只有 24 小时。
恢复流程因此得多走一步：重新核对同一个主档，向我披露具体候选，拿到确认再继续。直接导入一个新副本会开启一条新记录，这条长期主线不能这么”接上”。
这期间 DSP 自己也在更新：这局从 0.10.34.28529 经过四次有记录的迁移，走到 0.10.35.29145。旧引用编译得过，不代表和当前安装的游戏一致，恢复时还得检查世界身份、版本和 Journal 的连续性。
版本核对也误报过一次：调用脚本拿 Journal 最初创建时的版本和票据当前版本直接比，报不一致，其实日记里已经保存了中间那次迁移。修的是”怎么读当前有效版本”，不能靠把旧日记改成新版本来凑。
另一类恢复要处理”保存点有没有覆盖已完成施工”：固定的 LastExit 或自动保存候选，必须逐一证明身份和进度，更早的主档不能把后来已经成功的建筑抹掉。结果不明时，先追查原动作和原保存记录；换个请求标识再做一次，解决不了问题。
这些变化还是走 prepare_resume_owned_game / commit_resume_owned_game，没有把接口放开成任意存档选择器。正常重启可以恢复施工进度和扩产声明；生产观察从新会话重新计时，离线时间不算产量。
我也调整了 Agent 的工作方式
工厂的问题在增多，流程自己也开始拖后腿。
9 月中旬我先动分工：Sol Max 负责复杂设计，Luna Max 执行批准的有限步骤，主会话留代码实现和独立核验。同一个问题几轮设计没结果，就带着原始证据交回主会话。跑了一阵又收拢：主会话、唯一游戏执行者、按需参与的离线维护，交接少了，重复劳动也少了。
开销是有账的。10 月 8 日抽查了三个普通窗口，每窗允许十次写入：从第十个动作结束到下一轮第一个业务准备，平均 23 分钟，花在快照、核查、文档、提交、CI 和交接等待上。最离谱的一次，全目录解析历史动作记录耗了 6858 秒——快两小时，就为了找一条记录。
后来改了几件事：成熟的取材、制作、保存步骤用已有的有限模板串起来；一次采集的完整快照给独立核验复用；查历史动作按明确索引读原件，不再全目录扫；只改事实记录的文档工作，和无依赖的下一阶段分开推进。没必要每取材一步，就把全厂供需重新验证一遍。
新窗口的默认写入上限也从 10 次调到 20 次。旧窗口按原额度结束，保存和独立核验保留。这事就值一句实话：额度变大只是少封几次窗，整体速度翻倍是没有的。
10 月 14 日，收尾方式也定死了：保留已通过的实验和已建好的部分，列清原验收要求还缺什么，只补缺口。五对象续建实验不能冒充完整三级链；反过来，也不必为了补三级链，把建好的模块再建一遍。
补齐三级链，再看它能不能持续供货
最终的三级整合围着空间翘曲器转：金刚石和奇异物质汇入引力透镜，再送进翘曲器制造台。这次复用了四台已有加工设备，事前核算工作功率合计 12.9 MW，外部供料也一并说明。
注意，没有重造这四台机器。新增的活主要是接线：31 条基础带、2 个分拣器、1 个小仓，共 34 个对象。原计划还少两条带——输出端的真实原生连接检查拒绝了直连方案，于是保留已建好的仓库，补一段更短的接缝。
恢复验证故意分了两次。一次停在输入已保存、输出还没建的时候，装上 0.4.0、恢复，再完成剩余施工；另一次等整条链和出发物资齐备，再保存、重启、完整核对。只在全建完之后重启，证明不了施工到一半也能接着做。
然后才是联合供给观察。翘曲器和氘核燃料棒都预先要求至少每游戏分钟 1 件，同时查真实来源、相关库存、电力和运输。中途出缺口就按原声明判失败，几个好看的短窗口拼不成连续运行。
10 月 15 日通过的最终记录：
| 项目 | 已核实结果 |
|---|---|
| 连续观察 | 36,060 个游戏 tick，约十分钟游戏时间，无采样缺口或重置 |
| 空间翘曲器 | 保守产率至少 1.198 件／游戏分钟 |
| 氘核燃料棒 | 保守产率至少 1.797 件／游戏分钟 |
| 来源与库存 | 新链来源单独核验，22 次相关实物库存截面支持声明范围内的供给 |
| 电力 | 79 个有效电网样本均满足当时需求 |
| 收尾 | 正常保存覆盖最终结果，出发清单与日记保全 |
这轮完整取证 1,822 对请求与响应，现实耗时约 84 分钟。游戏 tick 的实际推进、读取和调度都算在里面——墙上挂十分钟，不等于游戏里过了十分钟。
出发清单的九类物资也备齐了：星际物流站、运输船、矿机、电塔、风机、基础带、分拣器、翘曲器和燃料棒。库存和持续补充是分开证的：仓里堆着成品，替代不了上面的生产窗口。具体数值在最终联合供给记录里，整轮耗时和验收范围在0.4.0 交付审查里。
反复出现的问题，留下了几条经验
一个多月的事故回头看，基本都落回这几类：
- 库存掩盖了断供。 下游还有产出，可能只是正在吃旧缓存。查供给要一路找到当前有效矿源、加工设备和实际连接，还要看相关库存趋势。
- 机器有电，入口未必有电。 分拣器的取料位置、塔覆盖和真实电网都要单独看；新建或移动端点后，旧供电结论不能照用。
- 共用仓库和副产物会把整条链堵住。 给仓库腾一次位置只解决眼前问题，后面还需要合理的槽位安排和持续消费。
- 纸面能接，原生检查未必允许。 球面网格、真实端口、跨度和占位要用当前游戏数据验证。同一种拒绝反复出现时，应改结构。
- 报错不等于动作没发生。 显示代码、字段解析、空数组或无人机状态判断，都可能在动作成功后出错。先查原动作，保留成功前缀，再决定怎样继续。
- 测量和验证也会出错。 短窗量化、采样缺口、动态字段被当成静态状态、换了序列化器后的哈希差异，都曾制造假阻塞。需要修的是判断方法时，就不要再动游戏现场。
这些经验现在进了工具返回、包内指南和验证脚本。下次再撞上同类问题，Agent 至少不用从零开始猜。
现在走到哪里
最终保存对应的工厂核对记录：6,660 个建成对象（含传送带），预建筑为零。Journal 留下 102 条记录和四次游戏版本迁移。主线还是原来那个开发存档。
0.4.0 源码过了 3,108 项自动测试，完整构建、两种发行布局的本地安装、运行、同版本恢复都有记录。已验证环境：Windows x64、DSP 0.10.35.29145、BepInEx 5.4.17.0。没验证的也说清楚：另一台电脑、独立 Mod Manager 配置、安装事务崩溃恢复，以及物流载具连续静止 600 tick 后恢复的那个特定诊断分支，目前还没有实机正例。
10 月 15 到 16 日，我把产品仓库和长期执行记录拆开了：Spherewright 留 Plugin、MCP、共享协议、核心逻辑、测试和打包；Spherewright-Lab 留场景、交接、时间线和完整证据，固定使用经过验收的产品版本。随后整理了产品文档和中英文指南。以后维护产品不用拖着某一局游戏的全部现场，接手游戏也有单独入口。
定版之后，后续的文档维护不算新的实机验收。当前位置：0.4.0 就是最新版本，这篇提到的遗留问题往后排；实际跨恒星飞行和物流，留给 0.5。
这篇就停在出发之前。母星有经过连续观察的补给，待建进度和恢复记录都能交给下一次接手。等真飞到另一颗恒星，再看这套办法撑不撑得住远端建厂。
本文事实截至 2026 年 10 月 17 日，主要依据固定的 Lab 历史记录、0.4 验收摘要、产品路线图和仓库拆分后的交接记录。