Halro 是什么与核心对象模型

Halro 是一个 Go 单二进制的自托管 LLM 网关。它坐在你的应用和上游模型服务之间，统一处理凭据、预算、路由、脱敏、审计和用量核算 —— 没有外部数据库、没有缓存、没有 CDN，也不在浏览器里存任何密钥。

模型调用链路

管理员在控制台里按这个顺序走一遍：

Credential → Provider → Deployment → Route → Project → Gateway Key

模型调用链路

对象	是什么
Credential	上游服务商的密钥，AES-256-GCM 加密存放
Provider	一个上游接入点，绑定一份不可变的 Provider Profile
Deployment	「这个 Provider 上的这个模型，能做什么」
Route	把一个公开别名映射到一个或多个 Deployment
Project	预算、限流、CIDR、Token Guard、脱敏策略的归属单位
Gateway Key	发给应用的凭证，gw_ 开头

应用只看得见其中两样：一个 Gateway Key（链条末端），和一个模型别名（它属于 Route）。上游服务商是谁、用的哪个模型标识、密钥是什么，应用一概不知道 —— 这是设计目标，不是副作用。

v0.8.2 起，Provider 还可以选择一个 Admin 管理的 Outbound Proxy。它不是调用链中的业务资源， 而是 Provider 的可选出站路径：代理认证由 Vault 加密，代理不可用时不会静默改为直连。一个 Route 如果同时包含代理连接和直连连接，就跨越了不同的出站信任边界，必须在上线前单独评审回退行为。

运行治理链路

运行治理在 Project 内增加四个对象：

Work Unit → Run → Request → Provider Attempt
     └──────────────────────────────→ Outcome

运行治理链路

对象	是什么	权威来源
Work Unit	最终只计算一次业务结果的工作对象，例如一张工单或一次代码修复	Accounting Ledger
Run	完成 Work Unit 的一次执行，可包含多个请求、重试和 fallback	Accounting Ledger
Request / Attempt	一次客户端请求及其一个或多个 Provider 尝试	Accounting Ledger 与 Usage 派生视图
Outcome	受信验收方按照冻结的 Definition 版本提交的结构化业务结果	Governance Journal

一个 Work Unit 可以有多个 Run。第一次执行失败后可以关闭该 Run，再在同一 Work Unit 下创建 新 Run；最终业务结果只计算一次，但单位结果成本包含这些 Run 的全部 Attempt。

Halro 不编排 Agent，也不替业务系统判断成功。它负责在 Provider I/O 前执行 Project 与 Run 双重预算准入，保存可核对的成本归属，并在报表读取时将成本与 Outcome 按 Work Unit 合并。

请求进来之后发生什么

客户端 / SDK  →  协议门面（OpenAI / Anthropic 兼容）
              →  鉴权 / 策略 / 预算 / 脱敏 / 核算
              →  能力感知路由  →  版本化 Provider Profile
              →  SafeTransport  →  上游

其中两条不变量值得先知道：预算预留必须先落盘，才会发出上游请求；一旦响应字节对客户端可见，就不再静默切换 Provider。

准备把这组对象配置成第一条真实链路时，继续阅读 首次配置 Admin Console。

v0.9 产品与路由配置

录入凭据前选择确切的Provider 产品；配置后查看路由暂停与 Advisor 结论。应用需要发现公开别名时，再同时授予 inference 与 discovery。