Context Layer 設計研究報告與導入 Proposal

SEEKRTECH 公司級 AI-Native Knowledge Management System Date: 2026-03-23 | Author: Rin (for Marcus)

Executive Summary

本報告研究如何為 SEEKRTECH 建立公司級的 Context Layer——一個 AI-native 的知識管理基礎設施，讓 Living Document 持續保持最新、讓 Agent 能在工作流中自動捕捉與更新知識、並基於事件驅動執行任務。

核心建議：採用 Hybrid Architecture（Notion 作為 Human UI + Local Markdown Mirror 作為 Agent Access Layer + Qdrant 作為 Semantic Index），三層分離，各司其職。

Flow Path 視覺化

Flow 1a: 同事透過 Slack 查詢知識

這張圖回答：「同事在 Slack 提問時，資料怎麼流動？」

同事不再需要知道 Notion Page ID，樂芽透過 QMD 語意搜尋自動找到對的文件，從 Local Mirror 讀取，零延遲回覆。

Flow 1b: Slack 對話中的知識捕捉

這張圖回答：「Slack 對話中的新知識怎麼被留住？」

樂芽判斷知識類型：碎片偏好存 Mem0，公司結構化知識寫入 seekr-kb 並自動 Git commit、QMD re-index、Notion sync back。

Flow 2: Notion 編輯自動同步

這張圖回答：「同事在 Notion 修改後，Agent 怎麼看到最新內容？」

同事繼續在 Notion 編輯，Cron 每 4 小時 pull 變更到 Local Mirror，Git commit 留下完整 diff，QMD re-index 後 Agent 即可搜尋最新知識。

Part 1: 現況分析

1.1 SEEKRTECH 目前的知識基礎設施

層級	工具	使用者	問題
公司知識庫	Notion	全員（人工讀寫）	Agent 存取受 API rate limit（3 req/s）限制；所有操作需走 REST API
個人知識庫	Obsidian Vault	Marcus（Rin 代理）	僅個人使用，非公司級
語意搜尋	QMD（10 collections, ~1800 docs）	Rin Agent	僅索引 Marcus 的 Vault，不含公司 Notion
對話記憶	Mem0（Qdrant + Ollama bge-m3）	Rin + 樂芽	Per-agent collection，跨 agent 不共享
數據查詢	BigQuery / Appfigures	樂芽 Agent（按需）	即時查詢，非持久化知識

1.2 樂芽（Seekr Agent）目前的 Context 讀取方式

樂芽收到問題
  → 檢查 Mem0（自動注入 + 按需查詢）
  → 用 Notion MCP 讀取對應 Page（需知道 Page ID）
  → 用 BigQuery / Appfigures 查即時數據
  → 回覆

痛點：

Notion API Rate Limit：3 requests/second（所有 plan 一致，讀寫不分），Agent 密集操作時容易撞限
無語意搜尋：樂芽只能靠 Page ID 定點讀取 Notion，無法「搜尋」相關知識
知識碎片化：公司知識在 Notion、對話記憶在 Mem0、數據在 BigQuery——三者不互通
更新靠人工：Notion 文件過時需人工發現、人工更新
No Event System：知識變更不會觸發下游任務

1.3 已有的強項（可複用）

QMD：成熟的 hybrid search（BM25 + Vector + Rerank），已有 MCP tools
Mem0：對話記憶自動捕捉，已有 dedup + cleanup
Dispatch Pipeline：成熟的 task delegation 架構
Slack Integration：樂芽已在 Slack，可作為 knowledge capture point
Cron / Event Hooks：OpenClaw 已有 cron + message hooks 機制

Part 2: Context Engineering 最新研究

2.1 什麼是 Context Layer？

Context Layer 不是單一工具，而是一個設計知識如何流動的系統架構。根據 2025-2026 業界共識：

"Context engineering is the systematic discipline of designing and optimizing how contextual information flows through AI systems — from collection through utilization." — FlowHunt, 2025

