公告與研報監控 Agent：變動時自動提醒你（Chinese original）

盯公告這件事，人工做只有兩種結局：每天花半小時翻披露平台，或者乾脆不翻、錯過重要披露。自動化做也有兩種結局：設計得好，它只在有實質變動時找你；設計得差，它每天推三十條無關緊要的通知，兩週後你把整個頻道靜音——然後在靜音的第三週錯過一份盈利警告。

這篇講的就是怎麼做出第一種。核心設計目標只有一句話：重要的事一定到得了你眼前，不重要的事一定到不了。 這兩個「一定」的實現方式完全不同：前者靠白名單與漏報自檢，後者靠分級過濾。先講清楚：本文是資訊管線的設計方法，不構成對任何公司或證券的評價與建議。

監控什麼：三類目標、三種節奏

目標類型	來源	節奏	雜訊特徵	漏報代價
公告與法定披露	披露易（HKEXnews）等法定披露平台	交易日每天都有新檔案	檔案數量中等，雜訊在「不重要的例行公告」	高——重大事項的第一手來源
研報	券商研究、獨立研究服務	不定期	觀點重複度高，同一事件多家跟進	中——錯過的是視角，不是事實
新聞與輿情	財經媒體、社交平台	即時	雜訊最高，轉述失真多	低——新聞能追到的，公告通常也有

三類目標的處理原則是同一條：下層做觸發，上層做確認。 新聞觸發關注，回到公告確認事實；研報觸發問題，回到財報驗證數字。資訊源的可信度分層見港股調研資訊源地圖：披露易、年報與第三方數據。

開始前的合規提醒：自動化抓取前，先確認目標網站的使用條款與爬蟲協議，控制請求頻率、避免對網站造成負擔；抓取內容的個人使用與再散布授權因來源而異，機構使用請諮詢你所在機構的合規部門或合格顧問。本文只描述設計方法，不替任何具體抓取行為背書。

抓取策略：輪詢、去重與失敗處理

增量輪詢。 定時抓取目標的「列表層」（公告標題清單、研報目錄），與本地的已知集合比對，只對新項目做後續處理。頻率按目標節奏設定：法定披露可以每小時一巡，新聞類可以更高頻，研報每日一巡通常夠用。

識別與指紋。 每個檔案需要兩樣東西：

機制	用途	說明
穩定識別子	判斷「是不是同一份文件」	優先用來源提供的正式標識（檔案連結、編號）；沒有穩定識別子時，用內容雜湊值當指紋
內容指紋	判斷「同一份文件有沒有被改過」	識別子相同但指紋變化，代表出現了修訂版——這本身是一個值得通知的事件，而不是新事件

實現載體。 三條路線，按團隊技能與目標複雜度選擇：

路徑	代表工具	適合	注意
無代碼工作流平台	n8n 等	快速原型：定時觸發、抓取、條件分支、推送通知，一天內能拼出來	對帳這類需要狀態的邏輯在節點裡彆扭；自託管時別忘了平台自身的備份
自寫腳本＋排程	Python 加 cron 類排程	生產級：日誌、對帳、心跳完全可控	需要維護能力；腳本悄悄死掉的風險要靠外部心跳兜住
Agent 框架	OpenClaw 等	沒有固定版面的頁面、需要「瀏覽—理解—決策」迴路的來源	成本與不確定性都更高；白名單規則部分仍應落在確定性代碼裡

實務上通常混合：抓取、去重、白名單匹配這些確定性步驟用腳本或工作流平台；只有灰區分類與摘要經過模型。能用規則做的不要交給模型——這是成本問題，更是可靠性問題：規則的行為可預測、可審計，模型不是。

失敗處理，比成功處理更重要。 監控系統最常見的實際故障不是誤報，而是悄悄死掉：網站改版導致解析失敗、反爬機制擋住了請求、排程任務停了——然後系統每天「正常」報告沒有新東西。三道保險：

