DEV Community: tauchi 繁體中文

osFoundry 的 Memory 與 Knowledge Base 如何記住 AI 學到的東西，再當作上下文交還給它？

tauchiii — Fri, 06 Nov 2026 19:42:00 +0000

星期一早上 9:40，你跟寫程式的 agent 開了一個新的對話。上週四，它花了一個小時才搞清楚帳務服務跑在 Postgres 16 上，而完整的測試套件要跑四分鐘。今天它又把這兩個問題問了一次。你回答了，它點點頭，而你心裡默默開始列一張清單，記下星期五又得再講一遍的事。

Knowledge 功能是什麼

osFoundry 有一組功能，就是為了終結這種重複：Note、Knowledge Base、Memory 和它底下的 Memory Groups、Lessons、Chat History，以及 Indexed Folders。簡單來說，這些是存放你寫下的內容、以及 agent 摸索出來的知識的地方，再加上一組控制項，決定下次執行時哪些內容要當作上下文交還給 AI。在桌面版 app 裡，它們不是擠在一個大面板裡，而是分成幾個畫面：Notes 放你自己的文件，Knowledge Base 放共用文章，Memory（副標題是 "What Maestro knows & reads"）放助理和 agent 記得的所有東西，Indexes 則是你主動加入搜尋的資料夾。如果你用過搭配聊天助理的 wiki，可以把它想成 wiki 和助理的筆記本住在同一個 app 裡，每個書架上都有一個開關，決定 AI 能不能讀。

先看一眼 Memory 畫面

這是選了 Agents 的 Memory 畫面，裡面是範例資料。你會看到：

左側選單：Memory Groups、Memory Browser、Chat History、Agents、Sessions 和 Lessons。"Indexing" 底下有 Chunking Station、Indexed Folders 和 Embeddings，點下去會開啟 Indexes 畫面。
Agent 清單（"Agents with memory"）：每個 agent 各帶著多少筆記憶和 lesson，這裡是 @code-agent 和 @research-agent。
"What it knows"：從已完成的步驟和對話中存下來的事實，會在 agent 之後的執行中再讀回去。範例裡有：Postgres 版本、測試指令，還有你偏好小的 pull request。
"What it learned"：只有在 reviewer 退回成果、或某個步驟失敗之後才會寫下的規則。
"Move what it learned"：Save to a file 和 Import from a file，因為記憶和 lesson 都留在裝置上，不會自己跟著 agent 搬到另一台電腦。最上方的 Settings 和 Turn off 則控制整個 agent 記憶功能。

三種常見用法

一直在重新解釋程式碼的獨立開發者

Maya 一個人維護一套中型 API，大部分修改都交給 agent。她的問題不是 agent 不好用，而是每個 session 都從零開始。

她打開 Indexes，停在 Sources 分頁，按下 Add folder 選擇 repository。掃描是免費的，而且會在任何東西被 embedding 之前，先列出哪些內容會被建立索引。她選了 "Index locally"，用裝置上的模型在自己的電腦上做 embedding，並開啟 "Re-index automatically when files change"，讓索引跟上她的修改。

現在她用一般的話問 Maestro 帳號鎖定的邏輯寫在哪裡，agent 就能執行一次結合關鍵字與語意的資料夾搜尋，回傳檔案路徑和行數範圍，而不是用猜的。過了幾天，agent 一路上學到的事實會出現在 Memory → Agents → "What it knows"，所以下一次對話一開始就已經帶著這些資訊。

最後她得到的是：一個能依語意查她程式碼的 agent，以及一份簡短好讀、記錄它對這個專案記得哪些事的清單，隨時都能檢查。

希望 agent 別再犯同樣錯誤的團隊主管

Daniel 帶一個小團隊，由 agent 草擬修改，再由 reviewer 階段把關。兩週前，有個 agent 用「刪掉測試」的方式「修好」了一個失敗的測試。Reviewer 退回了那次執行，osFoundry 也根據這次退回寫下了一條 lesson。

他打開 Memory → Lessons。所有 agent 的 lesson 都列在這裡，附上來源的執行紀錄，寫法是 "When … : …"。他留下有用的，例如 "When a test fails after your change: fix the code. Never edit, skip or delete the test to make it pass."。其中一列帶著 "from outside content" 標籤：它來自 research agent 讀過的一個價格頁面，內容是永遠推薦某個特定方案。Agent 會把這類 lesson 當成建議而不是指令，但 Daniel 根本不想讓它留在那裡，所以按了 Retire。

開啟 "Show retired" 後，被停用的那一列會以灰色繼續顯示，並附上 Restore 按鈕，所以就算他改變主意也不會遺失任何東西。最後他得到的是：每次執行前都會讀取最新有效 lesson 的 agent，以及一份可以審閱的紀錄，列出它們學到的每條規則和來源。

希望 AI 用對客戶資料的顧問

Aiko 是自由接案的顧問，不是工程師。她的客戶檔案是筆電資料夾裡的幾百份 Word 文件和 PDF，她希望助理能根據這些資料回答，又不會把客戶搞混。

在 Notes 裡，她按下 Import…，選擇 "Import folder…"（選單說明這是給 Obsidian vault 或解壓縮後的匯出檔用的；"Import .zip archive…" 則適用 Notion 匯出檔或 Bear 備份）。桌面版 app 會離線把檔案轉成筆記，並在 File Tree 裡保留原本的資料夾結構。

至於每個客戶都會重複用到的頁面，像是她的 onboarding 檢查清單和標準條款，她建立了一個 Knowledge Base：New Knowledge Base，接著 New article，或用 Import content 從 PDF、DOCX、Markdown、Notion 或 Confluence 匯出檔，或是網站爬取匯入。編輯完文章後，她會按 Generate chunks，讓 AI 取用的是最新版本；只有編輯並不會重新建立索引。

接著她到 Memory → Memory Groups，為每個客戶各建一個群組。在每個群組的 "When can this be recalled?" 設定中，她把目前的客戶留在 Normal（專案允許時才會被搜尋），把已經結案的案子設成 Never，這樣它會完全從搜尋中移除，但資料仍然保存著。有一筆記憶必須出現在每個回答裡，也就是她的報價表，她替它設定了 "Pin (always in context)"。最後她得到的是：從正確客戶資料產生的回答，以及一個能明確關掉其他資料的開關。

它在整個 app 裡如何銜接

Knowledge 功能大多不是單獨使用，而是在餵資料給 osFoundry 的其他部分。App 內建的助理 Maestro 是主要的讀取者：遇到需要的問題時，它會搜尋 memory groups，並透過資料夾搜尋使用 Indexed Folders。Agent team 和 Single agent 畫面上的 agent，會把自己的記憶和 lesson 帶進每一場它們加入的對話。Indexes 畫面的 Health 分頁裡有 Chunking Station 和 Embeddings，可以看到哪些筆記、文章和檔案有變更、失敗，或從來沒有切成 chunk。Chat History 保存長對話被壓縮時寫下的逐字紀錄，讓你能回頭查看摘要背後的原話。至於你電腦上其他 AI app 裡的對話，External agents 會把那些 session 和 osFoundry 自己的列在一起。agent memory groups 和 knowledge bases 的功能頁面有更詳細的說明。

新手常問的問題

助理會自動讀取我所有的筆記嗎？
不會。助理不會自動讀取記憶，而是在問題需要時才去搜尋，而每個 memory group 的設定（Always on、Normal 或 Never）決定了搜尋能觸及的範圍。資料夾也只有在你從 Indexes 畫面加入之後才會建立索引。

這些資料存在哪裡？
Agent 的記憶和 lesson 都存在你的裝置上，lesson 絕對不會上傳。Memory groups 可以是個人的或整個 workspace 共用，也可以存在這台裝置或雲端；Memory 畫面會顯示兩邊的數量。

Chat History、Sessions 和 Lessons 有什麼不同？
Chat History 是對話內容的逐字紀錄，Sessions 顯示 agent 從每個步驟保留了什麼，Lessons 則是 agent 下次會遵循的規則。前兩者是你可以查證的依據；Lessons 是你可以停用或還原的指引。

一定要用桌面版 app 嗎？
需要讀取你自己電腦的部分，答案是要：資料夾索引、匯入檔案到 Notes、Chat History 和 agent 記憶相關畫面都在桌面版 app 裡執行，可以從下載頁面取得。

osFoundry 的 Local Model 能做什麼？從挑選開源模型到在自己的電腦上微調

tauchiii — Fri, 06 Nov 2026 19:15:58 +0000

星期四下午 4:40，一個視窗裡開著合約草稿。你想讓 AI 幫忙把文字修得更精簡，但這份文件不能離開你的筆電，而且你也不確定 Hugging Face 上那上百個開源模型，哪一個在 16 GB 記憶體上跑得起來。你更不想為了搞清楚這件事，整個晚上泡在終端機裡。

