20260922 會議記錄

:::info

• 所有會議記錄

  編輯當週文件

  準備

  總結

• 9/22 (二) 20:00
• NPO Hub 出席：bil, mrorz
• 線上出席：nonumpa. ggm
• https://meet.google.com/mrz-dgrd-pri :::

上週待辦

• 追蹤 devops#12：開放 user-driven 爬蟲存取政策
  • Document AI bot policy and 2026-09-20 verified-bot rule change（opened 09-20）
  • TODO: 追蹤流量帳單
• 追蹤 devops#17：rumors-site / line-bot-zh / url-resolver 記錄 request header，並修 rumors-api GraphQL log header 迴歸
• 追蹤 devops#18：記錄 Cloudflare Analytics retention（31 天 / 3 天）與 Logpush Enterprise-only 限制
• cofacts.ai session 週報：GGM 手動貼到 #collab；MrOrz 準備 DC bot 之後自動化
• nonumpa：繼續研究 FB / IG preview 仍是登入畫面的問題
  • threads 要特別處理：title 不能拿 og-title，順便把還沒改完的一起改
• MrOrz：cofacts.ai 前端先打底（frontend skill + storybook），之後請 yutin 接手
• rumors-api#388 vector search：補 userId / appId backfill
  • 部署後驗證 embeddings 真正寫入 / 讀取（schema 已於 9/14 上 staging & production）
• 推進 ai#118（URL resolver pre-flight 檢查，補 hyperlinks 參考邏輯）
• MrOrz：cofacts.ai 125s 硬砍根因調查（需 Cloud Run / Vertex log；交接 prompt 已備）
  • https://github.com/cofacts/ai/pull/145 –> see below
• Staging VPS OS 太舊（Ubuntu 16.04 / 2018 kernel），Node 18+ 完全跑不動，排 OS 升級
• 十月小聚（10/3 or 10/17，華梵大學板橋中心）：比鄰問場地
• 建議：site-tw CPU/Mem p99 長期貼近 1 vCPU / 1GB 上限，列入擴容評估

移至 https://github.com/orgs/cofacts/projects/12 追蹤：

• rumors-site#631：/articles 新增「我送出的訊息」filter（接 selfOnly）
• cofacts/ai#144：claim_sources provenance 檢查（verifier ∪ investigator），實作時附 ADR
  • 新增 Jev 分析
  • 在 https://github.com/orgs/cofacts/projects/12 追蹤
• cofacts/ai#141：V1 editorial preference memory（Memory Bank，接續 #125）

url-resolver

https://github.com/cofacts/url-resolver/pull/74

• Threads 410 或 redirect 到 ?error，url-resolver 會回應 unavailable
• 可以設定 puppeteer 可以設定 UA
• 還有一些最佳化的東西我需要再 review 一下，希望這個禮拜可以 ready for review

cofacts.ai

125s timeout issue

https://github.com/cofacts/kb/blob/main/src/meetings/2026/20260914.md#1-network-errorllm-%E5%91%BC%E5%8F%AB%E5%9C%A8-125-%E7%A7%92%E8%A2%AB%E7%A1%AC%E7%A0%8D

@mrorz：關於 network error，調查出來了 —— AI 助手在查證資料時（呼叫 Google 搜尋／讀取網頁階段）有時連續 100 多秒沒有回應傳到瀏覽器端，而 Cloudflare 預設在 125 秒沒收到資料就自動斷線，導致對話被默默中斷、前端只顯示「連線錯誤」。修法：伺服器在等待查證結果時每 20 秒主動送心跳訊號維持連線，已寫測試並驗證，PR：https://github.com/cofacts/ai/pull/145

• fix: heartbeat the SSE proxy to survive Cloudflare’s 125s idle timeout（opened 09-14 / merged 09-17）
• release/20260917（released 09-17）

結論：目前沒有再看到 125s timeout 的問題。

修復部署時間：PR #145 於 09/17 20:02 UTC merge，透過 GCE rumors-deploy-cofacts-ai-1 container log 確認實際 restart/上線時間是 09/17 20:08 UTC（跟第一筆 Langfuse trace 時間吻合）。