心跳：即使沒有任何新項目，每天固定發一條「今日巡檢正常，抓到 N 條、新增 0 條」的心跳訊息。心跳消失本身就是警報
抓取日誌：每次輪詢記錄時間、抓到數量、失敗原因。事後要能回答「那天為什麼沒抓到」
對帳：每天用另一個獨立路徑（例如人工打開列表頁掃一眼）核對系統抓到的總數與來源實際總數是否一致。對帳差異觸發警報——這是「漏報自檢」的機械化版本

變動偵測：過濾雜訊的三道閘

不是每個新檔案都值得通知你。過濾分三道閘，順序執行：

閘一：去重。 比對識別子與指紋，擋掉重複出現的同一份文件。純機械操作，不需要 AI。

閘二：分類。 把新項目分成三堆，每堆的預設處理不同：

分類	處理	類別示例
白名單（高關注）	立即推送	業績公告、盈利警告或正面盈利預告、配售與供股、回購、更換核數師、董事變動、重大訴訟、關連交易、停牌與復牌、與除牌程序相關的公告
灰區	進入每日摘要	一般業務公告、無法一眼歸類的文件
低優先	只歸檔，不推送	例行股東大會通告、標準格式的定期申報文件

分類的實現紀律：規則先行，模型墊後。 白名單關鍵詞（標題匹配）直接命中、直接推送，不經過任何模型判斷；只有關鍵詞無法分類的項目，才交給 LLM 做初篩。原因很直接——模型偶爾會把「更換核數師」歸成人事類例行公告，而關鍵詞規則不會。LLM 初篩的結果要保存分類理由，供定期校準（見後文「平衡術」一節）。

閘三：影響評估。 對白名單與灰區項目，生成「與既有認知的差異」：這家公司的這個公告，相對於你已有的記錄（上一份業績、最近的股權變動）改變了什麼。輸出的是一句差異描述，例如「本季首次出現盈利警告類公告」，而不是任何買賣方向的評價。

摘要與影響評估：LLM 的用法與界線

摘要環節最容易引入幻覺，界線要畫死：

規則	理由
每條摘要必須附原文連結與披露時間	摘要的價值是幫你決定「要不要點開原文」，不是替代原文
只拿到標題時，摘要必須標注「僅基於標題」	模型會用標題腦補內容——腦補的部分就是幻覺（見 AI 在金融場景的幻覺風險：三種最貴的錯誤）
摘要不得添加原文沒有的因果與動機	「因銷售下滑導致盈警」——如果公告沒寫原因，這半句就是編的
過濾只影響推送，不影響存檔	所有抓到的項目全量歸檔。分類錯誤的代價因此從「永久丟失」降為「晚點看到」
LLM 不擁有「丟棄」權限	模型可以決定優先級，不能決定存在性。刪除權只在人

影響評估的進階做法是把新公告與你的研究記錄（你的第一個投研工作流：從提問到可回溯結論裡的證據卡）做比對：新資訊支持還是削弱既有結論？比對不上的，列為「待人工裁定」。這一步產出的是研究線索，不是交易信號。

推送管道與通知分級

三個層級，各走各的管道：

層級	管道	時效	內容規格
立即	IM 機器人或郵件	分鐘級	分類＋三句摘要（標注資訊完整度）＋原文連結＋披露時間
每日摘要	固定時間一封郵件或訊息	日	灰區與低優先項目的清單，每條一行；附當日心跳與對帳結果
每週歸檔	本地存檔或知識庫	週	全量索引、抓取統計、分類校準報告

立即推送的訊息格式，給一個具體示例（內容為教學用假設示例）：

【立即｜盈利警告類】教學用假設公司（代碼 00000）
摘要：披露盈利警告類公告。全文尚未取得，本條僅基於標題。
披露時間：2026-09-30 17:08
來源：披露易公告列表（附連結）
系統狀態：今日巡檢 3 次正常；對帳一致；本條為白名單規則命中，未經模型分類。

