title: "AGIRight 半自動領域資訊工作流 v0.1" series: "網路資訊海動態秩序化" series_id: "EML-IIODO" document_id: "EML-IIODO-WP-01" document_type: "內部 MD 技術白皮書" author: "Neo.K" organization: "EveMissLab" version: "0.1.0" status: "內部工程基線" date: "2026-08-01" language: "zh-TW" visibility: "internal" license_note: "內部技術文件；對外引用或公開前應再次檢查實作狀態、來源授權與網站現況。"

AGIRight 半自動領域資訊工作流 v0.1

從「每日重複觸發」到可排程自治前的工程基線

摘要

本文件是《網路資訊海動態秩序化》系列進入技術階段後的第一份內部白皮書。其目的不是重新論證 AI 是否能整理網路資訊，而是把 AGIRight Topics 已經存在的半自動工作方式，拆成可重現、可測量、可移交、可逐步自動化的工程流程。

截至 2026-08-01，AGIRight Topics 公開頁面明確標示為「Hand-curated — no crawler yet」，亦即目前沒有自主爬蟲持續抓取整個來源集合；然而實際操作流程已不是傳統人工編輯。依現行工作方式，人類主要負責觸發每日任務、提供必要邊界、查看結果與處理明顯問題；AI 則承擔大量搜尋、來源閱讀、候選事件辨識、去重、重要性初判、摘要、分類、多語入口與頁面內容生成工作。故本文件將此狀態定義為「Human-triggered, AI-executed, Human-audited」的半自動領域資訊工作流。

其最小閉環可表示為：

H_{trigger} \rightarrow A_{discover} \rightarrow A_{read} \rightarrow A_{cluster} \rightarrow A_{rank} \rightarrow A_{write} \rightarrow A_{package} \rightarrow H_{audit} \rightarrow P_{publish}

其中，人類並不逐步代替 AI 執行，而是在入口與出口維持邊界控制；AI 則在中段完成高重複、低至中風險、可回查的資訊加工任務。

本文件同時定義三個必須分離的系統狀態：

Current Baseline（現行基線）：人工觸發、AI 執行、人工抽查，無常駐自主爬蟲；
Automatable Boundary（可排程邊界）：可以立即由 Scheduler、工作流狀態與失敗重試取代的人工作業；
Deferred Autonomy（延後自治）：需要更完整權限治理、歷史資料層、多 Agent 審查或較高風險控制後才適合自動化的部分。

白皮書進一步提出 Run Manifest、Candidate Record、Topic Record、Source Evidence、Review Decision 與 Run Report 六種最小資料物件，以及來源可解析率、溯源覆蓋率、重複率、人工介入率、修正率、發布回滾率與自主步驟比等監測指標。本文不虛構目前尚未量測的數值，而把它們定義為下一階段必須開始記錄的工程欄位。

本文件的目標是把 AGIRight 從「使用者知道怎麼每天叫 AI 做」轉換成「即使更換執行 AI、維護者或 Runtime，也能依明確規格重現同一類工作」。下一篇 EML-IIODO-WP-02 將在此基線之上進一步定義 Scheduler–Loop–Graph Runtime。

關鍵詞： AGIRight、半自動工作流、領域資訊整理、每日三則、Human-in-the-Loop、Scheduler、Graph、AI 編輯、來源溯源、工程基線

1. 文件目的與邊界

1.1 這不是產品宣傳文件

本文件描述的是內部運作模型，而非向外宣稱 AGIRight 已具備完整自主新聞系統。

尤其必須區分：

\text{AI-assisted curation} \neq \text{autonomous crawler}

公開 Topics 頁目前仍標示：

Hand-curated — no crawler yet

因此，v0.1 不應寫成「系統會自己掃描整個網路」。目前較準確的工程描述是：人類啟動一次工作輪，AI 使用可取得的搜尋、瀏覽與生成工具完成主要資訊處理，再由人類進行基本抽查或要求修正。