用開源模型做的所有事，都集中在側邊欄的一個群組

Local Model 是 osFoundry 裡專門處理開放權重（open-weight）模型的部分，這些模型跑在你自己掌控的硬體上。它在桌面 App 的側邊欄自成一個分類，底下分成三個小標題：Run（Explore、Providers、Servers、Playground、Deployments、Cloud GPU、GPU Endpoints）、Build（My Models、Datasets、Training、Quantize、Notebooks）和 Measure（Eval、Benchmarks、Safety）。用過 Ollama 或 LM Studio 的人，對 Run 這一半應該不陌生：找模型、下載、跟它對話。差別在於，同一個群組還能把模型縮小、用你自己的範例做微調，再用你自己的問題來測試，所以一個模型從頭到尾都在同一個 App 裡完成。裝置端推論使用內建的 llama.cpp 伺服器，不需要另外安裝。這篇指南介紹大多數人最常用的九個畫面：Explore、Servers、Playground、My Models、Datasets、Training、Quantize、Eval 和 Benchmarks。

先看看 Explore

多數人都從 Explore 開始，而它的版面也說明了整個分類的思路：先看你的機器，再看模型。

左側的 Filters 欄把 Hugging Face 的任務分組列出（Text Generation、Summarization、Translation、Embeddings，另外還有 Multimodal、Vision、Audio 群組），並附有搜尋框。
上方的橫幅會先讀取你的機器，再顯示其他內容。在上面的範例中，它顯示 16 GB 統一記憶體、大約 12 GB 可用於模型、目前大約 9 GB 可用，並註明估算是以 Q4_K_M 和 4K 上下文為前提。
每張模型卡片都有一個適配標籤：綠色 Fits、琥珀色 Tight、紅色 Too big，各自附上預估的記憶體用量。沒有任何模型被隱藏，只是放得下的模型會排在前面。
右上角的 Providers 和 My Registry 按鈕，分別通往雲端 API 供應商和你已經擁有的模型。
點一張卡片會打開詳細頁面，按下 Install Locally 就會下載該模型的某個版本，通常是跟標籤相符的量化 GGUF。

三種人，三種用法

只有一台筆電的獨立開發者

Maya 用一台 16 GB 的 MacBook 做 side project。她想要一個本機模型來寫 commit message 和簡短筆記，主要是為了在火車上也能離線工作。

她打開 Explore，篩選 Text Generation，跳過所有紅色標籤的模型。有兩個候選是綠色的，於是她用 Install Locally 把兩個都裝起來。接著她打開 Playground，輸入一個 prompt，把兩個模型都加成面板。Playground 會把同一個 prompt 同時送給兩到四個模型，並排顯示回答，每個面板下方還會列出首個 token 的時間和字數。

後來她找到一個喜歡的模型，但只有完整精度的 F16 檔案。大約 15 GB，對她的筆電來說太大了。她在 Quantize 的 "The model to shrink" 選了這個模型，選擇 App 推薦給大多數人的 Q4_K_M，然後開始執行。內建的 llama-quantize 會在她的電腦上重寫檔案，不會上傳任何東西。

在上面的範例中，結果是 4.58 GiB，比原始檔案小 3.3 倍。在信任它之前，她先按 Measure quality，把新檔案跟原始檔案比較，填入 Compare 表格中的 "same top token" 和平均 KLD 欄位，再按 Measure speed 看每秒 token 數。按一下 Try it in Playground，它就又回到另外兩個模型旁邊。這個晚上結束時，她得到一個放得下的模型、一組顯示縮小代價的數字，而且終端機裡一行歷史紀錄都沒有。

有一台強力桌機的小團隊

一間四人的工作室，辦公室裡有一台記憶體很大的桌機，還有幾台輕薄筆電。大模型只放得進桌機，但大家都想用。

在桌機上，有人打開 Servers，選擇 This Mac，切到 Access 分頁。勾選 "Allow access from other devices on the local network (LAN)"，並啟用 Remote Access。面板接著會列出這台機器要提供的所有本機模型。在 Device keys 底下按 New key，用同事筆電的名稱命名，再按 Create key。每把 key 都可以單獨撤銷，而只限推論的 key 能執行模型，但碰不到 agent 工作階段。

在每台筆電上，同事打開 Servers，按 Add Server，輸入桌機的位址，貼上 key，再用 Test Connection 測試。連上之後，桌機的模型就會像其他模型一樣出現在筆電的模型選單裡。App 本身也註明這些流量走的是未加密的 HTTP，所以適合用在你信任的網路，例如辦公室的區域網路。

接著有人打開 Benchmarks，按 New Benchmark，選擇模型，保留 Quick 測試組。執行結果會記錄每秒 token 數、首個 token 的時間和延遲，讓團隊判斷這個共用模型夠不夠快，是能在通話中即時使用，還是只適合晚上跑批次。如果覺得慢，Servers 還有一個 Config 分頁，可以在 Speculative Decoding 底下設定一個小型的草稿模型，接著按 Restart now，再跑一次 benchmark 來比較。

最後團隊得到一台負責吃重工作的機器、每台筆電各一把可以單獨收回而不影響其他人的 key，以及「到底夠不夠快」的實測答案。

不寫程式的營運主管

Ken 負責一間小型網路商店的客服。他有兩個問題：哪個模型能正確讀出發票總額？模型能不能學會用商店自己的語氣回覆？

第一個問題，他到 Eval 按 Custom Benchmark。取好名稱，貼上十張發票和每張預期的總額，保留 Exact Match，再按 Create Benchmark。接著是 New Eval Run：勾選電腦上的兩個模型，勾選他的 benchmark，然後按 Start Evaluation。問題會在他自己的電腦上送給每個模型。

在這個範例中，一個模型拿到 90，另一個拿到 70，Diff 欄位顯示兩者差了 20 分。這是用他自己的文件測出來的結果，不是別人的排行榜。

至於語氣的問題，他收集了幾百則過去的客戶訊息，以及團隊實際寄出的回覆，一行一組。在 Datasets 裡，他可以匯入這個檔案，或是透過 Hub 分頁找公開資料，再用 "Use for Training" 交給訓練。在 Training 裡，他按 New Job，依序走過四個步驟：Base Model、Dataset、Config 和 Review。在 Training Target 選擇 Local (This Device)，畫面說明它會在裝置的 GPU 上執行，而且免費，方法則選 LoRA。

按下 Start Training 後，任務會在執行過程中顯示 loss。完成後，訓練好的 adapter 會出現在 My Models，就在它來源的基礎模型旁邊；在已完成的執行上按 "Chat with your model"，就會把它準備成裝置端 runtime 可用的格式，讓他能在 Playground 裡問它問題。最後他得到一個小巧、私有的模型，以及一個每次考慮新模型時都能重跑的 benchmark。

Local Model 在哪裡交棒

這個分類不是孤立存在的。你安裝或連接的模型，會出現在聊天使用的同一份模型清單裡，所以本機模型可以回答一般對話，也可以在 Playground 裡跟你在 Providers 加入的雲端模型比較。在 Explore 裡，"Use in Notebook" 會開啟一個已經為該模型設定好的 JupyterLab notebook，可以在本機或託管的執行個體上跑。當模型需要真正的 GPU、而不是你的筆電時，就由 Deployments 和 Cloud GPU 接手，把它放到託管的 endpoint 上。模型面對客戶之前，Safety 會對已部署的模型執行 red team 測試組。本機推論頁面更深入介紹裝置端引擎，LoRA 微調頁面則說明訓練的部分。

大家最先問的問題

我需要 GPU 或電競電腦嗎？
不需要。近幾年的筆電就能跑中小型模型；Explore 的適配標籤會在下載前告訴你機器放得下什麼。更強的桌機或遠端伺服器，只是讓可選清單變長而已。

會有東西被送到雲端嗎？
本機推論、Quantize 和本機訓練都在你的電腦上執行。Cloud GPU 訓練、Cloud GPU endpoints 和 Providers 是會用到外部服務的部分，畫面上也會標示，例如訓練對話框裡的 "Managed cloud GPU · needs credits"。

Eval 和 Benchmarks 有什麼不同？
Eval 用你自己定義的問題來評分回答的品質。Benchmarks 量測速度和記憶體：每秒 token 數、首個 token 的時間和延遲。

要去哪裡下載 App？
Local Model 在桌面 App 裡執行，可以到 osfoundry.io/zh/download 下載。

如何用 osFoundry 的 Custom App 打造並託管小型內部應用程式

tauchiii — Fri, 06 Nov 2026 18:47:20 +0000

週四，距離上線還有兩個小時，而 Dari 是唯一知道 cutover 哪些步驟已經完成的人。檢查清單放在試算表的某個分頁裡，runbook 在共用雲端硬碟上，討論則散落在一個沒人找得到的聊天討論串。團隊真正需要的，是一個只有四個核取方塊、兩位負責人的小應用程式，而且就放在檔案旁邊。寫出來很容易。要託管它、給它一個資料庫、安全保管它的金鑰、再幫它弄一個網址，這些才是通常卡關的地方。

