开源｜TeaQL Registry：用 Rust 做一个面向 AI Agent 与 CI/CD 的多格式制品仓库
内容提要
TeaQL Registry 是基于 Rust 的多格式制品仓库，作为 AI 沙箱和 CI 节点内的 L1 缓存，支持 14 种格式，采用 S3 存储与 SHA-256 去重。TeaQL 框架提供集中租户隔离、类型化分页查询、完整实体审计、事务前 Mutation Policy 审批，以及区分空值与未加载的 E 表达式。项目已开源，采用 Apache-2.0 许可。
延伸解读
定位：L1 缓存而非主仓库替代
TeaQL Registry 明确不替代 Nexus 或 JFrog 等企业主仓库，而是部署在 AI 编码沙箱、构建节点或集群内部，承担高频、短生命周期的中间制品交换与缓存。它作为靠近 Runner 的 L1 Registry，只将最终验证通过的版本提升到中心仓库，从而减少网络延迟、限流和长期仓库的清理压力。
多租户隔离：集中策略而非分散编码
多租户隔离通过 TeaQL 的统一执行入口 RequestPolicy 实现，在每条查询交给数据服务前自动注入租户条件。业务代码无需手写 filter_by_tenant，只需传递包含租户信息的 context。PAT 也绑定 tenant_id、user_id 和 username，服务端会重新校验，确保隔离是默认的基础设施能力。
变更治理：事务前审批与审计链
TeaQL 5.0.5 在事务开始前生成不可变 MutationPlan，交由 MutationPolicy::review 审查。策略可要求审计原因、限制操作数量，并通过 id、version、fingerprint 匹配批准记录。未安装策略或未精确批准会产生治理告警，而策略拒绝会终止保存，避免部分数据落库。审计事件记录策略身份和变更摘要，使规则批准可追踪。
E 表达式：区分空值与未加载
TQ 的 E 表达式保留 Value、Null、NotLoaded 三种状态，避免将漏写 select 的编码错误误判为业务空值。eval() 遇到 NotLoaded 会立即失败，or_if_null 只为真正的数据库 NULL 提供默认值。当前 E facade 已覆盖 Asset 的标量、ContentRepository 和 AssetBlob 前向关系，但部分手写 Service 尚未迁移，跨关系读取时建议优先使用 E 表达式。
Q&A
TeaQL Registry 是什么？它和 Nexus、JFrog 有什么区别？
TeaQL Registry 是一个用 Rust 构建的多格式制品仓库，目标不是替代 Nexus 或 JFrog 这样的企业主仓库，而是部署在 AI 编码沙箱、构建节点或集群内部，承担高频、短生命周期的中间制品交换与缓存。它作为靠近 Runner 的 L1 Registry，只将最终验证通过的版本提升到中心仓库。
TeaQL Registry 支持哪些制品格式？
目前支持 14 种制品格式：Docker Registry v2、Maven2、npm、PyPI、Cargo、Go Modules、NuGet、Swift Package Registry、Dart Pub、RubyGems、Composer、Conan 2、Hex，以及 Raw/Generic。
TeaQL Registry 如何实现多租户隔离？
隔离在 TeaQL 的统一执行入口 RequestPolicy 中集中实施。每条查询在交给数据服务前都会经过 enforce_select，策略从可信 context 取得当前租户，并将租户条件与原查询合并。业务代码只需传递 context，无需手动拼租户条件，隔离是默认发生的基础设施能力。
Mutation Policy Approval 是什么？它如何工作？
Mutation Policy Approval 是对应用自定义写策略的版本化批准。TeaQL 5.0.5 在 Checker/Fix 和 Graph Planning 后生成不可变 MutationPlan，Runtime 在开启数据库事务前将计划交给 MutationPolicy::review。策略通过后，Runtime 向可信的 MutationPolicyApprovalProvider 查询批准记录，批准必须匹配 Policy 的 id、version 和 fingerprint。未安装客户 Policy 时允许写入并产生 MUTATION-POLICY-001；安装但未精确批准时产生 MUTATION-POLICY-002；Policy Deny 会在事务开始前终止保存。
TeaQL 的 E 表达式解决了什么问题？
E 表达式区分三种状态：Value（已加载且有值）、Null（已加载但业务为空）、NotLoaded（未预加载，是程序错误）。eval() 遇到 NotLoaded 会立即失败，or_if_null() 只为真正的数据库 NULL 提供默认值，避免将漏写 select 的编码错误误判为正常空值。
如何快速启动 TeaQL Registry？
镜像和 .env 准备好后，执行 docker compose up -d 即可启动。首次部署需先克隆仓库、复制 .env.example 为 .env 并设置 POSTGRES_PASSWORD 和 S3_SECRET_KEY。启动后可访问 Web Console（http://localhost:8081/）、REST API、Prometheus Metrics 和帮助页面。TUI 可通过 cargo run -p registry-tui 运行。管理员初始密码默认随机生成，也可通过 ADMIN_PASSWORD 显式设置。
TeaQL Registry 使用 Rust 带来了哪些好处？
Rust 让协议适配、元数据服务和 Blob 流式传输可以在一个进程内完成，并将资源生命周期和错误路径前移到编译期处理。Axum/Tokio 负责 HTTP 与异步 I/O，TeaQL 负责领域模型、权限和可审计的数据变更，PostgreSQL 保存元数据。服务端和 TUI 都可构建成独立二进制，适合构建集群或受限网络环境，且启动时没有 JVM 或脚本运行时的预热过程。
TeaQL Registry 的存储和管理功能有哪些？
服务端支持 S3 兼容存储（RustFS、MinIO、AWS S3）、文件系统和内存模式，Blob 使用 SHA-256 内容寻址去重。管理侧提供多租户、RBAC、PAT、审计记录、保留策略和孤儿 Blob GC，并带有嵌入式 Web Console 与独立的 Ratatui TUI。TUI 适合只有 SSH 的跳板机或构建节点，可查询服务状态、仓库和组件，执行搜索、检查、清理、GC 与临时令牌生成。
