https://yennj12.js.org/yennj12_blog_V4/tags/gl-reconciliation/Recent content in GL Reconciliation on YennJ12 Engineering BlogHugo -- gohugo.ioen-usSat, 04 Jul 2026 11:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/anthropic-financial-services-intro-part3-example-zh/Sat, 04 Jul 2026 11:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/anthropic-financial-services-intro-part3-example-zh/講概念很容易流於空泛,所以這篇只做一件事:挑一個 Agent,走一次真實流程。 GL Reconciler 是 fund-admin 這條線裡最具代表性的 Agent——輸入是總帳(GL)和對帳來源, 輸出是「哪裡斷了、為什麼斷、該找誰簽核」,而不是一個自動幫你改帳的黑盒子。 一、核心問題:對帳為什麼還需要人做 GL 對帳的痛點不是「不會算」,是斷點的根因五花八門——可能是時間差(trade date vs settlement date)、可能是手續費分類錯誤、也可能真的是資料輸入錯誤。傳統做法是資淺 Analyst 一筆一筆比對兩份表,慢且容易漏看模式。 傳統對帳流程 ───────────────────────────── GL 匯出 ──┐ ├─ 人工逐筆比對 ──▶ 找到斷點 ──▶ 憑經驗猜根因 ──▶ 簽核 對帳來源 ──┘ │ 耗時、容易漏看跨期模式 GL Reconciler 要解決的,不是取代這個判斷,而是把「找斷點」和「聚類根因」這兩步自動化,把人力集中在真正需要判斷力的「這筆該怎麼調整」上。 二、三個演進階段 Phase 1(POC / 單一基金,< 10K 筆交易月對帳量) ┌─────────────────────────────────────┐ │ Claude Code + gl-reconciler plugin │ │ 手動貼上 GL 匯出 + 對帳來源 CSV │ └──────────────┬────────────────────────┘ ▼ Claude 讀兩份表,找斷點,輸出 markdown 報告 新增元件:僅 financial-analysis 核心 + gl-reconciler plugin,無連接器 成本/複雜度:幾乎零,一個 Analyst 手動貼資料跑 解決的問題:比人工逐筆比對快,能聚類出「同一根因造成的一批斷點」 未解決的問題:資料要手動匯出貼進去,無法排程,無歷史對照 Phase 2(MVP / 多基金,10K–200K 筆/月) ┌───────────────┐ ┌───────────────┐ │ Fund Admin │────▶│ Egnyte/Box │ │ 系統匯出 │ │ (GP 報告來源) │ └───────────────┘ └───────┬────────┘ ▼ ┌─────────────────────┐ │ gl-reconciler Agent │ │ (Cowork,人在迴圈) │ └───────┬─────────────┘ ▼ 斷點清單 + 根因分類 + 待簽核佇列 新增元件:接上 Egnyte/Box 連接器自動抓 GP 報告,Cowork dispatch 讓多個基金的對帳可以並行跑 成本/複雜度:需要文件儲存連接器的訂閱/權限設定,人力成本從「逐筆比對」降到「審核聚類結果」 解決的問題:多基金並行處理,斷點根因有分類而非逐筆羅列 未解決的問題:仍然是互動觸發,沒有排程,月底集中跑時人力仍是瓶頸 Phase 3(Scale / 機構級,200K–1M+ 筆/月,多基金多幣別) ┌──────────────┐ │ 排程觸發 │ (每日/每週跑增量對帳,而非月底一次性) └──────┬────────┘ ▼ ┌─────────────────────────────┐ ┌──────────────────┐ │ Managed Agent │─────▶│ callable_agents │ │ (agent.