1.2 本文件要回答的問題

本白皮書只回答六個問題：

一次 AGIRight Topics 更新輪到底有哪些步驟？
哪些步驟目前主要由 AI 完成？
人類目前真正不可替代的介入點在哪裡？
哪些錯誤容易自動檢查，哪些需要升級人工？
為了未來排程化，現在應開始保存哪些狀態與產物？
怎樣判定 v0.1 已經是一個可重現的工程流程，而不是操作習慣？

1.3 本文件刻意不處理的問題

以下內容延後至後續白皮書：

Scheduler、Loop、Graph Runtime 的完整執行架構；
工作難度、風險與自主等級的通用分類；
Domain Pack 的跨領域配置規格；
每日三則的正式差分與排序演算法；
母站—子站共用資料層；
Temporal Knowledge Graph；
多 Agent 審查與長期自治。

因此，本文件的角色是：

\boxed{ \text{現行行為} \rightarrow \text{顯式流程} \rightarrow \text{可記錄介面} }

而不是一次完成整個平台。

2. AGIRight Topics 的現行產品表面

從公開頁面可觀察到，Topics 已具備下列輸出元素：

日期；
一個或多個主題標籤；
來源名稱；
標題；
由站方重述的摘要；
原始來源連結；
搜尋；
多維篩選；
每頁筆數；
JSON 匯出；
多語介面入口。

這代表即使後端尚未自動爬取，前端資料結構已經不只是文章頁，而接近一個小型結構化事件索引。

可以把一筆 Topics 條目抽象成：

T_i = ( uid, headline, summary, source, url, date, tags, language, provenance )

真正需要固化的，不只是最後的 $T_i$ ，而是 $T_i$ 如何從候選來源形成。

3. 現行半自動模式的正式定義

本文件將 AGIRight v0.1 現況定義為：

Human-triggered, AI-executed, Human-audited domain information workflow.

即：

W_{current} = H_{trigger} + A_{execution} + H_{audit}

其中：

3.1 Human-triggered

目前人類仍會重複性地發出「今天繼續完成」、「更新今日內容」或同等語意的啟動訊號。

這個動作在工程上不應被理解為內容生產，而應視為：

H_{trigger} \approx \text{manual scheduler event}

亦即，人類目前扮演的是排程器。

3.2 AI-executed

觸發後，AI 可以承擔主要認知與內容處理步驟，包括：

搜尋候選來源；
閱讀來源；
分辨是否為新事件；
排除明顯重複內容；
判斷是否與 AGIRight 主題相關；
產生摘要；
產生標題；
指派標籤；
生成多語入口內容；
準備網站所需資料格式；
在工具允許時直接更新檔案或網站。

3.3 Human-audited

人類主要關注：

是否有明顯錯誤；
今天的三則是否太重複；
是否選到不合領域邊界的事件；
是否有法律、政治、權利或高爭議表述需要校正；
網頁有沒有壞掉；
是否需要要求 AI 重做。

這種工作已經不是逐篇人工採訪與撰稿，而接近：

\text{Human role} = \text{trigger} + \text{boundary setting} + \text{exception handling} + \text{spot audit}

4. 一次更新輪的標準流程

v0.1 將一次更新輪定義為十二個狀態。

S0｜Run Initialize

建立本輪執行識別碼：

run\_id = \operatorname{UUID}()

最低紀錄：

run_id
domain_id = agiright
requested_date
trigger_type
initiator
model/runtime
started_at

目前 trigger_type 多數為 manual。

S1｜Scope Load

載入本領域的基本範圍：

AI rights；
AI ontology；
AI consciousness / moral status；
AI governance；
agent autonomy；
content licensing；
training data rights；
machine-readable policy；
human–AI relations；
frontier progress 中與上述議題相關者。

這一步不是搜尋，而是確定：

\Omega_{AGIRight}

即本輪什麼算「可能相關」。

S2｜Candidate Discovery