"Every AI coding tool can generate code. Very few can generate the right code for your organization — because they're missing context." — QCon London 2026

核心概念：不是讓 AI 讀更多資料，而是讓 AI 在對的時間拿到對的資訊。

2.2 五大 Context Engineering 策略

根據 Anthropic 官方 Context Engineering 指南及 SwirlAI 2026 State of Context Engineering：

策略	說明	SEEKRTECH 對應
Write（持久化）	將關鍵資訊寫到 context window 外部儲存	Notion pages, Mem0, MEMORY.md
Select（檢索）	只取回當前任務需要的資訊	QMD semantic search, Notion Page ID
Compress（壓縮）	長對話/大量資料需要摘要壓縮	Mem0 fact extraction, memory-reflect
Isolate（隔離）	不同任務/Agent 看不同 context scope	Rin vs 樂芽 workspace isolation
Progressive Disclosure	分層載入：discovery -> activation -> execution	`.claude/skills/` 分層載入（已實踐）

Anthropic 2025/12 發布 Progressive Disclosure pattern 後數週內被 OpenAI、Google、Cursor 採用。核心概念：Agent 不需要一開始就看到所有資訊，而是根據任務進展逐步載入更深層的 context。

Gartner 預測：到 2027 年近半數 agentic AI 專案會因「不充分的 context delivery 系統」而被取消。Context Layer 已被視為戰略級基礎建設。

2.3 Manus（AI Agent 公司）的五大實戰教訓

File System as Extended Memory：Agent 的記憶不該只在 context window 裡，本地檔案系統就是最好的「無限記憶體」
KV-Cache 優化：system prompt 穩定、context append-only，cached tokens 成本只有 uncached 的 1/10
Masking > Removal：不要動態移除工具，用 masking 控制可用性（保護 cache hit）
Attention Manipulation（Living Todo）：Agent 自己維護 todo list，避免長任務鏈中目標漂移
保留錯誤證據：不要清除失敗紀錄，Agent 會隱式學習

2.4 Google ADK 的 Multi-Agent Context 管理

Scoped Context Handoff：sub-agent 只收到最小必要 context（非完整對話）
Artifact Pattern：大型資料（檔案、CSV）用 handle/reference，Agent 只在需要時 load
Memory Service 雙模式：Reactive（Agent 主動查）+ Proactive（pre-processor 自動注入）
Context Compaction：長對話自動摘要，保持 context window 清潔

2.5 Notion API 實際限制（深入分析）

限制	數值	影響
Rate limit	3 req/s（per integration, 所有 plan 一致）	Agent 密集操作撞牆
Rich text per object	2,000 字元	長文需拆成多個 block
Blocks per request	100 blocks	大頁面需多次 API call
Nesting depth	2 levels per request	深層嵌套需遞迴 fetch
Pagination	100 results per response	大 workspace 需多次分頁
JSON verbosity	比 raw markdown 高 3-5x token	Agent context window 浪費

實際影響估算：Sync 1,000 個 Notion pages（每頁 10 blocks）= 最少 10,000 API calls = 以 3 req/s 計算需 ~55 分鐘。

研究發現（Arize AI）："LLMs have extensive pretraining on filesystem/bash commands — minimal education tokens needed. The success of file systems as an interface is a symptom of the fact that we are bad at exposing APIs in a useful way."

2.6 業界新興工具值得關注

工具	特色	適用場景	成熟度
Cognee	開源 knowledge engine，6 階段 pipeline + Memify 自我進化記憶	需要 knowledge graph 的進階場景	中（$7.5M seed）
Graphiti/Zep	Temporal knowledge graph，bi-temporal model，20K+ GitHub stars	需要時間軸推理的記憶	高
LanceDB	嵌入式向量 DB（like SQLite for vectors），4MB RAM idle	輕量級本地語意搜尋	高
Galaxy	Enterprise context management，自動從資料推斷 semantic model	大型企業統一 context graph	早期

