Ouroboros 到底是什么
先把最要紧的更正说清楚：这不是一个「只有 skill、没有清单」的仓库。它是一个 Python 包——PyPI 上的 ouroboros-ai，README 里链到了 pyproject.toml，代码树是 src/ouroboros/——并且一次提供三种入口：名为 ouroboros 的 CLI、MCP server/client，以及一个终端 UI。README 自称它是面向 AI 编程的「Agent OS」：一个 local-first 的运行时层，把非确定性的 agent 工作变成「可回放、可观测、受策略约束的执行契约」。
项目把自己定位成三层仓库栈里的 OS 核心：Ouro-labs/ourocode 是终端外壳，Ouro-labs/ouroboros-plugins 装的是用户级领域工作流，而 Q00/ouroboros——也就是本仓库——掌管 Seed、Ledger、Runtime、MCP 与安全边界。本条收录指向的插件只跟核心这一层有关。
命令有两套写法，README 把它们分得很清楚：ooo <cmd> 是 agent 会话内的 skill 形式，ouroboros 是 CLI。ooo setup 是在宿主里做的一次性配置，ouroboros init start 则是不依赖 agent 宿主的终端入口。两者不能互换。
DSH 插件就在这个仓库里面
上面的 install: 命令不是把 Python 包装进 DeepSeek Harness，它指向同一个仓库里的子目录 integrations/dsh-plugin，README 称其为 dsh-ouroboros 插件。装好之后可以直接在 DSH 对话里敲 ooo interview 或 ooo auto，同一个 ouroboros_interview / ouroboros_auto 工具会原生地在这个宿主里跑起来，苏格拉底式提问也一并在内。
这个方向（DSH 当宿主、Ouroboros 长在里面）值得专门说明，因为同一份 README 也写了反方向：用 --llm-backend dsh（或环境变量 OUROBOROS_LLM_BACKEND=dsh）把 Ouroboros 自己的流水线接到 DeepSeek 模型上，底层驱动的是 DeepSeek Harness 的 ACP server。README 也说明 dsh 后端除了这一个变量还需要别的配置，并把这些额外要求在它的 DeepSeek Harness 指南里展开，而不是写在首页。
循环本身：面试、结晶、执行、评估、进化
README 给出的诊断相当具体：多数 AI 编程失败在输入而不是输出，瓶颈是人的清晰度，而不是模型能力。由此推出的流程是规格先行的：面试、结晶、执行、评估、进化。
- 面试：苏格拉底式提问，只问不写，职责是把隐藏的假设挖出来。
- 结晶：答案凝成一份不可变的 Seed 规格，带上验收标准、本体（ontology）与约束。
- 执行：按 Double Diamond 分解推进——Discover、Define、Design、Deliver。
- 评估：三阶段闸门，先 Mechanical（标注为免费、
$0），再 Semantic，最后 Multi-Model Consensus。 - 进化：Wonder/Reflect 循环把评估输出当作下一代的输入，直到本体不再变化。
设计的重心落在两个数值闸门上。歧义阈值是 ≤ 0.2，公式为 Ambiguity = 1 - Σ(clarity_i × weight_i)，各维度按 40/30/30（目标、约束、成功标准）加权，棕地项目再加一个占 15% 的上下文维度。高于 0.2 会挡住 Seed 生成；显式传 force 才能通过，README 把这道闸门描述为「一个值得争论的默认值，而不是一把锁」。循环收敛条件是本体相似度 ≥ 0.95（0.5 × 名称重合 + 0.3 × 类型匹配 + 0.2 × 完全一致），并设有 30 代硬上限，以及停滞、震荡、重复反馈三种病态模式的检测。
围绕这条循环，README 还记录了 PAL Router（1× / 10× / 30× 三档成本，失败自动升级、成功自动降级）、漂移度量（目标 50% + 约束 30% + 本体 20%，阈值 ≤ 0.3）、21 个 agent 中高亮 9 个且全部按需加载，以及 ooo ralph——一个跨会话持续的进化循环；因为步骤是无状态的，EventStore 能重建整条谱系，所以机器重启也能接着跑。
运行要求
- 核心与非 LiteLLM 安装支持 Python 3.12–3.14；任何带 LiteLLM 的组合（
[litellm]、[all]，或源码--extra all）只支持 Python 3.12–3.13，README 当前的示例用的是 3.13。 - 注册到宿主需要隔离启动器：
pipx或uvx --isolated --python '>=3.12'。README 说两者都不可用时，setup 会直接退出且不改动运行时配置；若干宿主路径还要求PATH上有uv/uvx。 - 需要
git；发布路径需要gh（可以把一份 Seed 发布成 GitHub Epic/Task issue），Copilot 的模型实时发现在这一步也用到gh。 - 原生 Windows 是实验性的。 PowerShell 安装脚本会在缺失时用 winget 装 Git 和 uv，并让 uv 自己拉 Python，但 README 明确写着原生 Windows 属实验性，且 Codex CLI 需要 WSL 2。macOS、Linux 与 WSL 2 走的是一行
curl … | bash。 - 有一个明确的版本下限：作为 MCP server 安装时应使用 0.51.1 或更高，因为更早的版本会在已有环境遮蔽
[mcp]profile 时启动失败。 - 许可证：MIT。
README 还记录了 Homebrew 安装，走自建 tap（q00/tap），它自己说明尚未进入 homebrew-core。
信任面：安装器会动哪些文件
安装器是一行 curl … | bash（Windows 上是 PowerShell 的 irm … | iex），所以跑之前值得读一遍。README 明确写了它会做这些事：
- 写宿主的 agent 配置文件。 对 Kiro 会把
OUROBOROS_RUNTIME=kiro写进~/.kiro/settings/mcp.json；对 Copilot 会把 MCP server 注册进~/.copilot/mcp-config.json。README 特别说明这些由 setup 管理的位置是可信的，而项目里的.env属于不可信输入，这个键在那里会被忽略。 - 按宿主各自的形态安装产物：Codex 得到 rules 与 skills，Hermes 得到 skills，OpenCode 得到一个插件加一份
AGENTS.md，Pi 与 GJC 得到 bridge。ouroboros setup refresh会针对机器上实际存在的宿主重装一遍。 ouroboros uninstall被描述为移除全部配置、MCP 注册与数据。
README 没有说明的部分：遥测、凭证存储，以及任何对外端点的清单。这应当读作「未说明」，而不是任一方向的保证。README 也没有对循环所生成或执行的代码作任何沙箱承诺。
已知限制与文档内部的不一致
- 宿主数量与宿主清单对不上。 README 说 setup 会装进「你装了的那十三个」，随后却列了十四个：Claude Code、Codex CLI、GitHub Copilot CLI、OpenCode、Hermes、Gemini、Kiro CLI、Pi CLI、OMP CLI、Zcode、Goose、GJC、Antigravity CLI 与 Grok Build CLI。数量是不一致的，以具名清单为准更稳妥。
- 并非每个
ooo命令都有 CLI 对应物。 README 说明evaluate、evolve、unstuck、ralph、publish是通过 agent skill、运行时规则或 MCP 工具使用的，而不是直接一条ouroboros <subcommand>。 - 名字存在冲突，README 也两处作了澄清。 另有一个不相干的项目（Anton Razzhigaev 的作品）同样叫 Ouroboros，那个 agent 会重写自己的架构；README 声明两者没有共享代码，本项目是先锁定规格再执行。它另外声明与任何使用该名字的加密货币、代币或交易社区无关。
- 演示数字不是基准测试。 诸如「暴露出 12 个隐藏假设」或最终歧义度 0.15 这类数字，来自演示流程的终端录像与录屏。README 把它们当作演示，本条收录也不把它们当作实测结果。
- 活跃度数字是实时徽章。 README 的星数与活跃度图由 GitHub 数据生成，缓存「可能延迟更新」；正文没有给出任何数字，因此这里也不作声称。
- README 还提到 Claude Code 的保留命令问题（
/resume、/run、/status、/help、/config），这属于特定宿主的摩擦，而非普遍限制。
什么时候用它、什么时候不要用
当问题出在需求而不是代码上时用它：brief 含糊、范围一直漂移、变更的评价标准不是「看起来没问题」，或者与其后面返工不如现在花时间做面试。当你想让同一条规格先行的循环覆盖多个 agent 宿主时，它也算合适——这些宿主共享的正是 MCP 这一层，而从 DeepSeek Harness 出发，这个插件是最近的一条路。
任务很小且已经足够明确时不要用它。面试闸门和三阶段评估是刻意的摩擦，README 自己的说法是它们用来避免昂贵的返工，而不是为了让琐事变快。也不要把它当信任凭据：它会写你的宿主配置文件，安装器是一行 shell，README 没有任何你可以依赖的沙箱、遥测或端点声明。如果你今天就要它跑在原生 Windows 上，请按 README 把 Windows 当作实验性支持，并优先用 WSL 2。
命名也要理清：ooo 是 agent 内的 skill 形式，ouroboros 是 CLI，而这个名字另有别的项目在用。
FAQ
Ouroboros 只是一组 agent skill，还是一个真正的包？
是真正的包。它是 PyPI 上的 ouroboros-ai，README 链到了 pyproject.toml，代码树是 src/ouroboros/，同时提供 CLI（ouroboros）、MCP server/client 与终端 UI。ooo 命令是叠加在其上的 agent 内 skill 形式，而不是产品的全部。
本条收录的安装命令到底给 DeepSeek Harness 装了什么？
它指向 Ouroboros 仓库里的子目录 integrations/dsh-plugin，README 称之为 dsh-ouroboros 插件——不是 Python 包，也不是仓库的其余部分。装好之后可以在 DSH 对话里直接输入 ooo interview 或 ooo auto，ouroboros_interview 与 ouroboros_auto 工具会原生运行。
它和 DeepSeek Harness 是两个方向都支持吗？
README 两个方向都写了。插件方向把 Ouroboros 的面试工具放进 DSH 对话；另一个方向用 --llm-backend dsh 或 OUROBOROS_LLM_BACKEND=dsh 把 Ouroboros 自己的流水线接到 DeepSeek 模型上，底层驱动 Harness 的 ACP server。README 说该后端的额外要求在它的 DeepSeek Harness 指南里，而不是在首页。
它到底支持多少个 agent 宿主？
README 正文说十三个，列出来的却是十四个，所以这个数字应视为不一致。具名清单是：Claude Code、Codex CLI、GitHub Copilot CLI、OpenCode、Hermes、Gemini、Kiro CLI、Pi CLI、OMP CLI、Zcode、Goose、GJC、Antigravity CLI 与 Grok Build CLI。setup 只会装进它在你机器上实际探测到的宿主。
它会上报遥测或存储凭证吗？需要 API key 吗？
README 没有涉及遥测、凭证存储或对外端点，所以本条收录无法作任何方向的断言；它也没有提出 API key 要求。它明确写出的是 Python 版本下限、对 pipx 或 uvx 这类隔离启动器的要求，以及通过 ooo setup 与 ooo config 完成模型配置。