AI 透過搜尋或外部來源取得候選集合：

C_t = \{c_1,c_2,\dots,c_n\}

每一候選至少保留：

URL；
來源名稱；
搜尋命中標題；
初始日期；
搜尋查詢或發現路徑；
初步主題；
發現時間。

本階段允許高召回，不需要太早追求只剩三則。

S3｜Source Resolve

對候選來源進行解析：

c_i \rightarrow s_i

其中 $s_i$ 是可供後續判讀的來源內容。

解析失敗應記錄，而不是默默丟棄：

SOURCE_OK
SOURCE_BLOCKED
SOURCE_NOT_FOUND
SOURCE_PAYWALL
SOURCE_PARSE_ERROR
SOURCE_UNSTABLE

這一步很重要，因為未來若自動排程，來源失敗率本身就是健康指標。

S4｜Evidence Read

AI 讀取來源，抽取至少以下事實欄位：

發生了什麼；
誰是行動主體；
事件發生日期；
來源發布日期；
關鍵數字；
原始說法與媒體／機構二手解釋的區別；
是否存在不確定性；
是否有原始文件可以回查。

若事件是法律、學術或政策類內容，優先尋找：

\text{primary source} > \text{institutional source} > \text{reputable secondary source} > \text{commentary}

此處的「>」表示作為事實基線時的優先次序，而不是絕對可信度排序。

S5｜Event Normalize

將多篇來源正規化為事件候選：

\{s_1,s_2,\dots\} \rightarrow E_j

最低正規化欄位：

event_id
event_date
entities[]
claims[]
source_refs[]
topic_candidates[]
novelty_hint

此步驟處理「多篇文章其實是同一件事」。

S6｜Duplicate / Continuation Check

將事件與既有 Topics 比較：

D(E_j,H)

其中 $H$ 為既有歷史條目。

結果至少分成：

NEW_EVENT
NEW_DEVELOPMENT
DUPLICATE
RESTATEMENT
CORRECTION
REVERSAL
UNCERTAIN

這個分類比簡單去重更重要，因為同一事件的「新進展」仍然可以是新聞。

S7｜Domain Relevance Gate

計算是否值得進入 AGIRight 候選池：

R_{domain}(E_j) \in [0,1]

v0.1 可先使用語意判斷與規則混合，不需要假裝已存在完美演算法。

最低判斷問題：

是否直接涉及 AGIRight 核心議題？
是否會影響 AI 權利、治理、授權、代理權限或人機關係？
若只是一般 AI 產品新聞，是否有清楚的權利／治理含義？
是否具有足夠新資訊，而非純評論？

低相關事件可以保存於候選日誌，但不進入發布池。

S8｜Importance Ranking

對通過領域閘門的事件進行排序：

Q(E_j) = \alpha N + \beta I + \gamma R + \delta V + \eta C - \lambda D

其中：

$N$ ：新穎性；
$I$ ：領域影響；
$R$ ：來源可靠與證據強度；
$V$ ：可驗證性；
$C$ ：與當前議題的關聯性；
$D$ ：與近日條目的重複度。

v0.1 不要求先固定權重，但要求把排序理由以文字保存，避免只保留最後名次。

每日三則可寫成：

Top3_t = \operatorname{Select3} (\mathcal{E}_t,Q,\mathcal{D})

其中 $\mathcal{D}$ 代表多樣性約束，避免三則都在談同一宗訴訟或同一公司。

S9｜Editorial Synthesis

對最終事件生成可發布條目。

最低輸出：

標題；
一至兩段摘要；
來源名稱；
原始 URL；
日期；
標籤；
必要的不確定性語句；
不代表本站立場的中立表述。

摘要原則：

\text{summary} \neq \text{source copy}

而應是：

\text{summary} = \text{verified paraphrase} + \text{domain context}

S10｜Packaging / Localization

將條目轉換為網站所需格式，並建立多語入口。