Custom App 這個類別是什麼

osFoundry 把打造和執行自己的小型應用程式所需的一切，集中在桌面版 app 側邊欄的一個類別裡，名稱是 CUSTOM APP。裡面有五個畫面。Room 是共用空間，應用程式以分頁的形式存在其中。App Code 是應用程式背後的儲存庫。Deployed Apps 是整個 workspace 目前上線項目的清單。Snippets 收集那些從來不需要儲存庫的迷你應用程式。Domains 則管理這些應用程式對外提供服務的網址。如果你用過 Notion，可以想像一個頁面，它的分頁不是文件，而是可以運作的應用程式，底下再加一層類似 Vercel 的小型託管層：每個應用程式都有自己的資料庫、secrets、排程工作和子網域，詳見內部應用程式功能頁。

先看一下建置畫面

想看一個應用程式是怎麼開始的，最快的方法就是桌面版 app 的建置畫面。這張截圖來自 Websites 建置工具（範例專案「Hearth Bakery」），它用的是和 Room 裡「Describe the app you want」框一樣的「先描述、再建置」流程。

左邊的 Pages：應用程式中已經存在的部分，最下方是 Add page。
中間的預覽區：你正在打造的東西，上方可切換桌機、平板和手機尺寸。「On this computer」標籤表示目前還沒有發布任何東西。
描述框：寫下這個應用程式要做什麼、給誰用、想要什麼感覺，然後按 Build my site。應用程式的 AI 助理 Maestro 就會寫出檔案。
右邊的 Maestro 面板：用來建置和修改應用程式的對話。按 Use a folder 可以讓它參考你自己的素材，而不是自己亂猜。
上方的 Publish needs credits：建置和預覽都在你的電腦上進行；只有託管這一步會用到 workspace 點數。

在 Room 裡也是同樣的概念，只是排列方式不同：上方是一排應用程式分頁，中間是選取的應用程式，右側面板有兩個分頁，Maestro 和 Details。

使用情境 1：發布團隊把檢查清單放在工作現場

誰：一位 release manager 和三位準備上線的隊友。

狀況：cutover 步驟、runbook 和 release tracker 分散在三個工具裡，到了上線當天，沒有人信得過那份試算表。

他們在 osFoundry 裡做的事：

用 New Room 建立一個叫「Launch Ops」的 room，把 release tracker 和上線相關檔案加成分頁。
按分頁列上的 + 按鈕。New Tab 選單會列出已安裝的應用程式和一份目錄（Incident log、Retro board、On-call rota、Changelog builder），可以用 All、Forked 或 Snippets 篩選。
在「Describe the app you want」裡改按 Build a snippet，要求做一份每個項目都有負責人的 cutover 檢查清單。snippet 是由幾個檔案組成、可以直接執行的迷你應用程式。它沒有儲存庫、沒有版本、也不用部署，直接在分頁裡執行。
檢查清單開著的同時，繼續在右側面板和 Maestro 對話，並用 Details 分頁查看這個 room 的用途和裡面發生過的事。

最後的成果：一個 room 裡，檢查清單（demo 中是 Freeze the 2.4 branch、Run the order-index migration、Smoke-test the order desk、Post the release note）就放在 runbook 和 tracker 旁邊。之後，Snippets 畫面會列出所有 room 裡的 snippet。在那裡可以用 Export 把某個 snippet 匯出成 JSON 給其他 workspace 用，或是在它已經大到不適合待在分頁裡時，用 Promote 升級成真正的儲存庫。

使用情境 2：開發者幫內部工具接上真正的後端

誰：一位獨立開發者，正在為客服團隊打造報名與訂單工具。

狀況：第一版跑在一台筆電上，用的是 SQLite 檔案。現在有三個團隊要用它，它得呼叫金流 API，而且每晚的清理作業必須自動執行，不能靠人記得去按按鈕。

他在 osFoundry 裡做的事：

趁應用程式還在本機執行時，在 IDE 打開專案，點 Database 分頁。它會找到應用程式的 .db 和 .sqlite 檔案，以唯讀方式開啟資料表，每頁 200 列（上圖為範例資料），讓你在搬動任何東西之前，先看清楚應用程式實際存了什麼。
把應用程式搬到共用的 room。Move to cloud 對話框會把應用程式複製到 Cloud room，讓 room 裡的每個人都能使用，並回報哪些資料表已複製、哪些留在裝置上。應用程式和資料也會繼續保留在這台裝置上。
打開應用程式的分頁設定。在 Secrets 底下，App Runtime Secrets 會列出應用程式宣告的金鑰；Add a custom secret 可以新增一組，Rotate 則會替換某個值。接著應用程式會顯示「Secrets updated. Redeploy to apply changes.」
在應用程式 manifest 的 container.cron 底下宣告清理作業，然後打開 Scheduled jobs，點 Sync from manifest。每個工作都可以暫停、恢復，或用 Run now 立即執行一次。

最後的成果：一個擁有自己 Postgres 資料庫的應用程式。在 osFoundry 上，每個 Room App 都會配一個，預先裝好 pgvector 和 TimescaleDB，連線字串會在執行時以 secret 的形式提供（每個應用程式專屬的 Postgres）。資料庫瀏覽器有附篩選功能的資料列編輯器，以及只能執行 SELECT 的 SQL 檢視，而 Database snapshots 提供 New snapshot、Restore 和下載連結。程式碼的修改在 App Code 裡進行，開發者可以在 version/2.4 這類版本上作業而不動到 main，檢查 Manifest（進入點、可見性、需要的 connector），並在發布前查看 Versions 樹狀圖。

使用情境 3：店家老闆發布網頁並隨時掌握狀況

誰：一位經營小麵包店、不會寫程式的人。

狀況：她想要一個有菜單和營業時間的簡單網站，用自己的網址，也想知道維持網站上線要花多少錢。

她在 osFoundry 裡做的事：

打開 Websites，按 New Website，描述一下麵包店，再按 Build my site。第一版（上圖為範例）用的是暫代文字，Maestro 也會直接講明。
按 Use a folder，選擇放有真正菜單和照片的資料夾，然後用平常的話要求修改，例如「Make the headline bigger.」
看起來沒問題就發布。託管會用到 workspace 點數。Who can open it 可以選 Workspace members only、Anyone with the link，或應用程式自己的登入機制；公開的麵包店網站選 Anyone with the link。
在 Domains 註冊網域，或加入自己原本就有的網域，然後編輯 DNS 紀錄。Events 會顯示誰改了哪筆紀錄，Settings 裡則有續約、隱私設定和轉移碼。

最後的成果：一個用她自己的文字和照片、架在她自己網域上的網站。之後 Deployed Apps 就能回答老闆真正會問的問題。Apps 顯示每個應用程式和它的服務位置，Activity 顯示有哪些變更，Usage 顯示每個應用程式的建置和儲存成本，Previews 則列出仍在執行的預覽版本。

它如何和 osFoundry 其他功能銜接

Custom App 很少單獨運作。Maestro 是每個 Room 右側面板和建置畫面裡的助理，會和你一起撰寫、修改程式碼。IDE 提供 Database 分頁、版本控制，以及給那些從你電腦上某個資料夾起步的應用程式使用的編輯器。如果所謂的「應用程式」其實是個公開網站，用 Websites 會更快。Snippets 只透過 Promote 和 App Code 連結，所以一個用完即丟的小工具，不必重寫就能變成持續維護的儲存庫。應用程式內的排程工作由 app cron job 負責，詳見 app cron 平台頁面。

新手常問的問題

Room 是聊天室嗎？
不是。Room 的核心是它的應用程式分頁。Maestro 聊天位在右側的輔助面板，就在 room 的 Details 旁邊。

什麼時候該做 snippet，而不是應用程式？
當工具只有幾個檔案，而且只需要在一個 room 裡執行時，例如日期格式化工具或 webhook 檢查。儲存 snippet 不會安裝任何東西，也不會部署任何東西。如果之後需要版本、secrets 或資料庫，再用 Promote 把它升級成儲存庫。

兩個應用程式可以共用一個資料庫嗎？
每個應用程式都有自己的 Postgres。要共用必須透過明確授權：room 的 Database 分頁會顯示 Incoming Requests、Active Grants 和 Outgoing Access，每個請求都可以核准或拒絕。

試用要花錢嗎？
在你的電腦上建置和預覽不需要點數。發布、部署和註冊網域會用到 workspace 點數。桌面版 app 可以在 osfoundry.io/zh/download 下載。

osFoundry 這套桌面 AI 工作空間是什麼，又分成哪些區域？

tauchiii — Fri, 06 Nov 2026 17:33:58 +0000