結果對比： | 期間 | GENERATION spans | 125s/0-token 訊號 | | ——————————- | —————- | —————– | | 修復前（9/1–9/13，PR 引用數據） | 357 | 30（~8.4%） | | 修復前夕（9/15–9/17 20:08） | 133 | 0 | | 修復後（9/17 20:08–9/22） | 71 | 0 |

修復後最長的成功呼叫跑到 161.7 秒都沒被砍斷（過去這種長度一定會在 125s 附近被切），跟 heartbeat 生效的預期行為一致。也檢查過同期間沒有任何 level=ERROR 的 observation。

要注意的限制：修復上線後 5 天內，production 只有 3 筆真實對話 trace（9/17 晚上、9/18、9/21 各一筆；9/19、9/20、9/22 目前都還沒有流量），樣本量偏薄。統計上如果舊的 ~8% 發生率沒變，71 次呼叫全部沒中的機率只有 ~0.3%，所以這個結果有意義，但建議等流量多一點後再確認一次比較保險。

New data sources / data subagents

Follow up of https://github.com/cofacts/kb/pull/10 ‘s 專業能力 subagent

• docs(research): 中央社 CNA MCP 觀察報告 + research(cofacts.ai): 中央社 MCP 專業 Subagent 可行性與必要性評估（opened & merged 09-17）
• research(cofacts.ai): OpenFun 資料 Subagent 可行性與必要性研究（opened 09-17）

Related article issue

@老鶴：回報一則臉書 reel 查核案例，結果誤連結到「智心樂學苑」及「AI·智慧共享專案」詐騙網站，附 session 連結供 debug

發生了什麼

session ad213c61-… = trace 4cf56228…（9/11 04:45）

文章本身抓對了。 get_single_cofacts_article({"article_id": "39xxtbmws59px"}) 回傳的 article.text 就是老鶴那則 FB 連結 https://www.facebook.com/share/r/1DKq8u7eWj/?mibextid=wwXIfr，attachmentUrl: null。

問題出在同一包回傳裡的 relatedArticles（tools.py:90，relatedArticles(first: 10)）。totalCount: 333，前幾名長這樣：

score	id	text
475.2	2m6wqpc68t5jy	智心樂學苑仁輝督導是投資詐騙…以「AI‧智慧共享專案」名義詐騙民眾
475.2	1yccnacsk2swu	不要使用5G網路&石墨烯 / 5G的陰謀📡…
355.3	1wuvio9iluho4	Gillsee 嘖嘖募資問卷
237.6	14ikn74382v0p	https://www.facebook.com/share/r/1HycXWYWzZ/…
237.6	321j8s2lysubn	https://www.facebook.com/share/r/1SDhksx7T8/…

這份 relatedArticles 是純噪音：

• 第一名和第二名分數完全一樣（475.2），第二名是 5G 陰謀論。
• 第 4–6 名全是其他 facebook.com/share/r/... 連結、分數同為 237.6 ——相似度在比對的是 URL 樣板（share/r、mibextid=wwXIfr），不是內容。

原因就是這篇文章的 text 只有一個網址，沒有內容可比對，相似度搜尋就吐出任意高分結果。

然後 writer 把 relatedArticles[0] 當成了查核對象。 04:45:17 第一次呼叫 investigator 時，request 裡已經帶著「智心樂學苑」「仁輝督導」——在任何搜尋發生之前。最終 draft 整篇在講假投資詐騙，references 第一條就是 https://cofacts.tw/article/2m6wqpc68t5jy。

加重因素：04:45:09 verifier 第一次想去看那支影片就掛了（ValueError: Tool 'google:browse:urls' not found — 模型幻覺工具名），而 hyperlinks[].summary 只有 FB 登入牆的樣板文字。agent 對影片內容是零資訊，這個真空就被 relatedArticles[0] 填滿了。

relatedArticles 效益調查：跨 session 分析摘要

資料來源與抽樣方式

