專案簡報

Jarvis 與 MemoryBank 簡報 v2

補強 MemoryBank 技術機制與 PM 可觀測性規劃的繁體中文簡報。

  • 模板：專案簡報
  • 工作區：personal
  • 用途：presentation
  • 受眾：owner
  • 發布狀態：approved
  • 公開範圍：public_unlisted

重點摘要

  • 前門私人助理與 control-plane agent
  • 負責理解 owner 意圖、讀取 canonical state、決定下一步、委派 worker、回報 provenance
  • 目標不是單一 CLI 指令集合，而是可持續運作的私人助理
  • 不是單純筆記庫，而是 Knowledge Orchestration substrate
專案視角

把產品定位、架構方向、採用理由與進度風險集中在同一頁。

重點區塊
  • 一句話定位
  • 為什麼要做這兩個產品
  • 產品定義
  • Jarvis
下一步
  • 前門私人助理與 control-plane agent
  • 負責理解 owner 意圖、讀取 canonical state、決定下一步、委派 worker、回報 provenance
  • 目標不是單一 CLI 指令集合，而是可持續運作的私人助理

一句話定位

Jarvis 是 以 MemoryBank 為記憶與治理核心的私人助理；MemoryBank 是 把專案規劃、決策、研究、當前真相與可重用知識分層治理的 Knowledge Orchestration 系統。

為什麼要做這兩個產品

問題 以前的痛點 Jarvis + MemoryBank 的做法
專案記憶會漂移 只靠對話、artifact、臨時文件，很容易過期與重複 把知識分成外部研究、可重用知識、專案真相、當前真相，分層治理
進度不可觀測 做到哪、還剩幾步、是否跑偏，不容易看 用 Workflow Board + Runtime Progress 形成 owner-visible control loop
外部研究容易污染專案方向 看過某個 repo 或論文，就可能直接影響決策 先隔離成 exploration thread，只有治理後才會被採用
Agent 可能亂寫、亂查、亂記 沒有明確 authority 與 provenance Jarvis 必須透過 governed retrieval / governed writes / audit surfaces 運作

產品定義

Jarvis

  • 前門私人助理與 control-plane agent
  • 負責理解 owner 意圖、讀取 canonical state、決定下一步、委派 worker、回報 provenance
  • 目標不是單一 CLI 指令集合，而是可持續運作的私人助理

MemoryBank

  • 不是單純筆記庫，而是 Knowledge Orchestration substrate
  • 負責：
  • 外部研究隔離
  • 決策治理
  • 專案真相管理
  • 當前真相錨定
  • bounded retrieval
  • reuse / refresh / conflict handling

兩者如何一起工作

層級 MemoryBank 負責什麼 Jarvis 負責什麼
外部研究 隔離來源、保留 provenance、避免直接污染專案 做研究、比較、提出是否值得採用
專案規劃 保存 canonical plan、workflow board、decision history 按照規劃一步步執行，不能靜默偏航
執行與回顧 保存 runtime progress、current truth、決策衝突 回報進度、提出衝突、要求 owner 選擇
對話前門 提供 bounded retrieval 與 governed memory packet 用自然語言理解 owner，選擇最適合的上下文

Knowledge Orchestration 的核心設計

分層治理，而不是全部混在一起

層級 意義 例子
Isolated evidence 還沒採用，只是外部資料 repo、論文、blog、DeepWiki 研究
Admitted reusable knowledge 已整理，可重用，但還不是專案真相 learning note、比較筆記
Project truth 這個專案目前採納的真相 architecture direction、workflow board
Current truth 現在最應信任的最新錨點 runtime implementation、runtime progress

這解決了什麼舊問題

  • 不再只靠 Google Anti-Gravity / artifact 累積一堆會過期的內容
  • 不再讓外部研究直接混進專案規劃
  • 不再讓 agent 只靠模糊對話記憶維持方向
  • 可以在衝突時明確指出：以前怎麼定、現在為什麼衝突、要 owner 選哪個方向

MemoryBank 技術機制

它不是一般 RAG

面向 純全文搜尋 純 RAG / 向量檢索 只靠 Agent Harness 工具 MemoryBank 混合檢索
召回方式 keyword / grep embedding 相似度 agent 自己用 grep、gh、文件工具現場找 keyword + metadata + slice-aware lexical + hybrid/vector strategy
上下文邊界 容易撈太多 容易撈到語意像但治理錯誤的內容 高度依賴 agent 當下判斷 先 bounded retrieval，再組 memory packet
token 成本 常把大量原文塞進 prompt 可能召回很多片段，需要額外 rerank agent 現場亂搜最耗 token 先用 metadata 壓縮範圍，只把必要切片交給 worker
治理能力 幾乎沒有 通常只有資料來源，沒有採用狀態 沒有長期治理 有 knowledge zone、adoption state、workspace、projects 等 metadata
衝突處理 無 無 無 可以追到 project truth / current truth / decision history
reuse 能力 低 中 低 高，因為知識有 lifecycle 與 promotion

為什麼要混合檢索

機制 作用 解決的問題
Metadata filter 先用 projects、workspace、knowledge zone、adoption state 限縮範圍 避免撈到不該進 prompt 的外部研究或錯專案內容
Lexical / BM25 / FTS5 快速抓明確關鍵字與穩定術語 對 procedure、decision、project note 很有效
Slice-aware retrieval 抓 note 裡最相關的片段，不是整篇 note 減少 token 消耗，降低 worker 被整篇淹沒
Hybrid / vector strategy 補 lexical 找不到的語意近似內容 保留擴充性，但不把向量檢索當唯一方法
Memory packet 將最終上下文整理成 bounded handoff 避免 worker 亂搜整個 vault

