對局平衡重做 ＋ 敵方 agent 移到 0G Compute，做出「整場都是同一位 agent」的證明

[k66inthesky]

兩件事，第二件是第一件查下去之後發現的連鎖問題。

---

一、對局平衡：玩家原本是「必輸」

用搜尋器把這局玩到底之後發現：對上會下棋的對手，玩家勝率是 0%。 不是操作問題，是兩個結構問題。

1. 火力性價比不對稱。 壓制傷害只看攻擊力總和，所以真正的貨幣是「每點算力換到多少攻擊力」：憶哨兵 1 費 2 攻，遺忘者的雜訊 1 費 3 攻。同樣的算力，它每條迴廊都比你高一截。

2. AI 是後手，而且看得到你這回合的部署。 原本是玩家部署完才把盤面送去問 agent —— 它拿到你的答案卷才作答。在「逐條迴廊比火力」的規則下後手幾乎必勝。

而原本的壓制是贏者全拿（多 1 點攻擊力就拿滿 2 點），使平衡變成離散跳躍：把哨兵調到 3 攻，結果直接從「必輸」跳成 100% 和局（雙方火力永遠打平，誰都不受傷）。

三件事必須一起改

改動	作用
壓制傷害 → min(2, ⌈差/2⌉)	讓平衡從離散變連續，數值才調得動。上限仍是 2 點，沒有任何迴廊變得更危險
憶哨兵 2 → 3 攻	補上算術劣勢
改成同時出牌	回合一開始就用「玩家部署前」的快照問 agent，按結束回合才 await

實測（每組 300 場，雙方都挑最好的一手、各 25% 失誤）

設定	勝 / 敗 / 和	核心差
原本	6% / 84% / 10%	−7.4
只改同時出牌	8% / 86% / 6%	−7.8
只改傷害公式	3% / 85% / 12%	−8.3
傷害公式 + 同時出牌	5% / 89% / 6%	−10.1
三個一起改	34% / 40% / 27%	−0.7

單獨改任何一項都沒用 —— 遞增傷害不是解方，是讓數值可以被調整的前提。

參數敏感度：min(2,⌈差/2⌉) 43/35/21 ← 採用；min(3,⌈差/2⌉) 39/37/24；min(3,⌈差/1⌉) 33/37/30；min(3,⌈差/3⌉) 17/61/22。失誤率 10%→40% 勝率穩在 28–38%，不是刀鋒。

雙方都下得更好時（失誤 10%）同時出牌的價值才明顯：勝率 29% → 37%，和局 35% → 28%。

瀏覽器實跑： 笨打法（每回合 1 張哨兵）→ 12:0 慘敗；好打法（零重刃破平手＋哨兵佔空迴廊）→ 5 回合勝，3:0 收尾。技術真的會影響結果了。

---

二、TEE：原本那個說法不成立

我們宣稱用了 TEE，但跟玩家對打的 agent 走 OpenAI，TEE 只掛在戰後旁白那一段，而且沒有驗 attestation。所以「TEE 驗證了對手身分」當時是空話。

要讓它成立，三件事缺一不可：

1. 敵方 agent 預設改跑 0G Compute（AI_PROVIDER 預設 openai → 0g）。

2. 每回合封存證據，串成鏈，封進記憶碎片：

欄位	綁住什麼
boardHash	它看到的盤面
responseHash	供應商回的原始文字 —— 刻意不是解析後的結果，解析後才算等於在證明我們自己的程式
signature / signer / measurement	enclave 簽名與公鑰

鏈存進碎片的 teeChain，會被錨定上鏈的 SHA-256 蓋住 —— 第三方拿鏈上摘要就能重驗整場，不是只能相信我們的伺服器。

3. 驗證與分級（POST /api/og/same-agent）：

等級	意思
attested	全簽 + 同一把公鑰 + 對得上 attestation 的 measurement（enclave 等級）
signed	全簽 + 同一把公鑰，但沒拿到 attestation
changed	有簽名但公鑰中途換過 —— 否定結果，正是「agent 被換掉」的樣子
consistent	沒有（或只有部分）簽名，只有供應商與模型一致 —— 我們伺服器的紀錄而已
none	沒有紀錄，或供應商／模型本身就換過

刻意不回傳單純的 true/false。 把「只是紀錄一致」講成「已驗證」是這個功能最容易犯、也最不該犯的錯 —— 那比沒有這個功能更糟。

前端

結果畫面新增「TEE 驗證 · 是同一位 agent 嗎」按鈕與面板：徽章按等級變色，逐回合一格燈（同一把公鑰＝藍、換過＝橘、沒簽名＝空心），下面攤開簽名覆蓋率、模型、供應商、公鑰、measurement。只有 attested 拿得到藍燈。