• 從 Langfuse 撈出全部 get_single_cofacts_article TOOL observation（475 筆），比對 production trace（invocation [cofacts_ai]，1072 筆 trace / 543 個 session），得到 468 次成功比對的文章查詢，涵蓋 267 篇不重複文章 / 389 個 session。
• 針對每次查詢，用「時間窗」把同一 session 內對應的 investigator / verifier / draft_factcheck_response 呼叫正確歸屬到「這篇文章」的那個回合（因為一個 session 可能連續查核好幾篇文章，naive 抓「session 內最後一次 draft」會抓錯）。
• 「是否為真近似重複」不是看 score，是我自己讀文字判斷：先用字元 bigram Jaccard 相似度粗篩，超過門檻的全部人工讀過原文 + 既有回應 + investigator 第一次請求 + 最終草稿。
• Harm（跑偏）偵測用兩種方法交叉：(a) 整體文字相似度比對、(b) 從 investigator 第一次請求抓出引號/書名號內的專有名詞，檢查是否只出現在某個 relatedArticles 節點、卻不在文章本身的 text/hyperlinks/attachmentUrl 裡。所有被標記的案例（35 筆）與全部「退化文章」（純網址/空文字，115 筆）都人工複核。

---

1️⃣ 理想情境出現頻率：真的近似重複 + 已有回應

理想：已有回應的 related article 可以協助 AI 更快回應，不用從頭搜尋

• 44 / 468 次查詢（9.4%），涵蓋 31 篇不重複文章 / 38 個 session，符合「relatedArticles 命中一篇內容真的相似、且已有 factCheckResponses」的理想情境。
• 不算罕見——大約每 11 次查核就有 1 次符合條件。

2️⃣ Writer 有沒有真的重用既有回應？

讀完全部 44 筆，沒有任何一筆在最終 draft_factcheck_response 的 references 裡引用相關文章本身或其回應——每次都是重新從外部新聞/政府網站/查核中心獨立查證。

• 長榮／五星旗事件（session a15f0e5b）：這個 session 裡總共有 6 篇「長榮拒掛五星旗」相關文章被查核。writer 只在 session 最前面（14:41–17:32）呼叫過 investigator（共 7 次），完整查證了一次事件細節；17:38 之後陸續進來的 4 篇幾乎相同的文章，都沒有再呼叫 investigator，而是直接呼叫 draft_factcheck_response，草稿裡的 claim_sources 引用的還是同一批稍早查到的 voacantonese、ltn 等外部新聞網址。 換句話說，省下重複查證工的是 writer 自己這輪對話的記憶，不是 Cofacts 的 relatedArticles.factCheckResponses——那些既有回應從頭到尾沒有被引用或提及。這其實是更乾淨的證據：即使在「同一事件重複進來、理論上最該用 relatedArticles 抄捷徑」的情境下，被拿來抄捷徑的也不是 relatedArticles。
• 唯一看起來「可能有受影響」的案例：兩篇互為 relatedArticles 的國旅補助文章（trace bf09d833 / trace 60be3a61）——文章本身只是裸網址，但 investigator 第一次請求裡的具體金額/日期，只在對方既有回應裡出現過。即便如此，writer 仍自行找政府網站重新驗證，沒有直接引用。
• 結構上也解釋了為什麼：
  • writer_citations.py 的 cite_as 機制只把「完整工具結果」往上遞給 sub-agent，並不支援單獨引用 relatedArticles 裡某一個節點——就算 writer 想重用，目前也沒有乾淨的路徑可以「引用」它。
  • relatedArticles 底下的 factCheckResponses 確實沒有 query reference（也沒有 hyperlinks）。所以就算某篇 relatedArticles 命中的真的是近似重複、且已有回應，writer 拿到的也只有回應的純文字，沒有 reference（來源網址）可以驗證或引用。
    • 對一個被要求「每個 claim 都要附來源網址」的 fact-check writer 來說，這種沒有出處的文字本來就不能直接拿來用。
    • 這解釋了為什麼 44 筆理想情境裡一次重用都沒發生，不只是行為選擇，是資料本身不夠用。
  • 理論上 writer 是可以「用 relatedArticles 挑到的 id 再呼叫一次 get_single_cofacts_article」去換到完整、帶 reference 的回應——但這需要 prompt 明確引導它這樣做，目前完全沒有這種指示，而且我查過的 468 次呼叫裡，沒有任何一次出現「拿 relatedArticles 的 id 再重新查一次」這種呼叫模式。

結論：理想情境發生率 ~9%，但實際被重用的比例 ~0%。

3️⃣ 影響估算（Harm rate）