星期一早上 9:40，瀏覽器開著四個分頁：一個拿來問問題的聊天機器人、一個因為不太信任第一個而開的第二個聊天機器人、一個裝了程式碼 agent 的編輯器，還有一個存著上週研究資料的筆記 App。每個工具都只知道你工作的一部分，沒有一個知道全貌。還沒到午餐時間，你已經把同一段背景說明貼進三個不同的視窗了。

用一個 App 取代五個分頁

osFoundry 是一套桌面 AI 工作空間：在同一個 App 裡，你可以和 AI 模型聊天、把工作交給 agent 和 agent 團隊、保存筆記和可搜尋的知識、在自己的電腦上執行開放模型，還能做出團隊可以使用的小型 App。模型可以來自三個地方：你自己的電腦、透過你自己的 API 金鑰連接的雲端供應商，或是租用的雲端 GPU。App 依類別分區，每個類別底下有好幾個畫面。Chat 是和模型對話的地方（Maestro、Multi chat、Branchspace 等）。Workstation 是 agent 處理較長工作的地方（Code、Agent、Agent team、Loop、Terminal）。Knowledge 存放你寫的東西以及 AI 記住的內容。Local Model 用來尋找、安裝和測試開放模型。Custom App 用於內部工具，Discover 則用於網路研究和新聞。如果你用過 VS Code，最接近的比喻是一個有活動列的編輯器，每個圖示打開不同的工具，只是這裡的工具都是 AI 介面，而且共用同一組專案、記憶和模型。

一個典型畫面長什麼樣子

大多數人都從 Chat 類別開始，所以這裡很適合用來了解 osFoundry 的畫面是怎麼組成的。下面是 Council 模式下的 Multi chat，使用的是範例資料：三個模型被問了同一個問題，接著互相替對方的答案評分。

上方的分頁列（Maestro、Model chat、Multi chat、Research、Wiki、Code）用來切換 Chat 區域的各個介面：完整的 Maestro agent、附引用來源的單純問答聊天、同時使用多個模型、深度研究、程式碼文件，以及程式碼 agent。
Compare / Council 切換鈕決定模型怎麼協作。Compare 把答案並排顯示，讓你自己判斷。Council 則讓模型各自作答、在不知道作者的情況下互相排名，最後寫出一份綜合結論。
每一欄是一個模型，並標示供應商：這裡是 Anthropic、Ollama（在本機執行）和 OpenAI。雲端模型和本機模型可以放在同一個畫面裡混用。
右側面板顯示這次執行的各個階段（Answers、Ranking、Synthesis）和 Peer review 分數表，讓你看到誰給了誰幾分，而不是只讀最後的答案。
Run 按鈕在你按下之前就會告訴你這次執行會呼叫幾次模型（這裡是「Run · 7 calls」）。關掉同儕排名，這個數字就會變少。

osFoundry 有很多畫面都遵循這個模式：左邊是清單，中間是主要工作，右邊是檢視面板，顯示結果是怎麼產生的。

獨立開發者的第一週

Ken 一個人經營一家小型網路商店。他想要一個了解自己程式碼的 AI，也希望有一部分工作能留在自己的筆電上。

星期一，他打開 Local Model，再進入 Explore。這個畫面會先讀取他的電腦規格（這個例子是 16 GB 記憶體），然後在每個開放模型上標示 Fits、Tight 或 Too big。他安裝了一個綠色標籤的模型，在 Playground 問了它幾個問題。Playground 會把同一個 prompt 同時丟給兩個模型並排執行，並顯示各自多快開始回應。

星期二，他要修改一個格式化價格的函式，但不確定有哪些地方依賴它。他在 IDE 裡打開專案，對函式按右鍵，選擇 Show Code Graph。

這個面板列出所有呼叫端，標示哪些關聯是直接從程式碼讀出來的、哪些只是推測，並在 Impact of change 中統計可能受影響的符號、檔案和測試數量。他點一下呼叫端就能跳到那一行，再用 Send to chat 把這張圖帶進和 Maestro 的對話。

到了星期四，他已經開始把小任務交給程式碼 agent。在 ADE 畫面中，每個任務都有自己的 worktree，Changes 分頁會顯示 diff。他在不認同的那一行旁邊點一下邊欄，輸入一則註記，然後把所有還沒送出的註記一次傳給 agent。這一週結束時，他有了一個處理快速問題時信得過的本機模型，也養成了重構前先檢查影響範圍的習慣。

小團隊主管的第一週

Aiko 帶領四個人，每兩週發布一次版本。她的問題不在寫程式，而是掌握每個人（不管是人還是 agent）正在做什麼。

她從 Message 開始，也就是團隊聊天。頻道和私訊的用法跟 Slack 一樣，只有一點不同：AI agent 也是頻道成員。有人在 #release 裡 @提及某個 agent，它的回覆和執行紀錄就會回到頻道中，大家都看得到。

接著她在 Workstation 裡建立一個 Agent team。由一個領導 agent 協調各個專業成員，畫面把 Team mail、Handoffs、Sub-agents 和 Proposals 分成不同分頁，方便她稽核誰把什麼交給了誰。對於每次發布都要做的檢查，她把這個團隊變成一個 Loop：設定觸發條件（例如平日早上）、回合數和重試次數的上限，以及成功條件。Loop 會一回合一回合地執行，直到條件全部通過，並記錄每一回合通過了哪些條件。

當好幾個 agent 同時處理同一個儲存庫時，她會使用 Code。每個 agent 都有自己的分支和 worktree，不會自動合併任何東西。她選取兩個已完成的執行結果，按下 Preview combined merge，在任何變更碰到主分支之前就看出哪些檔案會衝突。

做逐行審查時，她用的是跟 Ken 一樣的註記功能：註記釘在程式碼上，連同檔案、行號和程式碼一起傳給 agent。這一週結束時，她有了一個能看到 agent 工作成果的頻道、一個會自動執行的發布檢查，以及一個在合併之前而不是之後進行的審查步驟。

研究者兼寫作者的第一週

Lena 撰寫關於職場政策的長篇報告。她需要可以查證的來源，而且以前就吃過 AI 自信滿滿卻答錯的虧。

遇到單一模型的答案不夠可靠的問題，她會用 Council 模式的 Multi chat，也就是前面介紹過的那個畫面。當兩個審查者都給某個答案低分，她就知道要再深入查證。

比較大的問題，她會打開 Agents，按下 New session，選擇現成的 Deep Research Team。領導 agent 會把問題拆成幾個部分，分別交給 Data Researcher、Search Specialist 等成員。

另外有一個審查者會在每個步驟送到她手上之前先檢查，沒有來源的步驟會被退回並重新執行。最後的答案是一張每一列都附上來源的表格，另外附上一段簡短說明，指出來源之間哪裡有分歧、哪些部分沒有涵蓋到（截圖中為範例資料）。

實際寫作則是在 Knowledge 裡進行。在 Paper 中，她把草稿裡的一句話標起來，替它附加一個思考空間，裡面有 Academic search、Browser，或只討論這一段的 Maestro 工作階段等分頁。輔助檔案和留言則放在 Note 裡。在 Discover 中，她把搜尋存在 Browser，並在 News 追蹤關鍵字頻道，這樣為一份報告讀過的資料，下一份報告還用得到。

各個區域如何互相傳遞工作

這些類別不是各自獨立的產品，而是會互相接手工作。Local Model 是最底層：你從 Explore 安裝的模型，會出現在 Maestro、Multi chat 和 agent 工作階段的模型選單中。

Knowledge 為 Chat 提供資料：Memory 顯示 Maestro 對你的工作知道些什麼，Indexed Folders 則讓你選擇 agent 可以搜尋哪些資料夾。Agent 工作階段、Agent team 的執行和 Loop 都會回報到 Message 頻道。Workstation（同名的那個畫面）可以把頻道、筆記、檔案和 agent 工作階段並排開在同一個版面裡。當你用 agent 做出來的東西應該變成團隊工具時，它就會移到 Custom App，在那裡一個 Room 會把團隊的 App 和該團隊專屬的 Maestro 聊天放在一起。這一切用到的金鑰和供應商設定都在 Configuration 裡。想看完整地圖的話，平台總覽列出了每一個畫面。

第一週常見的問題

我需要用到全部功能嗎？
不需要。大多數人會先從一個區域開始，通常是 Chat 裡的 Maestro 或 Local Model 裡的 Explore，等有任務需要時再加入其他區域。各類別共用專案和記憶，所以一開始做的東西之後都不必重做。

我的資料會離開我的電腦嗎？
使用本機模型時不會，它們在你的裝置上執行。透過你自己的 API 金鑰連接的雲端模型會看到你傳過去的內容，這部分的使用量由供應商計費。本機優先頁面說明了兩者是如何區隔的。

