Posted by 
上回書說到：跟一群AI一起上班是什麼體驗
上一篇談的是我怎麼把 AI 開發流程拆成幾個角色：
我（Rayer） ↕ 產品方向、架構與 priority Hermes（由我指定為 TPM + Orchestrator） ↕ 分析問題、整理 spec、開票、派工 Coding Agent（Codex / Grok Build） ↕ 讀票、列 plan、寫測試、實作、開 PR YouTrack + Git repository ↕ 保存任務 context、長期規則與執行證據
當時我在文章結尾留了一個問題：
每個角色到底需要多「聰明」？哪些位置真的值得使用最強的模型？
給趕時間上班的直接答案：
- Orchestrator：別客氣，最高階用下去吧。Grok 4.5 或 GPT-5.6 Sol，high～xhigh 開下去。
- TPM：別客氣，最高階直接用下去吧。Grok 4.5 或 GPT-5.6 Sol，high～xhigh 開下去。記得 handoff 的票要寫好，不要再讓 Coding Agent 花腦袋重新做一次需求分析。
- Coding Agent：Grok Build 選 Composer 2.5 對我的工作已經夠用；Codex 則是 Luna high～xhigh。在我目前的 Plus quota 與這批任務裡，它比 Terra medium 更省額度也更好用；這是使用體感，不是固定價格或 benchmark 結論。
模型的 Culture Shock
說真的每個角色到底要多聰明？這關乎著荷包，值得想一下。
上禮拜隨著老馬發布 Grok 4.5，以及他的死對頭發布 GPT-5.6 Sol，這兩個模型給了我一個很直接的答案，也是 Anthropic 使用者也許早一個多禮拜就知道的答案——喔，我沒訂 Anthropic，呵。這進步是直接的、可見的，而且令我驚訝。
以前的我，總覺得 loop engineering會被卡住在那條 loop 裡最昂貴、也最容易被打斷的 message bus（這讓一個資深工程師被迫on-call當文件小弟，真是業界創舉）。但是使用了這兩個模型（以及花點時間「調教」過）後，環節終於閉合了。Loop engineering原來是真的！
—
「不適合的模型」（婉轉）真的搞不起Loop
我把 Hermes 的兩個責任分開稱呼：需求釐清、root-cause analysis 與 ticket decomposition 階段是 TPM；啟動 coding agent、維持 execution state、處理超出既定邊界而需要 human decision 的例外，並把結果接回原始 task context 的角色則是 Orchestrator。
Coding agent 當然要會寫 code，但一套 agent workflow 能不能真正形成 loop，瓶頸往往不在 coding agent，而在站在它上面的 Orchestrator 和 TPM。要我說的話，其實 Orchestrator 更重要一點。
模型不夠聰明時，流程看起來有 agent、有 ticket、有 tool call，也有 PR；實際上卻只是人類在幾個視窗之間搬運訊息。
理想流程很簡單：
我和 Hermes 討論需求 → Hermes 找 root cause、拆 ticket → Hermes 透過 terminal / PTY 啟動外部 coding agent → Coding agent 讀票、跑 Superpowers、實作與測試 → Coding agent 開 PR → Hermes 接回結果、檢查狀態、安排 review 或下一步
但在 Grok 4.5 以前，實際流程常常是：
我和 Hermes 討論需求 → Hermes 開 ticket → Hermes 嘗試啟動 coding agent → coding agent 等輸入 / Hermes 不知道怎麼 relay → 莫名 timeout，或停在等待狀態 → 我另外開一個 terminal 視窗 → 手動啟動 Codex 或 Grok Build → 告訴它去讀 YouTrack ticket、執行 Superpowers → coding agent 完成後開 PR → 我再把 PR link 貼回 Hermes → Hermes 才能繼續做 review、更新 ticket 或安排下一步
技術上，Hermes 並不是完全不能啟動 coding agent。這裡談的也不是 Hermes 內建的 delegate_task subagent，而是 Hermes 透過 terminal、PTY、tracked process 和相關 skills 啟動 Codex／Grok 等外部 CLI coding agent。
delegate_task 不是單純在同一個 context 裡角色扮演；它確實會啟動一個有獨立 conversation、terminal session 和 toolset 的 subagent。不過，child 預設繼承 parent 的 model／provider，除非另外設定 delegation.model 與 delegation.provider。所以如果 Hermes 當下使用 GPT，我只在 prompt 裡寫「請用 Grok review」，並不會真的把 Grok 叫起來；它仍可能只是讓 GPT 在隔離 context 裡扮演 Grok reviewer。delegate_task 通常比較絲滑，是因為它以非互動式 background delegation 回傳 final summary，不需要人類處理中途輸入；但它仍可能失敗或 timeout，不能說它絕對不會卡住。
透過 terminal／PTY spawn 外部 coding agent，才是真的啟動另一個 CLI runtime，也可能實際使用另一個 model。這種需要管理長時間 process、雙向輸入與 handoff 的路徑，才是我先前最常碰到問題的地方。
Grok 4.3 和 DeepSeek‑V4‑Pro 有時其實能正確讀懂 build agent relay 回來的問題，也能判斷：「這件事不應該由我猜，需要使用者決策。」問題出在接下來那一段：它不知道怎麼把問題可靠地送到我這裡，再把我的答案送回原本正在等待的 coding agent。
理想路徑應該是：
Coding agent 提出需要決策的問題 → Orchestrator 判斷需要 human input → 問我 → 收到我的回答 → Relay 回原本的 coding agent → Coding agent 繼續執行
實際上卻常變成：
Coding agent 提出問題 → Orchestrator 知道需要問我 → 找不到正確方式把問題送出，或送出後接不回答案 → Child process 持續等待 → Timeout → Orchestrator 誤以為該自己接手 → 開始自作主張地實作原本交給 coding agent 的工作
我可以透過反覆溝通、修 prompt、寫 skill，讓它少一點自作主張（玩過 Hermes 的大概知道，這其實就是它招牌的 self-improvement 能力），例如明確規定不要搶走 coding agent 的工作、遇到決策要停下來問、不要把等待誤判成失敗。這確實改善了一部分行為……暫時啦，時間只要拖久一點，它又忘了。
但 timeout 一直沒有真正消失。Skill 可以教它 policy，卻不能保證它真的完成「問人、等待、收到回答、送回 child」這條 process lifecycle。
卡住時好時壞，結果就是，我只好開新的 terminal 啟動 build agent，手動把 Hermes 寫好的票餵給它，跟它確認還有哪些地方不清楚並寫回票裡，再叫 Hermes 看票補充說明。最後 coding agent 在人力傳聲筒運作下開始工作、送出 PR；我再把 PR 和注意事項丟給 Hermes，請它安排 review 與 merge（或者發回修改，又是人力輸送帶，唉）。
最後，人類被迫變成整條 loop 的斷點。「Hi 剛剛跟我討論產品走向跟工程細節的文件小弟，我PR做完了你幫我送交Hermes去做code review喔～」
往高情商想，這至少讓人類增加更多的參與感，除了在前面打嘴砲跟TPM討論產品規格跟開票以外，還多了個送報童的工作。但是，往工程角度看，這是把整個系統裡最昂貴、最容易被打斷的節點，安排去做最機械式的 copy-and-paste。每次想到都很令人白眼。
當然，這個被迫存在的斷點也有一個副作用：我會順便看它們是不是已經走錯路。但那應該是有意識的 supervision 和 risk review，不該是因為系統無法正確解決一個問題，以至於我不得不隨時回來看一下有沒有被卡住，該不該去搬運了。我也想出去逛個街回來東西就搞定啦！這些工作半點需要我決定的事情都沒有，純純的搬運工。
—
拆解不夠細，拿廢話來頂的TPM
另一個問題發生在 TPM 階段。
一張 coding agent 能直接執行的 ticket，至少需要回答：
- 使用者看到的症狀是什麼？
- 如果 root cause 已定位，相關的 module、file 和 function 在哪裡？如果還沒定位，待驗證的 hypotheses 是什麼？
- 是一條資料流，還是多個獨立問題呈現出同一個症狀？
- 這次修改的 scope 和 non-goals 是什麼？
- 有哪些 module contracts 或 global invariants 不能破壞？
- Acceptance criteria 是什麼？
- 哪些 regression tests 一定要跑？
- 哪些地方需要人類確認，不能由 agent 自己猜？
能力不夠的 TPM 很容易產生一張「看起來很完整」的票。段落很多、格式正確、甚至每個欄位都有內容，但真正要動手時，coding agent 還是得重新理解問題。
常見狀況包括：
- 抓錯 root cause；
- 只看到第一條 data path；
- 漏掉另一個會產生相同症狀的條件；
- 把 solution 當成 requirement；
- Acceptance criteria 只驗證 happy path；
- 花很多篇幅解釋不重要的背景，真正的 contract 卻只寫一句；
- 討論過程一直繞，經過多次人工校正仍抓不到重點；
- 我指出方向不對後，它表面上同意，下一段又回到原本的錯誤理解。
這種摩擦很消耗人。
Coding agent 至少是在實作階段消耗 token；TPM 如果一直抓不到重點，消耗的是我重新解釋同一件事的耐心。有些模型有天生的順從傾向，什麼都是好好好，結果就是該抓的沒抓出來，該 clarify 的反而一大堆。開類似 grill-me 的 skill 也不是不行，但不夠聰明的模型其實開了也沒啥用，況且 grill-me 很多產出感覺也太鑽牛角尖了。
而且 TPM 的錯誤會向後傳遞。錯的 root cause 會產生錯的 scope，錯的 scope 會產生錯的 acceptance criteria，最後 coding agent 很有效率地寫出一份完全通過錯誤測試的實作。
所以 TPM 不是一個可以隨便放便宜模型的位置。它不一定要寫 production code，但必須能讀 code、維持因果鏈、區分事實與假設，並知道自己漏了什麼。
—
我試過的模型不少，但「比較好」不等於 loop 能轉
這段時間我在 Hermes orchestrator／TPM 位置上換過不少模型。
從表現最差的 local Ollama qwen3.6:35b-mlx，一路試到 DeepSeek‑V4‑Pro、Grok 4.3，再到後來的 Grok 4.5。不同模型當然有差。有些比較會讀 code，有些比較能維持長對話，有些比較願意使用工具，有些比較少自作主張。但在 Grok 4.5 以前，我的感受大多仍是「好一點」或「少修幾次」。持續寫 skill 確實能改善「不要自作主張接手」這類 policy 問題，卻沒有穩定解決 interactive relay 和 timeout。
它們可以整理需求，可以呼叫工具，也可以嘗試派工。只是到了真正需要跨越狀態邊界的地方，例如：
- Child process 問問題；
- Tool 沒有立即返回；
- 需要決定繼續等、補輸入、重試或升級給人類；
- Coding agent 完成後要把 PR、測試結果和 concern 收回 ticket；
- 前一個假設被推翻，必須重新拆解，而不是沿著舊 plan 硬走；
這些東西都變斷點，要不停下來等我回來看，要不就自作主張把後面做下去了，整個流程仍然很容易散掉。這讓我慢慢意識到一件事：
Agentic workflow 存在一個 orchestration threshold。模型在門檻以下時，每提升一點只是少一點麻煩；跨過門檻後，原本需要人類接線的流程才第一次有機會閉合。
這不是 benchmark 上多幾分的感覺，而是系統行為發生了 phase change。我知道有類似AgentBench跟GAIA這類測Agentic的workflow，不過這比較偏向於小方向，單一問題的連續解決能力。
—
Grok 4.5：突然可以跟Builder Agent緊密合作了！？
Grok 4.5 開放後，我試了一輪，第一個反應確實是驚為天人。它帶來的改變不是文筆更好，也是 ticket 寫得更長（老實講之前有個模型廢話真的有夠多），而是阻力突然少了很多。老馬啊，還得是你啊~
TPM 討論不再需要一直把它拉回來
以前的討論很像：
我指出問題 → TPM 理解一半 → 我補充另一半 → TPM 過度延伸 → 我要求縮 scope → TPM 又漏掉原本的重要條件 → 我又要即時抓回來
換到 Grok 4.5 後，它比較能：
- 找出問題裡真正需要決策的地方；
- 保留前面已確認的 constraints；
- 被糾正後真的更新 working model，而不是只改下一句話；
- 在資訊不足時提出有用的問題；
- 知道哪些是 root cause、哪些只是 symptom；
- 把 ticket 寫到 coding agent 能接手，而不是把分析工作整包丟下去。
人工仍然需要校正，但從反覆拉扯，變成比較像正常的 architecture discussion。
Orchestrator 能直接在 Hermes 裡完成派工
決定性的改變發生在 coding agent orchestration終於能夠自己管理整個builder agent的生命週期了。
Grok 4.5 作為 Hermes 的 orchestrator，在我這套 terminal／PTY／tracked-process workflow 裡，可以直接啟動 Codex／Grok coding agent，管理執行狀態，讀懂過程中的輸入需求；能從 ticket、repository 或既有決策找到答案時就自己回覆，只有真正超出既定邊界、需要新的產品決策時才把問題帶回來；最後等待完成，把結果接回原本的 task context。
這不代表所有 Hermes subagent 或非互動式 delegation 都支援中途問答，而是指我實際使用的外部 CLI agent 路徑。更精確地說，terminal、PTY 和 process tools 原本就提供了通道；Grok 4.5 是第一個讓我感覺 orchestrator 能可靠使用這些通道完成雙向對話的模型。
在我實際跑過的這批任務裡，同樣一張票，結果大致接近我自己另外開 terminal 啟動 coding agent；這是使用觀察，不是受控成功率比較。
以前由我手動做的工作：
開新視窗 → 啟動 agent → 指示讀票 → 啟動 Superpowers workflow → 回答過程中的問題 → 等 PR → 把 PR link 搬回 Hermes
第一次可以留在同一個 orchestration loop 裡完成。我不用再當信差小弟。那一刻，loop engineering 的最後一塊拼圖才終於被拼上。天啊，這真是開發史上的雷曼時刻（等等這詞好像意思對了但是完全是貶義ＸＤ）
以前 coding agent 已經會寫 code，YouTrack 已經能保存 task context，GitHub 已經能保存 PR 與 execution evidence，Hermes 也已經能開 process。缺的只是 orchestrator 無法穩定地和自己叫起來的 coding agent 對話… 「來，Rayer，我票寫好了你可以開Builder agent去寫code了」
只要這一段仍要由人類跨視窗 relay，人就無法離開 execution loop，而是被迫成為 loop 本身的 breakpoint。直到 orchestrator 能自己完成對話、等待、回復與 handoff，整套流程才第一次真的閉合。
—
GPT-5.6 Sol：原來不只 Grok 4.5 做得到
後來換 GPT-5.6 Sol 做同樣的 orchestrator／TPM 工作，發現它也能把這個 loop 跑起來。
它能維持 task state、拆問題、使用 Hermes tools，透過 terminal／PTY 啟動外部 coding agent，並在 child process 與原始 ticket context 之間完成協調。TPM 討論的人工校正次數也明顯下降。
所以目前我的主要配置變成：
Rayer → Product direction / architecture / risk ownership Hermes + GPT-5.6 Sol → TPM / root-cause analysis / ticket / orchestration Codex or Grok Build → Planning / tests / implementation / PR Different-model reviewer → Less-correlated review / adversarial cases
老實講，我對 Anthropic 有著根深蒂固的成見（或者一個更簡單的說法：我窮 XD)，所以一直沒有真正投入 Opus 4.8／Fable 5 與相關工具組合。兩三個禮拜前看到 Anthropic 的 Boris Cherny 推廣類似工作流時，我用手邊的模型和工具其實還做不太出來；Anthropic 當時的模型與 harness 組合，可能早已跨過我仍卡著的那條門檻。這不是對模型能力的比較結論，而是產品偏好和 workflow fit；我的個人 AI workflow 主要還是靠 SuperGrok 和 ChatGPT Plus 的訂閱撐起來。
如果只有某一家 provider 的旗艦模型能做 loop engineering，整套流程會很容易被工具偏好、價格和 account availability 綁住。還好，感恩老馬讚嘆老馬，還有奧特曼。
Grok 4.5 先讓我看到這件事能運作，GPT-5.6 Sol 則讓它變成我可以日常使用的配置。
—
「我們已經把跑道畫出來了，你沿著跑道跑，我先去吃飯了」
我沒有把同一張 ticket 分別交給 Grok 4.3 和 GPT-5.6 Sol 做 controlled replay，所以這不是同票 A/B test。舊側是我在 LLM Wiki Cloud workflow 裡反覆遇到的 failure pattern：Hermes 啟動 coding agent，agent 提出問題，Orchestrator 也知道這需要使用者決策，卻無法穩定完成「問人、等待、收到回答、送回 child」；接著 process timeout，甚至開始自作主張接手實作。最後我只好自己開 terminal、貼 ticket、搬答案，再把 PR link 搬回來。
我已經找不到一張足以重建完整 trace 的舊 ticket，所以不打算硬湊一個看似精確的案例。但新側有一個可以核對 artifacts 的 execution trace，來自我手邊一個仍在開發的 iOS 專案。
那是一個 foundation stabilization Epic，下面拆成十張有 dependency order 的 tickets。Hermes／GPT-5.6 Sol 建立 isolated worktree，啟動外部 Codex CLI，依序讓 coding agent 實作、測試、接受 review、修正，再把結果接回同一條 Hermes session。
One foundation epic + ten ordered tickets → Hermes creates an isolated worktree → External Codex implements ticket by ticket → Hermes reads process output and verifies artifacts → Review findings return to the implementation context → Codex fixes and reruns tests → Hermes creates a pull request → Merge to main → Verify the merged commit → Return PR, tests and evidence to the task context
中間唯一真的需要我動手處理的，是 macOS 要求 administrator authorization 才能接受 Xcode Simulator runtime license。這是 agent 權限外的 environment prerequisite，不是 coding agent 問了一個問題後，要我跨視窗搬運答案。處理完一次，execution loop 就繼續跑。我寫文章的當下他從凌晨一點多跑到token枯竭，我早上六點半起來幫他補個血，他到現在還在繼續跑 XD 零干預。
我有給他設定checkpoint停下來，在完成其中一個功能組後，最後產物是一個 GitHub pull request，裡面包含二十多個 commits 與數十個 changed files。合併後，Hermes 又在乾淨的 merged main 上重新驗證：
Full simulator tests: 100+ tests, 0 failures Debug simulator build: succeeded Release simulator build: succeeded git diff --check: passed
我仍然參與 scope、環境權限和高風險決策，但不用手動操作 Codex，也不用在 Hermes、terminal、GitHub 和 YouTrack 之間搬訊息。這離「無人值守開發」（最近這詞好夯）有段距離，但是至少我們能做到把跑道鋪好，鋪平，確認沒有障礙物，確認油料充足後，讓車子自動的沿著跑道開始慢慢地把路跑完。
—
Orchestrator 跨過 threshold 時，具體多了什麼？
對我來說，「模型變聰明」不是 benchmark 分數，而是我到底有沒有辦法跟這個模型deal好像下面這幾件關鍵事件：
- 維持 task model：記得目標、已知事實、constraints、dependencies、current state 和 completion criteria，並在工具返回新資訊時更新，而不是繼續照舊 plan 往下跑。
- 守住 decision boundary：判斷答案能否從 repository／ticket 找到、應由 parent 回覆 child、是否真的需要人類，以及 child 是卡住還是仍在執行。
- 管理 process lifecycle：能等待、觀察 progress、解讀 timeout、有限重試、保留已完成 state，並在結束後驗證 artifact，而不是只相信 agent 說「好了」。
- 讓 feedback 改變 working model：收到 correction 或 review finding 後，會重算 root cause、scope、acceptance criteria 和派工，而不只是說「你說得對」後照原路繼續。
- 壓縮 context 並接回 evidence：把資訊整理成 coding agent 所需的最小充分 context，最後再把 PR、tests 和驗證結果接回原始 ticket。模型太弱時，常用篇幅掩蓋沒有抓到重點；講廢話的本領我還真的沒看過哪家贏得過（消音，不批評別人 XD）。
這些能力同時依賴 reasoning 與 harness design。Tool schema、PTY、process lifecycle、timeout／retry policy、skills 和 context propagation，少一個都可能讓 loop 斷掉。當然，身為一個合格的工程師，這些斷點就是修修補補，然後希望他不要太快又斷掉…
以前我開發「A 做完觸發 B、B 做完觸發 C」只算 pipeline：
Pipeline:
A → B → C
Loop:
State → Action → Observation → Evaluation
↑ ↓
└──── Correction or next action ───┘
↓
Verified completion
Tool chain 只證明 agents 能被依序叫起來；loop 還要求中間產生的問題、review finding 和 execution evidence 能回到正確 context，讓下一步繼續。Coding agent、YouTrack、GitHub 和 process tools 原本都在，缺的是能把 feedback 接回來的 Orchestrator。
—
（後記碎碎念）模型進步後，人類終於可以被移出 loop 了
這不是「模型變強了，所以我就禿了……不對，所以我就沒事幹了」。
我想移除的不是人的責任，而是人類在 execution path 裡的必要性。理想狀態是：人先把 loop 定義好，接著離開正常執行路徑，讓 Orchestrator 和 coding agents 自己花時間跑完；等它交回可驗證的結果時，人再回來驗收。
Definition → 人類與 AI 把 vision、scope、non-goals 和驗收邊界談清楚 Execution → Orchestrator 拆解、派工、處理 feedback、修正並完成 Acceptance → 人類檢查成果是否符合原本的產品承諾
所以模型進步並沒有讓人類少思考，而是把注意力往前移：產品真正解決什麼、這版做什麼、不做什麼、未來可能做什麼、哪些條件才算完成。這段 definition work 很花時間，但至少花在「我們到底要做出什麼」，而不是 child process 是否在等 Enter、PR link 要貼去哪裡，或為什麼又 timeout。
我和 GPT-5.6 Sol 討論手邊一個仍在開發的 Apple-native 專案，就是一個具體的 definition case。它是一個 private-by-default 的個人餐廳記憶與用餐決策工具，不是公開評論社群；核心問題是：收藏或吃過那麼多餐廳，到了吃飯時，能不能更容易回答「這餐吃什麼？」
我是 product owner，負責定義問題、挑戰假設、決定 priority、MVP boundary 與產品承諾；Hermes 是 TPM 和 discovery partner，負責提出 candidate capabilities、追問 use case，並區分 recurring value、onboarding、fallback 和可能自嗨的功能。
一開始，AI 很快把「增加餐廳」展開成 candidate pipeline、去重、批次 review、資料結構和技術 spike。我把它拉回來：先不要談怎麼做，先問需求是否合理，而且一次只談一個 capability。
例如「從照片 GPS metadata 找附近餐廳」。AI 一開始認為它很有 demo 效果，但可能自嗨。我補上三個真實情境：親友傳來帶位置的照片、用餐後從當天照片補記、回顧舊照片時想起某家店。AI 反問：如果通訊軟體已移除 metadata 呢？我的回答不是再膨脹出 OCR 或視覺辨識，而是切清 boundary：有 GPS 就搜尋附近餐廳，沒有就誠實告知使用者。
我們用三個問題當 gate：有沒有具體 use case？情境是否合理？同一個使用者是否可能重複使用？通過後才排 MVP priority，並把 URL／文章、bookmark 和外部地圖清單等有價值但不屬於首版的能力明確留到未來。
AI 提出候選與假設 → 人類挑戰問題定義與價值 → AI 依修正重新整理 → 人類補入真實情境與限制 → AI 再質疑、分類與收斂 → 人類決定 vision、scope、non-goals 和 future options → AI 轉成可執行、可驗收的工程紀錄
等這些事情談清楚後，我希望自己可以離開 execution loop，只在真正超出既定邊界時被叫回來，或者完工後驗收。那次我先花大約三小時和 AI 把細節定義清楚，再讓它一個上午把漫長的執行跑完，中間不必充當 relay。放心回去睡覺，回來收網抓魚，還有什麼比這更愜意的嗎？
人類被移出的不是責任，而是正常執行路徑。斷點消失最大的價值，也不只是少開幾個視窗，而是讓我把有限的注意力集中在定義 loop 的成果。想想讀到這裡的你薪水是多少；跑去做 copy-and-paste，還順便成為團隊斷點，不覺得很掃興嗎？
—
這不是 benchmark，只是我的 workflow crossing a threshold
免責聲明喔，這篇不是受控模型評測。
我沒有使用完全相同的 prompt、相同版本的 Hermes、相同 repository 和幾百次固定 tasks，去計算成功率。期間 harness、process handling、tools、prompt 和我自己的操作方式也都在演進，因此無法把改善完全歸因於模型本身。
因此我不能把觀察寫成：
Grok 4.5 或 GPT-5.6 Sol 在所有 agentic tasks 都必然勝過其他模型。
我能負責任地說的是：
在我的 Hermes + YouTrack + Superpowers + Codex/Grok workflow 裡，Grok 4.5 首次讓 orchestrator 穩定跨過了「可以自己啟動、管理並接回 coding agent」的實用門檻；GPT-5.6 Sol 後來也做到了，而且成為我目前主要使用的 TPM／orchestrator。
在我的觀察樣本裡，這個差異不是少改幾句 ticket，而是原本需要我手動接線的流程，第一次能夠閉合。
—
下一步：不是每個角色都需要最強模型
有趣的是，這次經驗並沒有讓我得到「所有 agent 都用最強模型」的結論。
反而是角色越清楚，越容易看到不同位置需要的能力不同：
- TPM／Orchestrator 需要長程 reasoning、state management、tool judgment 和 error recovery；
- Coding agent 需要 code understanding、implementation discipline 和測試能力；
- Reviewer 需要較不相關的第二視角和找反例的能力；
- Format conversion、資料搬運或固定檢查可能根本不需要旗艦模型。
真正值得花錢的，通常是會讓整條 loop 斷掉的位置。在我的流程裡，那個位置原來不是寫 code 的 agent，而是站在上面、看起來只負責「協調」的 Hermes。
以前我以為 loop engineering 是把 agents 串起來。現在我覺得，它更像是在設計一套能自行觀察、修正、接手失敗，最後把可驗證結果帶回來的工程系統。
而這套系統能不能真的轉起來，有時只差 orchestrator 是否跨過那條能力門檻，老馬跟奧特曼，給你們個讚！