這些工具目前不建議立即引入，但作為 Phase 3+ 的進化方向值得追蹤。特別是 Cognee 的 Memify 模式（ingestion 後持續 prune stale nodes、strengthen frequent connections）和 Graphiti 的 temporal model（追蹤知識的有效時間區間）。

2.7 Event-Driven Multi-Agent 設計模式

Confluent 的研究提出四種 event-driven multi-agent 模式：

模式	說明	SEEKRTECH 對應
Orchestrator-Worker	中央排程器分配任務給 worker agents	`dispatch-subagent.sh`（已有）
Hierarchical Agent	樹狀結構，各層管理 sub-agents	Rin → 樂芽雙 agent（部分實現）
Blackboard	共享知識空間，所有 agent 讀寫	seekr-kb 即是此模式
Market-Based	Agent 競標任務	未來可考慮

Blackboard 模式最適合 Context Layer：所有 Agent 對共享的 seekr-kb 讀寫，curator logic 將碎片整合為結構化知識。這正是本 Proposal 推薦的架構。

Part 3: 架構方案評估

3.1 方案 A：Pure Notion（維持現狀 + 強化）

Notion（SSOT）── Notion MCP ──→ 樂芽/Rin Agent
                                     ↕
                              Mem0（對話記憶）

Pros:

零遷移成本，同事繼續用 Notion
Notion AI 持續進化

Cons:

3 req/s rate limit 是硬限制，Agent 密集操作會撞牆
無語意搜尋（只能 keyword filter + page ID 定點讀取）
Agent 每次都要走網路 API，延遲高
Notion 內容變更無法驅動事件
評分：★★☆☆☆

3.2 方案 B：Local-First（全部遷移到 Markdown）

Git Repo（Markdown）── Local FS ──→ Agent
       ↕ sync                        ↕
   Qdrant（Vector Index）      Mem0（對話記憶）

Pros:

Agent 直接讀本地檔案，零延遲、無 rate limit
Git 提供完整版本歷史 + diff = 變更事件
Markdown + frontmatter = 結構化 + 人類可讀
QMD/Qdrant 語意搜尋直接索引本地檔案

Cons:

需全員改用 Markdown 編輯器（高摩擦）
失去 Notion 的 database view、formula、relation 等功能
同事協作需學 Git
評分：★★☆☆☆（技術上最佳但導入阻力太大）

3.3 方案 C：Hybrid（Notion UI + Local Mirror + Semantic Index）⭐ 推薦

┌──────────────────────────────────────────────────────────┐
│                    Human Layer                            │
│   同事 ──→ Notion（讀寫 UI）                              │
│   Marcus ──→ Obsidian Vault（個人知識）                    │
└─────────────┬──────────────────────┬─────────────────────┘
              │ Notion→MD Sync       │ Already exists
              ▼                      ▼
┌──────────────────────────────────────────────────────────┐
│                Local Mirror Layer                         │
│   ~/seekr-kb/                     ~/clawd/vault/          │
│   ├── product/                    ├── 10_Projects/        │
│   │   ├── overview.md             ├── 25_People/          │
│   │   └── metrics-def.md          └── 34_Memo/            │
│   ├── strategy/                                           │
│   │   ├── brand.md                                        │
│   │   └── decision-log.md                                 │
│   ├── team/                                               │
│   │   └── structure.md                                    │
│   └── reports/                                            │
│       └── (agent-generated)                               │
│                                                           │
│   Git tracked → change events                             │
└─────────────┬──────────────────────┬─────────────────────┘
              │ Index                │ Index
              ▼                      ▼
┌──────────────────────────────────────────────────────────┐
│              Semantic Index Layer                          │
│   QMD / Qdrant                                            │
│   ├── seekr-kb collection (公司知識)                       │
│   ├── clawd collection (個人知識)                          │
│   ├── memo, people, meetings...                           │
│   └── Mem0 (對話記憶)                                     │
│                                                           │
│   MCP Tools: qmd_query, search_memories                   │
└─────────────┬────────────────────────────────────────────┘
              │
              ▼