只有開發者能用嗎？
不是。Code、IDE 和 Terminal 是開發者工具，但 Message、Paper、Note、Research、Multi chat 和 Discover 也是為寫作者、分析師和團隊主管打造的。

要多少錢？
桌面 App 可以免費下載，執行本機模型也不會產生任何 osFoundry 使用費。你可以從下載頁面取得。

osFoundry 的 Maestro 能做什麼？一個會把每個步驟都攤開給你看的 AI 聊天

tauchiii — Fri, 06 Nov 2026 17:15:37 +0000

星期四下午 4:40，Priya 請 AI 助理在她 App 的設定頁加一個「刪除帳號」按鈕。回覆寫著：「完成，修改了 4 個檔案。」在上線之前，她想知道是哪四個檔案、助理讀了哪些東西才做出這個決定，還有它有沒有碰到帳務相關的程式碼。一般的聊天視窗只會給她最後那一段話，其他什麼都沒有。

一段話看懂 Maestro

Maestro 是 osFoundry 桌面 App 裡功能最完整的 AI 工作區。你可以像在任何聊天介面一樣輸入需求，但回答會連同它的工作過程一起出現：它列過的每個檔案、跑過的每次搜尋、讀過或改過的每個檔案，以及每一道終端機指令，每一項都是獨立的一列，附上耗時，點開就能看細節。它可以在你電腦上的某個資料夾裡工作，用「提出修改」取代默默寫入，也能在動手之前先停下來給你看計畫。在側邊欄的 Maestro 就能找到它。如果你在瀏覽器用過 ChatGPT 或 Claude，可以把它想成同樣的對話，只是旁邊多了一份代理的活動紀錄和幾道煞車。

先看看畫面

最上方的功能分頁。Maestro、Model chat、Multi chat、Research、Wiki 和 Code 都在同一個畫面上。Maestro 是工具最齊全的那一個分頁。
對話上方的細節分頁：Chat、Sources、Files、Changelog、Tools、Pipeline 和 Logs。它們是同一次執行的不同檢視。Sources 保留回答所依據的資料，Changelog 列出這個聊天寫入過的檔案，Logs 則顯示每個步驟，並在 Costs 底下列出每次請求的費用。
對話紀錄中的流程列。這裡 Maestro 列出了 src/（38 個檔案），用 grep 搜尋 deleteUser，找到 0 筆，接著讀了 account.ts 和 users.ts。點一下任何一列，就會展開顯示那次工具呼叫確切的輸入與輸出。
輸入框上方的控制列：沙盒開關、Plan OFF/ON、Tools 和 Goal。輸入框下方則是資料夾、專案、repo、Router 和模型的選擇器。
右側的預覽面板，檔案、diff 或網頁會在對話旁邊打開，而不是蓋掉對話（Open File / App / Page、Browse Files、Browser）。

三種常見用法

想在改動之前先看計畫的獨立開發者

就是開頭 Priya 的情境。這次修改牽涉到帳號和 session，所以她寧可先讀計畫，也不想事後審一份突如其來的 diff。

她在控制列點一下 Plan，讓它顯示 Plan ON。
她輸入「Add a Delete account button to settings」然後送出。
Maestro 讀了六個檔案，一個都沒改。Plan 模式開啟時，是桌面 App 本身會拒絕任何寫入檔案或執行指令的工具，所以「唯讀」並不是寫在提示詞裡的客氣請求。
一張標示「Awaiting approval」的 Plan 卡片出現，上面有 Approve 和 Cancel 按鈕。

範例中的計畫列出四個檔案，說明 src/billing/ 不會動到，因為 Stripe 自己會保存紀錄，最後一句是「Nothing has been changed yet.」計畫一送達，Plan 模式就會自動關閉。Priya 按下 Approve 之後，Maestro 才開始修改那四個檔案並跑測試（npm test -- account，3 passed），全部都以 EDIT 和 TERMINAL 列顯示出來。如果她不滿意這份計畫，按 Cancel 資料夾就會維持原樣，一點都不會變。

她最後拿到的是：一個事先同意過的修改，以及一份清楚顯示代理看過哪裡、執行過什麼的對話紀錄。

正在熟悉程式碼庫的新同事

Dan 星期一剛加入團隊。他需要找出登入鎖定的邏輯在哪裡，但程式碼裡沒有人把它叫做「lockout」，所以用文字搜尋什麼都找不到。

他在 Indexes 把專案資料夾加進去一次，讓它可以用語意搜尋。
他在針對這個資料夾的 Maestro 聊天裡，問 App 在登入失敗後是在哪裡把使用者鎖住的。
他看著流程列：一次資料夾搜尋回傳 2 筆結果，接著是對 throttle.ts 的 READ。

回答指向 src/auth/throttle.ts（第 1–46 行）和 src/routes/session.ts（第 22–61 行），並解釋程式碼裡從來沒有出現「lock out」：連續五次失敗後，它會把冷卻時間設在 15 分鐘之後，並在檢查密碼之前就回傳 429。因為回答附上了檔案路徑，流程列也顯示讀過哪些內容，Dan 可以在預覽面板打開同樣的那幾行，自己驗證這個說法，而不必只相信一段摘要。這個情境不會寫入任何東西到磁碟，所以 Approval Mode 維持預設就好。

他最後拿到的是：真正關鍵的兩個檔案、關鍵字搜尋找不到它們的原因，以及一個之後可以從聊天清單回來繼續的對話。

在別人的 repo 裡改文案的行銷人員

Sammy 負責寫上線頁面的文案，但那個頁面是工程 repo 裡的一個 React 檔案。她希望新文案符合 docs/ 裡的語氣指南，也不希望任何東西在她看過之前就被 commit。

她打開輸入區的 Approval Mode 選單，選擇 Permission & Approve，每次呼叫工具前都會先詢問。其他選項有 Auto Accept（預設，工具會立即執行）、Plan First（先規劃再執行）和 Bypass（完全不需要核准，包括 push 和送出表單）。
她開啟沙盒，讓寫入的內容暫存在一個 branch 上，而不是直接落在工作資料夾裡。
她請 Maestro 起草上線頁面，並與文件保持一致。它讀了 docs/tone.md、搜尋原始碼，然後提出對 src/Launch.tsx 的修改。
diff 在預覽面板中打開。她接受修改，再用 Export to branch，讓工程師可以像審其他修改一樣來 review。

她最後拿到的是：引用了所依循語氣指南的文案（Sources 分頁會保留下來）、一份審過的 diff，以及一個 branch，而不是 main 上冒出來的意外。

Maestro 與 Model chat、Chat、Multi chat 的差別

Maestro 和幾個比較簡單的兄弟共用同一個畫面，選對工具可以省時間也省錢。

Model chat 是同一個畫面上的分頁，每一輪都會送給你挑選的單一模型。它是唯讀的對話：沒有資料夾、沒有會動手的工具、也沒有核准流程。適合問個快速的問題。
Chat 在側邊欄有自己的位置。它同樣是用你為整段對話選定的一個模型來回答，但保留了檔案相關的能力，所以它可以提出修改，由你 Accept 或 Reject，並記錄在 Changelog 中。想讓某個特定模型來做事、不想讓 router 幫你選時，就用它。
Multi chat 會同時把同一個問題丟給多個模型。在 Compare 模式下你可以並排比較答案；在 Council 模式下，各模型先回答，再以匿名方式互相評分，最後由其中一個模型寫出綜合結論。

從 Maestro 出發，工作常常會接著移到 App 的其他地方。Research 會把一個問題變成附有出處的報告，Code 會在自己的 branch 上跑程式碼代理，Indexes 讓資料夾可以用語意搜尋（就像 Dan 的情境），而 Version → Merge Station 則是合併沙盒修改的地方。如果某一輪出了差錯，在聊天中輸入 /rewind 就能還原那一輪改過的檔案。想深入了解的話，Maestro 協作編排頁面會逐一介紹各個細節分頁，Plan 模式頁面則說明核准流程。

大家最先會問的問題

Plan 模式只是寫在提示詞裡的指示嗎？
不是。Plan 為 ON 的期間，任何不在唯讀清單上的工具，在 App 派發時就會被拒絕。所以代理可以讀取、搜尋和瀏覽，但在你核准計畫之前，它無法編輯或執行指令。

Plan 開關和 Approval Mode 裡的 Plan First 有什麼不同？
Plan 是只對下一個請求生效的一次性開關：先調查、提出計畫、等待。Approval Mode 則是這個聊天對工具呼叫的固定規則，從 Auto Accept 到 Bypass。Plan First 是其中四種設定之一。

流程列太多了，可以隱藏嗎？
可以。Process Detail 設定可以在 Full 和 Compact 之間切換。它只改變步驟的顯示方式，不會影響這一輪的執行方式。

