個人學習記錄 · STAGE 05
這一階段要解決的問題 學習怎樣拆分搜尋、整理、審閱任務，並檢查不同 Agent 交回的證據。
子代理的價值來自分工和複核。這裡從不同 Agent 的體驗出發，再進入多代理搜尋、資料對比和具體研究場景。
本頁收錄 7 篇原文。正文來自個人 Google Drive 原文庫，已移除 x.com 地址和 t.co 媒體短鏈。原文涉及的版本與產品狀態以釋出日期為準。
2026-08-19 21:39:36 · 小墨同學原文
我想分享的是，一定要多嘗試不同的Agent，真的你會回來感謝我的！
因為每個Agent時間都有相似之處，但是又有很多不同之處。
比如我自己最常用的，Claude Code、Codex 他們兩個之間我覺得差別最大的就是生態上的差距，沒有幾個人可以完整的體驗Claude的產品線，但是Codex可以。
Pi Agent和Deepseek 代理框架兩個從裡層就有很大的區別，一個是簡潔的設計AI不需要這麼多，一個萬物皆外掛程式的設計思維。
還有就是我自己常用的Hermes和Openclaw，兩個產品類似，但是大方向不一樣，一個是講究自進化低維護skill優先，一個是外掛程式生態和獨特的記憶體系，各有優點。
用了這麼多，但是有部分核心設計都是共通的，用多了，你才能知道哪一些才是你真正需要的想用的
2026-08-24 18:52:20 · 小墨同學原文
Pi Agent 的 Sub-agent功能一定要用起來！
雖然官方沒有內建相關的功能，但是只需要安裝外掛程式就能用上。
再多工並行的情況下，是幫你提效的好幫手，尤其是處理一下簡單重複資料量大的時候，就非常合適。
這裡我簡單介紹一下工作原理：
- 主代理（Main Agent）負責拆任務
你平時對話的 Pi 就是主代理。
比如分析一個大型專案，它可以讓 scout 找入口檔案，讓 researcher 查文件，再讓 reviewer 檢查風險。
你只需要把目標和限制講清楚，剩下的任務分配交給外掛程式。
- 每個子代理都有獨立上下文（Context）
大部分外掛程式會單獨啟動一個 Pi 程序，讓子代理自己讀檔案、呼叫工具。
它幹完以後，只把結論交回主代理，不會把幾十次工具呼叫全部塞進主對話。
好處是省上下文，缺點是它不一定知道你之前聊過什麼。所以任務裡最好寫清楚路徑、目標和需要返回的結果。
- 不同 Agent 可以使用不同模型和權限
查程式碼的 scout，只開放 read、grep、find。
負責 Review 的 Agent 可以看程式碼、跑測試，但不一定需要修改檔案。
真正幹活的 worker，再開放 edit、write 和 bash。
簡單任務還可以交給便宜模型，複雜判斷再用強模型，不需要所有 Agent 都用最貴的設定。
- 支援單獨、並行和鏈式執行
官方子代理示例支援三種常見方式：
Single：一個 Agent 完成一個任務 Parallel：幾個 Agent 同時處理不同任務 Chain：scout 找程式碼 → planner 出方案 → worker 修改 → reviewer 檢查
自由組合任務，不僅可以讓任務分開跑，而且可以組合在一起跑最終的結果會聚到一起是分開處理
但是相關缺點也是有的，就是對Token的消耗會乘幾倍增長，如果你的工作不是很緊急，或者是對應方案額度不夠也不建議長期使用
如果大家對這部分感興趣，下次我就介紹一下相關的外掛程式，把你的Pi 打造成一個多執行緒並行開發工作臺
2026-08-28 10:16:28 · 小墨同學原文
Pi Agent 的子代理我一直在用，最近我又拿 Apodex 1.1 跑了一輪多代理搜尋。
它處理資料對比的方式，和普通 Deep Research 不太一樣。
Pi Agent 本身沒有內建子代理，需要透過外掛程式擴充。你可以讓 scout 搜資料，researcher 整理資訊，再交給 reviewer 檢查。每個角色使用什麼模型、開放哪些工具和權限，都能自己設定。
這種方式很靈活，適合喜歡自己搭 Agent 工作流的人。
這次我給 Apodex 1.1 的任務，是核對 Pi Agent、Codex CLI、Claude Code 和 FrontierAgent 的多代理能力。
這些工具更新都很快。同一項功能可能在舊文件裡沒有，最新版本已經加入，也可能只是外掛程式支援，最後卻被寫成官方內建。
所以我從一開始就限制了資料範圍，只接受官方文件、GitHub 倉庫和版本更新記錄。
Apodex 會根據問題拆分搜尋路線。多個 Agent 分頭查不同工具，階段結果持續彙總到同一個任務中，最後再集中比較。
我這次想看的，是它能不能把一個資料多、版本雜的任務持續做完，並把每條結論的來源留下來。
最終表格會單獨區分官方內建和外掛程式實現。不同官方頁面出現衝突時，它會列出各自的來源和更新時間。官方沒有明確說明的地方直接標成未知，不會為了填滿表格補一個答案。
交付結果還會經過 Statement Review。關鍵結論與生成過程分開檢查，遇到證據不足、引用不匹配或資料衝突時，會留下對應的檢查記錄。
兩種多代理的使用方向也很清楚。
Pi Agent 適合自己組建團隊。角色、模型和權限都能深度調整。
Apodex 更適合多路搜尋，把分散的資料放到一起比較，再交付一份可以繼續核查的結果。
如果你經常需要確認某項能力究竟是官方支援、外掛程式提供，還是目前沒有明確資料，這種工作方式會比較實用。
FrontierAgent 是開源的單機代理框架（Agent Harness），支援 ReAct 和 Agent Team。macOS、Linux 可以一條命令執行，無需強制預裝 Docker。覺得有用可以去 GitHub 點個 Star。
Apodex 1.1 mini 是開放權重的 35B 模型，可以本地部署，也能搭配 FrontierAgent 使用。
Apodex 1.1 線上工作臺已經上線。註冊新使用者有 credits，可以上傳自己的文件、資料或表格跑一次。API 平台目前免費兩週。
原帖包含圖片或影片，媒體素材待後續整理。
2026-08-28 11:24:12 · 小墨同學原文
我用Pi 接入 Apodex 1.1，讓它幫我查查孫宇晨說的是真是假🔥
孫宇晨那篇《我的女友景甜》發出來以後，相關話題很快衝上熱搜。
文章寫了大量戀愛和財產糾紛細節，開頭與結尾又標註了純屬虛構。隨後代理律師公開談到三千餘萬元財產爭議，景甜一方也作出了回應。
幾種來源混在一起以後，很多內容已經分不清是公開事實、單方說法，還是自媒體根據原文繼續加工出來的故事。
我剛好把 Apodex 1.1 接進 Pi Agent，就拿這條新聞跑了一輪。
我讓模型自己搜尋孫宇晨的原文、雙方回應和律師公開說明，繼續追查媒體報道的最初出處。遇到互相衝突的說法要保留，原始頁面打不開也要明確標註，證據不足的內容不能寫成事實。
Pi Agent 提供搜尋和網頁讀取工具，Apodex 1.1 決定從哪裡開始查，哪些內容需要交叉驗證，最後把新聞整理成一份帶來源的時間線和事實核查表。
這裡測試的就是Apodex模型的真實搜尋能力和資訊整合能力，大家也知道在Pi執行模型可以比較真實的回饋出模型的真正實力。
到底是李逵還是李鬼測試一下就知道了。
現在Apodex API 平台目前限免兩週，感興趣的可以自己去體驗一下，連結我放評論區了
原帖包含圖片或影片，媒體素材待後續整理。
2026-08-28 14:21:48 · 小墨同學原文
看到這個用 Apodex 搜《紅樓夢》的例子，我想到 Pi 的子代理很適合處理這類問題。
《紅樓夢》裡的很多問題都牽涉不同版本、脂批和後來的研究觀點。模型如果順著最先搜到的解釋寫下去，很容易把原文、校注和後人推論混在一起。
接進 Pi 以後，可以讓子代理分頭查。一個只找原文和版本出處，另一個整理不同研究觀點。主代理再檢查引用來自哪裡，把暫時無法解決的衝突保留下來。
這裡很考驗 Apodex 1.1 怎麼拆問題，也能看出它會不會檢查子代理帶回來的材料。
搜尋數量決定能找到多少資料，來源判斷決定最後的回答能不能信。
這種沒有唯一標準答案的問題，很適合拿來測試 Pi 子代理和 Apodex 1.1 的組合。
原帖包含圖片或影片，媒體素材待後續整理。
2026-08-30 20:01:38 · 小墨同學原文
我開始讓 Pi 學我怎麼分析自己的 X 推文了🔥
以前我覆盤X推文資料，基本都是自己來，其實很浪費時間。
要去看曝光、點贊、收藏，再回頭看開頭有沒有吸引力，中間哪一段資訊密度最高，為什麼有的內容明明寫得不錯，但就是沒人看。
做多了以後我發現，其實我每次分析的思路都差不多。
那就沒必要每次重新告訴 AI 一遍。
我現在開始把這套流程直接固化進 Pi。
比如以後我把自己的推文丟給它，它會按照固定順序去看：
1、先判斷這篇內容真正吸引人的點是什麼，而不是隻看資料高低。
2、再拆開頭、結構、選題和表達，找出哪些地方值得繼續保留。
3、最後結合我以前表現好的內容，告訴我這個方向還能往哪裡繼續挖。
現在我用Pi 不再是單純的去封裝成skill，而是卻發現生活中的習慣把它固化下來，用Pi的自定義外掛程式替我解決。
這也是我現在越來越喜歡 Pi 的地方。
原帖包含圖片或影片，媒體素材待後續整理。
2026-09-03 08:21:25 · 小墨同學原文
OMP 越做越狠了：一個 Agent，開始配一整個模型團隊。
以前使用Pi 開啟子執行緒代理，我都會糾結一個問題：
是不是所有的Subagent都需要繼承主執行緒的模型等級，但是實際使用下來消耗又高，使用又慢。
但是我在 Oh My Pi 這種多代理框架，找到了一個模糊的方向。
主執行緒Agent、Advisor、子代理需要分工明確什麼人幹什麼活，如果全部塞同一個最強模型，成本高不說和速度還慢。
現在 OMP 社群已經開始討論，把不同角色的模型徹底拆開：
1、Main Agent 要的是綜合能力
負責理解需求、做決策、控制整個任務，所以更適合放能力最強的模型。
2、Advisor 要的是判斷能力
它不一定負責真正幹活，更多是盯著主代理有沒有走偏，所以推理和判斷比速度更重要。
3、子代理更看價效比
查資料、掃程式碼、跑簡單任務，這些東西如果一下開十幾個，全用頂級模型完全沒必要。
我自己其實已經是類似的用法。
主代理我會用 GPT-5.6 Sol，Advisor 放 GPT-5.6 Terra，真正大量跑子代理的時候，反而會優先用 DeepSeek、GPT-5 Mini，甚至一些免費的模型。
強模型負責做判斷，便宜模型負責幹雜活，做執行層。
這個方向可能就是我正在尋找的破局之道，動態分配任務和模型，雖然複雜，但是又便宜又高效。
原帖包含圖片或影片，媒體素材待後續整理。
完成這一階段後，繼續閱讀第 6 階段 把 Pi 變成長期工作流。