最後一行是刻意設計的：讓每條通知自帶「我是怎麼產生的」——規則命中還是模型分類、基於標題還是全文。這樣當某條通知事後被證明有誤時，你能立刻定位問題出在哪一層，校準也才有對象。

兩個細節決定這套系統能不能長期活著：

安靜時段：立即推送設免打擾窗口。如果你發現自己需要半夜接收某一類通知，把它單獨列為「喚醒級」，其餘一律排隊到早上——喚醒級清單越短越好。
通知的固定格式：每條通知的結構一模一樣（什麼事、摘要、來源、時間）。格式穩定，你的眼睛才能訓練成「掃描器」，十秒決定一條通知要不要展開。

平衡術：「不漏」與「不煩」怎麼同時成立

這兩目標表面衝突，實際上是靠不對稱設計化解的：

原則	做法
誤報便宜，漏報昂貴	白名單寧可過寬：多推一條「不重要的更換董事公告」的代價是十秒鐘；把盈利警告歸檔的代價不可估量。分類猶豫時，一律向上歸檔
過濾可撤銷	全量存檔意味著任何過濾錯誤都能被挽回——被過濾的項目永遠查得到
漏報有自檢	心跳＋每日對帳（上一節），確保「系統沒抓到」與「沒有新東西」兩種狀態可以區分
分類會退化，定期校準	每月回顧一次：當月每日摘要裡有沒有「事後證明重要」的項目？有，就把對應模式升進白名單。這個回顧是防止三道閘隨時間失效的唯一機制
通知疲勞有指標	如果你連續一週沒打開每日摘要，說明灰區太寬——正確動作是收緊分類，錯誤動作是靜音頻道

還有一個常被忽略的雜訊源：同一事件的重複報導。一份公告觸發了立即推送，隨後幾家媒體跟進報導，又各自觸發新聞告警——你收到五條通知，講的其實是同一件事。解法是事件級去重：新資訊先嘗試掛到既有事件上，只有「事件出現了新事實」才值得再次推送，單純的轉述與評論只進歸檔。

一句話總結這套設計哲學：把「不漏」交給機械（白名單、全量存檔、對帳），把「不煩」交給分級（推送、摘要、歸檔），兩邊都留下校準的迴路。

AI 會在這裡出錯

出錯形態	場景	防法
摘要失真	添加原文沒有的因果、把「可能」寫成「已經」	摘要與原文並存；抽樣人工比對；重要公告永遠讀原文
標題腦補	只抓到標題就生成內容豐富的摘要	強制標注資訊完整度；「僅基於標題」的摘要不得包含內容細節
分類失誤	把白名單類別歸入例行公告	關鍵詞規則優先於模型；分類理由留檔供校準
時間戳混淆	把抓取時間當披露時間，新舊公告排序錯亂	兩個時間分開存；通知中顯示披露時間
監控本身悄悄死掉	抓取失敗但系統不報錯	心跳、日誌、對帳三道保險
用舊記憶補充現況	模型在摘要裡混入訓練資料中對該公司的舊印象	摘要只允許基於本次抓到的內容生成，禁止引入外部記憶

最後提醒：監控 Agent 的輸出屬於「發現層」，不屬於「結論層」。它告訴你哪裡發生了變化，變化意味著什麼，仍然要走你的第一個投研工作流：從提問到可回溯結論的查證流程。把監控管道直接接上交易決策，是所有環節裡最危險的自動化。涉及證券資訊發布與使用的監管面向，見投研 AI 的合規邊界：免責、留痕與可回溯。

下一步

港股調研資訊源地圖：披露易、年報與第三方數據：監控目標的完整資訊源地圖與可信度分層。
金融數據 API 調研：為 Agent 框架注入市場數據能力：用數據 API 取代部分抓取的選型研究。
財報電話會議紀要轉投資要點：監控抓到業績公告之後，下一條高價值資訊流——財報電話會議的處理方法。
AI 在金融場景的幻覺風險：三種最貴的錯誤：摘要環節所有防線的理論基礎：三種最貴的幻覺錯誤。