本階段不要求所有語言都具有完全等質的長篇內容。v0.1 的正確定義是：

\text{multilingual access layer} \neq \text{full multilingual editorial equivalence}

可包含：

UI 語言；
標籤在地化；
標題或摘要翻譯；
lang / locale metadata；
JSON 資料輸出。

S11｜Audit and Publish

目前人類在此進行基本抽查。

可能結果：

APPROVE
APPROVE_WITH_EDIT
REGENERATE
HOLD
REJECT
PUBLISH_THEN_CORRECT

發布完成後，必須留下：

published_at
published_ids[]
review_decision
reviewer
correction_required
run_status

至此一次更新輪結束。

5. 工作流狀態圖

v0.1 可抽象為：

flowchart TD
    A[Manual Trigger] --> B[Load AGIRight Scope]
    B --> C[Discover Candidates]
    C --> D[Resolve Sources]
    D --> E[Read Evidence]
    E --> F[Normalize Events]
    F --> G[Duplicate / Continuation Check]
    G --> H[Domain Relevance Gate]
    H -->|pass| I[Importance Ranking]
    H -->|fail| X[Archive Candidate]
    I --> J[Select Daily Set]
    J --> K[Editorial Synthesis]
    K --> L[Package / Localize]
    L --> M[Human Audit]
    M -->|approve| N[Publish]
    M -->|edit| K
    M -->|hold/reject| X
    N --> O[Run Report]

此圖的價值不是視覺化，而是把「人腦知道下一步要做什麼」轉成 Runtime 可以執行的顯式狀態轉移。

6. 六種最小資料物件

若未來要把人工觸發替換為排程器，首先不是寫更多 Prompt，而是保存狀態。

6.1 Run Manifest

run_id: "agiright-2026-08-01-001"
domain_id: "agiright"
requested_date: "2026-08-01"
trigger_type: "manual"
initiator: "human"
status: "running"
started_at: "..."
finished_at: null
model_runtime: "..."
policy_version: "agiright-domain-v0.1"

6.2 Candidate Record

candidate_id: "cand-..."
discovered_at: "..."
query: "..."
source_name: "..."
url: "..."
initial_title: "..."
published_date_hint: "..."
resolve_status: "SOURCE_OK"

6.3 Source Evidence

source_ref: "src-..."
url: "..."
source_name: "..."
retrieved_at: "..."
source_type: "primary|institutional|secondary|commentary"
content_hash: "..."
claims:
  - claim_id: "..."
    text: "..."
    support: "direct|indirect|uncertain"

6.4 Event Record

event_id: "evt-..."
event_date: "..."
entities: []
source_refs: []
claims: []
topic_candidates: []
continuation_type: "NEW_EVENT"
relevance_score: null
importance_score: null
ranking_reason: "..."

6.5 Topic Record

topic_id: "topic-..."
headline: "..."
summary: "..."
source_name: "..."
source_url: "..."
event_date: "..."
tags: []
languages: []
provenance:
  run_id: "..."
  event_id: "..."
  source_refs: []

6.6 Review Decision / Run Report

review:
  decision: "APPROVE"
  reviewer: "human"
  reviewed_at: "..."
  notes: "..."

run_report:
  candidates_found: null
  sources_resolved: null
  events_normalized: null
  items_published: 3
  duplicates_removed: null
  human_interventions: null
  corrections: null

v0.1 不要求所有數值今日就有，但資料結構必須先存在，否則未來無法知道自動化是否真的改善工作。

7. 人類與 AI 的責任矩陣

步驟	現行主要執行者	可立即自動化程度	人類保留責任
啟動每日任務	Human	高	可保留停用權
載入領域邊界	AI + 固定規則	高	定義／修改政策
搜尋候選	AI	高	特殊來源補充
讀取來源	AI	高	高風險來源抽查
事件正規化	AI	高	爭議事件覆核
去重／延續判斷	AI	中高	模糊案例覆核
領域相關性	AI	中高	邊界案例裁決
重要性排序	AI	中	最終編輯判斷可抽查
摘要與標題	AI	高	敏感表述抽查
多語處理	AI	高	重要頁面語言品質抽查
發布	工具／人類	中高	保留停用、回滾與高風險批准
更正／撤回	Human + AI	中	最終治理責任