┌──────────────────────────────────────────────────────────┐
│              Agent Layer                                   │
│   樂芽 Agent（Team）                                       │
│   ├── Slack 接收問題                                       │
│   ├── QMD semantic search → 找到相關知識                   │
│   ├── Local FS read → 讀取完整文件                         │
│   ├── BigQuery/Appfigures → 即時數據                      │
│   └── 回覆 + 更新知識庫                                    │
│                                                           │
│   Rin Agent（Marcus）                                      │
│   └── 同上，加上個人知識管理                                │
└──────────────────────────────────────────────────────────┘

Pros:

同事繼續用 Notion，零學習成本
Agent 讀本地 mirror，無 rate limit、低延遲
Git diff 提供變更事件（知道什麼改了）
QMD 統一索引公司 + 個人知識，支援語意搜尋
Agent 可直接寫入 local mirror → sync 回 Notion（反向更新）
增量式導入：先 sync 核心頁面，逐步擴大

Cons:

需要維護 Notion↔Local sync pipeline
Sync 有延遲（可接受，非 real-time critical）
需處理 Notion 特有功能（database views, formulas）的降級

評分：★★★★☆

3.4 方案 D：Hybrid + Event-Driven（方案 C 進化版）⭐⭐ 最終推薦

在方案 C 基礎上加入 event-driven 知識捕捉與任務觸發：

┌──────────────────────────────────────────────────────────┐
│                  Event Sources                            │
│   Slack 對話 → 樂芽 capture                               │
│   會議錄音 → PLAUD transcribe → extract                   │
│   Notion edit → webhook/poll → sync                      │
│   Agent task output → auto-update                        │
│   BigQuery insight → report → KB update                  │
└─────────────┬────────────────────────────────────────────┘
              │ Events
              ▼
┌──────────────────────────────────────────────────────────┐
│              Knowledge Router                             │
│                                                           │
│   Event → Classify:                                       │
│   ├── "碎片知識 / 偏好" → Mem0                             │
│   ├── "公司結構化知識" → Update local MD → Git commit       │
│   │                     → Notion sync back                │
│   ├── "數據 insight" → Generate report → local MD          │
│   └── "行動項目" → Linear issue / Reminder                 │
│                                                           │
│   Git commit event → Trigger:                             │
│   ├── QMD re-index (affected collections)                 │
│   ├── Notify relevant stakeholders                        │
│   └── Downstream tasks (if configured)                    │
└──────────────────────────────────────────────────────────┘

這就是你描述的三階段完整實現。

Part 4: 工具選型

4.1 Notion ↔ Local Sync

工具	方向	特點	推薦度
NotionFS	雙向	Python, bidirectional sync, conflict resolution, YAML frontmatter	★★★★☆
notion-to-md	單向（Notion→MD）	Node.js, 40k+ weekly downloads, 穩定	★★★☆☆
go-notion-md-sync	雙向	Go, git-like staging, frontmatter	★★★☆☆
Notion Guardian	單向（Notion→Git）	GitHub Action, 自動 daily export + git commit	★★★☆☆
Custom Script	雙向	用 Notion API 客製化，完全控制	★★★★★

建議：先用 NotionFS 做 PoC，視需求決定是否 fork/自建。

注意事項：

所有 sync 工具都受 Notion API 3 req/s 限制
Notion 的 database relations / rollups / formulas 無法完美轉換為 Markdown
NotionFS 支援 conflict detection + 3 種 resolution 策略（keep-local / keep-remote / keep-both）
自建的好處是完全掌控 sync 邏輯，可以做 incremental sync + change detection

4.2 Semantic Search / Vector Index

