AI Ark LLM Wiki

AI Ark 常駐 Loop 工程（Loop Engineering）

Properties2
descriptionAI Ark 知識頁：AI Ark 常駐 Loop 工程（Loop Engineering）。
tagsaiark, automation, workflow, multi-agent, hermes, llm-wiki

閱讀時間約 18 分鐘

AI Ark 常駐 Loop 工程（Loop Engineering）

這個 project 的目標，是把 AI Ark / aiark-llm-wiki 的知識蒐集與維護流程，拆成可長期運作的常駐閉環，而不是靠單次人工整理。

核心原則：

  • 高頻掃描，找出高價值來源
  • 結構化 ingest，把內容轉成 wiki 頁面
  • 嚴格 verify，維持 index / link / schema 品質
  • 定期 synthesize，把資料變成洞察與趨勢

目標

  1. 自動蒐集值得進 wiki 的新內容
  2. 將原始內容轉成 raw / entities / concepts / comparisons 結構
  3. 自動檢查 wiki 品質，避免 broken links、orphan pages、taxonomy drift
  4. 定期產出週報級洞察，讓 wiki 不只是資料庫，而是知識工廠

MVP 架構

1) Watch loop

任務：掃描來源、找新內容、去重、打分

輸入

  • RSS / blog / news
  • YouTube / social post / article URL
  • 關鍵字與白名單來源

Watch loop 白名單 v1

納入規則

  • 與目前 5 個主題簇直接相關
  • 有穩定 URL / RSS / 固定 handle，且最近 90 天仍有更新
  • 能轉成 raw / entities / concepts / comparisons / queries 任一層
  • 新來源先進 candidate queue，符合重複信號或高價值發布才升級為白名單

Tier A：固定監測

Tier B：主題觸發

排除

  • 一次性貼文、無法穩定追蹤的轉載
  • 無法解析原始連結或來源不明
  • 與目前主題簇無關的泛內容
  • 重複分發但沒有新增資訊的 repost

Watch loop score v1

目標

  • 把來源轉成可比較的分數
  • 決定進 queue、觀察、或直接忽略
  • 讓 Tier A / Tier B 可以用同一套規則微調

評分維度

  • topic_fit：0–3
    • 是否直接命中目前 5 個主題簇
  • freshness：0–2
    • 最近 90 天是否仍有穩定更新
  • stability：0–2
    • URL / RSS / handle 是否穩定，可持續追蹤
  • yield：0–3
    • 過去是否常產出可寫入 wiki 的新內容
  • duplication_penalty：0 到 -3
    • 是否高度轉貼、重複分發、幾乎沒新增資訊

判分細則 v1

topic_fit

  • 3：直接命中核心主題，且能明確落到現有頁面類型
  • 2：高度相關，但需要補一層推論才接得到主題
  • 1：只有邊際相關，偶爾可用
  • 0：與目前主題簇無關

freshness

  • 2：最近 90 天內持續更新
  • 1：有更新，但頻率不穩或間隔偏長
  • 0：明顯停更或無法確認活躍度

stability

  • 2：有穩定 domain / RSS / 固定 handle，追蹤成本低
  • 1：可追蹤但來源形式不夠穩，偶有變動
  • 0：來源經常變動、難以持續監測

yield

  • 3：過去多次產出可直接寫入 wiki 的新頁面或新段落
  • 2：偶爾有高價值內容，但不是每次都有
  • 1：低頻但偶爾可用
  • 0：幾乎沒有可轉寫價值

duplication_penalty

  • 0：原創或有明顯新增資訊
  • -1：有部分重複，但仍有新內容
  • -2：大多是轉載、改寫、摘要，新增有限
  • -3：幾乎完全沒有新增資訊

計分方式

  • score = topic_fit + freshness + stability + yield + duplication_penalty
  • 最高 10 分，最低 0 分
  • 先算基礎分，再由 Tier 做微調

判定門檻

  • 8–10：進入 fixed watch / priority queue
  • 5–7：保留在 candidate queue，等待下一次訊號
  • 0–4：不納入白名單，只做偶發觀察

實務修正

  • Tier A 預設 +1 但總分仍封頂 10 分
  • Tier B 必須靠 topic_fit 與 yield 拉高分數
  • 若來源雖然高頻但幾乎沒有新資訊，直接吃 duplication penalty
  • 若無法確認穩定來源，stability 上限先壓到 1

輸出

  • candidate queue
  • relevance score
  • reason / trace
  • 判分依據（可回溯）

Watch router flow v1

決策流程

  1. 先檢查來源是否在 Tier A / Tier B / 未知來源
  2. 計算 topic_fit / freshness / stability / yield / duplication_penalty
  3. 套用 Tier 修正
  4. 依門檻分流：
    • 8–10 → priority queue
    • 5–7 → candidate queue
    • 0–4 → ignore
  5. 將分數與理由寫入 trace，供後續 ingest / review / tuning 使用