這套設計比一般 RAG 多了什麼

  • 不只回答「找不找得到」，而是回答：
  • 這份內容現在屬於哪個治理層級
  • 能不能給 worker 看
  • 該不該進入當前任務
  • 任務後是否值得 promotion
  • 也就是說，MemoryBank 處理的不只是 retrieval，還包括：
  • admission
  • adoption
  • current truth anchoring
  • promotion
  • conflict surfacing

對 agent harness 的意義

問題 只靠 harness 工具的風險 MemoryBank 的補強
agent 會自己 grep 很多檔 token 浪費、方向漂移 先交付 bounded packet
agent 不知道哪個 note 才是真相 容易用到舊決策或外部研究 用 truth / adoption metadata 做治理
agent 看得到資料，卻不知道能不能採用 會把 isolated research 當已決策內容 用 isolation / adoption flow 隔開
agent 不知道之前做過什麼 重工、重寫、亂修 workflow board + runtime progress + memory packet

我參考了哪些系統

參考對象 借鏡的優點 沒直接照抄的原因
Hermes Agent 前門 UX、自然互動感 不足以處理 MemoryBank 式治理與分層記憶
Pi Agent provider-neutral runtime / agent shell thinking 不是完整的 owner-facing memory governance system
OpenHands CLI agent control / execution surfaces 對 durable governed memory 不夠強
Codex / Gemini CLI / Claude Code worker harness、session、observability、hooks 它們是 provider/harness，不是 owner 的長期知識系統
OpenAI Symphony orchestration / scheduler / reconciliation thinking 目前綁 tracker integration，不適合直接照搬
HyperAgents lineage / archive / self-improvement 更適合未來自我改進層，不是 Jarvis 前門
Google File Search file-grounding / retrieval reference 不等於 governed memory，也不能取代決策治理

為什麼不是直接用 Linear 或 SaaS tracker

  • 我們真正要的是 canonical state + reusable knowledge + decision governance
  • 單純 task tracker 只解決「任務列在哪」
  • 但 MemoryBank 還要解決：
  • 研究隔離
  • 決策採用
  • current truth
  • reusable learning
  • worker authority
  • 所以目前方向是：
  • MemoryBank note 是 canonical state
  • Obsidian Base / output layer 只是 view
  • 不先引入額外 SaaS 依賴

PM 與可觀測性規劃

我們目前的策略不是沒有，而是還沒收斂成最終界面

面向 現在已有什麼 還缺什麼
Agent 可讀進度 Workflow Board、Runtime Progress、recent notes、research recall 更強的自動 drift enforcement
人類可讀進度 簡報頁、workflow board、output layer、Obsidian Base 更直觀的單一 dashboard / PM 視圖
任務追蹤 canonical board step、evidence、next step 更好的整體板面與跨專案總覽
決策與研究 exploration isolation、decision notes、truth anchors 更好的「採用中 / 未採用 / 需 revisit」視覺化

Symphony 給我們的啟發是什麼

Symphony 的強項 我們要借什麼 我們不直接照搬什麼
orchestrator + scheduler thinking 讓工作有狀態機與 handoff 不把 Linear 當必要前提
reconciliation / proof-of-work 讓完成的步驟可驗證 不把所有狀態都綁到 PR / CI 流程
work board 視角 讓 owner 可看全局 不把 canonical truth 放在 tracker SaaS 裡

規劃目前寫在哪些 canonical notes

主題 目前主 note
Jarvis 執行進度 Projects/jarvis-core/Jarvis Workflow Board
MemoryBank 產品進度 Projects/memorybank/MemoryBank Workflow Board
Jarvis 落地進度與細節 Projects/jarvis-core/Jarvis Runtime Progress
MemoryBank 產品路線圖 Projects/memorybank/MemoryBank Product Roadmap
Symphony 對照研究 Explorations/openai-harness-engineering-and-symphony-review/OpenAI Harness Engineering and Symphony vs Jarvis Workflow Observability

目前做到哪

Jarvis

指標 現況
Workflow steps 7
已完成 6
進行中 JWB-07
下一步 drift audit 更強 enforcement
目前狀態 governed_recall_restored

MemoryBank

指標 現況
Workflow steps 7
已完成 3
進行中 MBW-04
下一步 MBW-05
目前狀態 productizing_owner_visibility

這兩個產品最後想達到什麼

目標 最終效果
私人助理真正可用 可以自然語言對話、追進度、查舊決策、要求研究、要求繼續開發
記憶可被信任 不依賴單一 app thread 的隱性記憶，而是靠 Jarvis-owned state + MemoryBank
專案不再失控 每一步都能回到 canonical plan、current truth、workflow progress
知識可以重用 研究、決策、學習、架構不會每次從零開始

現階段最重要的判斷

  • Jarvis 和 MemoryBank 已經不是概念驗證而已，核心治理骨架已存在
  • 但前門產品體驗、owner 可觀測性、drift control 還沒完全收斂
  • 目前最重要的不是再加更多零碎指令，而是讓 owner 可以直接信任：
  • 現在做到哪
  • 為什麼這樣做
  • 下一步是什麼
  • 有沒有偏離原本規劃

建議先讀

  • Projects/jarvis-core/Jarvis Workflow Board
  • Projects/memorybank/MemoryBank Workflow Board
  • Projects/jarvis-core/Jarvis Runtime Progress
  • Projects/memorybank/MemoryBank Product Roadmap
  • Projects/jarvis-core/Jarvis Control-Plane Model Policy
  • Explorations/openai-harness-engineering-and-symphony-review/OpenAI Harness Engineering and Symphony vs Jarvis Workflow Observability

治理與發布範圍

這份輸出屬於工作區 personal，目前使用的公開範圍是 public_unlisted。

只有被明確標記為可公開的內容包，才應該進入公開網站列表或公開檢索索引。