你让 AI 帮机器人写一个"摘苹果"的计划,它滔滔不绝,感知、规划、控制一应俱全,还顺手引用了几个"开源库"。你一查——库不存在,接口对不上,整个计划听着完美,实则全是现编的。

这不是模型不够聪明。是它手里没有一张总工程师的图纸


一、机器人缺的不是脑子,是图纸

过去几年,具身智能的进步全在模型端:更大的视觉模型、更强的策略学习、更猛的数据集。可一旦你真要让机器人去干件实事,卡住的从来不是"它会不会写控制器",而是——它知不知道整件事该先干什么、后干什么、哪一步踩着哪一步

机器人需要的知识其实早就存在了。数万篇论文、GitHub 仓库、ROS 包、模型中心、Benchmark 套件、工程博客……该有的都有。但它们以"散文"的形式散落在各处,而不是以"结构"的形式立在那里。

一个语言模型能给你检索出一段逆运动学的论文。但如果你问它:逆运动学到底有哪几种工程范式?各自的输入输出和失效模式是什么?分别有哪些开源实现?哪个问题不先解决,后面全白搭?——它给不出一个另一个程序能直接消费的答案

每次对话,它都从零开始推一遍这个结构。对话一结束,推导就没了。

这就是 Entropy Box 想解决的事。


二、一个任务背后,藏着十几个技术步骤

README 里有个比喻我特别喜欢:

模型是一个掌握了所有零件的工匠,但它从未拿到过总工程师的图纸。

你说"让机器人去把那个杯子拿过来",听着简单。背后呢?感知、标定、逆运动学、轨迹规划、碰撞检测、力控、抓取规划……一长串步骤,每一步都依赖上一步的输出,中间还缠着无数依赖关系。

模型能按指令写出其中任何一个模块——你说"写个检测器",它给你检测器;你说"写个控制器",它给你控制器。但它没法把整条工作流编排起来,因为它从来没有一张写着"先后顺序和依赖关系"的图纸。

左边:AI 面对散乱的文档和问号,一脸困惑;右边:AI 站在清晰的知识网络图前,从容操作

Entropy Box 干的事,就是把这张图纸画出来:把非结构化的知识源一次性编译成一份持久的、带类型的、去重过的、机器能直接吃的知识产物。画一次,用无数次。

查询时推导 知识编译
分析在哪做 请求里面 请求之前
产出什么 一段散文 一张带类型的图
答完之后 结构扔了 结构留着
全局身份 没有 有注册表、去重
谁能用 人读 程序吃

三、Entropy Box:一个知识编译器

在这里插入图片描述

简单说,Entropy Box 是一个面向机器人和具身智能的知识编译器

它一次性摄入论文、仓库、ROS 包、模型中心、Benchmark 这些非结构化来源,然后输出一份知识产物——不是一份静态的文档转储,而是一个正在运行的系统。你用自然语言输入一个机器人目标,它会把目标拆解成一条可执行的能力链,每个环节都标着对应的开源仓库,哪里还缺能力也明明白白标出来。

这个仓库就是项目的公开面:论文、开放数据、可复现的测量脚本、编译产物的交互视图,以及两个真正用它做出来的开发案例。


四、怎么编译的:三级分类 + 四阶段流水线

整个编译骨架是这样的:

一张三级分类法驱动所有编译——15 个顶层领域 → 420 个子领域 → 2,524 个叶子主题。每个叶子主题在一笔事务里被编译成三类东西:带类型的任务链、能力、资产。

一个四阶段的多智能体编译器,跑在一个持久控制平面下面:

  1. A1 — 链推导:先把任务链的骨架走出来
  2. A2 — 隔离研究:每个环节独立去查资料,互不干扰
  3. B — 带类型组装:把研究结果按类型组装成能力和资产
  4. C — 终结:过闸门,写进注册表

外面还有一个异步准入平面——注册表同步、去重和冲突台账、图物化、增量索引——没有任何智能体能直接往里写。这是保证整个产物一致性的关键:智能体负责生产,准入平面负责验收。

how-it-works/ 目录里不仅写了这套流程,还公开了某个主题真实的研究文档、检索台账和负结果表

为什么负结果表重要?因为一份只写"找到了什么"的记录,和一份编出来的记录,你根本分不出来。真正承重的,是那些"找到了但又被否决了"的记录。


五、规模:2524 个主题,37691 个能力

编译到现在,产物已经长到这个量级了(数字由 evaluation/analysis/measure.py 从磁盘上的产物实时算出来,还在涨):