機器可讀規格草案

router:
  tier_a_bonus: 1
  max_score: 10
  thresholds:
    priority_queue: 8
    candidate_queue: 5
    ignore: 0
  fields:
    - topic_fit
    - freshness
    - stability
    - yield
    - duplication_penalty
  output:
    - queue
    - score
    - trace

適合模型

  • gpt-5.4-mini：批次掃描、初篩、格式化
  • gpt-5.5：高風險來源或排序裁決

Candidate queue schema v1

目的

  • 讓 watch router 的輸出可被 ingest / review / tuning 重複使用
  • 保留分數與理由，避免後續無法回溯

欄位

  • item_id：唯一識別碼
  • source_ref：來源 ID / handle / page path
  • source_type：rss / blog / youtube / social / article / unknown
  • title：來源標題
  • url：原始連結
  • published_at：發布時間
  • discovered_at：首次被 watch loop 看見的時間
  • topic_fit：分數細項
  • freshness：分數細項
  • stability：分數細項
  • yield：分數細項
  • duplication_penalty：分數細項
  • score：總分
  • queue：priority_queue / candidate_queue / ignore
  • reason：人類可讀判斷理由
  • trace：可回溯的判分依據
  • action：ingest / hold / drop

最低要求

  • score 必須可重算
  • reason 必須能看懂為何進 queue
  • trace 必須能對回各細項

Watch agent prompt v1

任務定義

  • 掃描來源清單
  • 對每個來源計分
  • 產出 queue + score + trace
  • 不直接寫 wiki，先交給 router / ingest

輸出格式

  • 每筆 item 一個 queue record
  • 盡量保持欄位固定，避免自由文字漂移

Ingest trigger rules v1

觸發條件

  • priority_queue：直接進 ingest
  • candidate_queue：保留觀察，除非同來源累積到固定次數或分數上升
  • ignore：只記錄，不進 ingest

補充規則

  • 若來源是 Tier A，且連續兩次都在 priority_queue，可進入固定 ingest 檢查
  • 若來源連續三次落在 ignore，暫時降權，避免浪費抓取成本
  • Ingest 前仍保留人工 review / agent review 的閘門

Ponytail review gate v1

Ponytail 本身納入 loop 程序，作為每輪 watch / ingest / verify / synthesize 的最小化審查閘門。

套用時機

  • Watch 前：限制來源數量，避免白名單膨脹
  • Queue 後：檢查是否只需要 data/watch-queue.jsonl，而不是提前拆 schema / registry
  • Ingest 前：每輪預設只 ingest 1 筆，除非有明確高價值批次需求
  • Verify 後：只修低風險、可驗證問題，不做大規模自動重構
  • Synthesize 前：避免用少量樣本過度推論趨勢

Ponytail 停損線

  • queue record 未滿 10 筆前，不拆 source registry / queue schema
  • 手動閉環未穩定前，不接 cron
  • 新增自動化必須附最小 verify，否則不算完成
  • 能用 stdlib / Markdown / JSONL 解決，就不引入新 dependency

2) Ingest loop

任務：把高分候選內容寫進 wiki

輸入

  • candidate queue
  • 原文 / transcript / metadata

輸出

  • raw/... 原始頁
  • entities/... 實體頁
  • concepts/... 概念頁
  • index.md 更新
  • log.md append

適合模型

  • gpt-5.4-mini：抽取與格式化
  • gpt-5.5：歸類、邊界判斷、複雜合併

3) Verify loop

任務：維持 wiki 健康度

檢查項目

  • broken wikilinks
  • orphan pages
  • frontmatter / schema 問題
  • tag taxonomy drift
  • duplicate entity / concept
  • index completeness

輸出

  • lint report
  • severity-ranked issue list
  • low-risk fix suggestion

適合模型

  • gpt-5.4-mini：機械式檢查
  • gpt-5.5：最終判定與修復策略

4) Synthesize loop

任務：把新增內容整理成趨勢與洞察

輸入

  • 新增 raw / concept / entity 頁面
  • lint 報告
  • merge candidates

輸出

  • daily brief
  • weekly trend report
  • topic map
  • gap analysis
  • merge / normalize 建議

適合模型

  • gpt-5.5：主力負責

建議排程

  • 每 15 分鐘：Watch loop
  • 每天：Ingest + Verify + 短版 Synthesis
  • 每週：深度 Synthesis + Merge review
  • 每月：Source quality review + taxonomy review

任務切分

先做什麼

  1. 先把來源變成 queue
  2. 再把 queue 寫進 wiki
  3. 再加 verify
  4. 最後加 synthesis