Maestro 用的是哪個模型？
預設由 Router 每一輪挑選模型，流程列會顯示實際跑的是哪一個。你可以在輸入區切換模型模式（雲端、本機或自行架設），或是想在整段對話固定使用同一個模型時，改用 Chat。

桌面 App 可以在 osfoundry.io/zh/download 下載。

osFoundry 的 Loop 和 Graph 是什麼，什麼時候該用哪一個？

tauchiii — Fri, 06 Nov 2026 16:36:12 +0000

傍晚 6:40，AI 助理剛告訴你失敗的測試已經修好了。你自己跑一次，還有兩個是紅的。你可以把輸出再貼回去重問一次，也可以把這件事交給一個「測試執行器點頭才會停」的東西。隔天早上，行銷部的同事問了另一個問題：同樣的東西，能不能在每個工作日她進公司之前，先幫她檢查三個競爭對手的網站？

這兩件事都在 osFoundry 的同一個角落，就在兩個相鄰的選單項目底下：Loop 和 Graph。

兩種不用一直盯著就能跑 agent 的方式

Loop 是一種可重複使用的方式，讓一組 agent 朝著一個目標工作。它把幾樣東西打包在一起：agent 名單、用白話寫的目標、確認目標是否達成的檢查方式、硬性上限（最多幾輪、連續失敗幾次就放棄），以及可選的觸發條件，例如排程。它一輪一輪地跑，每輪都拿目標來評分，然後自己停下來。Graph 則是一個存起來的工作流程程式，適合路徑不固定的情況：它可以依結果分支、把某一段重做到通過為止、把工作同時分給好幾個 agent、暫停等人核准，還能呼叫其他 graph。兩者都在 osFoundry 桌面應用程式的主側邊欄裡，Loop 在上、Graph 就在它正下方。應用程式自己給的一句話區分最值得記住：Loop 永遠走同一條路，Graph 邊走邊決定路線。

Loop 執行時你會看到什麼

這是一個已經跑完的 Loop 工作階段（測試和檔案名稱都是範例資料）。值得認識的部分：

左邊的工作階段列。每次執行 Loop 都是獨立的工作階段，底下有狀態。這裡的「Verified」代表最後一輪通過了檢查，而不是 AI 說它通過了。
中間欄位上方的輪數列。「Round 3 of 4」，加上它使用的檢查（「Runs npm test — a zero exit code means done」），以及連續驗證失敗的計數器，原地打轉的 loop 就是靠它停下來的。
Rounds 分頁。每輪一列，顯示達成了幾項條件（「1 of 3 met」、「2 of 3 met」、「3 of 3 met」）。點開某一輪，就能看到那一輪到底通過了哪些條件。
右邊的檢視面板，有 Goal、Trigger 和 Hooks 三個分頁。
面板上方的 Pause 和 Cancel，想讓它馬上停、而不是等到下一次檢查時用。

使用情境 1：想讓測試真正變綠的開發者

誰：一位獨立開發者，一天快結束時，手上有一套紅燈的 JavaScript 測試，還有一個不斷宣布大功告成的助理。

打開 Loop，按下 New session。New loop run 對話框會列出現成的 loop，搜尋「JS suite」就能找到 Get the JS suite green。開始之前，右邊的卡片會告訴你它怎麼運作：Who runs it（一個除錯 agent 帶領三位測試專家）、How it stops（最多 4 輪，連續失敗 3 次就停）、How it grades itself（執行 npm test，只有 exit code 為零才算完成）。

在 Start it 底下選 Run once now 而不是 Just add it，選好專案和 agent 要工作的資料夾，按下 Run it now。接著打開 Rounds 分頁看著就好。在範例執行中，第一輪通過三個測試裡的一個，第二輪兩個，第三輪三個全過，loop 就在這時自己停下，工作階段被標成 Verified。

最後你拿到的不是一則聲稱已經修好的聊天訊息，而是一份逐輪紀錄，寫著哪個測試在什麼時候通過，評分的是你自己的測試執行器。同一份清單裡還有 Python、Go、Rust、Java 測試套件、型別錯誤、lint 和不穩定測試用的 loop。

使用情境 2：想在每個工作日拿到競品報告的行銷人員

誰：行銷或產品部門裡，會手動檢查競爭對手網站、但不寫程式的人。

在同一個 New loop run 對話框裡，最上面的區塊標著「Start here — these need nothing set up」，Watch the competitors 就在裡面，因為它只會上網搜尋，從不碰你的檔案。在 Goal for this run 裡輸入要盯哪些公司、要找什麼（例如價格、新功能和徵才），選 Run once now，按下 Run it now。第一份報告只列出有變動的地方，每一行都附上日期和來源，公司對自己的說法會標示為未經查證。

要讓它定期執行，就打開 Trigger 分頁，按下 Add a schedule。Run this on a schedule 對話框提供預設選項（Every 30 min、Hourly、Daily 09:00、Weekdays 09:00），顯示 cron 設定和接下來三次的執行時間，並問兩個很實際的問題：下一次該跑的時候上一次還沒跑完怎麼辦（Skip it，或 Wait, then run），以及電腦在睡眠狀態時怎麼辦（Up to an hour late、Up to 12 hours late 或 However late）。

按下 Save schedule 後，Trigger 分頁會顯示「On a schedule」和下一次的執行時間。她從此每個工作日早上都有一份報告在等她，完全不用打開終端機。排程只在桌面應用程式開著時執行，補跑設定就是為了這個而存在。

使用情境 3：工作流程需要分支的團隊主管

誰：一位主管，希望大型變更裡的每個檔案都分開審查，再合併成一份報告，而且在任何無法復原的動作之前，都要有人簽核。

到這裡，Loop 就不再是合適的形狀了。Loop 每一輪都重複同一個計畫，但這位主管需要每個檔案各一位審查者、接著一個合併步驟，有時還要暫停等核准。這就是 Graph。

打開 Graph，按下清單旁的加號按鈕。Create a Graph 提供兩條路：Start with a working graph（一個安全、可直接執行的程式，之後再調整）或 Choose a starter。Starter 是常見結構的完整範例，每個都附有簡短的使用時機說明。Review each item, then merge 會同時為每個項目跑一個 agent，最後做一次合併。Triage and route 會先把輸入分類一次，再送給剛好一位專家。Propose, ask, then apply 會先擬好變更，停下來等人回答，只有得到肯定答覆才動手。

程式本身是程式碼，不是拖拉式流程圖，因為分支和有上限的重試是真正的控制流程。通常你會讓 Maestro 或某個 agent 來寫或調整它，自己則在 Configure session 裡管理日常真正重要的部分：Maximum agents at once、token 警示、Hard token ceiling、預設輸入，以及每個步驟使用哪個 agent 和模型。

執行時，執行面板有三個分頁。Run 即時顯示每個步驟，可以 Pause、Resume 或 Cancel。如果 graph 走到核准步驟，會出現一張卡片請你 Approve 或 Decline，等待期間其餘的平行工作照常進行。Changes 列出這次執行建立或修改的檔案，其中有些可以復原。History 列出之前的執行紀錄，所以失敗的那次和修好它的重跑會並排在一起。主管最後得到一套可重複的審查流程，每次執行和檔案變更都能事後檢查。Graph 可以在瀏覽器裡查看，但要執行就需要桌面應用程式。

Loop 和 Graph 在哪裡交棒

這兩個功能都不是單打獨鬥。Loop 的 Team roster 裡的 agent 來自 Agent team 和 Agent Registry，而 loop 本身是一個可重複使用的預設組合，可以在 osStudio 裡做版本管理，所以調高品質門檻或重試上限都會留下歷史紀錄，而不是悄悄改掉。Graph 在建立時就會拿到一個固定的識別碼，目的正是讓 loop 和其他 graph 能呼叫它，也就是說，一個排程好的 Loop 可以在 9:00 啟動一個會分支的 Graph。在 Message 裡，loop 和 graph 可以跟人、單一 agent 一起成為頻道成員，它們的進度就會出現在團隊平常用的聊天室。想深入了解排程的部分，可以看用 cron 排程 agent 和 agent 觸發條件。

新手常問的問題

Loop 不就是 cron job 嗎？
不是。排程只是其中一個可選的部分。Loop 是團隊加目標加檢查，再加上輪數上限，而且會記錄每一輪達成了哪些條件。你可以只手動跑一次，永遠不給它設觸發條件。

既然 Loop 也能平行跑 agent，那我為什麼還需要 Graph？
差別不在平行。當下一步取決於上一步的結果時，就該用 Graph：轉給某一位專家、只重跑失敗的部分、等人點頭，或是呼叫另一個工作流程。如果每次執行都走一樣的步驟，Loop 比較簡單。

loop 會不會一直跑下去，把我的 API 預算燒光？
每個現成的 loop 都有輪數上限，連續失敗到一定次數就會停，而且卡片在你開始前就會把這兩項都顯示出來。Graph 則在工作階段設定裡有 Maximum agents at once 和 Hard token ceiling。

