Agent 开发圈子里有一个大家都不愿承认但心知肚明的问题：我们花在和 prompt 较劲上的时间，可能比实际编码还多。
Q00/ouroboros 的 README 上只写了一句话，但分量很重：
Agent OS: Stop prompting. Start specifying.
什么思路
ouroboros 的核心想法是：用**声明式规格（specification）**来定义 Agent 的行为边界、工具权限和输出格式，而不是靠自然语言的 prompt 反复调试。
这和目前主流的 Agent 开发模式有本质区别：
- prompt 模式：你写一段自然语言描述你希望 Agent 做什么，然后反复修改直到它"差不多理解"了
- spec 模式：你用结构化的规格语言定义输入、约束、工具、输出格式，Agent 按规格执行
类比的话，prompt 像是在用口语教一个聪明但容易跑偏的实习生做事；spec 像是给这个实习生一份 SOP，照做就行。
技术实现
ouroboros 提供了一套规格定义语言（具体语法需要看仓库文档），允许你声明：
- Agent 可以访问哪些工具和能力
- 输入数据的格式和约束
- 输出的结构和验证规则
- 错误处理和回退策略
这些规格被编译成 Agent 运行时可以理解的配置，而不是直接喂给 LLM 的自然语言。
为什么值得关注
如果你经历过这样的循环——改 prompt、测试、发现输出不符合预期、再改 prompt、再测试——你会立刻理解 spec 模式的吸引力。
Spec 模式有几个天然优势：
- 可版本控制：规格文件是代码，可以 git diff、code review
- 可复用：一套规格可以跑在不同的模型上
- 可测试：规格定义了明确的输入输出边界，单元测试成为可能
- 可审计：Agent 的行为不再藏在自然语言 prompt 的黑盒里
早期阶段的风险
ouroboros 目前 3,614 颗星，周增 332。它还很新，规格语言还在迭代，社区生态几乎没有。
最大的不确定性在于：规格语言的表达能力是否能覆盖真实场景中 prompt 能表达的所有意图。有些任务确实更适合用自然语言描述——比如创意写作、模糊探索、开放式研究。ouroboros 的定位更像是"精确执行型 Agent"的基础设施，而不是通用 Agent 的替代品。
如果你是那种"受够了 prompt 工程"的开发者，ouroboros 值得 fork 下来看看。它可能不是最终的解决方案，但方向是对的。
主要来源：