此表的重要含義是：

人類不需要因為某一步「可能出錯」就永遠親自執行那一步；應根據錯誤可逆性、影響範圍與驗證成本配置監督。

8. 錯誤分類與處理策略

8.1 E1｜來源不可取得

例：404、付費牆、阻擋、解析失敗。

處理：

retry \rightarrow alternate\ source \rightarrow hold

不得在沒有可回查來源時自動補寫確定性敘述。

8.2 E2｜日期錯置

新聞的「發布日」與「事件日」容易混淆。

因此至少保存：

(t_{event},t_{published},t_{observed})

若無法確定事件日，使用 event_date_status = uncertain。

8.3 E3｜重複事件

處理不是刪除所有重複來源，而是把來源聚合到同一事件。

\{s_1,s_2,s_3\} \rightarrow E_1

8.4 E4｜摘要過度推論

當來源只說「可能」、「初步」、「擬議」時，摘要不可升格成「已證實」、「已生效」。

需要一個模態保持規則：

M_{summary} \preceq M_{source}

即摘要的確定性不得高於證據本身。

8.5 E5｜領域偏離

熱門 AI 新聞容易進入候選池，但並非每個模型發布都屬於 AGIRight。

處理：保留候選，不發布；若未來多領域平台存在，可路由到其他子站。

8.6 E6｜三則過度同質

即使前三名都是真正重要事件，也可能造成每日頁面失去資訊多樣性。

可加入：

DiversityPenalty(E_i,E_j)

避免三則全部來自同一事件群、同一機構或同一議題。

8.7 E7｜網站格式失敗

此類錯誤可高度自動化檢查：

JSON schema；
必填欄位；
URL 格式；
日期格式；
標籤白名單；
HTML build；
連結存活檢查。

這些不應長期依靠人眼。

8.8 E8｜發布後發現錯誤

系統必須允許：

CORRECT
RETRACT
SUPERSEDE
ANNOTATE

而不是直接覆寫到沒有歷史紀錄。

9. 人工抽查不應是一個模糊動作

目前「看一下有沒有基本問題」若不被形式化，未來很難被 Agent Runtime 接管或量測。

因此 v0.1 將人工抽查拆成五個 Gate：

Gate A｜Source Gate

原始 URL 是否存在？
摘要所述核心事件能否由來源支持？

Gate B｜Date Gate

事件日期是否與來源發布日期混淆？
是否錯把舊事件當今天的新事件？

Gate C｜Claim Gate

關鍵數字、人名、機構、法案、判決結果是否一致？
是否把推測寫成事實？

Gate D｜Domain Gate

這真的屬於 AGIRight 嗎？
若只是一則一般 AI 新聞，是否有足夠領域關聯？

Gate E｜Presentation Gate

三則是否過度重複？
標題是否誇張？
中立聚合定位是否保持？

未來若某些 Gate 可以自動通過，就不必每輪全部人工作業。

10. 可立即排程化的部分

本文件判定，以下能力不需要等待 AGI：

10.1 每日啟動

現行：

H_{trigger}

可替換為：

Scheduler(t)

GitHub Actions 等現行 CI/CD 系統本身已支援固定時間排程；因此「每天記得啟動」不是 AI 能力瓶頸，而是工作流是否被正式配置的問題。

10.2 Run Manifest 建立

每次執行自動建立 run_id、日期、版本、模型與狀態。

10.3 基本格式驗證

Schema、URL、日期、缺欄、重複 ID、Build 測試可以完全自動化。

10.4 低風險失敗重試

例如暫時網路錯誤、單一來源解析失敗，可以有限次重試。