工具	部署	特點	SEEKRTECH 現況
QMD	Self-hosted	BM25 + Vector + Rerank, MCP tools	✅ 已在用
Qdrant	Self-hosted	高效能向量 DB, MCP server 官方支援	✅ 已在用（Mem0 backend）
Mem0	Self-hosted	對話記憶自動捕捉, dedup	✅ 已在用

建議：沿用現有 stack，擴展 QMD 新增 seekr-kb collection 索引公司知識。 不需要引入新工具。

4.3 Event / Workflow Orchestration

工具	特點	適合度
Git hooks (post-commit)	零依賴，detect file changes → trigger	★★★★★
OpenClaw Cron + Hooks	已有，可擴展	★★★★★
fswatch / chokidar	File system watcher	★★★☆☆
Temporal.io	重量級 workflow engine	★★☆☆☆（過重）
Inngest	Event-driven functions	★★★☆☆（需外部服務）

建議：用 Git hooks + OpenClaw event hooks，不引入新的 orchestration 層。 現有 dispatch pipeline 已經夠用。

4.4 Knowledge Capture Points

來源	捕捉方式	目標
Slack 對話	樂芽 Agent 在對話中識別 → Mem0 / local MD	碎片知識 / 決策紀錄
會議錄音	PLAUD → Whisper → LLM extract → local MD	會議結論、行動項目
Agent 任務輸出	分析報告自動寫入 `seekr-kb/reports/`	持久化 insights
Notion 手動編輯	Notion→Local sync 偵測變更 → re-index	保持同步
BigQuery Insights	Cron → query → detect anomaly → report	自動洞察

Part 5: 分階段導入計畫

Phase 1: Living Knowledge Base（2-3 週）

目標： 建立 Notion ↔ Local Mirror，讓 Agent 能透過語意搜尋存取公司知識

步驟：

建立 ~/seekr-kb/ repository
- 結構對應 Notion Company Context
- Git tracked，每次 sync 自動 commit
Notion → Local 單向 sync（先單向）
- 用 NotionFS 或 custom script
- Cron 排程：每 4 小時 pull（或 Notion webhook 觸發）
- 只 sync 核心頁面：Product Overview, Metrics Definitions, Brand Strategy, Team Structure, Decision Log
QMD 新增 seekr-kb collection
- 索引 ~/seekr-kb/ 目錄
- Daily re-index（加入現有 06:00 cron）
樂芽 Agent Context 升級
- 回答問題時：先 QMD search seekr-kb collection → 再 fallback Notion API
- 減少 Notion API 呼叫、增加語意搜尋能力

驗收標準：

樂芽能回答「我們的 Brand Strategy 是什麼？」而不需要知道 Page ID
同事使用 Notion 編輯，4 小時內 Agent 能看到最新內容

Phase 2: Agent Knowledge Capture（3-4 週）

目標： 讓 Agent 在工作流中自動捕捉知識並更新 Living KB

步驟：

Knowledge Router 建置
- 在樂芽的 message:received hook 中擴展判斷邏輯
- 碎片知識 → Mem0（已有）
- 結構化知識 → 寫入 seekr-kb/ local MD → git commit
反向 sync: Local → Notion
- Agent 寫入 local MD 後，push 回 Notion
- 用 NotionFS push 或 Notion API create/update
- 需 conflict resolution 策略（Agent 寫入 = append / 標記 section）
會議記錄 → KB 更新 pipeline
- PLAUD transcribe → LLM extract decisions/action items
- 自動更新 Decision Log、相關 Product pages
- 人工審核 gate（Discord/Slack proposal → 確認 → 執行）
分析報告持久化
- 樂芽產出的分析報告自動存入 seekr-kb/reports/
- 建立 QMD index → 未來可搜尋歷史分析

驗收標準：

會議結論自動出現在 Notion Decision Log
樂芽產出的報告可被搜尋到
同事在 Slack 提到的產品決策，樂芽能自動記錄

Phase 3: Event-Driven Task Processing（4-6 週）

