ouroboros

About

Ouroboros 是一个开源的本地优先 Agent OS，核心主张是两件事：意图没想清楚之前，不让 AI 开始写代码；验收标准的判分断言不进交给执行 agent 的成功契约（success contract），让它没法看着答案刷分。它坐在 Claude Code、Codex CLI 等 13 个编码运行时前面，把「写一句话就让 AI 开干」换成可复现的五段循环：苏格拉底式访谈 → 不可变规约 → 执行 → 自动验收 → 演化。 为什么做这个项目 AI 写不好代码，很多时候不是模型不够聪明，而是需求本身就是模糊的。 你说「做个任务管理 CLI」，它就自己猜数据模型、存储方式、优先级规则和 ID 生成策略。每一项都「不算错」，但都不是你想要的。等你 review 到第三个文件才发现方向不对，只能返工：写 prompt、被猜、返工，循环往复。 所以这个项目动的是输入侧：在意图足够清楚之前，不让它开始写代码。 和同类项目相比，最不一样的地方 现在「AI 编程工作流」类的项目不少。Ouroboros 把「什么时候可以开始写」和「什么时候可以停」都变成了数字，而不是感觉，并且认真处理了一个很少有人处理的问题：怎么防止 agent 学会刷分。 1. 访谈不靠「差不多了」结束，靠一个阈值 模糊度被量化成加权清晰度的反值： Ambiguity = 1 - Σ(clarityi × weighti) 模糊度高于 0.2 会挡住规约生成——是挡住，不是锁死；绕过它的办法是显式传入强制（force），屏幕上一直摆着这个选项。演化循环那头，最近两代的本体相似度 ≥ 0.95 会判定收敛，但那不是唯一的出口——停滞、反复出现的同类反馈、以及 30 代预算耗尽同样会让循环停下来。两道数学关卡，README 里把背后的想法写成一句话：没想清楚之前不要写，没稳定之前不要停。 2. 评估三阶段递进，先便宜后贵 Mechanical（免费、确定性检查）→ Semantic → Multi-Model Consensus。能在第一层否掉的，绝不送去烧 LLM 判分的钱。 3. 不让 agent 看见判分标准 大多数框架会把验证命令和断言原样贴进 worker 的 prompt，动机很朴素：让它知道会被怎么检查。但 agent 一旦看得见断言，糊弄断言就永远比真正实现需求更省力。你以为在测能力，其实在测抄答案。 Ouroboros 的处理有两点： 两条泄露路径一起堵。正向路径不再渲染 verifycommand / outputassertion。反向路径（失败原因里的断言 repr() 顺着重试 prompt 流回去）也用一个断言安全的提示构造器过滤掉，连命令输出那 2000 字符的尾巴都要过滤。堵住主路径、忘了日志尾巴，泄露口还是开着的。 不提供开关。「披露级别」的配置项被明确否决了。信息屏障一旦可以关掉，就会在某个赶进度的下午被关掉，而且没人会发现，因为分数看起来更好了。 那 agent 卡住了怎么办？给提示，不给答案。下一轮的指令是从这次会话实际做了什么重建的（工具调用轨迹、证据清单、验证器结论），而不是从断言里抄的。 4. 失败不是终点，但循环必须能停 被评估拒绝的结果会自动进入有预算上限的演化循环，下一代的力气集中在没通过的验收标准上（代码里把标准切成 active 和 frozen 两组）。但冻结是集中力气，不是保证已通过的不会再挂——另有回归检测器专门盯上一代通过、这一代却挂掉的标准。不冻结的循环会反复把做对的东西改坏，表现为分数在两代之间来回跳。循环自带震荡检测和等级回退检测，专门识破这种假收敛；预算耗尽才报 BLOCKED。 这部分的完整设计（含取舍和被否决的方案）写在 RFC #1917 里。 其他 支持 13 个运行时家族：Claude Code、Codex CLI、OpenCode、Gemini CLI、GitHub Copilot CLI、Kiro、Hermes、Pi、Zcode、Goose、GJC、Antigravity CLI、Grok Build CLI 本地优先，MIT 协议 中文 README：README.zh-CN.md 一行安装： bash curl -fsSL | OUROBOROSINSTALLREF=ruanyf bash 装完后在你的 AI 编码 agent 里按顺序跑两条命令（ooo setup 只需一次）： ooo setup ooo interview "I want to build a task management CLI" 它不会立刻写代码，而是先反问：数据存在哪里、命令边界到哪、任务 ID 怎么指定……这些答完了，才会生成规约并进入执行。 中文逐章指南 安装、访谈、规约、执行、评估、演化、现有项目、故障排查、术语表、架构，一共 13 页，和英文版章节齐平。里面的每个数字都注了出处文件，你可以直接对着源码核。其中「故障排查」那章有 -32000 启动失败的处理，英文版目前还没有。

Discovery history

1. Show HN

   Mar 3, 2026 – Mar 10, 2026 · 2 observations

2. HelloGitHub·用户投稿

   Aug 9, 2026 · 1 observations

3. 阮一峰周刊·用户投稿

   Aug 9, 2026 · 1 observations