瀏覽器實跑三條路徑：

沒有金鑰      → none      「沒有任何回合的紀錄」
七回合同一把  → attested   ok ok ok ok ok ok ok
第 5 回合換掉 → changed    ok ok ok ok changed ok ok

修掉一個訊息 bug：公鑰中途換過時原本落到 consistent，訊息寫「供應商沒有回傳可驗證的簽名（2/2 回合有簽名）」—— 自相矛盾，而且把最該警告的狀況講成中性。現在是獨立的 changed 等級。

⚠️ 這個 PR 唯一的不確定處

0G 把簽名與 attestation 放在哪個欄位、標頭叫什麼名字，我沒辦法在建置環境裡實際打一次確認（*.0g.ai 在那裡連不到）。所以抽取器不押寶在單一欄位名上：標頭與 JSON 樹都走訪一遍，看到像簽名／公鑰／measurement 的鍵就收。

抽不到就回報抽不到。 最壞情況是畫面顯示 consistent（未驗證，僅紀錄一致），不會出現假的綠燈。

上線後要確認實際等級，設好 OG_COMPUTE_API_KEY 打一場，然後看 /api/og/same-agent 回的 level。如果是 consistent 但你確定 0G 有簽名，把 /api/agent 回應裡的 evidence 貼給我，我照實際欄位名調整。

🤖 Generated with Claude Code

https://claude.ai/code/session_015NBxaWtzqEX3i8NvoZEeq3

---

Generated by Claude Code

[Copilot]

🟡 Changes recommended

The new “same-agent” verification path can fail in normal use due to oversized attestation payload forwarding and currently contains misleading verification/matching logic that risks incorrect “attested/signed” messaging.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

This PR rebalances core combat fairness by changing suppression (“壓制”) damage scaling and shifting the AI opponent to “simultaneous play” so it can’t see the player’s current-turn deployment. In parallel, it strengthens the “same agent for the whole match” claim by defaulting the enemy agent to 0G Compute, collecting per-turn TEE evidence into the shard, and adding an API + UI flow to verify and display the evidence chain.

Changes:

• Reworked suppression damage to scale with lane attack difference (min(2, ceil(diff/2))) and buffed “憶哨兵” atk 2→3.
• Changed turn flow so the enemy agent starts thinking at turn start (pre-player-deploy snapshot) and is awaited only at end-turn.
• Added TEE evidence extraction/sealing, shard persistence, and a /api/og/same-agent + /api/og/attest verification UX.

File summaries

File	Description
README.md	Documents new balance rules, simultaneous play, and attestation endpoint usage.
public/js/story.js	Updates briefing text to reflect new suppression rule + simultaneous play.
public/js/rules.js	Implements new suppression damage function/constants and buffs “憶哨兵” atk.
public/js/main.js	Starts AI request at turn start; accumulates teeChain; adds “same agent” verification panel flow.
public/js/ai.js	Plumbs evidence from /api/agent into the front-end decision result.
public/index.html	Adds UI button and panel for TEE “same agent” verification results.
public/css/style.css	Styles the TEE verification badge, per-turn indicators, and metadata panel.
functions/api/og/tee.js	New: evidence extraction, per-turn sealing, and chain-level verification logic.
functions/api/og/shard.js	Persists teeChain into the shard (hashed + bounded fields).
functions/api/og/same-agent.js	New: POST endpoint that normalizes inputs and returns a per-turn + overall verdict.
functions/api/og/attest.js	New: fetches provider attestation (configurable endpoint) and extracts key/measurement.
functions/api/og/_shared.js	Defaults enemy AI provider to 0G Compute (AI_PROVIDER default 0g).
functions/api/agent.js	Switches default provider to 0G; seals per-turn evidence using raw provider response text.
.env.example	Updates defaults/docs for AI provider and adds OG_COMPUTE_ATTESTATION_URL.

Review details

Suppressed comments (1)

functions/api/og/tee.js:154

• verifyChain 的 reason 文案在「有 attestation 但公鑰不匹配」時仍會說「沒取得 attestation」，而且也容易讓人誤解為已驗簽（實作只做欄位一致性比對）。建議把 attested/signed 的說明改成不過度主張，並涵蓋 attestation 不可用或不匹配兩種降級原因。

    level === 'attested'
      ? '每回合都有簽名、同一把 enclave 公鑰，且對得上 attestation 的 measurement'
      : level === 'signed'
        ? `每回合都有簽名且出自同一把公鑰，但沒取得 attestation${noAttest}，無法證明那把金鑰長在 enclave 裡`
        : level === 'changed'

• Files reviewed: 14/14 changed files
• Comments generated: 3
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.