目標： 基於知識變更事件，自動觸發下游任務

步驟：

Git-based Change Detection
- Post-commit hook 分析 diff → 分類變更類型
- 知識更新 → QMD incremental re-index（不等 daily cron）
- 重要變更 → 通知相關人員
Anomaly / Insight Detection
- 定期比對 BigQuery 數據 vs KB 中的 metrics targets
- 發現異常 → 自動產出分析 → 更新 KB → 通知
Cross-Agent Knowledge Sharing
- Rin 和樂芽共享 seekr-kb QMD collection（唯讀）
- 樂芽的 Mem0 collection 包含團隊 context
- Rin 的 Mem0 collection 包含 Marcus 個人 context
- 兩者不混合，但 seekr-kb 是共享知識層
Stakeholder-Aware Routing
- KB 變更時，根據 Team Structure 自動 tag 相關人員
- e.g., Metrics Definition 變更 → 通知 Data team

驗收標準：

知識更新後 < 5 分鐘，Agent 能搜尋到最新內容
數據異常自動被偵測並通知
跨 Agent 能共享公司知識

Part 6: 技術架構詳解

6.1 完整資料流

                        ┌─────────────┐
                        │   Notion    │ ← 同事手動編輯
                        │  (Human UI) │
                        └──────┬──────┘
                               │ Notion API (poll/webhook)
                               │ Rate: 3 req/s (shared)
                               ▼
                    ┌──────────────────────┐
                    │  Notion Sync Service  │
                    │  (Cron every 4h)      │
                    │  notionfs pull/push   │
                    └──────────┬───────────┘
                               │ Write markdown + git commit
                               ▼
┌─────────────┐    ┌──────────────────────┐    ┌─────────────┐
│  Obsidian   │    │    ~/seekr-kb/        │    │   PLAUD     │
│  Vault      │    │    (Git repo)         │    │  Meetings   │
│  (Marcus)   │    │    ├── product/       │    │  Transcripts│
└──────┬──────┘    │    ├── strategy/      │    └──────┬──────┘
       │           │    ├── team/          │           │
       │           │    ├── reports/       │           │ LLM extract
       │           │    └── decisions/     │           │
       │           └──────────┬───────────┘           │
       │                      │                        │
       │     ┌────────────────┼────────────────────────┘
       │     │   Git post-commit hook
       │     │   → detect changes
       │     │   → trigger re-index
       │     ▼
       │  ┌──────────────────────────────┐
       └─→│        QMD Index              │
          │  seekr-kb collection (NEW)    │
          │  clawd collection (existing)  │
          │  memo, people, meetings...    │
          │  + Mem0 (conversation memory) │
          └──────────────┬───────────────┘
                         │ MCP Tools
                         │ qmd_query / search_memories
                         ▼
          ┌──────────────────────────────┐
          │         Agent Layer           │
          │                               │
          │  樂芽 (Slack, Team)           │
          │  ├── QMD search seekr-kb     │
          │  ├── Read local ~/seekr-kb/  │
          │  ├── Write → seekr-kb/       │
          │  │   → git commit            │
          │  │   → Notion sync back      │
          │  └── Mem0 capture            │
          │                               │
          │  Rin (Discord/TG, Marcus)     │
          │  ├── QMD search all          │
          │  ├── Read Vault + seekr-kb   │
          │  └── Mem0 capture            │
          └──────────────────────────────┘

6.2 Notion Sync 設計

# ~/seekr-kb/scripts/notion-sync.sh

# Pull: Notion → Local (Cron every 4h)
notion_pull() {
    cd ~/seekr-kb
    notionfs pull --keep-remote  # Remote wins on conflict

    # Auto-commit changes
    if <span class="wikilink-unresolved"> -n $(git status --porcelain) </span>; then
        git add -A
        git commit -m "sync: Notion → local $(date +%Y-%m-%dT%H:%M)"
        # Post-commit hook triggers QMD re-index
    fi
}