一张宏大的三维知识网络图,数万个发光节点和连线,少量大而亮的枢纽节点分布在关键位置,从画面深处延伸而来

  • 2,524 个主题——分类树已经全量覆盖
  • 37,691 个独立能力(如果按主题记录条目算是 59,071,中间的差值就是去重的效果)
  • 11,442 个独立资产(仓库、框架、包、模型、数据集、模拟器……)
  • 7,907 条任务链,97,379 个步骤
  • 74,330 条推导出来的依赖边,8,513 个跨主题桥接

还有一个数字我觉得比规模更有意思:摊还率 1.57×。意思是每个能力平均被消费 1.57 次,其中 8,603 个能力(22.8%)被至少两个主题复用。

这就是编译的本质好处:你为一个主题铸的能力,后面所有主题都能用。覆盖越广,这笔买卖越划算。


六、最妙的设计:依赖网络是"走"出来的,不是写出来的

这一点我觉得是整个项目最值得停下来想一秒的地方。

74,330 条能力依赖边——不是人手工写的,也不是模型推断的。

每条任务链的步骤本身就带着"下一步"指针,以及它需要哪些能力。你只要顺着链走一遍,穿过那些不声明能力的纯路由步骤,潜在的先后关系就自己显形了。8,513 个跨主题桥接能力,也是同一遍遍历自然长出来的——而这些恰恰是编排器最需要拿捏准的东西。

一句话总结整个项目的主张:把结构编译一次,那些本来需要多步推导的问题,就变成了图遍历。


七、实证:比 RAG 强在哪?100% → 5.2%

光说理念不够,得看数据。这一版最硬的东西,是和 RAG 基线的正面对比。

先说结论:编译不是为了更快的检索,是为了有根有据的生成。

计划合成:无依据声明从 100% 砍到 5.2%

在 EntropyBench Track-P 计划合成基准上(24 个工程任务,覆盖 8 个机器人领域),结果是这样的:

系统 无依据声明 约束违反 约束覆盖
LLM 直接生成 100% 100% 0%
词法 RAG(BM25) 100% 100% 0%
混合融合 RAG 100% 100% 0%
Entropy Box 5.2% 66.7% 35.4%

什么意思?每一个不带 grounding 的基线,生成的计划里资产和接口声明 100% 是无依据的——听着头头是道,引用的库和接口全是编的。Entropy Box 把这个数字砍到了 5.2%。

这就是"编译结构"和"查询时拼段落"的本质区别。RAG 能给你相关的段落,但它没法保证生成的计划里每个资产引用、每个接口声明都真实存在。编译过的知识图可以。

仿真代码生成:首次跑通率从 0.58 到 0.92

同样的 grounding 能力,迁移到下游仿真代码生成(12 个机器人任务):

系统 导入有效 接口匹配 约束守卫 首次可执行
Zero-shot 0.55 0.50 0.16 0.33
Web 搜索 0.69 0.62 0.42 0.50
Vanilla RAG 0.75 0.71 0.50 0.58
Entropy Box 0.98 0.95 0.88 0.92

把代码生成器 grounding 在编译产物上,首次可执行率从 0.58 跳到 0.92,约束守卫从 0.50 跳到 0.88。

所有实验都能从 evaluation/ 目录复现——基线、全上下文 vs 搜索上下文、仿真代码生成、Track-P,脚本和结果全在里面。


八、两个值得记住的实验(包括一个负结果)

嵌入相似度判不了"重复"

我们用 2,362 个人工裁决过的近重复对做了实验:

路径 对数 真重复 Precision AUC
嵌入相似度 1,867 103 0.055 0.509
词法相似度 495 8 0.016 0.689

一旦闸门标出一对候选,相似度分数根本不足以决定"要不要合并"。提高阈值也没用——精度几乎不动,真重复先丢一半。

结论很硬核:保守的人工裁决阶段是必需项,不是安全边际。 一个"超过阈值就自动合并"的系统,在这个操作点上十次有九次以上是错的。

来源可解析性:一个便宜又难作弊的度量

每个编译主题都引用了它据以组装的研究文档。因为那些是文件,引用是机械可查的。当前实测:82.0% 的链-文档引用和 99.6% 的检索-文档引用可以解析。

生成式知识图都会例行检查结构有效性,但几乎没人查来源可解析性。这个度量便宜、难作弊,而且直接告诉你:你的证据层是真的,还是装饰。一个报不出这个数字的系统,等于没有证据层。


九、真的能用:4 个 API 端点,零注册零 Key

