Coding agent 同時開幾個，產出多咗點解收工反而攰過自己寫？

TechNews 科技新報報道，Midjourney 創辦人 David Holz 日前喺 X 話，身邊朋友用新 coding model 後都覺得做多咗嘢，同時攰得好快，跟住問大家有冇方法令每日好受啲。呢個只係佢對身邊人嘅觀察，貼文底下啲回覆亦係個人經驗，未足以代表科技圈。不過，件事點出 agent 工作一個隱形成本：打 code 少咗，個腦就要睇實更多同時跑緊嘅工作。

Agent 慳咗打字，驗收工作就排住隊

自己寫一個功能時，通常由需求、code、測試一路跟到底，腦入面得一套狀態。開三個 agent 後，A 等你拍板設計，B 交咗一堆 diff，C 測試失敗又要你決定繼續修定退返。幾個 agent 可以同時交貨，但開發者未必驗收得切。 每次切畫面都要重新記起需求、假設同風險，developer 變成 dispatcher、reviewer 同最後簽收嗰個，決策密度自然高咗。

Anthropic 2025 年內部研究問咗 132 名工程師同研究員，亦做咗 53 次深入訪談。部分員工話，Claude 幫佢哋做到更多工作，不過之後要執 code、debug，同理解一批自己冇親手寫嘅內容，認知負荷亦跟住上升。樣本只係 Anthropic 自己員工，未能代表所有 developer；但佢帶出一點：就算打 code 嘅時間少咗，理解同判斷輸出一樣要花時間。

圖片：METR

覺得快咗，未必真係早咗交貨

呢種「我今日做到好多」嘅感覺要小心拆開。METR 2025 年隨機對照研究搵咗 16 名熟悉自己 open-source repo 嘅 developer，完成 246 個真實 task。可以用 AI 嗰組平均慢咗 19%，但參加者做完仍估自己快咗 20%。樣本細，工具主要係 2025 年初嘅 Cursor Pro 同 Claude 3.5／3.7 Sonnet，條數唔適合直接套落今日所有工具。METR 喺今年 2 月更新話，新一輪研究受揀選偏差同多 agent 計時問題影響，只能估速度方向有改善，未能可靠計出幅度。diff 同 task 多咗，功能幾時安全 merge 仍要另外計。

頻繁轉 context，一樣會令人好攰

Agent 每交一次結果，你都要跳去另一套 code 同假設。一項早過 coding agent 熱潮嘅軟件開發中斷研究，分析 17 名專業 developer 嘅 4,910 個 task，再問咗 132 人，發現自發轉 task 喺佢哋個樣本入面可以擾亂表現，影響未必細過外來打斷。套用到 multi-agent 只屬合理推論，但個機制幾清楚：每個 agent 慳你一段執行時間，同時新增一次重新載入 context、判斷可信度同決定下一步嘅開支。

Token 同 task queue，會令人一路加速

當畫面擺住 token、用量上限、task queue 同幾個進度提示，停低一陣好容易令人覺得蝕咗產能。Business Insider 引述 Holz 貼文底下嘅個人回覆，有人甚至話休息一個鐘都似損失咗好多產出。呢啲只係個人感受，冇足夠資料落任何醫學判斷，不過佢解釋到點解你可能主動再開一個 task：等待時間睇落似空檔，最後塞滿晒驗收、補 prompt 同追進度。

四個做法，減少個腦做 traffic control

第一，先由一至兩個 agent 開始，每加一個之前，先睇 review queue 清唔清得切、返做次數同 merge conflict 有冇增加。第二，委派同驗收分時段：一次過寫任務，之後揀固定時間收貨；中間關提示，留一段只做單一難題嘅 deep-work。Holz 嗰串討論入面，Claude Code 產品主管 Catherine Wu 分享嘅個人做法亦係集中一個困難 task，同一個 agent 深入做。Codex 官方文件亦建議將平行工作留畀邊界清楚、互相獨立嘅探索、測試同整理，避免多個 agent 一齊改同一批檔案。

第三，每個任務一開始就寫驗收表：目標行為、可改範圍、唔准郁嘅檔案、要跑嘅 test command，同交付風險。測試同清單可以將部分反覆判斷壓成 pass／fail；身份驗證、付款、資料刪除同權限改動仍然要逐段睇。第四，用交付結果決定加唔加 agent，連續兩星期記低由委派到 merge 用咗幾耐、返工次數、漏出 bug 同收工後未驗收嘅數量，唔好用 code 行數或者 token 用量當成績。

公司、產品團隊同 freelancer 都可以由細規模試起。review queue 開始過夜、同一個 task 要反覆返做，或者你成日放低本身工作去救 agent，就代表同時工作量高過自己接得住嘅水平。先減少同時工作數目，再補清楚驗收條件同自動測試；等交付時間、返工同工時穩定咗，先再加下一個 agent。

參考來源

• TechNews 科技新報 — Midjourney 創辦人一問，掀開科技圈「AI 疲勞」共同心聲 — original report
• David Holz 原始 X 貼文 — 核對 Holz 原本只係講身邊朋友嘅感受，冇生產力數據或者具體模型資料
• Business Insider：Midjourney founder says new AI coding tools are leaving his friends more productive — and extremely drained — TechNews 引用嘅直接來源，載有 Catherine Wu 同其他開發者嘅個人回覆
• Anthropic：How AI is transforming work at Anthropic — 內部問卷同訪談顯示，AI 帶來更多產出之餘，亦增加理解、debug 同執 code 嘅負荷
• METR：Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity — 隨機對照研究直接比較自我感覺同實際完成時間，亦交代樣本同工具限制
• METR：We are Changing our Developer Productivity Experiment Design — 交代新一輪研究受揀選偏差同多 agent 計時影響，未能可靠量化 2026 年速度增幅
• Task Interruption in Software Development Projects — 提供開發者自發轉 task、重新載入 context 同工作中斷成本嘅背景
• OpenAI Codex：Subagents — 官方建議先將平行 agent 用喺獨立、偏讀取嘅工作，並提醒同時改 code 會增加衝突同協調成本

本文根據原文及公開資料整理；資料有出入時，以原文及官方資料為準。