不建議一開始就做的事

  • 全自動長鏈自主寫作
  • 無人工審核的大規模 merge
  • 沒有驗證的自動修補

失敗處理

  • Watch 失敗：不寫入，只記錄失敗
  • Ingest 失敗：保留原始輸入，標記 pending
  • Verify 失敗：只輸出報告，不做高風險修復
  • Synthesis 失敗：退回簡短摘要，避免過度推論

驗收標準

MVP 算成功，至少要滿足：

  • 新內容能自動進 queue
  • 高分候選能穩定寫入 wiki
  • index.md 與 log.md 持續更新
  • lint 報告能抓到常見結構問題
  • 每週可產出一份可讀的趨勢摘要

實作順序

  1. 先手動跑通 watch once → queue → review → ingest one item → verify wiki
  2. 累積 10+ 筆 queue record 後，再抽 source registry / queue schema
  3. 建立 verify job
  4. 建立 synthesis job
  5. 最後才接 watch cron 與 merge / normalize 自動化

MVP execution log

2026-06-22 第 1 輪手動閉環

暫不新增 source registry、cron、retry system。等 queue record 變多且重複欄位造成維護痛點，再拆 schema。

2026-06-22 第 2 輪手動閉環

  • queue file：data/watch-queue.jsonl
  • 新增 queue records：2 筆，累計 4 筆
  • review hold：Google Research Blog New framework for auditing machine unlearning（score 8，review）
  • ingested：dynamic-agent-workflows
  • raw source：raw/articles/aihao-code-act-dynamic-workflows-2026-06-05.md
  • verify：broken wikilinks 0；raw sha256 ok；index / log 已更新

第二輪仍維持一輪只 ingest 一筆，避免 watch loop 變成無節制內容匯入。

2026-06-22 Ponytail 納入 loop 程序

  • queue record：2026-06-22-ponytail-loop-review-gate
  • ingested：ponytail-loop-review-gate
  • raw source：raw/articles/ponytail-skill-2026-06-22.md
  • 用途：把 Ponytail 變成 watch / ingest / verify / synthesize 的最小化 review gate，防止 loop 工程過早長出 registry、cron、retry、dashboard

2026-06-22 第 3 輪手動閉環

  • queue file：data/watch-queue.jsonl
  • 新增 queue records：2 筆，累計 7 筆
  • queued：Google Research Empirical Research Assistance (ERA)（score 7，candidate）
  • ingested：agent-trace-observability
  • raw source：raw/articles/aihao-agent-trace-analysis-2026-06-02.md
  • verify：broken wikilinks 0；raw sha256 ok；index / log 已更新

第三輪維持 Ponytail gate：仍不拆 registry / schema，先累積 queue evidence。

2026-06-22 使用者指定來源補強

  • queue record：2026-06-22-bnext-loop-engineering-ai-coding-loops，累計 8 筆
  • ingested：loop-engineering
  • raw source：raw/articles/bnext-loop-engineering-ai-coding-loops-2026-06-15.md
  • 來源重點：把 loop engineering 定義為從手動 prompting 轉向 automation、worktree、skills、connectors、sub-agents、memory/state 與 gate 的 AI coding loop 設計
  • 對本專案的影響：確認目前 watch queue / raw source / log / verify gate 是合理的 minimal viable loop；仍先累積 queue evidence，不急著上 cron 或 registry。

2026-06-22 Codex record/replay 補強

  • queue record：2026-06-22-bnext-openai-codex-record-replay-skills-automation，累計 10 筆
  • ingested：loop-engineering
  • raw source：raw/articles/bnext-openai-codex-record-replay-skills-automation-2026-06-22.md
  • 來源重點：Codex 用 record and replay + skills 封裝一次示範，直接把常見操作轉成可重播流程；適合拿來對照 watch / ingest / verify 的 loop 形狀。
  • 對本專案的影響：bnext 除了 loop engineering，又多了一個更貼近產品操作層的 workflow 實例；後續若再出現類似 record/replay 文章，可優先納入 loop / workflow 主題簇。

2026-06-22 Coding Agent 作為外層優化器

  • queue record：2026-06-22-aihao-coding-agent-as-optimizer，累計 11 筆
  • ingested：coding-agent-as-optimizer
  • raw source：raw/articles/aihao-coding-agent-as-optimizer-2026-06-03.md
  • 來源重點：把 coding agent 視為外層 optimizer，靠固定成本 eval、保留變好版本、丟棄變壞版本，持續改進系統
  • 對本專案的影響：這個案例把 loop engineering 從流程設計推進到「優化器」觀點，補強 AI Ark loop 的 evaluation / commit / rollback 語彙

