Spherewright 现在的做法，是让一个 AI Agent 通过 MCP 操作伊卡洛斯。Agent 能读到位置、能量、背包和附近的设备，也能下达移动、采矿、建造和生产指令。它不能通过编辑存档文件改变资源和进度，也不能凭空往背包里塞东西。严格说，这不是现实里带摄像头和机械臂的机器人，身体和环境都是虚拟的。不过伊卡洛斯会被建筑卡住，会因为没电走不动，也得亲自飞去另一颗星球。蹭一下现在最火的赛道，叫它“赛博具身智能”应该不过分。
怎么接入使用
使用信息更新于 2026 年 10 月 19 日，对应 10 月 17 日发布的 v0.4.0。
Mod 可以从 Thunderstore 的 Spherewright 页面 获取；GitHub 的 v0.4.0 Release 同时提供 Windows x64 手动安装包和 Thunderstore 布局包。包里已经带了游戏内 Plugin、配套的独立 MCP Server 和 Agent 指南，不需要拉源码，也不用自己安装 .NET SDK。当前包对应 DSP 0.10.35.29151 和 BepInEx 5.4.17.0。
安装、升级前先正常保存需要保留的进度，停止相连的 MCP 进程并退出游戏，再换上同一构建的整套组件，不要覆盖还在运行的 DLL。手动包使用随包安装脚本，Thunderstore 布局则从所选 profile 找到配套的 Spherewright.Mcp.exe，把它注册为本地 stdio MCP 服务。具体路径和同版本重装方式见 v0.4.0 安装说明。
安装后默认只能观察。让 Agent 操作游戏需要启用 Safety.AllowWrites=true，并正常重启游戏使配置生效；接手玩家手动载入的受支持和平旧档，还需要启用 Safety.AllowUserSaveImport=true，并在预检后的对话里单独确认另存副本。原档保持不变。操作前先读取随包指南或 MCP 资源 spherewright://agent/playbooks/opening-movement-v1。
0.4 主要补了三组能力：Overseer 负责有限范围的观察和诊断；Foundry 做配方、材料、供电和依赖规划，并接上有限规模的原生蓝图施工；Governor 提供生产声明。当前发布包共暴露 64 个 MCP 工具和 1 个资源。观察和规划不会顺带获得写权限，材料、科研、供电、施工无人机和游戏时间仍然按原版规则走。
这次发布的 3165 项自动化测试已通过，手动包与标准 Thunderstore 布局也分别完成了本机冷安装、同版本主档恢复和完整的 64 工具调用检查。调用检查里包含预期的安全拒绝，不能理解成每种写操作都已实机执行；历史连续生产验收也保留原来的源码和游戏版本范围。当前仍以单人和平模式为前提，独立 Mod Manager/r2modman profile、其他计算机、黑雾战斗和多人兼容还没有验证，实际跨恒星航行和物流也仍是后续工作。详细结果见 v0.4.0 发布记录。
这个项目还在边玩边改，发布包会跟着已经跑通并验证过的功能及时更新。安装、升级、卸载和回滚说明会一起放在 Release 页面和压缩包里。
想先看看早期不同 Agent 实际接入后的表现，可以读仓库里的 v0.3.2 Sol Max 与 Luna Max 黑盒验收对比。
最后想做成什么
眼下最直接的目标，是让 Agent 从一个刚创建的新档开始，自己采矿、研究科技、铺生产线、跨星球运输，最后造出一个完整的戴森球。中间不换准备好的存档，也不需要人临时进去补材料或者收拾残局。
现在负责思考和推进游戏的还是外部 Agent，Spherewright 主要负责把游戏状态和操作能力接出来。等从开档到戴森球这条流程能够稳定跑通以后，我想再做一个自己的 Agent 应用，把现在分散在对话、工具返回和日志里的东西放到同一个界面里。
它大概会像一个操作台：中间是游戏画面，周围是资源和产线数据、整局进度、当前目标、刚刚执行的行为，以及遇到的阻塞和恢复状态。最好只打开这一个应用，就能同时看到伊卡洛斯正在做什么、Agent 为什么这么做，以及它下一步准备去哪里。
再往后，也许可以直接把游戏嵌进这个界面里，最后形成一个完整的 Agent 游戏客户端。
先定几条规则
目前的规则是：不通过编辑存档文件改变世界状态，不注入物品和科技，不瞬间完成建筑，也不加速游戏时间。保存和另存副本都走游戏正常的保存流程。如果 Agent 缺一台电弧熔炉，它得先把材料准备出来，不能让接口直接生成一台。
长期开发这局固定为单人、和平、非沙盒、资源倍率 1×，新建世界沿用同一套默认。早期接口把沙盒状态和倍率也当成接手条件，从 v0.3.3 起放宽了：已有的和平存档可以用不同设置，Spherewright 如实报告就行。和平模式仍是接手和写入的必要条件，存档归属、写入开关、每次操作的计划检查都保留——操作本身还是走正常游戏机制。
Spherewright 在游戏内只依赖 BepInEx 5，不依赖 CommonAPI、LDBTool、DSPModSave 等功能 Mod。游戏外的 MCP Server 使用 .NET 8，正式发布包会把运行时一起带上。除了多出一组受控接口，实际玩的仍然是原版内容。
主要操作也不走截图识别和键鼠宏，MCP 返回的是结构化状态，比如坐标、能量、背包、矿脉、设备连接和科技进度。
状态可以直接读，动作还是要按游戏的规则来。移动是真的在地面上走，建筑会消耗背包里的物品，之后还要等建设无人机把它建好。
怎么控制伊卡洛斯
模型没有放进游戏进程。游戏里装一个 BepInEx Plugin，Agent 和 MCP Server 跑在游戏外面。
MCP Host / 外部 Agent
│
│ stdio / MCP
▼
Spherewright.Mcp .NET 8
把游戏能力整理成 MCP tools
│
│ 当前用户可访问的 Named Pipe
▼
Spherewright.Plugin BepInEx 5 / .NET Framework 4.7.2
读取游戏状态，调度和执行动作
│
│ DSP 主线程调用
▼
Dyson Sphere Program
Spherewright.Contracts 两端共用的数据和协议
Spherewright.Bridge.Core 认证、快照、计划和幂等逻辑Plugin 负责读取游戏状态和执行动作。游戏对象只留在 DSP 进程里，而且只能从主线程访问，后台通信线程不会直接碰它们。
MCP Server 负责把 Agent 的工具调用转换成 Bridge 请求，再把返回结果整理好。它不直接读游戏内存。Spherewright.Contracts 放两边共用的数据结构，Spherewright.Bridge.Core 放认证、快照、计划和幂等这些不依赖游戏的逻辑。
游戏内外通过本机 Named Pipe 通信。Pipe 和启动凭据只允许当前 Windows 用户访问，Plugin 每次启动都会换一份凭据。这个接口能控制正在运行的游戏，所以即使不出本机，也不能默认谁都可以连。
一次操作怎么走
写操作大致会走下面这几步：
观察 → 准备 → 提交 → 等待 → 复查 → 保存拿建造来说，准备阶段会确认要建什么、放在哪里、背包里缺不缺材料，但这时不会动游戏。提交时再检查一次玩家、星球、库存和目标位置，然后才调用游戏里的建造逻辑。
之所以分成两步，是因为游戏不会停下来等 Agent。Agent 从观察、思考到提交，中间可能已经过了几十秒。背包数量可能变了，原来的目标也可能被拆掉。遇到这种情况就让本次操作失败，不临时换一个相似目标。
每次提交还带一个幂等键。如果同一个请求因为超时又发了一遍，应该返回第一次的结果，不能多造一台机器。提交成功后还要等建设结束，再读取设备状态做一次确认。产线也是一样，要看到输入在消耗、输出确实增加，才算真的跑起来。
这套流程最初落在 34 个工具上：14 个只读工具负责观察状态，另外 20 个按十组准备／提交配对，分别对应开新档、移动、手采、手搓、科研、建造、配置、转移、补充燃料和保存。后来跨星球飞行、物流塔和存档导入又各自补了入口。完整的工具清单和后续新增记录，分别写在 0x01 和 0x02 里。
怎么接着上次玩
这条长期开发主线持续使用同一个存档，每次接着上次保存的进度往下走。发行包的开局验收会另建独立新档，记录也各自保留。因此保存、关闭和恢复都算功能的一部分。
正常关闭游戏前要先保存，并记录下次该读哪个档。跨星球飞行风险比较高，起飞前会另外留一份检查点，失败就从那里重来。第一次手搓或经产线产出一件物品、第一次选择一项科技或升级，也都会把现实时间和游戏时间写进本局日志。
实际运行中已经遇到过这样的情况：伊卡洛斯被建筑基座卡住，移动没有进展却一直耗电，直到没电才停下来。类似问题需要变成可检测的状态，处理办法也要写进仓库。后面发现原来的经验不合适，就直接改掉，不把旧结论当成永久规则。
后面写什么
这篇是 0x00，先写项目的起点、规则和当前架构。
从 0x01 开始记录具体进度。每篇尽量对应一次实际开发：当时要做什么，游戏里发生了什么，原来的判断哪里不对，代码怎么改，最后又怎么验证。