by Rain Chu | 9 月 24, 2026 | Agent, AI
這篇以 Harness Engineering（AI 執行框架工程）為主軸，把工作案例、生活比喻與延伸設想逐項拆開，再補上實作時需要的界線。重點是做出可驗收的工作成果，而不是收集更多工具名稱。
先釐清：改善 Skill、訓練模型與 Harness 是三件事
把作品整理成提示詞、Skill 或知識庫，再用新案例修訂規則，通常是在改善模型外部的工作方式。除非真的執行參數更新，否則不能直接稱為大模型微調。模型能在目前對話參考你的糾正，也不代表它已永久記住，重要規則仍要明確保存。
Harness 的範圍更廣，包含資料入口、工具權限、任務狀態、評估、重試與交接。Anthropic 的長時間應用開發研究示範把規劃、產生與評估拆開，也強調主觀品質需要可判定的標準。不是多放幾份文件就完成整套工程。
實務上先保留三種素材：用來建立規則的示範、用來反覆調整的驗證案例，以及最後才打開的保留測試。scikit-learn 的交叉驗證文件說明了用同一份測試集反覆調整會造成的問題。
從企業導入到日常工具：先證明你解決了問題
1. 微軟派工程團隊進企業（FDE)
每家公司的資料、權限與作業順序不同，買同一套 AI 工具不代表能得到相同成果。這個例子說明，導入工作常常發生在模型之外。
怎麼用：先盤點實際流程與驗收責任。微軟官方公告日期為 7 月 2 日，將 Frontier Company 描述為新的營運事業，並強調與客戶共同設計及持續改善。不要直接寫成所有企業都不該自己做，或把它等同於一間獨立法人公司。
2. Palantir 到情報單位做原型
工程師到客戶現場、展示原型、接受批評再修改，說明需求必須在真實場景裡被看見。
怎麼用：把第一次展示當成收集回饋的工具。Palantir 的 Deployment Strategist 職務說明確實包含深入客戶流程、理解資料及與工程團隊合作，但不能據此替所有故事細節背書。
3. 漂亮網站隔週壞掉
頁面第一次能跑，和日後能維護是不同要求。這個情境包含故障找不到原因、資料管理不清楚，以及錯誤操作破壞網站。
怎麼用：初版完成後就補上備份、可還原版本、關鍵操作驗證與錯誤紀錄。把「看起來正常」改成「主要工作能完成，而且失敗後能恢復」的驗收標準。
4. 遛狗的牽繩比喻
模型可能用不同路徑完成同一件事，牽繩象徵人在必要時能限制或中止行動。比喻要說明的是可控性，不是要求每次輸出逐字一致。
怎麼用：把牽繩具體化成工具權限、可修改範圍、預算與停止條件。只寫一句「不要出錯」，不能代替程式與權限上的控制。
5. 看起來能賣錢的 Skill，直接問模型也能做到
有人投入心力做工具，卻沒有和一般對話比較。關掉工具、交付相同需求後，如果品質差不多，就還沒有證明額外流程的價值。
怎麼用：做基準比較與移除元件的對照測試，固定模型、資料、任務與評分方式，再比較品質、成本及修改時間。
6. 訪綱 Skill
額外 Skill 的差異沒有想像中明顯。這是上一個原則在內容工作中的具體例子。
怎麼用：同一位來賓的背景資料，分別交給直接對話與 Skill，隱去版本名稱後請編輯評估。訪綱要看可追問性與資料正確性，不能只看格式整齊。
7. 模仿 The Diary of a CEO 設計訪談
先用部分訪談建立提問原則，再給未揭露答案的來賓背景，請 AI 設計問題，最後和實際訪談比較。差異可以揭露它是否忽略個人故事、衝突或追問。
怎麼用：拿實際問題當參考，不把原主持人問過的題目視為唯一答案。反覆修訂使用驗證素材，另留從未用來調整的新來賓或新主題，才能檢查原則是否可遷移。
8. 訪綱越像原稿，反而越僵硬
若評分只獎勵字句相似，系統可能把語助詞、段落節奏與固定句型寫死。它會更像舊答案，卻不一定更會訪問新的來賓。
怎麼用：過擬合的重點是新資料上的泛化表現，不是超過某個分數就發生。不要把八成或八成五寫成通用最佳值，也不要故意讓好答案變差以符合比例。資料洩漏與測試集使用原則可作為評估設計的起點。
模型焦慮與工作安排：把限時額度放回任務價值
09. 近期任務、未來版本與系統改善三份清單
把眼前必須交付的工作、未來想做的功能，以及安全、模型切換與 Skill 管理等改善工作分開，能降低新模型推出時不知道該測什麼的混亂。
怎麼用：預先寫好輸入、預期成果及優先順序。比較新模型時使用固定任務清單，才能看出它是否改善真正的瓶頸，而不只是帶來新的待辦事項。
把個人判斷變成可測試的工作規則
10. 寫出自己的文章與影片腳本分身
只請模型歸納過往文風，容易得到泛泛的形容。較有用的做法，是先讓 AI 按相同題目與大綱寫一版，再對照本人完成的版本。
怎麼用：把差異拆成觀點、結構、證據、取捨與措辭，保存能重複使用的規則。文風相似和內容正確要分開評分，避免模仿語氣卻新增未發生的經歷。
11. 巴菲特分身與台積電評論測試
角色提示可以生成像某位投資人的論述，卻不代表知道本人當時有哪些資訊。用實際公開評論比對，也可能遇到模型早已看過答案的污染問題。
怎麼用：把它當分析練習，要求引用公開資料並分開標示事實與推論。歷史評論的相似度不等於投資能力，更不能代表本人對目前個股的建議。
12. 馬斯克分身與創業問題
用名人身分求創業建議，容易把有辨識度的語氣誤認成可靠判斷。真正值得拆解的是成本假設、限制與需要驗證的關鍵條件。
怎麼用：改成要求列出目標、已知事實、不可省略的條件與可測試假說。第一性原理可幫助重新檢查假設，但不是輸入名人名字就會自動成立的能力。
13. 從演講稿找出自己的思考習慣
把多篇演講稿交給 AI，請它辨識常見的論證及決策方式，能把原本不容易說明的思考偏好，變成可討論的候選規則。
怎麼用：要求每個判斷附原文位置，再用另一篇新稿檢查。不要把 AI 歸納的幾個標籤當人格定論，文字只呈現部分情境下的表達。
14. 提問時附選項、建議與可能後果
只把問題丟給主管，會把分析工作一起往上移。附上替代方案與推薦理由，能讓討論直接進入取捨。
怎麼用：先比較可行方案、成本、風險及決策條件。這可以進一步畫成決策樹，但只列三個選項還不是完整決策樹，計算期望值也需要有根據的機率與效益。
15. 董事會報告自動化後，主管的價值在哪裡
把例行報告交給 AI 之後，人的價值可能需要重新說明。但能產生報告，不等於能承擔組織協調、決策與結果責任。
怎麼用：在自動化之前寫清楚省下的時間要投入什麼，以及誰對決策負責。把報告能力和整個職務混為一談，會高估工具的替代範圍。
教育訓練與企業知識：把成果背後的過程留下來
16. NGO 把教材做成志工培訓短片
既有教材拆成較短的知識單元，再接上講稿、配音、簡報、影片與登入觀看流程，目的是降低重複培訓負擔。
怎麼用：先檢查教材內容與學習目標，再製作媒體。聲音複製須取得本人授權，影片也應經內容審查。是否學會要用練習或操作驗收，不能只看播放完畢。
17. Echo 找問題，Delta 快速做原型
討論用兩種角色說明需求洞察和工程實作的互補性：一邊發現不合理之處，一邊快速做出能測試的方案。
怎麼用：讓每個提案同時具備問題證據、可測的改動和使用者回饋。官方職務頁可確認 Echo 與部署策略職務的關聯，但「特種部隊」及人格分類只是訪談的比喻，不是完整招募規則。
18. 中醫師請 AI 反過來挑戰自己的判斷
與其讓 AI 一味附和，這位醫師用它提出不同解釋、追問選擇理由。這個例子強調專業人士的反思過程。
怎麼用：要求反對意見附證據，並區分缺資料、邏輯問題及可考慮的替代解釋。AI 提出的質疑仍可能錯誤，不能直接據此改方或讓一般讀者自行處置病情。
19. PDF 圖表轉成可檢索內容，並留下來源
只抽取文件文字可能漏掉圖片中的座標、單位與圖例。VLM 可以協助閱讀視覺內容，Markdown 則是保存描述的一種格式，兩者不是同一種東西。
怎麼用：同時保留圖表原檔、頁碼、讀出的數值與不確定處。需要計算時優先取得原始表格，別只依賴看圖估值。可延伸看本地 VLM 與文件理解。
20. 資深編輯的價值藏在退稿與修改往返
只有定稿，AI 很難知道編輯刪掉了什麼。作者初稿、編輯意見、作者回稿與最後定案，才顯示修改的理由和界線。
怎麼用：將修改分成事實、結構、讀者理解與風格，整理正反例。新的稿件再測一次，確認它學會判斷原則，而非對每篇文章都套同樣的刪改方式。
21. 課程企劃的 120 個節點為何不能一路直跑
把大型課程專案連成很長的順序，等全部完成才說不對，很難找出最早偏離需求的地方。分段產出、審查與退回，能讓錯誤更早被看見。
怎麼用：節點數不等於必須配置相同數量的 Agent。先按企劃、內容、驗證等成果切段，設定最多修改次數與人工接手條件。Anthropic 的 Agent 設計模式同時包含工作流與評估迭代，線性流程並非一律錯，應依任務需要選擇。多角色安排可參考CrewAI 與多 Agent 工作流。
內容、跑步與遊戲：把好奇心變成可驗證的專案
22. 全聯與 citysuper 超市開箱
兩種超市開箱哪個更受歡迎，不必只靠直覺猜測，可以先查找已發布作品。訪談用它說明觀察市場的方法，沒有提供可核對的比較樣本。
怎麼用：比較發布時間、頻道規模、題材角度及影片形式。搜尋得到的觀看數只能提供需求線索，不能保證你再拍同一主題也有相同流量。
23. 高中生用論文與姿態辨識研究跑姿
先找運動研究，再分析自己的跑步影片，最後提出調整方向，形成文獻、觀察與練習的回饋流程。訪談未提供所用技能包、原始影片或訓練前後紀錄。
怎麼用：技術上，MediaPipe Pose Landmarker可從影像估計人體關鍵點，但關鍵點不等於直接量到力量、傷害風險或完整動力鏈。需在教練指導下核對鏡頭及追蹤誤差，逐步測試調整，有疼痛時先尋求專業評估。
24. 傳說對決重播，找出戰術與技能時機問題
把玩家喜歡的遊戲當學習題目，回看哪個時間點做了什麼選擇，可以練習提出假說與檢查結果。這段不是已完成的產品實測。
怎麼用：請 AI 指出畫面證據、可選動作及判斷的不確定性，再由熟悉遊戲的人確認。理解重播與即時操作是兩種能力，不能把前者直接推成後者。
25. 錄下網站操作，再整理成可重複使用的 Skill
下載文件、移到指定位置等固定操作，可以先示範，再整理輸入、步驟與驗收方式。所核對的官方插件名稱為 Record & Replay，與字幕中的 recall and play 不同。
怎麼用：錄製內容可作為建立技能的素材，但工作流程仍需確認輸入、權限與結果。這不等於能可靠學會任何即時遊戲，也不代表錄一遍便能替孩子自動打完對局。
六個值得留下的觀點，以下為意譯
先定義成果，再選工具
寺廟需要的是可靠的法會系統。程式語言、模型及插件都應服從這個目標。
知道哪裡不好，是把 AI 用好的前提
如果無法判斷品質，就先和領域專家一起建立標準，不能只讓 AI 自己給自己高分。
完成品之外，修改理由也值得保存
編輯與主管真正的判斷，常出現在否決、補證據及改寫的過程。
把大任務拆成能退回的小循環
每段都有產出、檢查與停止條件，出錯時才知道該修哪裡。
先解決身邊可驗證的需求
主管往來及自己的文章，通常比不可求證的名人分身更容易建立回饋。
興趣要接上實作，才會形成能力
跑步和遊戲都能成為專案入口，前提是願意研究、練習、接受證據與修正。
把這些方法用在自己的第一個專案
挑一個你熟悉、會重複發生，而且能檢查對錯的工作。先寫出使用時機、使用者、輸入與成果，再拿現有直接對話作為基準。建立最小版本後，每次只針對清楚的失敗原因修正，保留改版前後的結果。
能被重複利用的不是一句神奇提示詞，而是一組可信資料、清楚規則和可檢查的成果。等小流程穩定，再增加資料來源、角色分工及自動化程度。
需要了解來賓的課程與教學範圍，可參考說明欄提供的AI 超級大腦課官方頁與李佳達頻道。課程宣傳中的效果與比例不作為本文技術查核證據。
常見問題
Harness Engineering 就是微調模型嗎？
不是。它主要設計模型之外的資料、工具、狀態、權限與評估流程。修改提示詞或 Skill 通常不會更新大模型參數。
把資料分兩半，一半反覆測試就夠了嗎？
被用來修正規則的案例已參與開發。若要檢查泛化，還需要未參與調整的保留測試，並避免重複資料與事後資訊洩漏。
AI 準確率超過八成五就叫過擬合嗎？
不是。過擬合應觀察已見案例和新案例的表現差異，不能用固定百分比判定。不同工作也需要不同品質標準。
一百多個流程節點就需要一百多個 Agent 嗎？
不需要。先依成果、相依關係與驗收責任切分工作，再決定是否增加角色。大量 Agent 也會增加協調成本和錯誤來源。
自己的 AI 分身應該收集哪些資料？
除了完成品，還應保留當時的輸入、初稿、修改意見、理由及定稿，並另留新案例驗證。涉及他人或公司的資料，須具備適當使用權限。
by Rain Chu | 9 月 24, 2026 | Agent, AI, 商模
Meta Muse 的吸引力，在於它開始把「幫我想辦法」接到「替我動手做」，例如找二手商品、向賣家議價、整理購物車、聯絡電信客服，都屬於它想接手的生活任務。這也是市場重新評估 Meta AI 業務的一個理由，最近股價狂漲的關係：消費者終於比較容易想像，AI 能替自己省下什麼時間。
Muse 是產品，Muse Spark 是背後的模型
Meta 在 2026 年 9 月 8 日推出 Muse 個人 AI Agent，以對話方式接收任務，搭配自己的雲端電腦與瀏覽器執行操作。它可以在關閉 App 後持續工作，需要你介入時再通知你。
Muse Spark 是模型系列，Muse 則是把模型、工具、記憶與權限控制整合起來的產品。
Meta 在 9 月 2 日發表的 Muse Spark 1.3，重點包括較長的任務流程、多工作切換與指令遵循。
模型表現改善，與每一個網站任務都能成功，仍是不同層次的事。
此外，能使用 Facebook 或 Instagram 連接器，不代表產品會自動讀取你在所有 Meta 服務中的全部資料，實際能取得什麼，仍取決於你連接的服務、核准的權限與資料是否可用。
Muse 可以做到哪些事？先看六類任務
以下把已出現的公開操作案例、官方公布的能力與仍未完成的環節分開整理，判斷 Agent 是否有用，重點不只是它回覆得好不好，而是它交付了什麼結果。
| 任務 | 可代辦的環節 | 仍須確認的結果 |
|---|
| 找商品與議價 | 搜尋刊登、篩選條件、代發訊息、追蹤回覆 | 對方是否答應，以及是否真的成交 |
| 挑衣服與購物 | 依尺寸與場合選品、準備購物車 | 商品、總價、地址與付款核准 |
| 處理帳單 | 比較方案、開啟客服對話、整理下一步 | 能否登入，優惠是否符合資格 |
| 整理社交資訊 | 依條件搜尋可取得的好友資料 | 資料是否完整，名單是否正確 |
| 追蹤長期目標 | 記住需求、持續追蹤、適時提醒 | 任務是否持續有效，通知是否有用 |
| 行政與內容產出 | 信件、行程、表單、文件與互動頁面 | 寄送、預訂和交付內容是否通過檢查 |
一、Facebook Marketplace：找得到，也能代你開口談
以尋找 iPhone 為例，任務包含地區、品牌與可接受價格，Muse 不只提供搜尋建議，還能整理候選商品，準備議價訊息，經確認後送出，再持續追蹤賣家回覆。
這類工作最耗人的地方，往往是反覆搜尋、比較與等待。交給 Agent 的價值，是把多個零碎步驟串起來。只是「訊息已送出」與「已用理想價格買到」必須分開，公開案例尚不足以證明最後成交或實際省下多少錢。
如果要委託這種任務，條件可以寫得更具體：限可面交地區、指定品牌與容量、最高預算、可接受的商品狀況，以及超出預算時是否必須回報。談價的目標與能承諾的範圍愈清楚，愈容易檢查結果。
二、Facebook 好友整理：
把多年沒聯絡好友找出來，是一個很貼近 Meta 社交背景的需求．
這項案例比較適合用來理解任務方向，還不能作為「能準確重建社交圈」的結論。實際使用時，應要求列出判斷依據與不確定的項目，再由本人決定是否聯絡。
三、長期目標：把一次指令變成持續追蹤
Muse 的另一個方向，是記住你正在處理什麼。買 ㄞiPhone 不必等同一次聊天，還可以成為待追蹤的目標。賣家晚些回覆、條件改變，或需要你決定下一步時，再把資訊帶回來。
官方產品設計說明把這種能力放進 Goals、活動紀錄與記憶管理，讓任務可以依排程或事件繼續推進。對使用者而言，真正該驗收的是「有沒有在需要時帶回新結果」，而非訊息數量多不多。
手機使用時間、學習進度或運動計畫，也能成為對話與追蹤的題目。但提出計畫不等於目標已達成。健康與財務類建議，更需要核對原始資料，不能因為連接了帳戶，就假定分析一定正確。
四、行政與文件：不只回一段文字，也能產出成果
官方公布的用途還包含處理信件、旅行安排與填表。產品設計文件也列出文件、PDF、網頁及互動式追蹤工具等輸出。
這和 讓 AI Agent 操作 Office 文件談的是相近的需求：使用者需要能打開、修改與檢查的成果，而不只是聊天中的一段建議，不同 Agent 的工具、檔案支援與權限仍各有差異。
安全設計怎麼看？付款核准與資料隔離要分清楚
依 Meta 的Muse 安全架構說明，Muse 在獨立雲端環境中工作，外部操作由另一套 Sentinel 權限系統把關。密碼與付款憑證透過隔離儲存供工具使用，主要 Agent 不直接看到原始憑證。
Muse 可以協助購物，但購買時需要使用者核准具體交易內容。應透過產品提供的登入與錢包介面授權，不能把密碼或信用卡號直接貼進聊天，當成安全儲存的替代方式。
官方表示，對話與 VM 資料不直接提供給 Meta 廣告系統，模型訓練使用另有退出設定。現行 Secure VM 並非讓 Meta 在技術上完全無法存取資料，進一步的 Confidential VM 在發表時仍列為後續計畫。
若你在意資料留在哪裡，可以對照本機優先 Agent 與雲端服務的差異。雲端隔離環境和本機部署，解決的問題並不完全相同。對生活助理而言，方便程度也往往和你願意授權的範圍一起增加。
Meta 股價最近為什麼大漲？先把日期對齊
這一波最醒目的變動出現在美東時間 2026 年 9 月 21 日。Meta 收盤價由前一交易日的 665.75 美元升至 741.25 美元，依這兩個未調整收盤價計算，上漲約 11.34%。9 月 22 日則收在 736.60 美元，較前一日回落約 0.63%。
| 美東交易日期 | 收盤價（美元） | 與前一列收盤價相比 |
|---|
| 2026-09-18 | 665.75 | 比較基準 |
| 2026-09-21 | 741.25 | +11.34% |
| 2026-09-22 | 736.60 | −0.63% |
市場重新評價的，是 AI 能否成為大眾產品
依 Yahoo Finance 的 9 月 21 日報導，當日的催化因素包含 Muse 在美國 App Store 免費榜的表現，以及 Wells Fargo 上調 Meta 目標價。報導同時提到，市場正關注即將到來的 Meta Connect。這些因素同時出現，不能把全部漲幅單獨歸因於某一個功能。
我的解讀是，Muse 讓市場比較容易看見 AI 投入與消費者需求之間的連結。模型跑分離多數人的生活很遠，但替人查帳單、找便宜商品、處理行政瑣事，價值更容易被理解。
Meta 的機會，在於它既有的消費者產品與使用習慣。如果個人助理能在熟悉的介面裡完成有用的事，就可能降低嘗試門檻。不過，下載榜名次不是長期活躍人數，更不是付費率或獲利能力的證明。
想試 Muse，先交付一件可驗收的小事
官方公開發表資訊仍以美國推出為主，可從Muse 官方入口確認自己帳號的可用狀態、方案與額度。
開始時，可以沿用先釐清 Agent 任務需求的做法，把目標、限制與交付結果一起說清楚。例如：「找出本週可面交的指定品牌商品，整理價格與狀況，先不要聯絡賣家。」確認資訊品質後，再決定是否交付議價或後續追蹤。
Muse 值得關注的地方，是把生活中的搜尋、判斷、操作與追蹤接得更完整。它能否成為長期使用的個人助理，要看這些日常小事能否反覆做對。Meta 股價已反映一部分期待，接下來還需要使用者留存、服務可靠度與商業成果接棒。
Muse 與 Meta 股價常見問題
Meta Muse 和 Muse Spark 有什麼不同？
Muse 是面向使用者的個人 AI Agent 產品，Muse Spark 是背後的模型系列。實際任務還需要瀏覽器、工具、記憶與權限控制配合。
Muse 可以自行刷卡購物嗎？
它能準備購物流程，但官方設計要求在購買時核准具體交易。憑證應透過專用登入與錢包介面處理，不應直接貼進對話。
台灣現在能使用 Muse 嗎？
截至 2026 年 9 月 23 日核對，官方發表資訊仍以美國推出為主。台灣是否開放、帳號是否符合資格，需以官方入口與帳號顯示為準。
by Rain Chu | 9 月 20, 2026 | Agent, AI
本機 AI 的價值，不能只用「回答有沒有雲端模型聰明」判斷。當工作需要反覆讀取私人文件、呼叫工具，或同時執行多個任務，模型之外的資料流向、硬體安排與執行框架，也會影響實際成果。
DSH Privacy Router、NVIDIA PAIR、EXO 與 Perplexity Portable Computer，分別處理隱私分流、區網排程、模型分散運算與完整 Agent 工作流程。它們可以放進同一張架構圖理解，卻不是可以直接互換的產品。
本機 AI 先看三件事：資料、容量與工作流程
第一件事是資料能不能外傳。即使雲端模型能力更強，有些內容仍應留在自己的設備或信任的內部網路。第二件事是硬體能不能容納模型，以及能否在可接受的時間內完成工作。第三件事是模型以外的操作，像讀檔、搜尋、驗證與產出文件，有沒有完整流程。
這些問題需要分別處理。推論引擎負責執行模型，Agent 框架負責組織工具與任務，路由器則決定請求送到哪裡。還不熟悉這些層次，可以先看 本地大模型推論框架比較，再判斷自己缺的是哪一層。
DSH Privacy Router：先判斷哪些內容能送雲端
DSH Privacy Router 是 DeepSeek Harness 的 Host 端插件。它先用本機規則與模型檢查文字，分類為 public、sensitive 或 unknown。只有通過公開分類的請求才送雲端，敏感或不確定的內容留在本機。這是隱私導向的分流，不是單純把困難問題全部轉給大模型。
預設雲端上下文只包含本輪通過檢查的純文字、固定系統提示與空工具清單。專案文件說明，私有對話與本機工具結果不會直接附帶過去，雲端回答則直接串流回目前對話，不由本機模型再次改寫。開啟特定相容事件功能後，才可納入先前已核准的雲端對話。
公開程式可看到兩個關鍵控制：雲端分支只在分類結果為 public 時啟用，真正送出時會重新組合訊息，並把工具列表設為空。這比只在提示詞寫「不要洩漏資料」多了程式層的限制。不過，這仍不代表整個應用的所有網路流量都受到同一個插件管理。核對版本見 DSH 路由程式。
導入前要知道，這個公開儲存庫不包含展示用 Web UI 或 DSH 原始碼補丁。README 的介面展示屬於構想，不能把安裝插件理解成會立即得到完整視覺介面。先依文件設定可信任的本機 Provider，再確認實際連到的服務確實位於可信任環境。
自動發現本機算力，不等於自動信任任何設備
配套的 Local AI Discovery Server 用 mDNS／DNS-SD 宣告區域網路中的 OpenAI 相容 API，提供主機、連接埠、模型清單位置與認證需求等資訊。它負責讓服務被找到，本身不執行模型，也不是 API 代理。DSH 端仍需要對應的發現整合。
發現服務與信任服務是不同步驟。在家中看得到的端點，不代表公司文件就適合送過去，更不用說共享空間的陌生設備。評估時應確認設備由誰管理、是否使用認證，以及請求最後送往哪個端點。服務名稱帶有「local」，不能取代這些確認。
NVIDIA PAIR：把獨立請求分配給區網內的電腦
NVIDIA Personal AI Router，也就是 PAIR 目前以測試版提供本機推論路由，支援相容的 Windows、Linux、macOS 系統，搭配 Ollama 與 LM Studio。它的目標是讓應用使用單一入口，把多個推論請求分配給可用設備。實際平台與硬體組合，應以當前官方支援清單為準。
PAIR 不會把多台電腦的顯示記憶體合成一個大空間，也不會把同一個推論請求拆到多台執行。每個請求會交給一個符合條件的節點，該節點負責執行到結束。當多個 Agent 同時提出獨立請求時，其他設備才有機會分擔排隊壓力。
官方技術文件說明，排程會考慮節點是否在線、推論引擎是否可用、是否有指定模型，以及目前負載。節點經過配對後，通訊使用相互 TLS 驗證與加密。這解決的是信任節點之間的推論傳輸，不能延伸成 Agent 使用任何搜尋或外部工具都不會外傳資料。詳見 NVIDIA PAIR 技術說明。
若工作主要是一個接著一個的長推論，或只有一台設備裝了需要的模型，多加節點的效益可能有限。評估時要看整個任務完成時間，以及 Jobs 紀錄是否真的顯示不同節點處理請求，而不只看畫面上出現幾個 Agent。
EXO：把模型拆到多台設備，與 PAIR 的用途不同
EXO 的核心包含模型分片與分散推論，會考慮裝置資源及網路拓樸，讓單一設備放不下的模型有機會跨設備執行。README 介紹了 MLX、張量平行與 Thunderbolt RDMA 等能力，這和 PAIR 分派完整請求的做法不同。
分散推論需要設備交換資料，速度取決於模型、切分方式與實際互連。能容納更大模型，不代表每次回答一定更快，也不能直接把各台硬體的標示效能相加。想理解雙機部署的取捨，可延伸閱讀 雙機本地模型部署與實測整理，並分開看容量與速度。
截至 2026 年 9 月 14 日核對，EXO 的 平台支援文件 把 Apple Silicon macOS 列為已測試與維護的主要平台，Linux CUDA 與 DGX Spark 則仍列在規劃區。這不等於所有相關實驗都不存在，但不足以把 DGX Spark 支援寫成已成熟可用的標準路徑。
Portable Computer：把本機模型接成完整 Agent
Perplexity Portable Computer 的定位是本機優先的 Agent 軟體，不是一款 Perplexity 品牌硬體。官方發表資料以 DGX Spark 為首波設備，將模型、執行框架與工作紀錄放在本機，必要時再經授權使用搜尋、連接器或雲端模型。平台支援與訂閱資格會更新，安裝前應重新確認產品入口。
比起單純啟動模型，它更重視框架如何配合本機模型的能力：縮小核心工具集合、按需載入 Skills、整理過長上下文，以及加入結果驗證。官方研究也說明，工具執行受作業系統層的沙箱限制，沙箱不可用時不退回無隔離執行。參考 Perplexity 的本機優先 Agent 研究。
雲端顧問只接收核准的上下文並回傳文字建議，沒有直接操作本機檔案與工具的權限。是否開啟顧問，以及採手動或自動核准，由使用者設定。因此，「本機優先」仍須搭配實際的連外與核准政策來理解。
中文導讀也可參考 AI 郵報 Portable Computer 整理。其中的硬體需求、測試分數與上市資訊，應回到對應官方文件與測試條件核對，不宜直接推論成所有任務的表現。
四個方案怎麼分？先對照自己要解的問題
| 方案 | 主要處理的問題 | 不能直接推論的能力 |
|---|
| DSH Privacy Router | 判斷文字是否可送雲端並限制上下文 | 不能保證分類永遠正確或涵蓋所有資料出口 |
| NVIDIA PAIR | 把獨立推論請求分配到可用的區網節點 | 不合併顯示記憶體，也不切分單一推論請求 |
| EXO | 跨設備切分模型與分散推論 | 不代表任意平台組合都已支援或一定加速 |
| Portable Computer | 整合本機模型、工具、沙箱與授權連外 | 本機優先不代表開啟外部服務後仍完全離線 |
這張表依前述官方文件整理的是功能範圍，不是效能排名。若想組合使用，還要核對 API、模型格式、端點與執行框架是否相容，不能假設名稱都和本機 AI 有關就能直接串接。
隱私真正難的地方，是內容看起來不敏感
沒有姓名、電話或金鑰，不代表內容可以公開。例如尚未發表的產品構想、內部定價方法或獨特研究策略，就算去掉身分資訊，仍可能包含不應外傳的價值。這是自動隱私分類需要面對的限制，不能只用是否偵測到個資判斷。
DSH 用規則加模型檢查，Portable Computer 也描述了分類器與核准機制，但分類器仍可能漏判。對不可外傳的工作，應有明確的本機限定設定，以及實際阻止連外的權限或網路政策。對允許求助雲端的工作，則要看清楚送出的片段、歷史上下文與工具結果。
驗收可以從幾種情境開始：一般公開問題、含機密的文件、依賴前文的「繼續」、分類失敗，以及雲端要求呼叫工具。確認它們分別送去哪裡、留下什麼紀錄，並能追查答案由哪個模型產生。不要為了觀察系統又把完整機密複製進不受控的日誌。
開始之前，先用現有設備跑完一個真實任務
先挑一個可驗證的小工作，例如整理不含機密的測試文件，用現有設備與合適模型完成一次。若問題是模型服務與應用怎麼接，可以先參考 LibreChat 與 Ollama 的串接方式。等單機流程穩定，再處理分流與多機。
接著辨認瓶頸。獨立請求很多、都擠在同一台，才評估 PAIR。模型放不下，才研究 EXO 等分散推論路線。需要選擇哪些內容送雲端，再檢查 DSH 的分流設計。想降低工具、沙箱與任務流程的整合工作，則可評估 Portable Computer。
本機推論能減少按量 API 費用，但仍有硬體、電力、維護與等待時間。選擇性使用雲端，也可能產生額外用量。先量出自己的任務品質與完成時間，再決定是否擴充設備，會比從硬體規格開始更容易做出合適選擇。
本機 AI 路由常見問題
DSH Privacy Router 會把困難問題自動交給雲端嗎？
它主要依隱私分類分流，只有判定為 public 的請求才走雲端。敏感、不確定或無法分類的內容留在本機，不能視為單純依難度切換模型。
NVIDIA PAIR 能把多台電腦合成一張大顯卡嗎？
不能。PAIR 將獨立推論請求分派給符合條件的單一節點，不合併顯示記憶體，也不把一個請求切到多台電腦執行。
EXO 和 PAIR 差在哪裡？
EXO 包含跨設備模型分片與分散推論能力，PAIR 則分派完整的獨立請求。選擇前要先分清楚瓶頸是模型容量，還是同時有太多請求排隊。
Portable Computer 等於完全離線嗎？
不一定。核心工作預設在本機，搜尋、連接器與雲端顧問則可能連外。是否外傳資料，取決於開啟的功能、授權設定與實際送出的上下文。
本機 AI 一定能避免機密外洩嗎？
不能只靠模型位置保證。還要檢查服務端點、工具、搜尋、日誌與雲端升級路徑，自動分類也可能漏判不含個資的商業機密。
by Rain Chu | 9 月 8, 2026 | Agent, AI, Apple, Mac, 程式開發
買 Mac 跑本地 AI，我會先考慮以下三件事：
模型能不能放進記憶體，送出長篇資料後要等多久，以及開始回答後每秒能生成多少 token。這三件事分別牽涉容量、運算能力與記憶體頻寬，不能只看晶片名稱裡的數字。
同一台電腦，短問短答很順，換成讀程式碼、查工具、反覆執行任務的 Agent 卻很慢，並不矛盾。
聊天介面讓你注意到的是持續輸出的速度，Agent 更容易暴露長輸入、多輪推理與工具等待的成本。
模型載入成功，只代表跨過容量門檻，還不代表這台機器適合你的工作流。
本文於 2026 年 9 月 6 日核對規格。Apple 已公布新款 Mac mini 與 Mac Studio，官方標示 9 月 22 日開始供貨。以下會把官方規格、推理原理與選購判斷分開，未取得的新機實測不會用推估值冒充。供貨資訊可查 Mac mini 公告與 Mac Studio 官網。
先分清 Prefill 與 Decode，才知道慢在哪裡
Prefill，預填充，是模型處理輸入內容、建立後續推理狀態的階段，系統提示詞、聊天記錄、工具定義、檢索文件與程式碼都可能算進輸入，並非只有你剛打的那一句話。長輸入通常有較大的矩陣運算需求。
Decode，解碼生成，則是在已有上下文狀態上逐步產生 token，單一請求、低批次的生成常受記憶體資料搬運限制，所以記憶體頻寬很重要，Token 不是固定的一個中文字，不能把 tokens/s 直接當成每秒中文字數。
觀察體感時，我會同時記錄 TTFT，也就是送出後到第一個 token 的時間，以及生成階段的 tokens/s，TTFT 還可能包含排隊、模型載入與服務端處理，不能把所有等待都歸因於 Prefill，Apple 的 MLX 與 M5 技術說明也分別討論提示詞處理與生成效能，兩個階段應分開比較。
記憶體容量，是門票而不是速度保證
Apple Silicon 的 CPU 與 GPU 共用統一記憶體，跑較大模型時不必完全受限於一張獨立顯示卡的顯存容量，在這規格表上的 32GB 或 128GB 並不等於模型可以獨占同樣的空間，macOS、瀏覽器、開發工具、KV cache 和推理暫存都需要預算。
估算可以從權重開始：參數數量乘上每個參數的位元數，再除以 8，以約 27B 參數、理想化 4-bit 權重計算，純權重約 13.5GB，這只是十進位容量的粗估，還沒加入量化分組資訊、部分高精度權重與執行時開銷。
32GB 能否跑某個 27B 模型，答案是「有機會，但要指定量化檔、上下文長度與框架」。只拿 27B 這個名字，無法保證長上下文與多 Agent 都順暢。先核對實際模型檔大小，再測一個完整任務，會比只看成功載入的畫面更有用。
如果想先理解不同推理工具的定位，可以參考 MLX、llama.cpp、Ollama 與其他本地推理框架比較，格式、核心實作與快取策略都會影響同一台硬體的表現。
記憶體頻寬，影響持續輸出但不是萬用答案
可以把容量想成能放多少資料，頻寬則是每秒能把多少資料送到運算單元。當低批次生成需要反覆讀取大量權重，而硬體運算能力足夠時，頻寬往往成為主要限制。
但「頻寬加倍，速度就一定加倍」只適合當理想化的直覺，實際還有量化解碼、注意力、KV cache 存取、核心效率、批次大小與模型架構，MoE 也不是每個 token 都動用全部專家權重，所以不能把所有模型都套進同一條簡單公式。
M5、M6 規格怎麼看，先看配置再看名稱
以下整理 Mac mini 技術規格與 Mac Studio 技術規格中，和本地模型最直接相關的容量與頻寬。這是規格對照，不是速度排名，也不是實測 tokens/s。
| 機型與配置 | 統一記憶體 | 記憶體頻寬 |
|---|
| Mac mini M6 基本配置 | 16GB | 153GB/s |
| Mac mini M6 較高記憶體配置 | 24GB 或 32GB | 170GB/s |
| Mac mini M5 Pro | 24GB，可選 48GB 或 64GB | 307GB/s |
| Mac Studio M5 Max 32 核心 GPU | 36GB | 460GB/s |
| Mac Studio M5 Max 40 核心 GPU | 可選至 128GB | 614GB/s |
| Mac Studio M5 Ultra | 96GB，特定配置可選至 512GB | 1.2TB/s |
2026 年 9 月 6 日核對，容量與頻寬不等同實測生成速度
M5 Max 的 32 核心與 40 核心 GPU 版本不只差核心數，頻寬與可選記憶體也不同，M5 Ultra 的 256GB、512GB 選項綁定更高階晶片配置，升級容量的成本可能同時包含晶片升級。選購時應核對最後的完整配置，不要把某個系列的最高值套到入門款。
供貨時間也要分開看。依 Apple 台灣的新款 Mac Studio 公告，一般配置自 9 月 22 日起供貨，512GB 統一記憶體配置則預計 10 月底推出，需要立即交付工作的團隊，應再確認實際可下單配置與交貨日期。
跑 Agent 為什麼更容易卡在等待
一個程式碼 Agent 可能先讀專案規則，再讀檔案，接著呼叫工具，最後把工具輸出帶回模型繼續判斷，每一輪都可能增加輸入，輸出卻只有一小段指令，讓「先讀懂，再動作」的成本更加明顯。
「每開一個子代理，就一定完整重算一次全部上下文」並不精確，是否能重用相同前綴，取決於服務端的 prompt cache、請求路由、模型支援與上下文是否一致，MLX LM 官方專案就提供 prompt caching 功能，實際 Agent 框架有沒有用到，仍要另外確認。
- 把長期不變的規則放在穩定前綴，減少每輪重新排列內容
- 只提供當前任務需要的檔案與工具，避免把整個專案一次塞進提示詞
- 先測單 Agent，再逐步增加並行數，觀察排隊與記憶體壓力
- 同時記錄模型等待、工具執行與重試時間，避免把外部服務延遲算到 GPU 頭上
如果任務需要很長的推理輸出，Decode 仍可能占大部分時間，真正值得比較的是完成同一項工作要多久、成功率如何，而不只是某個階段的峰值數字。選擇 Agent 模型與本機部署方式時，也應把工具呼叫品質一起放進評估。
M5 的加速器，要配合軟體才能發揮
M5 GPU 的 Neural Accelerators 是 GPU 內的矩陣運算加速能力，不應和晶片上另一個 Neural Engine 混為一談，對長輸入這類運算密集的工作，支援相應路徑的框架與核心可以帶來收益。
買到新晶片不代表任何模型、量化格式和舊版工具都會自動得到相同比例的加速，我會連同 macOS、MLX 或 llama.cpp 的版本一起記錄，並查看執行時使用的後端。Apple 早期公布的 M5 測試可以用來理解方向，但不能直接當成新款 M6 或 M5 Ultra 的實測成績。
MoE 為什麼值得看，但不能只看啟用參數
Mixture of Experts，混合專家模型，會依 token 選用部分專家，降低每步需要參與計算的參數量，它讓「保存很多知識容量」和「每一步動用多少運算」有機會分開，這和大容量統一記憶體的特性很搭。
以 Qwen 官方的 Qwen3-30B-A3B為例，30B 指總參數量，3B 指啟用參數量，不能因為看到 A3B，就用一個 3B 稠密模型的記憶體需求來估算，通常仍要保存更大的整體權重。這是用來解釋命名與架構的例子，不代表它是目前唯一或最適合的選擇。
MoE 的速度還受專家路由、量化、核心最佳化與批次大小影響，也不保證同樣容量下的工具使用品質一定勝過稠密模型，我的做法是準備一組真實任務，用完成品質與總耗時一起決定。
三種使用情境，我會這樣安排預算
主要使用雲端 AI，優先顧好日常工作
如果主要運算都在雲端，Mac 更多是在跑瀏覽器、編輯器與本地工具，無須只為遠端模型購買超大記憶體。16GB 到 32GB 可以作為一般工作起點，但大型專案編譯、虛擬機與剪輯仍可能需要更多。這是用途判斷，不是所有人的最低規格。
本地聊天、寫程式與剪輯混用，先看 48GB 到 128GB 的實際需求
先列出最常用的兩三個模型，再加上平常同時開啟的軟體。M5 Pro 和 M5 Max 各有不同容量與頻寬選項，能否容納模型加上真實工作環境，比只追求最大 GPU 核心數更重要。若以 Agent 為主，要優先找長提示詞與連續工具呼叫測試，而不是只看短聊天跑分。
目標是超大模型，再考慮 Ultra 與多機
當權重、長上下文或多請求確實超出較小容量，才有充分理由看 256GB、512GB 或分散式部署。先問自己是否需要那個模型能力，以及它能否在可接受時間內完成任務，不要為了「裝得下最大模型」而買一台長期等待的電腦。
AI 生圖與生影片，要另做一份評估
剪輯影片和用生成模型產生影片，是不同的運算工作，ProRes 編解碼能力強，不能直接推論擴散模型也會很快。ComfyUI 官方支援 Apple Silicon，但你的模型、量化與自訂節點是否支援 Mac，以及完整生成一段內容要多久，仍需逐項確認。
若主要目的是高頻率生影片，我會拿實際工作流比較 NVIDIA GPU、本地 Mac 與雲端方案，再把等待時間與每次產出的成本算進去。可從 LTX 2.3 的 ComfyUI 影音工作流理解需要核對哪些模型與節點，不應只拿文字模型的速度替影音生成下結論。
不過可以肯定的是現在要生圖還是首選 Nvidia 畢竟 pyTouch 還沒有完整支援 MAC
DGX Spark 加 Mac Studio，是分工不是魔法加總
EXO 的異質推理示範把 Prefill 放在 DGX Spark，再把 KV cache 傳給 Mac Studio 進行 Decode，並透過逐層傳輸，讓通訊與運算時間部分重疊。這說明不同硬體可以各做擅長的階段。
但 EXO 示範的是特定模型、輸入長度、硬體與網路，不能外推成任何組合都會同倍率變快。兩台 256GB 也不必然優於一台 512GB，模型如何分片、互連頻寬、框架支援與並行方式都會改變結果。多機還增加設定與維護成本，應以整個任務的實測決定。
對多機部署有興趣，可以接著看 雙機 EdgeXpert 與大模型工作負載，把單機容量、網路傳輸和軟體支援一起考慮。
購買前怎麼測，至少分開短提示詞與長提示詞
請測試者提供完整模型名稱、量化檔、框架版本、系統版本、上下文長度與 GPU 配置，相同模型換一種量化，或把長輸入改成一句問候，都足以改變結果。
已有 llama.cpp 與本地 GGUF 模型時，可參照 llama-bench 官方說明使用下列命令。把路徑改成自己已下載的模型，這裡的參數是測試設定，不是我在新機上測出的數字。
llama-bench -m /absolute/path/model.gguf -p 512,8192 -n 128 -r 3 -o json
這會分別測試不同長度的 prompt processing 與文字生成，輸出中的 pp 與 tg 對應不同階段。合成測試適合比較核心效能，不能直接當成真實 Agent 的 TTFT 或任務總耗時。還要補一輪實際工具呼叫流程，並分別記錄冷啟動、快取命中和未命中的狀態。
- 同一份短問答，觀察穩定生成速度
- 同一份長文件，觀察首個 token 等待時間
- 同一個修改程式任務，觀察工具呼叫與完成率
- 同樣的並行數，觀察尖峰記憶體、swap 與排隊
- 若要生圖或生影片，使用完全相同的模型、尺寸、步數與節點
FAQ
32GB Mac 可以跑 27B 模型嗎
部分量化版本有機會，但要加上 KV cache、推理暫存、macOS 與其他程式的需求。能載入不等於長上下文或多 Agent 都能流暢使用。
M6 一定比 M5 Max 適合本地 AI 嗎
不一定。要比較完整配置的容量、頻寬、運算後端與實際工作負載，不能只用世代數字排序。
為什麼聊天很快，Agent 卻很慢
Agent 可能反覆處理長上下文並等待工具，瓶頸不只在生成速度。應同時檢查 Prefill、快取、排隊、工具時間與任務重試。
MoE 的啟用參數少，記憶體也只要那麼少嗎
不是。啟用參數主要描述每步參與計算的部分，通常仍要保存全部專家權重，容量估算不能只看 A 後面的數字。
我的選購順序：先定工作，再定模型，最後選配置
先確定主要工作是在雲端還是本地，再決定模型與上下文需求。容量不足先解決容量，等待第一個字太久就看輸入處理與快取，開始輸出後仍然慢才進一步比較頻寬與生成核心。用這個順序選 M5、M6 或 Ultra，比追規格表上最大的數字更能把錢花在真正的瓶頸上。
by Rain Chu | 7 月 28, 2026 | Agent, AI
CrewAI 不是一個大語言模型，而是一套用來編排 AI Agent 的 Python 框架，它把一個複雜任務拆成不同角色，再透過 Task、Process 與 Crew 控制合作方式。模型負責思考，工具負責行動，知識庫負責補充事實，而 CrewAI 負責讓這些元件按照可理解的流程運作。
提示詞優化是一個很適合理解 CrewAI 的案例，只要把工作拆成分析、改寫、測試與最終審核，就能看見多 Agent 的價值，也能看見它的代價，Agent 數量增加後，模型呼叫、檢索次數、延遲與費用都會一起增加。真正重要的不是組一支看起來很熱鬧的 AI 團隊，而是讓每個角色都有不可取代的責任。
CrewAI 是什麼
CrewAI 是獨立開發的多 Agent 自動化框架，不依賴 LangChain，官方把主要能力分成 Crews 與 Flows，Crews 適合需要角色分工、探索與協作的任務，Flows 適合需要明確順序、狀態、條件分支與可稽核結果的工作流。
可以把它想成一間小型公司，Crew 是團隊，Agent 是成員，Task 是工作單，Process 是工作順序，Tool 是成員可以使用的工具。Knowledge 則是團隊共同或個別可查閱的資料庫。
| 元件 | 負責內容 | 提示詞優化案例 |
|---|
| Agent | 角色、目標、模型、工具與行為 | 分析師、改寫者、測試者 |
| Task | 工作描述、輸入、預期輸出與驗收條件 | 找出缺漏、產生新版、比較品質 |
| Crew | 組合 Agent 與 Task 並啟動執行 | 完整的提示詞優化團隊 |
| Process | 決定工作如何安排 | 依序分析、改寫、測試與定稿 |
| Flow | 控制狀態、事件與條件路徑 | 品質不合格時退回重寫 |
| Knowledge | 提供文件、網站或結構化資料 | 提示詞規範與優秀案例 |
| Tool | 讓 Agent 存取外部能力 | 向量檢索、網頁搜尋與評分器 |
提示詞優化 Crew 的完整架構
使用者輸入原始需求
↓
RAG 檢索提示詞規範與案例
↓
Prompt Analyzer 找出目標、限制與缺漏
↓
Prompt Optimizer 建立第一版完整提示詞
↓
Prompt Tester 以驗收標準比較品質
↓
Ultimate Optimizer 整合修正並輸出定稿
這種設計的關鍵是讓每個 Agent 產生下一個 Task 能直接使用的結果，分析師不應只給模糊評論，而要輸出結構化問題清單，改寫者要根據問題清單產生完整版本，測試者要使用固定量表，而不是憑感覺說新版比較好，最後的審核者只整合已確認的修正，不再任意改變需求。
若要進一步降低漂移，可以用 Pydantic 或 JSON 結構固定每一階段的輸出。這比單純增加角色背景故事更有效，因為下一個步驟能明確知道要讀取哪些欄位。
四個 Agent 不一定比兩個好
分析、優化、測試與最終優化看起來很完整，但每個角色都使用大型模型，還在每一階段重複查詢向量資料庫時，成本很容易放大。對簡單提示詞而言，分析與改寫可以由同一個 Agent 完成，再保留一個獨立測試 Agent，就已經有清楚的製作與驗收分工。
- 保留不同 Agent，當兩個角色需要不同工具、不同權限或不同模型時。
- 合併 Agent，當工作只是同一段文字的連續改寫時。
- 改用一般函式，當步驟不需要推理，只是格式轉換或資料驗證時。
- 改用 Flow，當流程需要條件分支、重試、人工確認與狀態保存時。
RAG 在 CrewAI 裡負責什麼
RAG 的用途不是替 Agent 增加想像力，而是讓它在執行任務前找到可靠的參考資料，提示詞優化系統可以把提示詞指南、優秀範例、品牌規範與輸出格式放進知識庫。使用者送出需求後，系統只取回最相關的片段，再讓 Agent 根據這些內容工作。
2024 年的實作組合是 Phidata、pgvector 與 OpenAI Embedding，Phidata 現在已改名為 Agno，如果要維護舊專案，應先確認套件名稱與匯入路徑，不宜直接照搬舊版命令。
目前 CrewAI 已有內建 Knowledge，可讀取文字、PDF、CSV、Excel、JSON 與網站內容，官方的 provider-neutral RAG client 預設使用 ChromaDB，也支援 Qdrant，若既有系統已使用 PostgreSQL，仍可把 pgvector 封裝成自訂 Tool，若只是做第一個原型，先用內建 Knowledge 通常更省事。
想理解本地檢索的完整取捨，可以搭配 GraphRAG 使用本地 Ollama，若知識來源主要是專案文件與程式碼，OpenWiki 建立 Agent 共用知識庫也很適合一起比較。
先用 RAG，不要急著訓練模型
手上有大量人工撰寫的中英文檢索式或高品質提示詞時，第一步不一定是微調。先把資料清理成「需求、上下文、限制、輸入範例、理想輸出」的成對資料，再用 RAG 找相似案例，通常能更快驗證需求。
- 先建立測試集，保留一批資料完全不進知識庫。
- 用 RAG 加單一 Agent 建立基準結果。
- 加入獨立評分 Agent，比較正確性、完整性與格式。
- 只有在格式高度穩定、資料量充足且 RAG 已到瓶頸時，再評估微調。
這樣做的好處是資料更新不必重新訓練，錯誤案例也能快速撤換。若資料彼此關聯複雜，還可以參考 Graphify 知識圖譜，評估是否需要從純向量檢索進一步加入實體與關係。
CrewAI 2026 最新安裝方式
截至 2026 年 7 月，官方文件要求 Python 3.10 以上且低於 3.14，並建議使用 uv 管理套件。CrewAI 現在預設建立 JSON-first 專案，Agent 放在 agents/*.jsonc，Task 與 Crew 設定放在 crew.jsonc。若需要早期常見的 Python 與 YAML 結構，才使用 --classic。
uv tool install crewai
uv tool update-shell
crewai create crew prompt_optimizer
cd prompt_optimizer
crewai install
crewai run
建立後會看到 crew.jsonc、agents/、knowledge/、skills/ 與 tools/。這個結構已經把多數需求放進設定檔，適合先從角色與任務定義開始，再加入自訂 Python Tool。
需要舊版 Python 與 YAML 專案時
crewai create crew prompt_optimizer --classic
舊版教學常出現 crew.py、agents.yaml 與 tasks.yaml，這些概念仍然有效，但預設腳手架已經不同。遇到匯入錯誤時，先確認 CrewAI 版本，再對照該版本官方文件。
CrewAI 如何連接 Ollama
CrewAI 不限定 OpenAI 或 Anthropic。官方文件提供 Ollama 設定，只要在 Agent 指定 LLM 與 base_url 即可。這能把多數推理留在本地端，避免每個 Agent 都產生雲端 API 費用。
from crewai import Agent, LLM
local_llm = LLM(
model="ollama/qwen3:8b",
base_url="http://localhost:11434"
)
analyzer = Agent(
role="提示詞分析師",
goal="找出需求缺漏並建立清楚的改寫規格",
backstory="你擅長把模糊需求拆成可驗收的條件",
llm=local_llm
)如果 Ollama 在另一台主機，把網址換成實際內網位置即可。部署前要確認 Ollama 有對區域網路監聽、防火牆已開放，而且 CrewAI 使用的模型名稱與 ollama list 完全一致。選擇模型時可以參考 本地大模型推理框架比較。
Docker 與硬體需求怎麼看
Docker Desktop 不是 CrewAI 的必要條件。早期範例需要 Docker，是因為它用容器啟動 PostgreSQL 與 pgvector。Linux 伺服器可以直接使用 Docker Engine，也可以把 PostgreSQL 安裝成系統服務。若改用 CrewAI 內建 Knowledge 與本地 ChromaDB，第一版甚至不一定需要 Docker。
一般筆電可以執行 CrewAI，因為框架本身不重。真正決定硬體需求的是模型、Embedding、向量資料庫與同時執行的 Agent 數量。雲端模型加本地向量庫的門檻最低。本地模型則要依參數量、量化格式與上下文長度準備足夠的記憶體或顯示記憶體。
成本最高的地方不是框架
CrewAI 開源框架本身不是主要成本。費用通常來自每個 Agent 的模型呼叫、反覆 RAG 檢索、長上下文、Embedding 建庫與失敗重試。四個 Agent 各自檢索並呼叫一次大型模型，很可能比單一 Agent 加一次驗收多出數倍費用。
- 讓檢索結果在同一輪工作流中共用，不要每個 Agent 重複搜尋。
- 分類、格式檢查與簡單摘要改用小模型。
- 昂貴模型只負責最終改寫或高風險判斷。
- 為 Task 設定清楚的 expected output、guardrail 與最大重試次數。
- 保存每次輸入、檢索片段、輸出與評分，才能知道錢花在哪裡。
Crews 與 Flows 應該怎麼選
若任務需要研究、創作、分析與不同專業觀點，使用 Crew。若工作需要固定順序、條件分流、錯誤重試、人工核准與狀態恢復，使用 Flow。正式系統通常會把兩者結合，由 Flow 控制整體流程，只在需要推理的節點呼叫 Crew。
| 需求 | 建議方式 |
|---|
| 研究後寫成報告 | Crew |
| 分析、改寫與交叉審核 | Crew |
| 依分數決定重寫或通過 | Flow |
| 呼叫 API 並等待人工批准 | Flow |
| 完整內容生產管線 | Flow 控制流程，Crew 處理創作 |
如果需要從桌面工作台管理 Agent 專案，也可以參考 OpenWork 與 OpenCode Agent 工作台，比較框架層與操作介面的差異。
我會怎麼重做這套提示詞優化系統
- 先用單一 Agent 加 Knowledge 建立基準版本。
- 定義固定評分表，檢查目標、背景、限制、格式與可驗收性。
- 加入一個獨立測試 Agent，只負責找問題與打分。
- 分數未達門檻時，由 Flow 送回改寫，並限制重試次數。
- 先用 Ollama 小模型跑分析與分類，必要時才把最終改寫交給較強模型。
- 用保留測試集比較原始提示詞與優化結果，不把自我評價當成唯一證據。
這個版本的 Agent 更少，但責任更清楚，也更容易測試。CrewAI 的價值不是替程式多包幾層，而是讓角色、任務、工具、知識與執行順序都能被明確描述。當每個步驟都能觀察、驗證與替換，多 Agent 才真正從展示走向可維護的系統。
官方資源與案例程式碼
FAQ
CrewAI 是模型還是框架
CrewAI 是多 Agent 編排框架。它負責組織 Agent、Task、Process、Tool、Knowledge 與 Flow，實際推理由 OpenAI、Anthropic、Ollama 或其他模型提供。
CrewAI 可以完全使用本地模型嗎
可以。Agent 的 LLM 可指向 Ollama，也能連接其他 OpenAI 相容端點。若 Embedding 與知識庫也改用本地方案，就能大幅降低雲端 API 成本。
Crew 和 Flow 有什麼差別
Crew 強調角色分工與自主協作。Flow 強調精確的執行路徑、狀態、條件分支與可恢復性。正式系統常用 Flow 管理整體流程，再把需要創作或分析的工作交給 Crew。
建立提示詞優化工具需要微調模型嗎
通常不需要先微調。先用 RAG 提供規範與案例，再建立獨立測試集評估品質。只有資料格式穩定、數量足夠，而且 RAG 已無法改善時，才值得評估微調。
使用 CrewAI 一定要安裝 Docker Desktop 嗎
不一定。Docker Desktop 只是啟動 pgvector 的方便方式。CrewAI 本身不依賴 Docker，Linux 可以使用 Docker Engine，也能改用本機 ChromaDB 或遠端向量資料庫。
by Rain Chu | 7 月 20, 2026 | Agent, AI, API, Tool
Cloudflare Workers AI 拿來接 Claude Code 的做法很簡單：Cloudflare 跑模型，LiteLLM 在本機當轉接橋，Claude Code 只需要改 Anthropic 相關環境變數，就能把請求送到本機 proxy。
這篇整理的是一個比較務實的路線。它不是要你把所有模型成本都消失，而是讓你知道免費額度在哪裡、帳單風險在哪裡、命令怎麼下、哪些設定一定要看清楚。
先講結論
Cloudflare Workers AI 有免費額度，官方價格頁寫明 Free plan 每天有 10,000 Neurons，GLM 5.2 目前也在 Cloudflare Workers AI 模型列表裡，可以透過 Cloudflare API 呼叫。這代表你可以把 Claude Code 的模型入口改成本機 LiteLLM proxy，再由 LiteLLM 轉送到 Cloudflare 的 @cf/zai-org/glm-5.2。
但「免費」不是「無限」，Cloudflare 的計費單位是 Neurons，免費額度用完後會受到方案限制，更重要的是，Cloudflare AI Gateway 也能接外部模型，如果你把 OpenAI 或 Anthropic 這類外部模型接進去，那就不再是 Cloudflare Workers AI 的免費模型邏輯，帳單會回到外部供應商那邊。
Claude Code 只改成本機 Anthropic 入口，真正的模型請求由 LiteLLM 轉到 Cloudflare Workers AI。
這個架構在解什麼問題
Claude Code 很好用，但長時間寫程式、重構、跑測試、修錯時，模型成本會變得很有感。若只是一些低風險任務，例如產生腳手架、改小工具、做簡單 demo、先跑一輪想法，Cloudflare Workers AI 的免費額度可以拿來當低成本緩衝層。
這和 用 Claude Code 搭配 LM Studio 與 Ollama 的思路很像，只是這次不是跑本地模型，而是把免費雲端額度接進本機開發流程。若你的工作流已經在用 Claude Code、Codex 和 skill 組合工作流，這種 proxy 入口會很有彈性。
完整操作命令
下面命令以 macOS 或 Linux 為主。你需要先有 Cloudflare 帳號，並在 Cloudflare dashboard 取得 Account ID 和 API Token。API Token 建議只給 Workers AI 需要的最小權限，不要用過度寬鬆的全域 token。
0. 安裝 Claude Code
npm install -g @anthropic-ai/claude-code
1. 用 curl 單測 GLM 5.2
先確認 Cloudflare 端可以呼叫模型。把 `你的ACCOUNT_ID` 和 `你的API_TOKEN` 換成自己的值。
curl https://api.cloudflare.com/client/v4/accounts/你的ACCOUNT_ID/ai/run/@cf/zai-org/glm-5.2 \
-H "Authorization: Bearer 你的API_TOKEN" \
-d '{"messages":[{"role":"user","content":"用一句話介紹你自己"}]}'2. 安裝 uv
LiteLLM proxy 用 uvx 跑，可以固定 Python 3.12，避開較新 Python 版本造成的編譯問題。
curl -LsSf https://astral.sh/uv/install.sh | sh
3. 驗證 LiteLLM 能跑
uvx --python 3.12 --from 'litellm[proxy]' litellm --version
4. 建立 cf-config.yaml
建立 `cf-config.yaml`。`你的ACCOUNT_ID` 有兩處要換。`cf-glm-5.2` 給 Claude Code 主要模型用，`cf-small` 給較輕量任務用。
model_list:
- model_name: cf-glm-5.2
litellm_params:
model: openai/@cf/zai-org/glm-5.2
api_base: https://api.cloudflare.com/client/v4/accounts/你的ACCOUNT_ID/ai/v1
api_key: os.environ/CLOUDFLARE_API_TOKEN
- model_name: cf-small
litellm_params:
model: openai/@cf/meta/llama-3.1-8b-instruct-fp8
api_base: https://api.cloudflare.com/client/v4/accounts/你的ACCOUNT_ID/ai/v1
api_key: os.environ/CLOUDFLARE_API_TOKEN
litellm_settings:
use_chat_completions_url_for_anthropic_messages: true5. 啟動 LiteLLM 翻譯橋
這個終端視窗要保持開啟。Claude Code 之後會連到 `localhost:4000`。
export CLOUDFLARE_API_TOKEN=你的token
uvx --python 3.12 --from 'litellm[proxy]' litellm --config cf-config.yaml --port 4000
6. 新開視窗測 proxy
curl http://localhost:4000/v1/models -H 'Authorization: Bearer sk-1234'
7. 把 Claude Code 指到本機 proxy
export ANTHROPIC_BASE_URL=http://localhost:4000
export ANTHROPIC_AUTH_TOKEN=sk-1234
export ANTHROPIC_MODEL=cf-glm-5.2
export ANTHROPIC_DEFAULT_HAIKU_MODEL=cf-small
接著啟動 Claude Code，若跳出自訂 API 設定就選是。進入後用 `/status` 確認 Base URL 指向 `localhost:4000`。
8. 把設定寫進 shell profile
如果你確定要長期使用，可以把上面四行 `ANTHROPIC_` export 加到 `~/.zshrc` 或 `~/.bashrc`。我會建議先手動跑幾次確認沒有問題，再寫進 profile。
Windows PowerShell 寫法
PowerShell 不用 `export`，改用 `$env:`。
$env:ANTHROPIC_BASE_URL="http://localhost:4000"
$env:ANTHROPIC_AUTH_TOKEN="sk-1234"
$env:ANTHROPIC_MODEL="cf-glm-5.2"
$env:ANTHROPIC_DEFAULT_HAIKU_MODEL="cf-small"
若要永久保存，放進 PowerShell 的 `$PROFILE`。Windows 跑 AI Agent 時，環境隔離也很重要，可以延伸看 Windows 跑 AI Agent 為什麼要用 WSL。
保命提醒：不要把外部模型當免費額度
最容易出事的地方，是把 Cloudflare Workers AI、Cloudflare AI Gateway、OpenAI、Anthropic 混在一起。這篇的低成本前提，是 Cloudflare config 裡的模型走 `@cf/` 開頭，例如 `@cf/zai-org/glm-5.2`。這類模型用的是 Cloudflare Workers AI 額度。
如果你把 Gateway 接到 GPT 或 Claude，那些請求可能會回到 OpenAI 或 Anthropic 的帳單。Cloudflare 只是通道，不代表外部模型突然免費。真正要保命，就是把模型名稱、api_base、API key 來源逐一檢查，並在 Cloudflare 後台看用量。
官方價格頁目前寫得很明確：Free plan 每天 10,000 Neurons，Paid plan 也有每天 10,000 Neurons 免費額度，超出後依 Neurons 計費。免費方案超出額度通常是操作失敗，不是自動無限跑。這點比「無限免費」四個字重要太多。
省額度的三個做法
第一，任務分層。小任務用 `cf-small`，複雜推理再用 `cf-glm-5.2`。第二，讓 Agent 先輸出計畫再執行，避免一次丟太長上下文。第三，把重複流程寫成腳本或 skill，減少模型反覆讀同一批資料。
這也是我一直看好的方向：不要只追求模型本身，而是把模型接到穩定工具鏈。像 Playwright CLI 讓 Codex 操作瀏覽器，或 讓 Agent 自己搜尋和使用 skills，本質上都是把昂貴推理留給真正需要判斷的地方。
我會怎麼用
我不會把這套當成主力模型的完全替代品，而是當成低成本實驗層。適合拿來跑 demo、試 prompt、生成小工具、做簡單 code review、補文件、處理一次性腳本。真正重要的架構決策、複雜除錯、長上下文專案，還是要保留更強模型或本地大模型選項。
如果你已經在用 Codex 和 ChatGPT Work 這類 AI 代理工作流，這套 Cloudflare Workers AI + LiteLLM 的做法可以當成另一個模型入口。它的價值不是讓你省到零，而是讓你有更多成本可控的實驗空間。
延伸資源
FAQ
Cloudflare Workers AI 接 Claude Code 真的免費嗎？
不是無限免費。Cloudflare Workers AI 有每日免費 Neurons 額度，超出後會依方案限制或計費。要把它當成低成本額度，不要當成沒有上限的模型。
為什麼需要 LiteLLM？
LiteLLM 在本機當 proxy，把 Claude Code 發出的 Anthropic 入口請求轉成 Cloudflare Workers AI 可接受的 OpenAI 相容請求。
最容易踩到哪個帳單風險？
最容易把 Cloudflare AI Gateway 接到外部 GPT 或 Claude，卻以為仍在用 Cloudflare 免費 @cf 模型。設定時要確認模型名稱是 `@cf/` 開頭，並檢查 API key 來源。
這套適合取代主力 Claude 嗎？
不建議直接取代。它比較適合低成本實驗、簡單任務、小工具和批次工作。複雜架構、長上下文和高風險任務，仍應保留更強模型。
近期留言