linkex.ai——第一個 Open Tally 實例

生產部署——閘道是什麼，以及讓「記下來的就是發生的」可信的工程。

linkex.ai 是一個生產級 AI API 閘道：40+ 上游供應商（OpenAI、Anthropic、Google Gemini 等）匯聚於單一 OpenAI 相容端點，按 token 計費、支持 agent 原生穩定幣支付、帶管理控制台。產品文件在 docs.linkex.ai。

它同時是 Open Tally 的第一個生產級實現：它服務的每筆可計費呼叫都獲得一張簽名回執、寫入本站描述的公開可驗帳本，承諾由 RFC 3161 令牌（DigiCert）固定時間，並每小時錨定到 Base 主網——上線以來每個錨定窗口都有一筆已確認的公開交易（實時統計）。

實例頁為什麼存在

協議保證記下來的東西無法被靜默修改或丟棄。而記下來的是否就是實際發生的，是實現側的工程性質——信任模型對此毫不含糊。這些頁面記錄 linkex.ai 如何承擔這份責任。其中沒有一條要求抽象的信任：每項措施要麼在帳本裡可見，要麼寫在交付對手方的規範裡，要麼可對照公開端點查驗。

計量的誠實

事務化捕獲。 結算扣費與回執出站事件在同一個數據庫事務內提交。不存在「錢動了、帳沒排」的窗口，來源事件上的唯一索引防止重複。這是對協議殘餘完備性缺口的工程回答：缺口無法靠密碼學閉合，就把它做到事務語義所允許的最小。
獨立 token 計數。 閘道不只抄上游報的 token 數，而是用自己的本地 tokenizer 並行計數，兩個數都記錄，並對照數據驅動的基線持續追蹤偏差。回執在簽名內容中記錄 tokenizer id/版本與計數模式（local / upstream / estimated / disabled）——每個數字都聲明自己的來源，閘道無法誠實計出的數會被如實標記，而不是洗白。
模型身分觀測。 閘道觀測上游實際服務的模型身分（可得時含權重 digest）並寫入回執；變更逐次告警。來源分級、絕不拔高——未觀測到的 digest 記為「未觀測」，不編造。
合成流量拒簽。 健康探針等非計費流量在 sequencer 入口即被拒絕，守住「鏈上每一筆都是真實計費事件」的論證。所有豁免路徑都被顯式計數並披露——豁免不靜默。
持續的自我對帳。 在任何對手方查帳之前，實例先查自己：逐筆交叉核對自己的計量與上游報數；供應商帳單先過一遍實例要求別人對它跑的同樣六項檢查；差異歸因到具名原因並附建議處置——歸因本身也被記錄，不在走廊裡了結。

金額的可重算

價格版本化。 合同價與價目表走 draft → active → superseded 生命週期；激活需要第二個人（職責分離）。回執記錄施用的是哪個價目版本。
匯率凍結。 匯率快照強制記錄來源與觀測時間並防寫——期間用了哪個匯率是凍結的事實，不是可事後調整的參數。
期間關閉即封帳。 會計期間關閉時計算匯總哈希並禁寫；調整與收款都校驗期間狀態。
調整走前門。 事後調整（退款、重開帳、對帳沖抵）本身就是佔序號的回執事件——連改帳都在帳本上。
算術只有一份實現。 計費路徑與驗證器調用同一份重算代碼，「記帳的」與「驗帳的」不可能漂移。

運營方的自我約束

配置變更寫入 append-only 審計日誌——UPDATE 與 DELETE 在 ORM 層被拒絕，不是僅僅「不提倡」。
危險開關需要兩名不同管理員（maker-checker）並填寫理由——控制這條規則的開關以同樣方式保護自己。
數據讀取也留痕（有界異步訪問日誌）：一個自身訪問史不可見的帳本，做「可見性」論證的地基未免奇怪。
fail-closed 密鑰：簽名密鑰解不開就拒簽，絕不鑄造替代——第二把密鑰會讓公開密鑰歷史說不清哪把簽了哪些回執。每條流的第一把密鑰只允許在單一節點上創建一次。信任模型把保管的極限說得與保證一樣直白。

有據可查的工程原則

構建歷史執行著一小組原則，值得寫出來，因為它們可對照帳本本身查驗：

已簽名歷史逐字不動——公式演進按分段代際分派；一次會破壞已簽一致性向量的改動被整體回滾、以新代際重做，而不是修補進歷史。
fail closed 優先——密鑰解不開 ⇒ 拒簽；必需主密鑰未設 ⇒ 拒啟動；證據可疑 ⇒ 拒出證。
單向門顯式化——密鑰加密遷移與錨定鹽都被記錄為不可逆，並設過門確認。
豁免不靜默——每條把事件排除出計費或回執的路徑都被計數並披露。
先暗跑、後武裝——新的校驗與錨定能力先以只記錄/影子模式運行，量測就緒後才開啟強制——「機制可用」是一個觀測結果，不是一個願望。