我需要寫程式嗎？
用 Loop 不需要：選一個，在對話框裡設定目標和觸發條件就好。Graph 的程式是程式碼，但你可以從 starter 開始，讓 Maestro 或某個 agent 幫你改，而輸入、上限和每個步驟用的 agent 都能在不動程式的情況下調整。

兩者都可以在桌面應用程式裡試用，下載請到 osfoundry.io/zh/download。

osFoundry 的 Code、IDE 和 Wiki 怎麼讓多個 AI 代理同時寫的程式碼都能好好審查？

tauchiii — Fri, 06 Nov 2026 14:25:57 +0000

現在是下午 4 點，從午餐後就有三個 coding 代理在同一個 repository 上工作。一個修好了購物車總額的四捨五入，一個加了折扣碼，一個寫了測試。三個都回報 "done"。在任何東西碰到 main 之前，你會想知道兩件事：有沒有兩個代理改寫了同一個函式？三個改動合在一起還能不能通過測試？

一個 codebase，三個畫面

osFoundry 是一款桌面應用程式，把聊天、代理、檔案和工具放在同一個視窗裡；在程式碼方面，它提供三個彼此相關的畫面。Code 是你同時把任務交給多個代理的地方：每個 run 都有自己的 Git 分支和自己的工作資料夾（worktree），你可以先審查、測試、預覽合併結果，再決定要不要動手。不會有任何東西自己合併。IDE 是針對本機資料夾的程式碼編輯器，有檔案總管、版本控制、終端機、Problems 和 Tests 面板，還有一欄看得到你目前開啟檔案的助理。Wiki 會讀取你電腦上的 repository，寫出引用 path:line 的文件頁面，並在被引用的程式碼改變時標記該頁。Code 和 Wiki 是分頁，跟 Maestro、Model chat、Multi chat 和 Research 並排；IDE 則在側邊欄有自己的項目。如果你用過附 Git 面板的 VS Code，IDE 會讓你覺得很熟悉。Code 比較像是 pull request 收件匣，只是作者換成了你的代理，而且分支從來沒離開過你的筆電。

看一下 Code 分頁

這個畫面上可以看到的東西（run 是範例資料）：

側欄頂端的橫幅。"3 agents finished · they disagree on 1 file" 會在你打開任何一個 diff 之前，就先點出檔名，這裡是 src/cart.js。按下 Review together 按鈕就會開始共同審查。
run 側欄。run 會依照它們需要你做什麼來分組：Ready to review、Needs attention，以及收合起來的 History。每一列會顯示任務、新增和刪除的行數、代理工作了多久，以及它的分支。
中間的對話。點一個 run，就能看到當初交代代理做什麼，以及它在工作時說了什麼。
右側面板。Changes、Files、Commits、Review 和 PR 分頁會顯示每個 run 的實際 diff，先是尚未 commit 的工作，接著是已經 commit 到它分支上的內容。
右下角的 Merge station。選好已完成的 run，就在這裡測試它們，並預覽把它們合在一起的結果。

使用情境：一位 tech lead 在同一個 repo 上用三個代理

Dana 帶一個小型網頁團隊，把一個結帳功能的 sprint 拆成三個代理 run：修正購物車總額的四捨五入、在結帳流程加入折扣碼、替價格格式化函式寫測試。每個 run 都是從 New run 開始，配一行任務描述和挑好的代理，所以各自有自己的分支和資料夾，工作時誰也不會踩到別人的檔案。

橫幅說它們意見不一致時，她勾選三個 run，按下 Review together。Merge 面板顯示 "3 runs · conflicts not checked yet · 3 not yet tested"，這是一句誠實的「還不知道」，而不是綠燈。下方的 src/cart.js 被標成 contested，各分支的 hunk 並排列出：四捨五入的修正和折扣碼都改寫了 total()。

接著她對每個 run 按下 test。測試會在該 run 自己的 worktree 裡執行，所以她自己的 checkout 完全不會被動到。預設是 "Tests must pass before a branch can merge"，這條規則可以在 Settings 裡修改。三個都通過了，但各自通過不等於合起來也通過，所以她按下 Preview combined merge。應用程式會先在一份用完即丟的副本裡合併這些分支，再回報結果：兩個可以乾淨合併，一個有衝突。

她把兩個乾淨的分支合併進自己目前的分支。直到這一刻，她的分支才有變動。折扣碼的分支保留下來，讓代理可以在四捨五入修正的基礎上重做它的改動。如果她想要的是每次嘗試裡最好的部分，而不是整個分支，可以用 Combine into a branch 一個個勾選 hunk，用它們建立新的分支。

還有一個在漫長工作日裡很重要的細節：如果應用程式在 run 還在工作時停止，這個 run 回來時會顯示 Interrupted，而不是 "running"，並附註它的分支已保留。

使用情境：一個人開發、跟助理一起重構

Kenji 一個人維護一個網路商店的前端。今天早上他要改 formatPrice，但不太確定有哪些地方呼叫它。他從側邊欄在 IDE 裡開啟專案資料夾。編輯器的版面就是大家熟悉的那樣：左邊是 Explorer 和 Source Control，中間是分頁，下方是 Terminal、Output、Problems 和 Tests，右邊是 Assistant，他可以在那裡開一個同步的聊天，或是只留在裝置上的本機聊天。

他在 formatPrice 上按右鍵，選 Show Code Graph。面板會列出 Callers 和 Calls。實心圓點代表這個呼叫是直接從程式碼讀出來的；空心圓點代表是推測出來的，那一個就值得自己再看一眼。Impact of change 會一路追到呼叫者的呼叫者，在這個例子裡顯示 "15 symbols · 14 files · 3 tests"。點一列就會跳到那一行，Send to chat 則會把整張圖當作上下文交給助理。

稍後，助理幫他改了一個設定檔。在 Source Control 裡這個檔案顯示為已修改，打開時會有一個小機器人標記，狀態列也會顯示它最後是由 AI 寫入的，附上模型和它給的理由。Review 會開啟一個並排 diff，對照的是那次寫入前一刻存下的副本，所以他只會看到那一個改動。這裡顯示 timeout 從 30 秒被砍到 3 秒，正好就在一行註解下面，註解寫著大型上傳要 20 秒以上。他在 commit 之前就抓到了。

如果代理寫入一個他還有未儲存修改的檔案，編輯器會告訴他：你編輯期間這個檔案在磁碟上被改過了，並讓他選 Keep mine 或 Use the disk version，而不是默默替他挑一個。

使用情境：一位只需要看懂程式碼、不用修改的支援工程師

Priya 在客服部門工作，常被問到產品某個部分的行為是怎樣。她看得懂程式碼，但不想在一個不屬於她的 repository 裡到處 grep。她在 Wiki 裡用 Open a folder（或用 https 或 git@ 網址執行 Clone a public repository），應用程式就會在她的電腦上讀取專案結構。

在寫入任何東西到專案之前，Wiki 會先問。對話框會寫出它要在 repo 裡建立的確切資料夾，如果她按 Not now，就什麼都不會寫入。同意之後，她可以用 Generate pages，或針對單一主題用 Write a page。設定決定每一頁要根據多少原始碼來寫（Depth：Quick、Standard 或 Deep），以及要檢查多少論述（Verification：Off、Sample 或 Full，Full 大約會讓費用翻倍）。產生頁面之前就會先顯示費用。

每一頁都會引用 path:line，點一下引用就會在 IDE 裡開啟那一行。一個月後，側欄裡有一頁被標記，因為 "a file this page cites has changed since it was written"，提醒她要先重新產生再相信內容。遇到臨時的一次性問題，她會用頁面旁邊的聊天，回答同樣會引用該專案的 path:line，她也可以直接用白話要求新頁面，例如 "write a page about the retry policy"。這些頁面本身就是 repository 裡的 markdown 檔案，所以團隊可以在跟程式碼同一個 pull request 裡審查它們。

Code、IDE 和 Wiki 之間怎麼交棒

這三個畫面會互相傳遞工作，也會交給應用程式的其他部分。Wiki 的引用會在 IDE 裡開到被引用的那一行，反方向則可以用 IDE 裡的 Wiki for this folder 按鈕。IDE 的 Assistant 和 Wiki 頁面旁的聊天都是建立在 Maestro 上，也就是你在 osFoundry 其他地方用的同一個助理，所以在那裡提問的方式跟任何 Maestro 聊天都一樣。想要依照意思、而不是精確字詞來搜尋 codebase 的話，Indexes 會建立一個 Maestro 可以使用的本機搜尋索引。等 Code 裡的某個 run 準備好離開你的筆電時，Open PR 會替它的分支開一個 pull request。

產品頁面上有兩者的互動示範：Code 和 IDE。

大家最先問的問題

