xianyu-sheng/Xenon

一个循环，一个账本，一套可回放的真相
模型可以提案，但不能把未验证的效果说成交付。 Xenon 把每一步工具执行变成 typed receipt，把每个 claim 绑定到 fact，把不能验证的部分显式变成 debt 或 abstain。
SWE-bench Lite ：固定 30 例 62.2% · 零重叠留出集 52.2% （2026-10-16 记录，见「评测」的适用范围）· 3,900+ 测试 · Python 3.10–3.12 · 当前版本 0.9.6
快速开始 ·
内核架构 ·
证据 ·
评测 ·
文档 ·
Issues ·
English
> [!TIP]
> The model proposes; the harness proves. Xenon 不把 LLM 当裁判，也不让多个同构引擎各自解释工具。它只保留一个 LoopRuntime：模型输出 capability action，catalog 绑定工具，gateway 返回 receipt，controller 决定 repair/debt，Finalizer 独占交付提交。
## 它和 Claude Code 有什么不同
能力面上两者接近：终端里跑、多轮、工具调用、MCP、计划模式、审批。如果你要的是一个已经很好用的编码代理，先用 Claude Code。
Xenon 想解决的是另一件事——它凭什么说「做完了」：
交付有物理边界：只有 Finalizer 能提交；preflight 审计不过就回滚本次 commit，而不是返回一段“已完成”的文字。
claim 必须绑到 fact：模型说「已创建 3 个文件」，这三个路径必须出现在 ledger 的 receipt 里，否则算 debt，挡住交付。
验证不了就 abstain：语义类要求无法确定性验证时如实说「无法验证」，不包装成 pass。
每一步可回放：一条 append-only ledger，/evidence 看到的是同一份真相，不是模型的自述。
能拦住的硬规则：git push、破坏性命令不经询问直接拒绝；需要越权时走一次性授权，用完即撤销。
一句话：Claude Code 让你更快地完成工作；Xenon 试图让「完成」这件事可以被检查。
> 目前是 research beta：机制齐备、有限真实任务验证过（docs/evidence/），但内核路径尚未重跑 SWE-bench。别把它当生产工具用。
## 快速开始
bash
# 从 GitHub Releases 安装（不依赖 PyPI）
pip install https://github.com/xianyu-sheng/Xenon/releases/download/v0.9.8/xenonharness-0.9.8-py3-none-any.whl
xenon --version # 0.9.6
xenon # 首次运行会引导配置 API Key、模型与运行入口
Windows 若提示 'xenon' 不是内部或外部命令，把 pip 输出的 Scripts 路径加入 PATH，或直接使用 python -m xenon。
bash
# 源码安装
git clone --depth 1 https://github.com/xianyu-sheng/Xenon.git
cd Xenon && python -m venv .venv
.venv/Scripts/python -m pip install -e . # Windows
source .venv/bin/activate && pip install -e . # Linux / macOS
## 为什么是单循环
旧版 Xenon 有 7 个“推理引擎”。engine/registry.py 自己承认：七种内置模式运行流程完全同构，差异只有引擎类、少量参数、模式行和面板标题。结果是同一套循环被复制 7 次，工具语义散落在 prompt、plan 校验、TaskState、ClaimGate、delivery 五处。
现在只剩一条控制流：
text
TaskSpec
→ LoopRuntime（唯一 writer，显式 phase machine）
view = Projection(ledger[0..seq], catalog, spec)
action = Strategy.propose(view) # 模型只提案
decision = Policy.check(view, action) # 确定性 veto / approval
receipt = Gateway.execute(action) # 唯一副作用入口
verdict = Controller.reconcile(...) # V0 / V1 / V2
event = Runtime.append(...) # 唯一 durable write
→ Finalizer（只 stage 已验证路径，生成交付提交）
## 内核架构
text
┌──────────── LoopRuntime（唯一 writer）────────────┐
TaskSpec ─────────▶│ intake → running → toolcall → reconciling │
│ → auditing → delivering → finalized │
│ view = Projection(ledger, catalog, spec) │
│ action = Strategy.propose(view) │
│ decision = Policy.check(action) │
│ receipt = Gateway.execute(action) │
│ verdict = Controller.reconcile(...) │
│ event = Ledger.append(...) │
└─────────────────────────────────────────────────┘
▲ │ │
Projections ToolCatalog EventSink
ModelView / TaskState core + MCP pack TUI / JSONL / SDK
PlanView / EvidenceView
### 七条不变量
I1 单 writer：只有 LoopRuntime 能 append ledger。
I2 单入口：所有工具副作用经过 ToolGateway；交付提交由 Finalizer 独占。
I3 单事实源：ledger 是唯一真相；其他都是带 inputseq 的只读投影。
I4 语义接口：kernel 只认 capability / obligation / receipt；工具名只活在 catalog。
I5 提案/事实分离：LLM 输出是 claim- / hyp-；只有 binder 能产生 fact-。
I6 单一决策权：VerificationController 决定 repair / replan / abstain / abort。
I7 可回放：同一 ledger 前缀产生逐字节一致的投影，回放过程零网络。
## 一个回合怎么走
text
输入
→ TaskSpec：objective / userobjective / obligations / budget / permission
→ 模型提案：think / calltool / submitplan / updateplan / finish / abort