10.5 Run Report

每日產生：

找到多少候選；
解析多少來源；
排除多少重複；
最終發布幾則；
是否有人工介入；
是否發生錯誤。

以上能力的共同特徵是：

\text{deterministic or bounded} + \text{low consequence} + \text{easy to verify}

11. 暫不全自動化的部分

11.1 高爭議法律解讀

法律新聞可自動整理，但若摘要涉及「合法／非法」、「已確立判例」、「正式生效」等強結論，應提高審核門檻。

11.2 主題邊界變更

AI 可以建議新增標籤，但不應在 v0.1 自行重構整個 AGIRight 本體。

11.3 歷史內容大量重分類

這涉及既有 URL、標籤統計與歷史一致性，留待後續可逆分類與 Temporal Knowledge Graph 實作。

11.4 自動刪除舊內容

不得把「過時」直接等同「刪除」。更正、撤回、取代與歷史保存應分離。

11.5 無界搜尋

v0.1 不允許 Agent 在沒有候選上限、時間上限與成本上限的情況下持續搜尋。

12. 持久化：從聊天上下文轉成工作流狀態

一次 AI 對話可以記住本輪發生的事，但正式工作流不能依賴「模型大概還記得」。

因此狀態應外部化：

S_t = ( run, candidates, sources, events, reviews, published )

LangGraph 等現行 Graph Runtime 已區分 thread-scoped checkpoint 與跨 thread store：前者保存一次流程的圖狀態，後者保存跨執行的長期資料。這種區分非常適合未來 AGIRight：

Checkpoint：本次每日更新做到哪裡；
Store / Database：過去發布過哪些事件、來源與分類。

Human-in-the-Loop 也應是正式的暫停狀態，而不是「AI 做完後另外叫人看」。

因此未來一次執行應能：

run \rightarrow interrupt(review) \rightarrow persist \rightarrow resume

而不是重新從第一步開始。

13. 冪等性與發布安全

若工作流失敗後重跑，最危險的不是摘要重算，而是重複寫入與重複發布。

因此發布操作必須具有：

IdempotentPublish(run\_id,topic\_id)

對同一 topic_id 重複執行，不應生成兩筆內容。

最低措施：

穩定 Topic ID；
發布前查重；
原子寫入或 transaction；
build 成功後才切換 production；
保存上個可用版本；
支援 rollback。

對於任何會產生外部副作用的節點，應遵守：

\text{AI reasoning} \rightarrow \text{validated action plan} \rightarrow \text{side effect}

而不是模型一產生文字就直接修改 production。

14. v0.1 可觀測性指標

從本版本開始，建議開始收集下列指標，但不得補造歷史數據。

14.1 Source Resolution Rate

SRR = \frac{N_{resolved}}{N_{candidates}}

14.2 Provenance Coverage

PC = \frac{N_{published\ with\ source\ evidence}}{N_{published}}

目標應接近：

PC=1

14.3 Duplicate Rejection Rate

DRR = \frac{N_{duplicate}}{N_{normalized}}

14.4 Human Intervention Rate

HIR = \frac{N_{runs\ requiring\ material\ human\ change}}{N_{runs}}

注意：人工「看過」不等於 material intervention。

14.5 Correction Rate

CR = \frac{N_{postpublish\ corrections}}{N_{published}}

14.6 Rollback Rate

RR = \frac{N_{rollback}}{N_{publish\ runs}}

14.7 Autonomous Step Ratio

ASR = \frac{N_{AI/automatic\ executed\ steps}}{N_{all\ workflow\ steps}}

這個指標比「我們有沒有 Agent」更能反映自動化程度。

14.8 Operator Touch Time

OTT = \sum \text{human active handling time per run}

未來自動化的主要價值之一，就是降低 $OTT$ ，而不是單純追求更多 Agent 呼叫。

15. v0.1 服務品質目標

本版本不先要求高吞吐，而要求低錯誤與可重現。