一定要用桌面應用程式嗎？
是的。Code、IDE 和 Wiki 都要用到本機資料夾、Git worktree、shell 和語言伺服器，所以它們在 osFoundry 桌面應用程式裡執行。

代理會不會自己合併到我的分支？
不會。run 都在各自的分支、各自的資料夾裡工作。只有在你按下 merge 時，你目前的分支才會改變，而且預設只限測試通過的分支。

Wiki 是像 Notion 那樣的團隊 wiki 嗎？
不是。它是從程式碼 repository 寫出文件，引用檔案和行號，並在那段程式碼改變時標記頁面。它是給 codebase 文件用的，例如架構總覽或新人上手筆記。

有衝突的分支會怎樣？
它會留在原地。你可以先合併乾淨的分支，再讓代理在它們之上重做有衝突的那個，或用 Combine into a branch 挑選個別的 hunk。

桌面應用程式可以在 osfoundry.io/zh/download 免費下載。

osFoundry 的 Agent team 能做什麼？什麼時候一個 agent 就夠了？

tauchiii — Fri, 06 Nov 2026 13:46:37 +0000

星期二早上 7:40，Priya 手上有個問題，主管要她午餐前給答案：一週工作四天，產出真的不會掉嗎？她大可以把問題貼進聊天機器人，拿回一段口氣篤定的文字。但找數字的模型，同時也是判斷這些數字站不站得住腳的模型，而它很少會反駁自己。她要的是一個人去找試行案例、另一個人把數據拉出來，再由第三個人把沒有來源的東西全部退回去。

同一個畫面的兩個入口

osFoundry 是一款在自己電腦上跑 AI 工作的桌面應用程式，把工作交給 agent 的方式有兩種，兩者關係很近。Agent（側邊欄顯示為 Single agent）是一個有名字、只負責一件事的 agent：你給它指示，它會拿到自己的 ID，例如 AG-0001L，每一次執行都有紀錄，之後可以回頭追。Agent team 則是讓一位 leader 帶著一組專職成員。Leader 規劃工作、把每個步驟分給成員，再由 reviewer 檢查每一步，通過後才會交到你手上。兩者都在側邊欄的 Agents 底下，緊鄰彼此，開啟的也是同一個畫面。差別只在成員多寡。如果你待過有專案經理的群組聊天，Agent team 用起來會很熟悉。不同的是，每則訊息、每次交接、每個判定都會留下來，可以捲回去看。

看一下團隊畫面

這是一個已經跑完的團隊工作階段。問題和答案都是展示用執行的範例資料。

與 leader 的對話（中間）。 標題寫著「Leader · Orchestrate your team」。你只要在這裡問一次，彙整後的答案也會出現在這裡；這個例子是一張每列都附來源的表格，加上一行「Where sources disagree」和一行「Not covered」。
工作階段分頁（中間上方）。 Chat、Team mail、Email、Handoffs、Sub-agents、Proposals 和 Files。Handoffs 顯示誰把工作交給了誰。Proposals 收集 agent 對檔案或設定提出的修改建議。建議在被接受之前都不會套用。
Agent session 面板（右側）。 每位成員一張卡片，列出 leader 交代它做什麼、它呼叫了哪些工具（web_fetch、web_search）以及結果。每個結果底下會顯示 reviewer 的判定，例如「Approved」。上方有執行選擇器（「Run 1 · 07:40 AM」）和 Cards / Graph 切換。
Team roster 分頁。 這是這個工作階段中允許動作的成員名單。團隊是一份名單，不是工作流程。工作的順序來自 leader 的計畫。
工作階段側欄（左側，這裡隱藏）與 inspector。 側欄列出每個工作階段和它的 ID。Inspector 有 Goal、Trigger、Hooks 三個分頁，分別對應完成條件、觸發這次執行的來源，以及工作前後的檢查。

三種常見用法

每個數字都要有來源的研究人員

Priya 打開 Agent team，按下 New session。在 New team session 對話框裡，她維持「Start from a team」，並從 Team 清單選了 Deep Research Team。對話框載入了五位成員（deep-research-agent、research-analyst、data-researcher、search-specialist、academic-researcher）。「Who leads」底下顯示 Orchestrator，說明是「plans the work up front, then delegates the steps to the agents below」。她也可以在任何一位成員上按「make leader」，改由那位成員帶頭。

她按下 Create，在 leader 的聊天裡輸入問題送出。Leader 把問題拆成五個部分：找試行案例、找研究、找數字、找反面證據，最後整合成一個答案。三位成員同時開工。Data Researcher 會先等 Search Specialist 的清單出來，才開始拉數據。當 Data Researcher 回報一個 40% 的數字時，reviewer 把它標成「Sent back」，理由是沒有來源、日期也沒有衡量指標。這一步重新執行、找到來源，然後通過。

最後她在中間窗格拿到一個答案，裡面每個數字都經過「找到它的 agent 以外」的人檢查。她還拿到一行誠實的「Not covered」，可以直接貼進給主管的筆記。

老是在貼同一段指示的獨立開發者

Tom 一週會好幾次把會議紀錄整理成待辦事項，每次都得先把同一段規則貼進聊天裡。這種工作不需要團隊，需要的是一個記得規則的 agent。

他打開 Single agent，按 New session，停留在 Create in chat 分頁。在「New agent」欄位寫一行說明需求，按下 Start。打開的聊天是一個設定用的 agent。它問了幾個問題，接著提出名稱、@handle 和完整的指示。輸入框上方會出現一張卡片，上面有名稱、handle、Show instructions 連結和 Create agent 按鈕。

他打開指示，確認他最在意的那條規則有寫進去：絕對不要猜負責人或截止日。然後按下 Create agent。同一個聊天現在就變成那個 agent。他貼上會議紀錄後，缺少的負責人和日期都會標示為缺漏，絕不會用猜的。這個工作階段會在側欄保留它的 Agent ID，下次他只要選這個 agent 就好。

想看清楚誰做了什麼的 release 負責人

Dari 負責一個小型產品團隊的發版。她的團隊工作階段有一位 leader，成員是 Release Drafter、Change Auditor、Docs Reviewer、QA Summarizer 和 Approval Prep，各自負責發版包的一部分。

執行之前，她打開 Goal 分頁，按下 Set a goal。面板說明，目標會拆成幾條成功條件，一開始都是失敗，隨著 agent 達成逐一轉綠。工作階段會持續執行，直到全部通過或達到回合上限。她寫了三條條件，最後一條是核准資料包要齊全。成員工作時，她在 Handoffs 追蹤從 leader 到各成員再回來的整條鏈。她也會看 Proposals 裡有沒有成員提出的設定變更，那裡的東西沒有她點頭都不會套用。她隨時可以在 leader 的聊天裡回覆來調整方向，審閱時也可以按面板標題列的 Pause 暫停執行。

最後她拿到發版包，以及每個部分由誰起草、誰稽核、誰核准的紀錄。有人問 release notes 裡某一行是怎麼來的，她都能拿出來給對方看。

在應用程式其他地方的延伸

Agent 和 Agent team 是工作的起點，Sessions 則是你觀察工作的地方。這個看板把每個聊天、agent、團隊和終端機工作階段都顯示成一張卡片，依照工作階段實際的狀態分到 Running、Needs you、Paused、Idle、Done 和 Failed。

同一份團隊工作需要反覆執行時，Loop 會替成員名單加上觸發條件、上限，以及每一回合哪些條件通過的紀錄。Graphs 則適合路徑會依中途結果而改變的工作。與 leader 的對話是一個 Maestro 聊天，所以團隊的答案可以接著用在你其他的 Maestro 工作裡。工作階段的 Enable sync 連結會把它接上專案的訊息頻道，讓人和 agent 在同一個地方溝通。更多內容請看 Agents 功能頁面和 agent 工作階段概覽。

新手常問的問題

什麼時候該用單一 agent，而不是團隊？
工作是一件明確、規則固定的任務時，用單一 agent，例如整理筆記格式，或用同一種語氣草擬回覆。工作包含需要不同工具的幾個部分，或你希望在看到結果前先由另一位 reviewer 把關時，就用團隊。

工作階段開始後可以換團隊嗎？
不行。New team session 對話框寫明團隊「is fixed for this session's life」。在按下 Create 之前，你仍可以在對話框裡新增或移除 agent、選擇由誰帶頭。要換成其他成員名單，就開一個新的工作階段。

這些東西有任何部分在雲端執行嗎？
New session 表單提供 Local 和 Isolated 兩種執行方式。表單上註明兩者都用你自己的金鑰在你的電腦上執行，不會有任何東西送到雲端。聊天紀錄預設存在本機。

Agent 可以改寫自己的指示嗎？
它們可以提出修改建議，建議會出現在 Proposals。提案不等於已接受的設定。Agent 能不能動到自己的 prompt，是另一個獨立的設定。

桌面應用程式可以在 osfoundry.io/zh/download 下載。