# Push: Local → Notion (triggered by Agent writes)
notion_push() {
    cd ~/seekr-kb
    notionfs push --keep-local  # Local wins (Agent just wrote it)
}

Conflict Resolution 策略：

Notion pull: --keep-remote（人工編輯優先）
Agent push: --keep-local（Agent 剛寫的內容優先）
衝突時：保留兩個版本，通知 Marcus 決策

6.3 QMD Collection 擴展

// ~/.qmd/config.json 新增 collection
{
  "collections": {
    "seekr-kb": {
      "paths": ["~/seekr-kb/"],
      "exclude": [".git", "scripts/", "*.lock"],
      "description": "SEEKRTECH company knowledge base"
    }
  }
}

6.4 Knowledge Router（樂芽 Hook 擴展）

message:received event
  → 現有 Mem0 capture (unchanged)
  → NEW: Knowledge classification
    → If structured company knowledge detected:
      → Write to ~/seekr-kb/<category>/<topic>.md
      → Git commit with semantic message
      → Trigger Notion push (async)
      → Trigger QMD incremental index

Part 7: 風險與緩解

風險	嚴重度	緩解措施
Notion sync 延遲導致 Agent 讀到舊資料	中	4h sync + Agent 可 fallback Notion API 讀最新
NotionFS 不穩定 / 維護停止	中	只用 pull 功能（最穩定）；備案：自建 Notion API script
Agent 自動更新寫壞 KB	高	Human-in-the-loop gate：重要更新需確認；Git 可 revert
seekr-kb Git repo 越來越大	低	純 Markdown，增長慢；可定期 archive
公司同事不信任 Agent 更新的內容	中	Phase 2 初期：Agent 更新加 callout 標記；逐步建立信任
Notion 特有功能（database view）無法 sync	中	Database 只 sync 內容，view 保留在 Notion；報告用 local

Part 8: 成本估計

項目	預估成本
NotionFS sync (Notion API calls, 4h × 6 pages)	~36 req/day → 遠低於 rate limit
QMD incremental index（seekr-kb collection）	零（self-hosted）
Qdrant 儲存增加	極小（Markdown embeddings）
Agent LLM costs（knowledge classification）	~$0.02/day（Haiku for classification）
開發時間	Phase 1: 2-3 週, Phase 2: 3-4 週, Phase 3: 4-6 週

Part 9: 與競品方案比較

9.1 vs. Guru / Notion AI / Confluence AI

這些是 SaaS knowledge management 平台，提供 AI 搜尋 + 自動推薦。

優點：開箱即用，UI 友好
缺點：Agent 無法直接存取（只有 human UI）、無法自訂 event pipeline、vendor lock-in
結論：適合「只給人用」的場景，不適合「Agent 也要用」的需求

9.2 vs. LangChain / LlamaIndex RAG Pipeline

這些是開發框架，用來建構 RAG pipeline。

優點：靈活、可自訂
缺點：需要大量開發、不含 UI、不含 sync
結論：我們的方案已經內含 RAG（QMD），不需要另起爐灶

9.3 vs. 全 Notion MCP

直接靠 Notion MCP 做所有事。

優點：最簡單
缺點：3 req/s rate limit、無語意搜尋、高延遲、無 event system
結論：Phase 1 之前的 fallback，但不該是長期方案

Part 10: 決策要點

需要 Marcus 決定的關鍵問題