必須滿足

每筆發布內容至少有一個可回查來源；
發布條目可以追溯到 run_id；
同一事件不得因重跑而重複發布；
事件日與發布日可分離保存；
人工要求修改後能留下 Review Decision；
來源失敗不得被模型自行補成確定事實；
每次執行結束產生 Run Report；
可回滾到上一個正常網站版本。

建議滿足

三則至少跨兩個不同事件群；
高風險法律／政策條目具第二來源或原始文件；
新標籤不在無審核情況下進入正式 taxonomy；
每筆條目保存 content hash 或 source snapshot reference；
修正不覆寫歷史，而建立新版本或更正記錄。

16. 最小檔案與資料夾結構

v0.1 建議先用簡單、可 Git 化的結構，不必一開始導入大型資料平台：

agiright-intel/
├── config/
│   ├── domain.yaml
│   ├── taxonomy.yaml
│   ├── sources.yaml
│   └── policies.yaml
├── runs/
│   └── YYYY-MM-DD/
│       └── <run_id>/
│           ├── manifest.yaml
│           ├── candidates.jsonl
│           ├── evidence.jsonl
│           ├── events.jsonl
│           ├── selection.json
│           ├── review.yaml
│           └── report.json
├── topics/
│   └── <topic_id>.json
├── corrections/
├── logs/
└── schemas/

此結構的設計目的：

\text{simple first} + \text{migration friendly}

日後可以再把 runs/、topics/ 與 evidence 搬進 PostgreSQL、事件儲存或 Temporal Knowledge Graph，而不改變概念物件。

17. 建議的 Run Policy v0.1

policy_version: "agiright-run-v0.1"
max_candidates: 30
max_selected: 3
require_source_url: true
require_event_date_check: true
allow_same_event_multiple_items: false
allow_auto_publish: false
human_review_required: true
retry:
  source_fetch_max: 2
  generation_max: 1
stop_conditions:
  - no_viable_candidates
  - source_resolution_below_threshold
  - build_failure
  - human_hold

注意：這是一個建議基線，不是宣稱目前 production 已照此配置。

18. 從現況到下一版的遷移路徑

M0｜現行操作

HumanTrigger \rightarrow AIWork \rightarrow HumanCheck

M1｜狀態化

新增：

run_id；
Run Manifest；
Candidate / Evidence / Event；
Review Decision；
Run Report。

M2｜可恢復

新增：

checkpoint；
node status；
retry；
failure codes；
idempotent publish。

M3｜排程化

將：

HumanTrigger

替換為：

Scheduler

但仍保留：

HumanReview

M4｜條件式人工介入

只有當：

高風險條目；
來源不一致；
信心不足；
新 taxonomy；
build failure；
異常指標；

才要求人類介入。

此時工作流才會真正從：

\text{semi-automatic}

轉向：

\text{bounded autonomous operation}

19. 為什麼 AGIRight 適合作為第一個 Runtime 實驗場

AGIRight 有幾個工程優勢：

19.1 輸出規模小

每日三則天然限制了發布量。

19.2 來源可以回查

每筆內容附原始來源，錯誤容易追溯。

19.3 錯誤多數可逆

摘要、標籤與排序錯誤可以修正，不會直接造成不可逆物理副作用。

19.4 任務高度重複

每天的核心結構幾乎相同，非常適合排程與 Graph 化。

19.5 領域有明確邊界，但仍足夠多樣

它同時包含法律、哲學、AI 研究、治理與內容授權，可以測試跨來源與跨類型分類能力。

19.6 已存在真實前端

這不是純測試資料集。任何工作流改善都可以對實際網站輸出產生可觀察效果。

因此 AGIRight 的意義不只是第一個內容子站，而是：

\boxed{ \text{第一個可用來測試領域資訊自治的真實觀測站} }

20. 驗收條件