• 兩種偵測法 + 全部 35 筆標記案例、115 筆退化文章人工複核後：只找到你原本回報的那一個案例（39xxtbmws59px，智心樂學苑／仁輝督導），兩筆 trace 都對得上（4cf56228... / 45fe7252...）。其餘標記全部是偵測方法的假陽性（台/臺異體字、詞語切分問題）或是「relatedArticles 內容其實補足了原文 OCR 缺漏、主題仍然相同」的正常情況（例如中聯油脂事件、城鎮韌性演習）。
• 但深入看這篇文章完整的 relatedArticles 清單後，發現一個更值得注意的現象：同一組「誘餌」文章（智心樂學苑投資詐騙 / 5G石墨烯陰謀論）在至少 6 篇不同、互不相關的裸 facebook.com/share/... 網址文章的 relatedArticles 裡，都以幾乎一模一樣的分數（474～475）排在最前面——這代表命中的是「網址格式雷同」，不是「內容雷同」，而且是穩定重現的現象，不是單一巧合。
  • 這 6 篇裡只有 2 篇（都是 39xxtbmws59px）真的被寫進最終草稿跑偏；另外 4 篇因為 writer 另外透過影片/連結內容解析成功抓到真實內容，沒被誤導。
  • 換句話說：目前實際造成錯誤產出的機率是 2/468（0.4%），但「潛在暴露」——同一組誘餌被排進前幾名——遠高於此，只要文章本身內容解析也失敗，就會踩到。

4️⃣ score 能不能當篩選依據？

• score 與「真的相似」有中度相關（整體 Pearson r ≈ 0.55，短文字子集 r ≈ 0.63），且在同一次查詢的 10 筆候選裡，若真的存在近似重複，86%（81/94）情況下會排第一名——當作「同一批候選裡的排序依據」還算堪用。
• 但跨查詢完全不可比：同一組誘餌文章對 4 篇不同的查詢文章，分數都落在 474～475（幾乎沒有查詢特異性）；且「不相關」配對的分數最高可達 647，超過任何一筆「真的重複」配對的最高分（645）。你原本觀察到的 475.2 平手，是這個現象的典型代表，不是特例。

5️⃣ 退化情境是否可以事先辨識？

• 可以，而且辨識條件很乾淨：468 次查詢裡有 90 次（19%）文章本身是裸網址；目前找到的所有實際跑偏案例、以及那組「誘餌」的完整暴露，百分之百都落在「裸網址」再加上「爬到的 hyperlink 內容也是空的／登入牆樣板文字」這個子集合裡。
• 其他大部分裸網址文章（YouTube／Threads 連結），hyperlink 爬蟲其實爬得到真實標題／摘要，investigator 也確實是照著這些真實內容去查證，沒有受 relatedArticles 誤導。

建議（分兩部分）

A. 讓 ~9% 的理想情境真的發揮作用：教 AI 去查 related article

在 get_single_cofacts_article 的 docstring / hint in JSON response ／writer 的 prompt 裡加一句指示：若判斷 relatedArticles 某節點與本文章是同一則訊息且已有回應（factCheckCount > 0），應該用該節點的 id 再呼叫一次 get_single_cofacts_article，把它當主文章查一次，換取完整、帶 reference、可以 cite_as 的版本，再決定是否直接沿用或需要補充驗證。

純 prompt 層改動，不需要動 GraphQL query。

B. 跑偏案例（實測發生率很低，~0.4%，但有結構性暴露）：加防護

雖然目前只抓到你原本回報的那一個真實案例，但同一組「誘餌」文章在至少 6 篇不同的裸網址文章裡都排到前幾名，代表這不是單一運氣問題，是裸網址／爬蟲失敗這個情境下相似度搜尋本身就不可靠。防護要點：

1. 防護點放在查詢文章本身內容是否可信，不是 relatedArticles 的 score：article.text 是空的或裸網址、且爬到的 hyperlinks[].summary 也是空的／登入牆樣板文字時，該次呼叫直接不回傳 relatedArticles（或只回傳 id+score，拿掉 text／factCheckResponses），等文章本身的真實內容（影片/圖片/連結）被其他方式解析出來後才提供。
2. 不要把 score 當跨查詢的信心門檻——已證實同一組不相關文章對不同查詢可以拿到幾乎相同的高分，且不相關配對的最高分還超過真近似重複的最高分。score 只能在同一次查詢的 10 筆候選裡做相對排序。
3. docstring 加一句防呆提醒：relatedArticles 裡的實體/主張，若在文章自己的 text/hyperlinks/attachmentUrl 裡找不到對應佐證，不應該被當成本文章已確認的事實去查證。