2026-06-22 提示詞除錯評估清單

  • queue record：2026-06-22-bnext-prompt-optimization-anthropic
  • ingested：prompt-debugging-eval-checklist
  • raw source：raw/articles/bnext-prompt-optimization-anthropic-2026-06-17.md
  • 來源重點：先建評估清單、再清理提示詞結構、一次只修一個失敗案例；必要時用工具與輸出契約補足能力
  • 對本專案的影響：把 loop engineering 的前半段補齊成「eval → cleanup → isolate failure → repair」的最小閉環，和 aiark-loop-engineering 的 watch / ingest / verify / synthesize 互補

2026-06-22 ReasoningBank：讓 agent 從經驗學習

  • queue record：2026-06-22-google-research-reasoningbank-agent-memory
  • ingested：reasoningbank-agent-memory
  • raw source：raw/articles/google-research-reasoningbank-agent-memory-2026-04-21.md
  • 來源重點：把成功與失敗經驗壓成高階 memory，形成 retrieval / extraction / consolidation 的 closed loop
  • 對本專案的影響：補上 agent memory 與 test-time self-evolution 的語彙，讓 aiark-loop-engineering 的 verify / synthesize 不只看 trace，也能回寫可重用經驗

2026-06-22 Agent event streaming format

  • queue record：2026-06-22-aihao-agent-streaming-chunk-format
  • ingested：agent-event-streaming-format
  • raw source：raw/articles/aihao-agent-streaming-chunk-format-2026-06-02.md
  • 來源重點：把 token deltas 升級成語意事件、namespace、projection 與 state snapshot / patch 的前端可消化格式
  • 對本專案的影響：補上 loop 的 UI / transport / harness 分層語言；之後看 trace 時，不只看後端事件，也可把前端投影格式一起納入觀測

2026-06-22 Google Research ERA

  • queue record：2026-06-22-google-research-era-computational-discovery
  • ingested：empirical-research-assistance
  • raw source：raw/articles/google-research-era-computational-discovery-2026-05-19.md
  • 來源重點：ERA 用 Gemini 寫與優化 scientific code，核心流程是 search literature → write code → explore solutions → evaluate results
  • 對本專案的影響：把 research workflow 直接拉進 loop engineering，和 [[loop-engineering]]、[[coding-agent-as-optimizer]]、[[agent-trace-observability]] 形成一組可重用的驗證語彙

2026-06-23 Google Research ERA follow-up

  • queue record：2026-06-23-google-research-era-scientist-usage
  • ingested：empirical-research-assistance
  • raw source：raw/articles/google-research-era-scientist-usage-2026-04-29.md
  • 來源重點：ERA 延伸到四個真實研究場景：流感 / RSV 預測、CO2 監測、cosmic strings 推導、zebrafish neural circuits
  • 對本專案的影響：把 ERA 從「能寫 scientific code」補強成「能在真實研究 loop 中持續產出可驗證結果」，更適合拿來對照 [[aiark-loop-engineering]] 的 watch / ingest / verify / synthesize 閉環

相關頁面

Synthesis v1（2026-06-20）

這一輪 synthesis 先抓目前 wiki 最明顯的 5 個主題簇：

  1. LLM wiki / knowledge base workflow

    • Karpathy LLM Wiki、Hermes + Obsidian、Claude Code、model-specific prompts、knowledge distillation
    • 核心問題不是「寫一份文件」，而是「把知識變成可持續維護的頁面網路」

  2. Agent workflow engineering

    • harness engineering、agentic RAG、five-agent content workflow、1-person product team workflow
    • 重點已從單次生成，轉向可觀測、可驗證、可迭代的 loop

  3. Edge / local deployment

    • RTX Spark、local machine gateway、model naming syntax
    • 關鍵在模型可跑性、量化格式與硬體整合，不只是參數大小

  4. Knowledge infrastructure / enterprise context

    • Knowledge Catalog、Palantir Ontology、AI-native HR architecture
    • 共同主軸是把資料、語意、決策上下文串成 agent 可用的 context layer

  5. AI SEO / distribution layer

    • AI SEO、GEO、zero-click search、content layering
    • 重點從傳統搜尋排名，轉向被 AI 回答引用與重組的內容層

目前缺口

  • watch loop 已手動跑通 3 輪閉環，但還沒累積足夠 queue record 來校準 score
  • synthesize 已有 daily / weekly template，但還沒接成自動化輸出
  • queries/ 目前已成為正式輸出層，下一步仍是接 cron / agent

下一步

  1. 再手動跑 3–5 輪 watch queue，觀察 score 噪音
  2. 把 daily brief / weekly synthesis 接到固定排程
  3. 把主題簇對應到固定輸出
  4. 需要時再建立 source registry / queue schema

Graph View

反向連結