EML-IIODO-WP-01 v0.1 的完成，不要求今天立刻部署所有自動化；它要求規格已足以讓另一個工程實作依據本文重建相同流程。

文件驗收

現行人工與 AI 分工已明確；
公開網站「無 crawler」狀態與內部 AI 輔助流程已分離；
十二個工作狀態已定義；
最小資料物件已定義；
錯誤分類已定義；
人工 Gate 已定義；
可立即排程與暫不自動化範圍已區分；
持久化與冪等要求已定義；
指標已定義，未虛構量測值；
下一階段 Runtime 介面已形成。

工程驗收（待實作）

每輪自動產生 run_id；
候選、證據、事件與發布條目可追溯；
Run Report 自動生成；
發布操作具冪等性；
支援 checkpoint / resume；
人工審核可作為正式 interrupt；
可由排程器取代每日人工 trigger；
異常可自動升級人工，而非無限重試。

21. 與下一份白皮書的接口

本文件輸出的是：

\text{Workflow Semantics}

下一篇 EML-IIODO-WP-02 要實作的是：

\text{Workflow Runtime}

亦即將本篇十二個狀態轉成：

G=(V,E,S,T,P)

其中：

$V$ ：工作節點；
$E$ ：條件轉移；
$S$ ：持久狀態；
$T$ ：Scheduler 觸發；
$P$ ：權限、重試、停止與人工介入政策。

因此：

\boxed{ WP01:\ What\ the\ workflow\ is }

\boxed{ WP02:\ How\ the\ runtime\ executes\ it }

兩者不可混為一篇，否則會再次把概念流程、產品規則與特定框架實作綁死。

22. 結論

AGIRight Topics 的意義不在於它已經是一個全自主新聞機器，而在於它顯示了一個更實際的轉折：資訊領域管理的主要認知工作，已經可以由 AI 承擔；人類正在從內容逐項生產者，移向觸發者、邊界制定者、抽查者與例外處理者。

現況可以寫為：

\boxed{ \text{Human Trigger} + \text{AI Execution} + \text{Human Audit} = \text{Semi-Autonomous Domain Curation} }

而近一步的工程轉換是：

\boxed{ \text{Scheduler} + \text{Persistent State} + \text{Graph Runtime} + \text{Bounded Retry} + \text{Conditional HITL} }

這個轉換不需要等待完整 AGI。真正困難的是把目前存在於使用者習慣、對話上下文與模型臨場判斷中的隱性流程，轉換成可記錄、可恢復、可驗證與可治理的系統結構。

因此，本文件的最重要結論不是「AGIRight 已自動化」，而是：

AGIRight 已經具備足以被正式工程化的半自動工作流；下一步不是讓 AI 更會寫，而是把觸發、狀態、證據、失敗、審核與發布變成 Runtime 能夠持續管理的顯式物件。

這將作為《網路資訊海動態秩序化》技術系列其餘九篇的共同工程起點。

參考與查核基線

AGIRight.org, Topics, accessed 2026-08-01. 公開頁面顯示中立第三方資訊聚合、搜尋／篩選／JSON 匯出、多語入口，以及「Hand-curated — no crawler yet」現況。
W3C, PROV-O: The PROV Ontology, W3C Recommendation, 2013. 用於 Entity／Activity／Agent、生成、使用與責任溯源的資料模型參照。
LangChain / LangGraph Documentation, Persistence, accessed 2026-08-01. 用於 checkpoint、thread-scoped state、cross-thread store、故障恢復與長期狀態的工程參照。
LangChain / LangGraph Documentation, Interrupts, accessed 2026-08-01. 用於正式 Human-in-the-Loop 暫停、恢復、批准、編輯與條件回環的工程參照。
GitHub Docs, Workflow syntax for GitHub Actions / on.schedule, accessed 2026-08-01. 用於證明固定排程觸發在現有一般工程基礎設施中已屬成熟能力，而非 AGI 前提。

11_AGIRight半自動領域資訊工作流_v0.1.0