這兩部分互不衝突、也互相獨立——A 是要讓工具「真的有用」，B 是要讓工具「不會出事」，可以分開排優先序或分開驗收。

[!Note] 開票：待在 cofacts/ai 建立 issue（本次 session 因 repo 權限限制尚未建立，待補） 好像不常出現，priority 不高

Vector search

• Review https://github.com/cofacts/rumors-api/pull/400
• Review https://github.com/cofacts/rumors-api/pull/388

Langfuse v4 upgrade

[!Note] 下週

• Langfuse v3 在 2027 年 1 月 EOL
• v4: merges trace into observation
• Migration guide: https://langfuse.com/self-hosting/upgrade/upgrade-guides/upgrade-v3-to-v4

追蹤票：devops#23

Cofacts article classifier

[!Note] 下週

https://github.com/cofacts/kb/pull/29

小聚籌備

• 10/03 (六) 板橋中心（新北市板橋區文化路二段 242 號 6 樓 604 室）//(華梵大學推廣教育處/龍山寺文化廣場)一般教室604

• 週五早上
  • KKTIX 行前通知：提醒時間、使用電腦而非手機

    Hello 你好，

    本週日就是查核志工培訓囉！

    志工培訓需要大量查詢資料，請自備筆電 💻 與充電器 🔌 並帶著愉快的心情來參加。帶順手的平板也可以的！Cofacts 資料庫也有很多影音謠言，請自備耳機唷 🎧！

    🕒 時間：（六）14:00 - 17:00 📍 地點：新北市板橋區文化路二段 242 號 6 樓 604 室

    費用全免，會很準時開始。若不克前往，記得取消報名 :)

    Cofacts 真的假的 查核協作 VIP 臉書社團在這裡 👉 https://www.facebook.com/groups/cofacts Cofacts 真的假的 查核協作 Discord 在這裡 👉 https://cofacts.tw/discord 說你會來查核小聚優先加入 ＝Ｄ

    感謝你的閱讀。

    那麼明天見囉😊

    比鄰敬上

  • 55次小聚 KKTIX https://cofacts.kktix.cc/events/cofactseditor55
  • 開場使用材料更新（含 cofacts.ai 介紹：期待的用法、點開 tool call 看細節、複製 fact check response 或繼續 tune、查出處是否存在、遇到錯誤記得倒讚）
  • 準備 Slido #cofacts
• 當日準備 / 攜帶
  • 樓下用的標語
  • 拍照用大布條
  • 貼紙
  • 黏土
  • 手板
  • 講義
  • 一次性杯子
  • 延長線（場地有 6 個插座、現場兩條延長線，建議再帶 5 條）
  • Wifi 機（rt-ax57 go + 電源線）
  • 多帶一條 type-c 公公線 for dongle 的電
  • 備用 wifi 機
• 13:00 - 場佈
  • 簽到（問飲料）
  • 排桌子椅子
  • 投影位置？
  • 麥克風
  • 延長線佈置
  • 門口黏引導牌
  • WIFI：佈機，手機 USB 選擇網路分享，等待白燈亮；用 ASUS Device Discovery 確認可連線到 ASUS
  • 投影的電腦用 google chrome 開好（投影片 / Bignum / KKTIX / Slido admin / Slido / 開場影片 / BGM / Analytics）
• 14:00 - 14:20 開場：放長影片（8min）、場地、Slido、Cofacts 機器人系統簡介
• 14:20 - 14:40：引導 註冊網站、介紹評價現有回應
• 14:40 - 14:50：實作評價（從網站找訊息按讚）
• 14:50 - 15:10 介紹補充資訊
• 15:10 - 15:40 實作補充資訊、自我介紹、休息（閒聊「看到覺得最好的回應、覺得哪裡好」）
• 15:40 - 16:10：介紹撰寫新回應
• 16:10 - 16:40：實作撰寫新回應（挑選「一篇」最有興趣的回應）
• 16:40 - 17:00 介紹 RSS、社群、合照