知识库完全开放。不用注册,不用 API Key,中英文查询原生支持。任何能说 OpenAPI、MCP 或 REST 的客户端都能直接接——Claude、ChatGPT、Cursor、Trae、WorkBuddy,都行。

端点 干什么
POST /api/consult 方案咨询:意图分解 + 技术链组装
GET/POST /api/lookup 实体查找:直接查能力/资产档案
POST /api/evidence/search 证据搜索:在策展语料上 RAG
POST /api/search 混合搜索:多通道向量 + BM25
curl -X POST "https://xiangshang.ngrok.app/api/evidence/search" \
  -H "Content-Type: application/json" \
  -d '{"query": "robot obstacle avoidance algorithms", "top_k": 5, "mode": "hybrid", "rerank": true}'

OpenAPI Schema 在 https://xiangshang.ngrok.app/openapi.json,MCP Server 一行命令就能下载。各客户端的完整接入指南在仓库 integrate/ 目录里。


十、用它做了什么:两个农场机器人案例

黄昏时分的果园,一个人形机器人和一个小型农场机器人在整齐的果树间工作,暖色调,科技与自然融合

光有知识库不够,得真的用它做点东西。仓库里带了两个基于编译产物的开发案例:

  • farm_robot_sim:以编译器为向导开发的农场机器人仿真项目
  • g1_farm_sim:宇树 G1 人形机器人的农场仿真项目

这两个案例目前都是仿真,不声称真实机器人迁移。但它们证明了一件事:编译出来的知识图,真的能当开发向导用。


十一、开放数据:能复现,不是只能看

数据 CC BY 4.0,代码 MIT。该开的都开了:

  • data/taxonomy.json——三级分类骨干,双语
  • data/capability_names.json——每个能力的中英文名和抽象层级
  • data/asset_index.json——所有资产的索引,含上游来源
  • data/dedup_adjudication_ledger.json——去重裁决台账(就是上面那个负结果的数据集)
  • data/retrieval_golden.json——126 条查询的检索评测集
  • data/measurements.json——所有报告数字的结构化输出
  • case-study/——九个主题的完整版:37 条链、564 步、284 个能力、149 个资产,每个都带真实仓库 URL

为什么不全量开放能力描述?作者说得很直白:带着输入输出、约束、性能包络的描述字段,是整个项目的实体,也是最值得被整段抄走的东西。 九个案例主题里能完整读到,足够你判断这套结构是不是真的。


十二、诚实的边界

一个敢把"没做到什么"写出来的项目,比一个只吹成绩的项目可信得多。目前的边界:

  • 没有真实机器人迁移——案例都是仿真
  • 困难意图的检索还弱——身份查询 MRR 0.89,但功能查询 0.33、多跳因果 0.30
  • 计划合成里图有效性降到 62.5%——消除了无依据声明,但图结构有效性还有代价
  • 语义正确性没测——过了 schema 和图闸门,没过人工语义评审
  • 构建成本没测——单主题耗时和 token 消耗还没核算
  • 56.95% 的任务链是纯线性的——schema 支持分支,但编译器只输出能过闸门的最简结构

它也不是搜索引擎、不是 RAG、不是向量数据库、不是执行本体、不是经典知识编译。论文里写得很清楚。


十三、最后:编译一次,复用无数次

这个项目的公开版本是有意部分开源的——最承重的材料暂时保留,能让你判断"结构真不真"的部分全部开放。论文、数据、脚本、对比实验、九个完整案例、测量脚本,足够你复现、验证、甚至反驳。

对一份知识层来说,能被检查,才是基础设施。


仓库:https://github.com/chenli-yy/entropy-box-public
在线演示:https://xiangshang.ngrok.app
文档镜像:https://chenli-yy.github.io/entropy-box-public/
论文:https://github.com/chenli-yy/entropy-box-public/blob/main/paper/entropy_box_journal_latest.pdf

@software{wang_entropy_box_2026,
  author    = {Wang, Yuqi},
  title     = {Entropy Box: A Knowledge Compiler for Embodied AI},
  year      = {2026},
  publisher = {Zenodo},
  doi       = {10.5281/zenodo.21712178},
  url       = {https://doi.org/10.5281/zenodo.21712178}
}
Logo

DAMO开发者矩阵,由阿里巴巴达摩院和中国互联网协会联合发起,致力于探讨最前沿的技术趋势与应用成果,搭建高质量的交流与分享平台,推动技术创新与产业应用链接,围绕“人工智能与新型计算”构建开放共享的开发者生态。

更多推荐