01
◐
SHOWCASE
專案介紹
做了什麼 · 開放資料 × 地圖
2026.06.13 · SCIWORK SEMINAR
Mini Taiwan！
把台灣開放資料，交給 Agent 養成一套會自己長大的系統
當 Agent 能自己跑完整個循環，人的工作只剩 —— 出題與驗收
MIGU｜資料分析師
MINI TAIWAN PULSE · OPEN DATA · AGENT LOOP
OPENING · 開場P2 / 51
Hi, 我是 migu
資料分析師
- 大學碰過 GIS（都計背景），出社會走資料分析，很久沒再碰
DATA ANALYST · 3 TEAMS · GIS SIDE PROJECT
OPENING · 路線圖P3 / 51
今天的三段路
成果 → 系統 → 循環
02
⟳
SYSTEM
幕後系統
怎麼組起來 · 接收 → 觸發
本場核心
03
∞
AGENT LOOP
協作循環
怎麼自己跑 · 出題 → 交付
前半：做了什麼
後半：怎麼讓它自己跑起來
01
01 SHOWCASE · 專案介紹
專案介紹
從一個個的 CSV，到一張會呼吸的台灣地圖。陸、海、空全部疊起來。
01 SHOWCASE02 SYSTEM03 AGENT LOOP
SHOWCASE · 成果介紹P4 / 51
DAY 0 第一張地圖
起點 · KEPLER.GL
一切的起點
把一份 CSV 轉成 GeoJSON 拖進 Kepler.gl，就有了第一張地圖 ——「原來台灣有這麼多資料，原來轉成地圖並不難」。
KEPLER.GL · CSV → GeoJSON · 0 行程式
SHOWCASE · 成果介紹P5 / 51
CASE 1
Mini Taipei
捷運 → 台鐵 → 高鐵，三套軌道疊成一張會動的地圖。體驗到動態的魅力。
- TDX 開放資料
- 6 SYSTEMS
- 351 TRAINS LIVE
SHOWCASE · 成果介紹P6 / 51
SOLAR SYSTEM
CASE 2
衛星
用公開 TLE 推算衛星軌道，再延伸到太陽系 —— 同一套做法，只要有資料，都可以無限延伸。
CELESTRAK TLE · SGP4
SHOWCASE · 成果介紹P7 / 51
CASE 3
船舶
航港局 AIS 即時點位 —— 青藍光球 + 30 分鐘漸層拖尾，畫出台灣周邊海域的脈動。
- AIS 即時點位
- ~10 MIN 更新
- 台灣周邊海域
SHOWCASE · 成果介紹P8 / 51
CASE 4 · MINI TAIWAN PULSE
台灣的脈動
天空、海洋、大地、街道、清運 —— 五脈共動，疊成同一張會呼吸的地圖。第一次從「靜態 JSON」進化成「時空間資料庫」。
5脈共動
飛機 / 船 / 列車 / 公車 / 垃圾車
23圖層
十大分類 · 獨立 toggle
5,700+ 輛公車
TDX · 30s polling
SHOWCASE · 整合案例P9 / 51
農田範圍
灌排溝渠 · 水系
河川幹線
整合案例 · 農 × 水
三個部會的孤島，
疊成一張圖
農田、河川、溝渠、堤防、淹水潛勢同框
—— 把孤島 JOIN 起來，看到更多連結性。
400MB → ~5MB
PMTILES · HTTP RANGE REQUEST
SHOWCASE · 整合案例P10 / 51
整合案例 · 醫療資源
把民生疊在人口上，
缺口自己浮出來
醫院、診所、藥局、AED、長照點位 + 等時圈
—— 看見可及性，也看見醫療沙漠。
- NHI + 衛福部
- POI × 人口 × 等時圈
SHOWCASE · 整合案例P11 / 51
整合案例 · 大雨與災害
一條 Timeline，全部聯動
雷達回波、水庫、雨量、災害示警
—— 不同頻率在 RPC 層統一，一拖時間軸全部同步回放。
- CWA 雷達
- 雨量 10MIN
- 水庫日更 → 1 TIMELINE
SHOWCASE · 成果介紹P12 / 51
CASE 5 · DASHBOARD
Mini Taiwan Info
整理成主題儀表板網站 —— 基礎統計、人口、軌道運輸、航運、水資源、消防、醫療，一頁一主題。
- 7 THEMES
- OPEN DATA · CC BY 4.0
SHOWCASE · FLIGHT ARCP13 / 51
CASE 6 · 飛航軌跡
Flight Arc
把一段時間的所有起降，畫成一張航跡圖 —— 高度色變 + 光軌拖尾，疊起來就是機場的「指紋」。
- RCTP 桃園
VHHH
香港
EDDF
法蘭克福
RCTP
桃園
RJTT
羽田
每座機場，都有自己的指紋
同一支 API · 不同的城市性格
P14a / 74
SHOWCASE · 軌跡畫廊P14 / 51
世界最忙機場
亞特蘭大的「賽道」
五條平行跑道 + 等待航線，畫出像賽車場的幾何 —— 流量本身，就是一種形狀。
KATL · 1,839 TRACKS · WORLD'S BUSIEST
SHOWCASE · FLIGHT ARCP15 / 51
VIEWSHED — 高度越高、看得越遠
模式 ② · 跟隨模式
相機鎖定一架飛機，跟著它飛完全程
顯示航司 / 機型 / 註冊號 / hex，並依高度畫出該機在空中的可見扇形（Viewshed）。
SHOWCASE · FLIGHT ARCP16 / 51
模式 ③ · 進場管制區（空域）
規範長什麼樣
禁航區、限航區、管制盤的 3D 極光圖層。點限航區，顯示時段限制（如 2300–0200 UTC）。
- TW eAIP （PDF 手抄）
- UK OpenAIP（API）
SHOWCASE · 案例P17 / 51
案例 A · 倫敦機場體系
一座城市的天空，怎麼分流
EGLL / EGKK / EGSS / EGGW + 支線約 10 場 —— Heathrow 單點樞紐密集進場，周邊分流。
- EGLL — HUB
- 約 10 AIRPORTS
SHOWCASE · 案例P18 / 51
KLGA
KEWR
KJFK
案例 B · 紐約都會三角
同一個都會，三場輪轉
KJFK / KEWR / KLGA 日間輪轉、晚間集中 —— 對照倫敦的單點樞紐，是兩種城市性格。
SHOWCASE · 案例P19 / 51
日期 A — 戰前
日期 B — 戰時
案例 · 時間軸下的地緣事件
戰前、戰時、戰後 —— 航跡怎麼改道
同機場、不同日期對比。杜拜 OMDB（2,740 軌跡），看見迴避路線與戰後復甦。
同一支 API · 拉不同日期 · COMPARE 模式
SHOWCASE · 資料源對比P20 / 51
過境航路 — 天上的高速公路
起降 — 交流道
OpenSky 的拿手好戲 · 空域覆蓋
拉遠看，航路就像天上的高速公路
大面積無差別覆蓋是 OpenSky 的長處 —— 進場細節用 FR24、空域骨架用 OpenSky。
SYSTEM
02 SYSTEM · 幕後系統
系統，長這樣
前面看到的成果，背後都來自同一套資料系統 ——
接收 → 整合 → 生成 → 觸發
接下來，帶你看它怎麼一塊塊組起來。
01 SHOWCASE02 SYSTEM03 AGENT LOOP
SYSTEM · 我的這套流程P21 / 51
SYSTEM · 系統四步驟P22 / 51
// 我的系統長這樣
資料 → 整合 → 生成 → 觸發
每一步都可以單獨抽換 —— 整套不需要重蓋，加新東西也不會牽動其他層。
01
資料接收
DATA INTAKE
外部 + 開放資料源
標準化、驗證、入庫
標準化、驗證、入庫
→
02
知識整合
KNOWLEDGE FUSION
把零散資料變成
可推理的知識結構
可推理的知識結構
→
03
分析生成
ANALYZE & GEN.
推理、視覺化、報告
Pulse / Art / Brief
Pulse / Art / Brief
→
04
行動觸發
FEEDBACK LOOP
事件驅動 / 任務調度
自動回饋 · 形成閉環
自動回饋 · 形成閉環
// 接下來
逐個展開 —— 從資料接收的生命週期，到 Agent 怎麼用、應用怎麼長出來。
SYSTEM · STEP 01 · 資料接收P23 / 51
SYSTEM · STEP 01 · 知識庫
P24 / 51
資料接收 · 第一步
手動下載 → 上網找 → 系統化建構
A
// 最早期
手動下載
data.gov.tw 點 Excel
自己讀、自己存、自己想。
自己讀、自己存、自己想。
format.xlsx / .csv
where~/Downloads
limit人腦記憶
B
// 中期
上網找
API、PDF 報告、各縣市開放平台
—— 散落各處。
—— 散落各處。
sources22 縣市平台
extraNGO + 學術 + 民間
problem沒有索引
C
// NOW
結構化知識庫
每筆 metadata 標準化
存進 SQLite catalog。
存進 SQLite catalog。
sourcesdata.gov.tw
+ 所有縣市平台
+ 各部會平台
✓queryable 可自動化查詢
✓scalable 可自動化拓展
SYSTEM · STEP 02 · COLLECTORS
P25 / 51
資料接收 · 第二步
40+ 個 Collector，每天早上一份 Review
// 來源涵蓋
陸運YouBike · Bus · VD · Freeway
鐵路TRA Train (live) · Timetable
航運Ship AIS · Ship TDX
航空FR24 · OpenSky
氣象Weather · CWA Satellite · Rain
災害Earthquake · NCDR Alerts
太空Satellite TLE · Launch
水文Reservoir · River · Ground
空品AQI · MicroSensor
⚠連錯 3 次 立即發 Telegram 告警
📊每天早上 09:00 推送 Daily Review
// 每天 09:00 推送 Daily Review · Telegram
SYSTEM · STEP 02 · 知識整合P26 / 51
SYSTEM · AGENT · 規模的詛咒
P27 / 51
為什麼要 Agentic OSINT
規模的詛咒
data.gov.tw · 各縣市 · 民間 — 人類掃不完
52,891
+22 縣市平台 ~6–7 萬筆（含重疊）
+民間 / NGO / 學術 還沒算
= 你的人腦掃不完 → 這就是 LLM 該介入的地方
SYSTEM · AGENT · 盤點 × 關聯
P28 / 51
把資料轉成 LLM 可觸及的形式之後
交給 Agent，盤點 → 關聯 → 產出
// 前置條件
資料 → LLM 可讀
統一目錄 · metadata · 結構化欄位
→
// AGENT 動腦
大量關係 × 跨主題
人腦無法逐筆比對的搜尋空間
→
// 產出
應該互相影響的資料集
自動拉出 · 互相關聯 · 可被驗收
①
盤點
跨平台、跨主題、跨格式 逐筆 vetting 不再只是關鍵字搜尋
②
關係抽取
抓出資料集之間應該會有的影響關係 時間 · 空間 · 主題
③
互相關聯
把零散資料拉成可被推理的網絡 Agent 自己跑下一步
// 一句話
資料能被 LLM 看見，Agent 才能幫你發現「哪些資料應該放在一起看」。
SYSTEM · AGENT · 火災主題報告
P29 / 51
Pipeline 跑完一次的真實產出
輸入一句話，產出整套盤點報告
「分析台灣火災相關公開資料」
// 候選池逐輪擴張
582
關鍵字命中
→
1,945
同義詞 + 主題擴張
→
2,404
FTS5 補搜 + 去重
21 平台 · 73,900 筆 統一目錄
// 一條龍 6 階段（自動拆解）
A
預防
B
應變
C
通報
D
起火分析
E
損失
F
報表
22 縣市 × 6 階段 — 自動產出覆蓋矩陣
// 獨家盤點
新竹 火災潛勢圖
臺北 搶救困難地區
桃園 埤塘救援
// GAPS
× 沒有即時火災 API
× 事件級座標稀缺
× 災後追蹤不公開
Pipeline 自動產出
我 沒 寫 一 個 字
SYSTEM · AGENT · 實際運作 · 動腦
P30 / 51
案例 · 垃圾清運主題盤點
Claude 自己拆主題 · 自己分層
SYSTEM · AGENT · 實際運作 · 查詢結果
P31 / 51
案例 · 加油站 / 用電統計合成策略
Agent 直接回 · 可落地的合成方案
SYSTEM · STEP 03 · 分析生成P32 / 51
SYSTEM · 應用層 · 系統化分層
P33 / 51
// CASE STUDY · WATER
以「水資源」為例
政府兩三百筆水資料，先依點 / 線 / 面盤點，再依怎麼來 → 怎麼留 → 怎麼用 → 何時警示重組。
// LAYERED GIS
POINT · LINE · AREA
→ NARRATIVE
POINT · LINE · AREA
→ NARRATIVE
點POINT · 站點
STATIC
水庫位置
雨量站
地下水位站
DYNAMIC
即時雨量
水庫水位（hr）
河川水位即時
線LINE · 河川 / 水道
STATIC
河川流域
水道網路
OSM Waterway
DYNAMIC
流量推估
（少量、可推算）
面AREA · 邊界 / 網格
STATIC
集水區邊界
水利分區
行政區
DYNAMIC
降雨網格
災害示警 polygon
土壤含水量
// 重組為故事性架構
01
怎麼來？
FACE降雨網格+FACE集水區邊界
02
怎麼留？
POINT水庫水位+FACE土壤含水量
03
怎麼用？
LINE河川流量+POINT地下水位
04
何時警示？
FACE網格水量趨勢+FACE災害示警
先盤點圖層，再依邏輯串成敘事——同一批資料，組裝出一個能講故事的系統。
SYSTEM · 應用層 · CASE 01 · 火災分析
P34 / 51
113 年火災事件 · 全國 15,405 筆
從 datagov:13764 一路打到「縣市 × 起火原因」
datagov:13764 · TGOS street-level 9,226 筆
鄉鎮 fallback 6,179 筆 · 空間用精確點位、時序用全量
鄉鎮 fallback 6,179 筆 · 空間用精確點位、時序用全量
// SO WHAT
這份 reflect 報告完全由 Agent 串 API 跑出來。「新北市最大宗起火原因是電氣因素 30.9%」「屏東縣是菸蒂 35.2%」——資料源換成 API 之後，這種跨欄位、跨主題的描述性分析，可以被 Agent 主動產出。
SYSTEM · STEP 04 · 行動觸發 · 自動回饋P35 / 51
SYSTEM · 主題巡邏P36 / 51
// 未來模式 · 給目標
Agent 跑完整循環
人類角色 —— 給目標、收報告。中間五個齒輪自己轉。
// STATUS
雛形已經在跑 · 還沒做完 —— 但循環的形狀已經出現。
SYSTEM · AGENT 自己跑P37 / 51
// 結果 · 當循環建立起來
Agent 自己掃 · 自己分析 · 自己給結果
人不用守在前面。給目標、收報告 —— 其餘的事 Agent 自己排隊跑完。
01
定期掃資料
每週跑開放資料目錄差分，找出新增 / 更新的 dataset。
→
02
自己執行分析
調用 Agent Orchestrator + GIS Agent，挑工具、跑空間 / 時序分析。
→
03
定期回傳結果
brief / 報告 / 圖表自動產出，事件記錄與學習滾回去。
// SO WHAT
當這個 loop 跑起來，產出不需要排程 —— 主題自己冒出來、報告自己送到信箱。
SYSTEM · AGENT · 週報產出P38 / 51
★ 自動產出 · 每週一份
本週新增開放資料 brief
LOOP
03 AGENT LOOP · 協作循環
讓系統自己跑一圈
前面的成果、後面的系統，最後串成一個 Agent 能自己跑完的循環 ——
我出題，Agent 跑整圈，回來交付。
01 SHOWCASE02 SYSTEM03 AGENT LOOP
AGENT LOOP · 循環全景P39 / 51
我目前的 GIS 循環
一個編排中樞，串起一圈獨立 repo —— Agent 依序進站。
編排
中樞
中樞
.GIS-AGENT-SYSTEM
探索
EXPLORE
收集
COLLECT
呈現
RENDER
①
taipei-gis-analytics
資料探索 · 盤點分類 · 原始資料歸檔
②
data-collectors → gis-platform
收集器 · Supabase Migrate · 清理
③
mini-taiwan-pulse / info
前端顯示 · 同步更新
每一站都是獨立 repo —— 編排層只管進度與決策，活都在各 repo 的 worker 手上。
AGENT LOOP · 第一站P40 / 51
第一站 · 資料探索
TAIPEI-GIS-ANALYTICS — 進資料夾，先把家底摸清楚。
A · 盤點
有哪些資料、長什麼樣
初步確認可用資料與格式 —— 能用的、缺的、要再找的，先攤開來。
B · 歸檔
原始資料整理歸檔
所有 raw data 統一歸位，變成之後每一圈都能重複使用的素材庫。
輸出：一份乾淨的原始資料層 —— 後面每一站都靠它。
AGENT LOOP · 第二站P41 / 51
第二站 · 收集與入庫
DATA-COLLECTORS × GIS-PLATFORM — 啟動收集器，把資料變成資料庫。
① 部署
啟動收集器
30 多個即時收集器掛在雲端 cron 上 —— 部署完，資料自己進來。
② MIGRATE
Supabase Migrate
Migrate 進 gis-platform —— Supabase / PostGIS 統一底座，所有 repo 共用。
③ 清理
清理與整併
完成整體的資料清理與整理，留下乾淨可用的一份。
收集與 Migrate 相對好處理 —— 真正的關鍵在規則化。
AGENT LOOP · 第三站P42 / 51
第三站 · 前端與同步
MINI-TAIWAN-PULSE × INFO — 資料各就各位，頁面自己長出來。
① PULSE
資料放到對應位置
放對位置，地圖就會動 —— 陸、海、空即時脈動。
② INFO 同步
另外整理一份，同步過去
同一批資料再整理一份，同步更新到 Mini Taiwan Info。
③ INFO 規則
版型自動完成 ＋ 截圖驗收
制定規則：依預設版型自動完成頁面，再用資料截圖檢查當驗收。
規則定好之後，Info 的新頁面就能自動完成、自動驗收。
AGENT LOOP · 指揮P43 / 51
一個 Orchestrator，一群 Worker
主 Agent 是一個 Claude Session；TMUX 負責隔離 —— 每個 Worker 都是獨立分頁、獨立 Session。
ORCHESTRATOR · CLAUDE SESSION
$讀 proposal.md · 拆任務、排依賴
$spawn_tmux_claude.sh · 開 worker 分頁
→ med_t1_explore：去 taipei-gis-analytics 盤點
→ med_t3b_aed：去 gis-platform 建表 migration
→ med_l1_poi：去 mini-taiwan-pulse 上視覺化
… 監控 board · 彙整進度 · 驗收 PR
med_t1_explore · ANALYTICS
醫療資料盤點 · 分類 ✓
med_t3b_aed · GIS-PLATFORM
AED 建表 · 3-GATE ✓
med_l1_poi · PULSE
點位 LAYER 上線 ✓
一個 Worker ＝ 一個 Tmux 分頁 ＋ 獨立 Session ＋ 一個 PR。
AGENT LOOP · 共同文件P44 / 51
進度與決策，全部寫成文件
集中看板 SESSION_BOARD.md ＋ 一個 Session 一份報告 —— 不用互相猜。
ORCHESTRATOR / SESSION_BOARD.md
✓med_t1_explore · 醫療資料盤點完成ANALYTICS
✓med_t3b_aed · 建表 3-gate 通過PLATFORM
▸med_l1_poi · L1 點位 layer 上線中PULSE
✓HANDOFF.md · 下一棒任務書就緒ORCH
一人一檔，不打架
每個 Worker 寫自己的 board 報告；集中狀態，只看 SESSION_BOARD。
最後一關：驗收
Orchestrator 對照文件驗收 PR —— merge 由人拍板，這一圈才算收束。
AGENT LOOP · 實際產出P45 / 51
AGENT LOOP · 實際產出P46 / 51
AGENT LOOP · 接下來P47 / 51
接下來 —— 我只負責出題
一個計畫一個資料夾：PROPOSAL → DESIGN → TASKS → ARCHIVE。
2026-W22 · 醫療開放資料 ✓
2026-W2X · 下一個主題
計畫 C · ……
→
出題
PROPOSAL.MD
→
分派 Worker
ORCHESTRATOR · SPAWN
→
驗收 · 合併
REVIEW & MERGE
↺ ARCHIVE 之後，接下一個計畫 —— 全自動閉環，是下一步
這就是「會自己長大的系統」—— 資料會自己流，頁面會自己長
AGENT LOOP · 實驗現況P48 / 51
實驗進行中 —— 收在一起，一人驗收
把所有東西收整在一起 —— 結果全部回傳給一個主 Agent 驗收，通過了，才開始後續動作。
Worker 們回傳結果
RESULTS IN
→
主 Agent 統一驗收
ONE GATEKEEPER
→
執行後續動作
NEXT ACTIONS
EXPERIMENT PROGRESS~ 50%
進度大約一半 —— 初步結果：這個方向可行。
AGENT LOOP · 實驗現況P49 / 51
但是，Harness 還沒調到理想
可行歸可行，還沒穩，且也還在思考是否真的要這樣。
① 穩定性
容易跑掉、中斷
執行步驟還不夠明確，系統不夠穩定 —— 過程中容易跑掉或中斷。
② 開放資料
開放資料較雜
還是有很多需要人來判斷這資料實際上是否可行 —— 這一塊目前還無法完全交給它判斷。
③ 人工介入
每個階段都還要人
資料處理的每個階段，仍需要人工介入調整、給出行動方案。
以實驗的角度 —— 有成功的地方，也有還在努力改進的部分。
CLOSING · 結語P50 / 51
台灣的開放資料很多 —— 結合起來，才看得到影響力
01
資料要結合
孤島疊起來，影響力才出現
02
交給 AI 跑
更多資料 · 更多機器資料
03
持續推進
實驗繼續 · 看到更多台灣脈動
CLOSING · Q&AP51 / 51
Q & A
本場簡報
sciwork-showcase
GITHUB
ianlkl11234s
THREADS
@ianlkl1314