場地想法摘要 — 板橋中心（下次小聚同場地）

[!Note] 下週

來源： 20260811 籌備、20260818 小聚檢討

• 地址/容量：新北市板橋區文化路二段 242 號 6 樓 603 室，30 人教室
• 桌椅：9 張 3 人桌，中間前面改 2 人桌（因夾著投影機）；延長線從教室後方往前拉，避免絆腳；門旁邊有 4 個連桌椅位子最擠；門外可設接待桌
• 飲食：教室內可以吃東西，但用畢需整理乾淨
• 麥克風：場地只能提供一支麥克風
• 電力/插座：場地有 6 個插座，現場備 2 條延長線，籌辦時建議再多帶 5 條
• WiFi：網路整體穩定，但曾有一人連不上（wifi router 最後設定只有 5 個裝置連線）
• 出席狀況：報到率高，大多數人準時抵達
• 原始檢討 HackMD：https://g0v.hackmd.io/abknsfWxQXur2rqM09LPXg（小松果）

---

我先前錯誤地把 6 月的青職基地場次當成「上次」，已用 8/16 板橋中心的正確資料替換。之前給你的 GitHub/Discord 週報（09-14～09-21）部分是正確的、不受影響，若需要我可以重新整併成一份完整貼文。

Scientist update

• 上週太多，這週只有 7 個 [name=ggm]
• 用輪數判斷是否成估，這個指標可以用 [name=ggm]
• 常見問題：草稿沒產生、引用有問題 etc [name=ggm]
• 會把資料整理到 langfuse dataset，等等或明天會整理，測試會用 dataset 來測 writer & verifier

上週重點整理（2026-09-14 ～ 2026-09-21）

GitHub 活動

cofacts/ai

• feat(adk): add standalone Verifier and Writer evaluations（opened 09-14）

cofacts/cofacts-ai-eval

• Evaluate conversation prefixes with swappable judge providers（opened & merged 09-14）
• Score delivered drafts independently from conversation quality（opened & merged 09-14）
• Add dated usage review archive（opened & merged 09-14）
• Publish 30-day draft and conversation evaluation results（opened & merged 09-19）
• Add reusable weekly usage review skill（opened & merged 09-20）
• Add reproducible Cofacts evaluation skill（opened & merged 09-20）

cofacts/takedowns

• #347 新增 2026/09/11 移除隱私資訊公告，並新增隱私下架處理規範 AGENTS.md（merged 09-14）
• 多筆 spam 帳號下架 PR：#348、#349（merged 09-17）、#350、#351、#352（merged 09-18）、#354（merged 09-20）、#355（merged 09-19）
• Document PR format/process rules generally, not just for privacy cases（opened 09-18 / merged 09-20）

cofacts/devops

• takedown skill: always link taken-down accounts to community builder（opened 09-17 / merged 09-20）

cofacts/kb

• doc: add 20260914 meeting notes（opened 09-14 / merged 09-15）

cofacts/rumors-api

• Issue #403: 逐字稿 fallback 模型仍用 gemini-2.5-flash：Gemini 2.5 停售前需評測並決定替代方案（opened 09-16）

Discord 重點討論

dev

@yutin：https://github.com/cofacts/rumors-api/pull/400 修改完成

Cofacts 正式環境狀態報告（2026-09-15 ~ 2026-09-22）

一、GCE 主機（cofacts-prod）每日資源使用率

日期	CPU (min|avg|p95|max)	Mem (min|avg|p95|max)	Swap (min|avg|p95|max)
09-15	13.00% | 20.01% | 26.63% | 43.68%	64.77% | 67.80% | 70.34% | 74.83%	43.38% | 46.47% | 48.77% | 49.83%
09-16	10.04% | 18.86% | 24.90% | 43.74%	64.59% | 67.43% | 69.63% | 73.07%	44.75% | 46.86% | 48.62% | 49.99%
09-17	11.34% | 18.98% | 27.92% | 41.22%	63.94% | 68.00% | 70.47% | 71.28%	41.81% | 45.98% | 48.41% | 49.86%
09-18	11.79% | 17.44% | 23.84% | 45.71%	65.09% | 67.65% | 70.00% | 71.84%	42.00% | 45.00% | 47.77% | 48.13%
09-19	9.94% | 16.16% | 23.20% | 41.97%	63.91% | 67.16% | 69.56% | 70.60%	45.75% | 47.91% | 49.82% | 50.60%
09-20	10.04% | 19.27% | 26.59% | 39.54%	64.35% | 67.27% | 69.60% | 71.92%	45.66% | 48.03% | 50.00% | 55.38%
09-21	10.53% | 18.60% | 24.62% | 39.28%	64.31% | 67.32% | 69.21% | 51.51%	46.35% | 47.84% | 50.69% | 51.51%

