为什么不直接用 Agent？
X-Hub 要解决的，不是“怎么让一个 agent 赶紧动起来”这一件事，而是“怎么让 AI 持续执行，同时让信任、记忆、授权和运行时真相仍然处在可治理状态”。
公开对比视图 这一页解释的是产品层取舍，不是完整公开控制目录。目标是先把系统讲清楚，而不是把所有仍在变化的实现细节一次性摊开。
简短答案
如果你只想要一个能接任务、调工具、给结果的 agent，市面上已经有很多项目能做到。
X-Hub 关注的是更难的那部分：
- 当 terminal 不应该成为信任根时怎么办
- 当一个插件不应该静默扩大全系统权限时怎么办
- 当自治提高时，监督不应该自动消失时怎么办
- 当 memory、grant、audit 和 runtime truth 需要继续挂在同一套系统记录面上时怎么办
- 当控制平面应该由用户持有，而不是悄悄掉进客户端 bundle 或云厂商默认设置里时怎么办
典型 Agent 堆栈通常会把哪些东西压得太扁
| 关注点 | 典型 terminal-first / execution-first 默认形态 | X-Hub 的方向 |
|---|---|---|
| 信任根 | 当前客户端、运行时或插件包往往悄悄变成最终信任区 | 把信任继续锚定在 Hub，让客户端保持可替换 |
| 能力调用 | 工具和插件装上后通常默认带来更大权限 | skill 和高风险执行路径被视为受控能力链路 |
| 自治 | 能力越强，监督越容易变模糊，运行时真相也越容易不透明 | 执行范围、复盘深度、干预方式和 clamp 被拆成明确控制项 |
| 记忆 | 上下文、笔记和执行状态容易分散到不同表面 | 记忆真相应继续挂在 Hub 侧系统记录面上 |
| 云端控制 | 云厂商默认配置容易变成隐藏控制平面 | 基础姿态是 user-owned Hub，外部服务只是受控附属面 |
X-Hub 真正在优化什么
X-Hub 优化的是另一种运行模型：
- User-owned control plane：权限、密钥、记忆真相、审计、发布时间和运行姿态继续由用户掌握
- Governed autonomy：执行能力更强，不等于监督自动更弱
- Governed skills：可复用能力单元可以被路由、审批、拒绝、审计、重试和撤销
- Fail-closed runtime truth：准备状态不足、配对损坏或授权不明确时，系统应该阻断，而不是假装成功
- 多表面执行：配对表面、远程通道和本地运行时通过同一控制平面汇聚，而不是长出影子权限路径
什么情况下，简单 Agent 就够了
如果你的需求是下面这些，轻量 execution-first agent 很可能已经够用：
- 主要是一次性任务
- 环境本身风险较低
- 不需要持久治理、审计或项目级 memory
- 可以接受 terminal 或 runtime 自己持有信任边界
- 更看重快速实验，而不是长期可控性
什么情况下，X-Hub 开始更有意义
当你需要下面这些能力时，X-Hub 的价值会更明显：
- 长期项目推进，而不是一次性 prompt
- 项目级执行上限和监督分层
- skill 体系保持受控，而不是 install-equals-trust
- 远程通道和语音表面不能绕过控制平面
- 本地优先运行，隐私、密钥和发布时间继续掌握在自己手里
- downgrade、blocked、readiness truth 必须诚实可见，而不是静默掩盖
这背后的取舍
X-Hub 不是通往“看，agent 动起来了”这件事的最短路径。
它做的是一个更刻意的取舍：
- 多一点结构
- 更清楚的信任边界
- 更可信的安全与治理故事
- 更适合高后果、长周期执行的基础设施
所以真正应该比较的，不只是 capability 对 capability。 而是“受控之下的 capability”和“软边界下的 capability”之间的差别。