minecraft-automation-knowledge
# Minecraft Automation Knowledge
MinecraftAgentKit 的生电知识包。先比较材料投入和资源产出,再按条目看为什么能工作、适用版本和可复核的研究记录。
[仓库规范](AGENTS.md) · [材料与产出目录](docs/catalog.md) · [内容契约](docs/content-contract.md)
九条知识包含四份外部教程和五份原创原型记录。表中作者产率带工具或变体条件;原型实测只列有界样本产量,持续产率尚未测量。人工回收测试、计量窗口和完整记录见条目。燃料数量为实投量。目标环境为 Minecraft Java 1.21.1;各条目的验证范围见正文。
<!-- resources:start -->
| 装置 | 一次投入 | 运行投入 → 产出 | 人工环节 |
|---|---|---|---|
| [Triloms 刷石机:水岩浆再生,镐采收](docs/entries/cobblestone-triloms.md) | 建造:建筑方块 32块、楼梯 4个、箱子 8个、漏斗 4个、告示牌 1个<br>初始化:水桶 2桶、岩浆桶 1桶<br>设备:镐 数量未知(把) | 效率V钻石镐采收(作者声明):镐耐久 数量未知(点) → 圆石或石头(由采收工具决定) 1200个/小时;使用效率V钻石镐;采石头还需精准采集。产率为作者陈述,目标1.21.1整机待测。 | 持续挖掘生成格;工具磨损和维护由采收者承担 |
| [ilmango 仙人掌农场:分层种植与水路收集](docs/entries/cactus-ilmango.md) | 建造:沙子 数量未知(块)、支撑与收集层方块 数量未知(块)、栅栏或开启的栅栏门 数量未知(个)、收集容器 数量未知(个)<br>初始化:仙人掌种苗 数量未知(株)、水 数量未知(源) | 自然生长后收集(机制参考):无 → 仙人掌 数量未知(个) | 选定布局后种植和灌水;运行时保持随机刻覆盖并处理容器容量 |
| [ianxofour 刷铁机:村民与僵尸方案](docs/entries/iron-ianxofour.md) | 建造:床 数量未知(张)、船 数量未知(艘)、结构与收集材料 数量未知(个)<br>初始化:村民 3名、僵尸 数量未知(只) | 基础窒息击杀版(作者声明):持续投入未完整登记 → 铁锭 175个/小时;基础版;持续耗材未完整登记。村民需要实际睡眠机会;和平会移除僵尸。<br>岩浆击杀升级版(作者声明):持续投入未完整登记 → 铁锭 335个/小时;升级材料及持续耗材未完整登记;不得与基础版叠加计算。<br>作者1.18版本注记(作者声明):持续投入未完整登记 → 铁锭 320个/小时;1.18独立版本注记,不能据此填写1.21.1实测产率;持续耗材未完整登记。 | 运送村民和僵尸、安排床与睡眠视线、维护加载及击杀收集区域 |
| [gnembon 刷怪塔:自然生成与周期冲水](docs/entries/hostile-mob-gnembon.md) | 建造:生成平台与结构方块 数量未知(块)、红石与冲水装置 数量未知(个)、收集设施 数量未知(个)<br>初始化:水 数量未知(源) | 目标敌对生物掉落物(机制参考):持续投入未完整登记 → 目标生物掉落物(品类未完整登记) 数量未知(个) | 选择目标生物与层数、布置AFK位置,维护自然生成条件与收集容量 |
| [单格刷石原型:干结构与镐采收样本](docs/entries/cobblestone-single-cell-prototype.md) | 建造:石砖 85块、漏斗 2个<br>初始化:水 1源、岩浆 1源<br>设备:石镐 1把 | 原址连续采收样本A(原型实测):石镐耐久 3点 → 圆石 3个<br>同址后续单次采收样本B(原型实测):石镐耐久 1点 → 圆石 1个 | 工作原型需投液、用石镐破坏生成格、取回下斗物品并维护工具;不含自动采矿器 |
| [单箱库存反馈:显示库存与锁停上斗](docs/entries/inventory-feedback-single-chest.md) | 建造:石砖 10块、红石粉 4份、箱子 1个、比较器 1个、红石灯 1个、漏斗 1个、中继器 1个 | 仅存取与转运;新增资源:无 | 手动放入和取回测试物品;本结构只做存取、转运与库存反馈,不开采或合成物品 |
| [单株仙人掌:无水漏斗收集原型](docs/entries/cactus-single-plant-dry-hopper.md) | 建造:石砖 21块、漏斗 8个、沙 1块、箱子 1个<br>初始化:仙人掌 1株 | 清箱后首次自然实收(原型实测):无 → 仙人掌 1个 | 初始化底部种苗;运行依赖随机刻覆盖 |
| [双株仙人掌:共享漏斗收集原型](docs/entries/cactus-dual-shared-hoppers.md) | 建造:石砖 29块、漏斗 13个、沙 2块、箱子 1个<br>初始化:仙人掌 2株 | 清箱后首次自然实收(原型实测):无 → 仙人掌 1个 | 初始化底部两株,保持随机刻覆盖并维护收集容量;人工验证另放测试上节 |
| [炉顶漏斗进料与石砖加工](docs/entries/furnace-stone-bricks-top-feed.md) | 建造:漏斗 1个<br>设备:既有炉 1座 | A:手工烧石并合砖(原型实测):圆石 4个、橡木板(实际投入燃料槽) 3个 → 石砖 4个<br>B:顶部漏斗送料后烧石(原型实测):圆石 1个、橡木板(实际投入燃料槽) 1个 → 石头 1个 | 手动备料、投燃料和取出炉产物;A另手工合砖 |
<!-- resources:end -->
每条正文默认展示因果、版本依据、关键约束、可扩展边界及具体待验证推论。五条原型的旧样本按历史观察保留,新增推论尚未做实验;来源更正与新实验结论分别记录。
## 运行
需要 Node.js 20 或更高版本。在本仓库执行:
```sh
npm ci
npm start
```
MCP 客户端启动配置示例:
```json
{
"mcpServers": {
"minecraft-automation-knowledge": {
"command": "node",
"args": ["/absolute/path/to/minecraft-automation-knowledge/src/server.js"]
}
}
}
```
两个只读工具:
- `automation_search`:中文或英文关键词、和平依赖筛选、`offset` / `limit` 分页。返回材料、运行投入、产出和人工条件;空查询列出目录。
- `automation_read`:按知识 ID 读取完整事实、来源与验证记录。
例如先以 `{"query":"仙人掌","limit":2}` 搜索,再以 `{"id":"cactus-dual-shared-hoppers"}` 读取。工具离线运行,不访问游戏或执行施工。
## MinecraftAgentKit 导入
`exports/minecraftagentkit/*.json` 是九份知识 Skill。导入后由宿主自己的管理流程处理;条目没有附带可执行 Blueprint 或 Routine。
为兼容当前导入器,导出保留实际格式标记 `yourmaid.skill_export.v1`。
## 修改与验证
按[仓库规范](AGENTS.md)编辑 `content/knowledge.json`,然后执行:
```sh
npm run generate
npm run check
```
正文、目录、README 表格与严格导出由同一事实源生成。[内容契约](docs/content-contract.md)解释结构与证据口径,[发布检查](docs/release-checklist.md)说明独立复验方法。维护方在发布前还会进行私有集成与公开文件检查。
MIT。外部教程、视频与作者下载按各自许可使用,本包只链接原件。
TDQS
Scored across 2 tools
The two tools have clearly separate roles: automation_search finds candidate knowledge entries, while automation_read retrieves one exact id. Their boundaries are explicit, and the search description even explains how to list all entries, preventing confusion with read.
Both names follow the same predictable snake_case pattern: automation_<action>. The shared prefix groups them as one tool family, and search/read are conventional, distinct verbs.
Two tools are minimal but justified for a read-only bundled knowledge base: search to discover ids and read to inspect full records. It is slightly thin compared with the 3-15 ideal, but neither tool appears redundant.
The surface covers the full retrieval lifecycle for a static knowledge corpus: discovery through search and full inspection through read, including sources, conditions, revisions, and evidence. No create/update/delete operations are needed because the knowledge is bundled and offline.