Phase 1 先 sync 哪些 Notion 頁面？
- 建議先 sync AGENTS.md 中列出的 6 個核心 pages
- 需要擴大嗎？（e.g., 所有 wiki pages）
seekr-kb repo 放在哪？
- 選項 A: ~/seekr-kb/（獨立 repo，樂芽 workspace 可 mount）
- 選項 B: ~/seekr-agent/kb/（放在樂芽 workspace 內）
- 建議選 A，獨立性更好
Agent 自動更新 KB 是否需要人工審核 gate？
- Phase 2 建議：重要頁面（Metrics Def, Product Overview）需審核
- 次要頁面（reports, decision log append）自動執行
樂芽的 Docker Sandbox 如何存取 seekr-kb？
- 需要額外的 bind mount（:rw for writes, 或 :ro + API gateway）
Notion Webhook vs Polling？
- Notion 目前沒有原生 webhook for page changes
- 建議用 Cron polling（4h 足夠，未來可縮短到 1h）

Part 11: Agent-to-Agent Protocol 展望

2025-2026 年出現了 Agent 互通標準的整合：

協定	發起者	方向	狀態
MCP	Anthropic (2024/11)	Agent→Tool（垂直）	已成事實標準，97M+ monthly SDK downloads
A2A	Google (2025/04)	Agent→Agent（水平）	成長中，ACP 已合併入 A2A
AAIF	Linux Foundation (2025/12)	統一治理 MCP + A2A	OpenAI, Anthropic, Google, MS, AWS 共同創立

對 SEEKRTECH 的意義：

目前 Rin→樂芽的溝通是透過 dispatch pattern，未來可考慮 A2A 標準化
MCP 投資（Notion, Linear, Slack, QMD, Mem0）方向正確，已被業界驗證
seekr-kb 可以透過 QMD MCP server 讓兩個 Agent 共享存取

Context Layer 設計研究報告與導入 Proposal

Context Layer 設計研究報告與導入 Proposal

Executive Summary

Flow Path 視覺化

Flow 1a: 同事透過 Slack 查詢知識

Flow 1b: Slack 對話中的知識捕捉

Flow 2: Notion 編輯自動同步

Part 1: 現況分析

1.1 SEEKRTECH 目前的知識基礎設施

1.2 樂芽（Seekr Agent）目前的 Context 讀取方式

1.3 已有的強項（可複用）

Part 2: Context Engineering 最新研究

2.1 什麼是 Context Layer？

2.2 五大 Context Engineering 策略

2.3 Manus（AI Agent 公司）的五大實戰教訓

2.4 Google ADK 的 Multi-Agent Context 管理

2.5 Notion API 實際限制（深入分析）

2.6 業界新興工具值得關注

2.7 Event-Driven Multi-Agent 設計模式

Part 3: 架構方案評估

3.1 方案 A：Pure Notion（維持現狀 + 強化）

3.2 方案 B：Local-First（全部遷移到 Markdown）

3.3 方案 C：Hybrid（Notion UI + Local Mirror + Semantic Index）⭐ 推薦

3.4 方案 D：Hybrid + Event-Driven（方案 C 進化版）⭐⭐ 最終推薦

Part 4: 工具選型

4.1 Notion ↔ Local Sync

4.2 Semantic Search / Vector Index

4.3 Event / Workflow Orchestration

4.4 Knowledge Capture Points

Part 5: 分階段導入計畫

Phase 1: Living Knowledge Base（2-3 週）

Phase 2: Agent Knowledge Capture（3-4 週）

Phase 3: Event-Driven Task Processing（4-6 週）

Part 6: 技術架構詳解

6.1 完整資料流

6.2 Notion Sync 設計

6.3 QMD Collection 擴展

6.4 Knowledge Router（樂芽 Hook 擴展）

Part 7: 風險與緩解

Part 8: 成本估計

Part 9: 與競品方案比較

9.1 vs. Guru / Notion AI / Confluence AI

9.2 vs. LangChain / LlamaIndex RAG Pipeline

9.3 vs. 全 Notion MCP

Part 10: 決策要點

需要 Marcus 決定的關鍵問題

Part 11: Agent-to-Agent Protocol 展望

Sources

Context Engineering

Notion API

Local-First Sync Tools

Knowledge Management

Event-Driven & Multi-Agent

Agent Memory Frameworks

MCP & Agent Protocols

Industry Data