即時狀態（查詢當下）：Load average 0.72/0.66/0.74（138 天未重啟）；記憶體 31GB 中已用 21GB、可用 9.7GB；Swap 4GB 中已用 2.0GB；磁碟使用 70%（47G/67G）。

觀察：CPU、Mem、Swap 一週內都非常穩定，沒有異常尖峰或趨勢性上升，屬正常運作範圍。Swap 平均維持在 45-48%，這與 Elasticsearch 常駐佔用約 19.2GB（占總記憶體 62%）有關，屬長期已知型態，非本週新增異常。

二、Cloud Run 服務清單

11 個服務全數正常運作（✔），近期部署者皆為 rumors-site-deployment 服務帳號，最近一次部署為 cofacts-ai（09-17）。

三、Cloud Run CPU/Memory 使用率（p50 = 正常範圍，p95/p99 = 穩定性觀察）

服務	CPU 正常範圍 (p50)	CPU 尖峰 (p99 峰值)	Mem 正常範圍 (p50)	Mem 尖峰 (p99 峰值)	備註
site-tw	0.05–0.14	1.01（滿載）	0.76–0.81	1.01（滿載）	p99 CPU/Mem 連續多日卡在 ~101%，疑似觸及配置上限，建議留意尖峰時段是否有節流(throttling)
site-staging-tw	—	0.28	0.68–0.84	0.93	穩定
site-staging-en	—	0.29	0.59–0.81	0.87	09-19 起才有資料，穩定
line-bot-ja	0.005–0.02	0.46	0.39–0.42	0.67	09-20 有一次 CPU/Mem 同步尖峰
line-bot-en	0.007–0.01	0.36	0.38–0.40	0.43	穩定
cofacts-ai	0.015	0.36	0.06	0.10	資源用量低且穩定

觀察與建議：site-tw 是唯一 CPU/記憶體 p99 貼齊 1.0（100%配置上限）的服務，且連續四天（09-18~09-21）數值完全相同，代表尖峰時段可能持續被節流。建議後續追蹤該服務的請求延遲是否受影響，必要時提高 CPU/記憶體配置。

四、GCE 主機 Process 層級 Top 資源消耗者

Process	CPU 穩定性（相對值）	Mem 平均/峰值	備註
Elasticsearch (java)	最高，日均降低趨勢（09-15→09-21 CPU avg 由高降低，09-20 有尖峰）	平均 ~19.2GB / 峰值 19.8GB	常駐最大宗記憶體用戶，與上週（09-01~09-09，平均 ~19.2GB）持平，無異常成長
node /srv/www/server.js	中等，標準差 ~2-3.6萬	平均 343-375MB / 峰值 992MB	峰值較上週（最高 1.45GB）明顯下降
node /srv/www/build/index.js	中等，標準差穩定	平均 143-148MB / 峰值 811MB	與上週相近
cloudflared tunnel	低，穩定	—	穩定
dockerd	低，穩定	—	穩定
Chromium (puppeteer 截圖用)	短暫尖峰，單次執行	峰值 290-411MB（單次）	屬預期的短生命週期截圖行程，非常駐

跨週比較：與上週（09-01~09-09）相比，Elasticsearch 及 node server.js 的 CPU/記憶體峰值都略為下降，整體資源用量呈穩定或微幅改善，沒有發現持續成長的資源消耗趨勢。

總結

本週（09-15~09-22）GCE 主機與 Cloud Run 服務整體運作穩定，沒有明顯異常。唯一值得留意的是 site-tw Cloud Run 服務 CPU/記憶體 p99 連續多日貼齊配置上限（~101%），建議後續觀察尖峰時段是否有節流影響使用者體驗。