@xinyu391 他本身不是库,只是接口规范没有任何实现。具体实现在 backend, 而 backend 你可以直接是内核或对系统调用封装的 C ，openkal 不关心实现方式 只做接口规范和标准。

这是 openkal 的 linux 实现, 直接走系统调用, 而 C 语言只是方便使用的工具

- https://github.com/mcpplibs/openkal-linux/blob/main/src/sys.h

但其实 openkal 不关心 是汇编或是其他。因为他是面向内核接口规范设计的一组 SPEC / 规约 / ABI, 即:

openkal: 是一组内核接口规范 (这个不是传统意义上的库)
openkal-linux: 是对这个内核接口规范的实现。(这个规范的具体实现以库形似表现, 也可以是内核)

只不过这个确实不太清楚怎么解释比较好, 核心就是理解 规范 和 具体的库的区别。

当然概念上有个类似的东西叫 posix, 你可以了解一下

(当然你我上面这段话复制给 AI 和他多轮对话辅助理解)

@SmiteChow 目前 mcpp 的方式是 把 kernel abi / c abi / c++ abi 变成编译期确定 可组合，和 编译器核心 解耦，和 zig 方式 可能稍微有点区别

@xinyu391 llvm 设计上就是多指令集后端，但是各种原因 通用交叉编译是用不了的。即在 linux 构建出可以用标准库的 macos / windows / linux 程序 现实好像没有人做这块，只有 mingw 做了 linux -> windows 是比较常用的，但目前 mcpp + openkal 体系 做到了 3 x 3 任意交叉构建 直接覆盖了 mingw 的功能范围 (当然目前是 MVP 初步验证通过，稳定性等一些方面肯定不能和 mingw 比

@coefu 就是可以啊, 屏蔽了底层库区别，走统一 ABI openkal ，编译期自动分发

备注: 除非是有人主动添加包, 自动抓取会过滤掉 小于 2 Star 的项目

工具开源仓库: https://github.com/mcpp-community/mcpp
包索引/网站源码: https://github.com/mcpplibs/mcpp-index

@DeeCheung 复杂度高了后 模块间影响 性能很容易下降, 可能需要 按模块 + 全局性能优化

@DeeCheung 也是用 C++吗 还是 rust

@magicdawn 原来还有 nub, 这个之前还真没有发现 hhh

@msg7086 我实际体验下来, 超过 5 个 agent 并行 使用 worktree 依然会有冲突问题, 往往并行过多时推进还会慢 (可能和我使用方式有关系)

@msg7086 Bun 作者说他 11 天重写, API 费用花了 16+万美元

@msg7086 gcc 16 / llvm 22 用 import std 目前感觉上没有什么大问题(上面 mbun 就是用的)。之前有做了个为模块化 和 import std 打造的 构建工具 基本没有工具链负担 mcpp new / mcpp run 就可以了。上面 mbun 项目也是用这个 mcpp 构建工具构建的, 具体可以可以看下面仓库

- https://github.com/Sunrisepeak/mbun


@cnbatch mcpp 这个工程描述文件不对不同平台有不同配置, 并且如果同一个平台有多个可选功能。mcpp 还有 feature 机制 例如 imgui

使用默认配置

[dependencies]
imgui = "0.0.3"

配置 backend 或相关 feature

[dependencies]
imgui = { version = "0.0.3", features = ["docking"] } # Request a feature of this dependency
widget = { version = "1.0", backend = "glfw_opengl3" } # Sugar for: features=["backend-glfw_opengl3"]

@c0xt30a 是指库 dll 在 mcpp 包索引进行分发 (这个是支持的) 还是指 支持在 linux 上构建 windows 的 dll 可以提一个 issue: https://github.com/mcpp-community/mcpp/issues

@openercn 大概有这么几个视角

xlings 内部实现是通过 EventStream 进行能力暴露的 TUI 命令行 / xlings interface json 接口 都只是其前端消费者(之一)

xlings interface 设计的是时候是把 xlings 的所有能力(包括 install/use/subos 及其他命令), in/out 都用 json 格式 这样 xlings 可以是"库"的形式呈现

- 1.基于 xlings interface 接入 Agent Tool Use 做 agent 的执行层 可以做为 Agent 工具能力的扩展器 / 包管理 Agent 需要什么工具可以从 xlings 里查找安装
- 2.做为其他工具的包索引/管理模块 - 这个目前已有具体示例 - [mcpp 项目]( https://github.com/mcpp-community/mcpp)

---

目前已经实现的是 让 Agent 跑到 一个 SubOS 里面 这样 agent 的登陆验证/key/记录等等都是隔离 并且可以给 agent 开很大权限 不会直接操作/损坏 host 的文件和数据. 并且可以创建一个基础环境(里面用 xlings 配置好一些基础的工具和环境) 然后通过 fork 创建多个 subos 环境 给不同或相同的 agent 使用

而 xlings interface 怎么使用 主要还是看使用者, 因为他本质上算是 xlings 的 "库型态的接口"

目前 linux 上支持还不错 gcc 16 / llvm/clang 20, macos 和 windows 后面准备先通过 llvm 进行支持, 欢迎交流反馈

@sslyxhz https://docs.xllmapi.com/docs

@sslyxhz 感谢反馈, 问题已经修复