绯金初思长明 / THE EVERLIGHT HOUSE
← 返回项目档案
Open-source engineering system · Active · eos-1.15.1

EOS

为严肃工程工作而生的本地优先操作系统。

GitHub ↗

EOS：把工程纪律变成可以运行的系统

EOS（Engineering Operating System）不是项目管理模板，也不是一组漂亮的提示词。它是一套放在仓库里的、本地优先的工程工作流系统：让人、工具与 Agent 在同一套可验证的状态、证据和门禁上工作。

它的真正问题不是“怎样让 Agent 写更多代码”，而是：当决策由概率性系统参与时，我们如何知道它为什么可以继续，以及它什么时候必须停下来？

一台没有云端依赖的工程机器

EOS 的核心 CLI 位于 .github/eos/eos.mjs，零外部依赖、跨平台、可离线运行。它不要求团队先购买一套 SaaS，也不把治理权交给一个远端仪表板。

仓库里的 .eos/ 保存项目声明、工作流配置、门禁定义、证据、交接包、release manifest 和 append-only ledger；.github/ 则承载 agents、prompts、instructions、skills、hooks 与 EOS CLI。工程规则因此跟着代码走，能够被复制、审查、分支和恢复。

它真正管理的是三种状态

EOS 不用一个含糊的“项目状态”覆盖所有事情，而是把状态拆成三个 scope：

  • Product baseline：项目是否完成发现、需求、PRD、UX 与架构基线；
  • Change / story：一项功能、缺陷修复、Spike、热修复或治理变更走到哪里；
  • Release：这一组已验证的变更是否可以作为一个有明确边界的发布候选。

.eos/local/active-work.json 只保存当前机器的关注范围，不保存 gate 结果，也不拥有任何权威性。真正的状态由仓库中的 artifacts、evidence、ledger 与 workflow policy 推导出来，因此不会因为某个人忘记更新 prose summary 就悄悄漂移。

十一道门，不是十一句口号

标准工作流从 G0 activation 开始，经过 discovery、requirements、PRD、UX、architecture、story、verification、release、telemetry，最后进入 iteration。每个 gate 都有机器可执行的检查；不适用必须被记录为 NOT_APPLICABLE，而不是静默跳过。

证据还会被检查新鲜度和绑定关系：代码树、配置、测试结果与 release manifest 变化后，旧证据不能继续冒充当前结论。next 给出唯一的推荐下一步，resume 恢复当前阻塞点，check 执行并记录门禁，transition 拒绝不合法的状态跃迁。

EOS 还把异常路径纳入模型：SPIKE 默认不可合并；HOTFIX 可以在有记录、会过期的 waiver 下暂时绕过部分门禁，但 verification 永远不可豁免；waiver 必须有风险负责人、补偿控制和期限。

四道本地防线

  1. 规则层：十类 instructions 按技术栈与工作场景分层，避免一条巨大 prompt 统治所有文件；
  2. Agent 与路由层：agent-map 将动作交给明确的 primary agent 或 prompt；
  3. Hooks 与验证器层：危险操作阻断、秘密扫描、配置校验、文档一致性与项目门禁在本地执行；
  4. 证据与账本层：gate evidence、transition event、release manifest 与 handoff 形成可追溯链条。

这四层不是为了制造流程感，而是为了让“我记得已经做过了”不再等同于“系统可以证明已经做过了”。

确定性软件与 Agentic 软件，不能用同一把尺子

EOS 明确分开两条路径：

  • 对传统 SaaS，重点是 API / REST、RBAC、多租户、数据库状态、可靠性与可观测性；
  • 对 Agentic / LLM 产品，重点增加 prompt-as-artifact、工具白名单、评测集、G-EVAL、模型成本与 token 追踪、认知重试和 LLM observability。

这不是把 Agent 当成更聪明的 CRUD。EOS 承认它的概率性，并用评测、证据和边界约束它，而不是用一句“模型应该理解”掩盖不确定性。

provider adapter 的克制

EOS 可以通过 provider adapter 向外部权威询问，例如 GitHub governance 或 attestation，但外部系统不是本地状态的主人。适配器的意义是补充证据，而不是把工程判断黑箱化。

同样，EOS 的能力边界也写在文档里：它能提供本地规则、命令、状态推导、门禁和交接上下文；它不能替团队完成组织级 branch protection、CODEOWNERS、审批基线或真实生产权限配置。哪些事情没有被验证，必须诚实地留在“没有被验证”里。

为什么它属于绯金书房

绯金书房保存的不只是完成品，也保存我们如何让复杂事情重新获得秩序。EOS 是 niaodian 目前最完整的一次回答：

不让 Agent 的流畅掩盖证据的缺席；不让流程的完整掩盖判断的缺席；不让一次成功掩盖系统无法恢复的事实。

它是一套可以复制到下一个项目的工程骨架，也是一种我们希望长期坚持的工作伦理。

从哪里开始

如果你想实际使用 EOS，可以从公开仓库的 README、Quickstart 和 User Manual 开始。模板支持固定 release tag 复用，也可以通过 node .github/eos/eos.mjs next 进入日常循环。

访问 niaodian/eos GitHub 仓库