代理工程入門｜四十萬次工作階段顯示的「交辦方式」設計

您好，我是TIMEWELL的濱本隆太。

AI已經會寫程式了，為什麼一部分工程師的市場價值反而上升？這個問題，現在有一份研究用資料回答了。

Anthropic在2026年6月16日公開了「Agentic coding and persistent returns to expertise」。從2025年10月到2026年4月，七個月、約23萬5,000人、約四十萬次工作階段，以保護隱私的方式做了分析¹。重點在於，這不是基準測試，而是實際使用資料。

讀完之後，我自己帶著的幾個前提垮掉了。依序寫。

四十萬次工作階段顯示的分工

最清楚的發現在這裡。原文是這樣寫的：

people make about 70% of the planning decisions but only 20% of the execution decisions¹

**人做了約七成的規劃決策，執行決策卻只做了約兩成。**反過來說，怎麼做的約八成，是AI在決定。

這組數字好的地方，是它拆掉了「AI代替人寫程式」這種粗糙的理解。**角色沒有被替換，是按層分開了。**人留下當建築師，AI承擔施工。這種結構不是誰下了命令，是自己長出來的。

工作階段的內容也有公布¹。

用途	占比
撰寫、修改、測試程式碼	約56%（撰寫25%、修改26%）
操作軟體	17%
規劃、探索	14%
分析、撰寫文件	13%

**將近一半不是在寫程式。**這點出乎我意料。

時間序列的變化更有意思。七個月裡，用來除錯的工作階段從33%降到19%，幾乎砍半。另一方面，單次工作階段的估計價值上升了27%。依類型看，建構上升43%、操作上升34%、修改上升32%¹。

可以讀成：從用來修好壞掉東西的工具，轉成用來做出東西的工具。

專業不會消失，而是被放大

我認為這才是最大的發現。

常聽到一種說法：AI普及之後，專門知識就不再需要。這份資料指向相反方向。

所謂驗證過的成功，也就是測試通過、已經commit，帶得走可核對證據的成功，比例是這樣¹。

• 被評為新手的工作階段：15%
• 中級以上：28%到33%

Sessions rated expert reach verified success more than twice as often as those rated novice¹

被評為專家的工作階段，達到驗證成功的頻率是新手的兩倍以上。

產出量更好懂。單次工作階段，新手約600字，專家約3,200字。相差約五倍¹。同一個AI，看起來也用差不多的方式和它說話。

出狀況的時候，差距還會再開。新手4%，專家15%¹。事情走歪之後怎麼把局面拉回來，專業在這裡清楚生效。

為什麼？我認為專業愈深的人，愈能把任務切乾淨，也愈能把成功條件定義對。AI會忠實放大指示的品質。含糊的指示變成含糊的成果，精密的指示變成很大的成果。

而這裡有一件重要的事：**那份專業，不必是軟體工程的經歷。**依職種看，驗證成功率在軟體相關職是30%，其他職種是26%¹。

Every one of the ten largest occupations in our dataset lands within seven points of software engineers¹

資料集裡人數最多的十個職種，全部落在軟體工程師上下七個百分點以內。真正生效的不是會不會寫程式，而是對自己領域知道得夠深。

想先盤點自家的AI運用走到哪一階段，後面的數字讀起來會比較像自己的事。

該量的是「能交出去多久」

一講模型比較，就容易變成基準測試的分數。實務上想知道的是另一件事。

AI安全研究機構METR把問題這樣問：「人類專家要花幾小時的任務，能以多高的成功率做完？」他們稱之為任務視野（task horizon）。「50%任務視野是一小時」，意思是：人要花一小時的任務，它有50%的機率能做完²。

METR用約230個任務來量。結果如下²。

模型	50%任務視野
GPT-2	2秒
Claude 3.7 Sonnet	50分鐘
o3	約2小時
Opus 4.6	約12小時

從2019年的4秒，到2026年超過16小時。長期平均大約每七個月倍增一次²。

不過，這裡有比我當初當作素材的資料更新的事。最近這段在加速。2024年到2025年是大約每四個月倍增，若這個速度持續，推估2027年會碰到一個月尺度的任務²。

這個指標好的地方，是它把問題換了問法。不是「這個AI會不會寫程式」，而是**「多大的一塊，可以中間不盯著就交出去」**。

而且，**設計交辦方式這項本事的價值，會用複利往上長。**今天就算只能交出三小時的量，倍增若持續，明年就是九小時，再往後是以日為單位。**設計的本事可以停在原地，能託付給代理的工作量自己會變大。**我認為現在該把這項能力學起來，理由就在這裡。

長任務失敗，往往不是模型的錯

那是不是把塊切大一點就好？沒那麼單純。

Anthropic做過一個實驗：讓模型跨過多個上下文視窗，去做可上線水準的網頁應用，並且把失敗公開了³。

先說一個詞。上下文視窗是AI一次能保住的資訊上限。對話和程式碼超過這個上限，舊的就會從前面掉出去。長作業一定會撞上，所以工作會被切成好幾個工作階段。

結果，就算是最前線的模型，系統還是垮了。**原因不是模型的智力，是環境設計。**垮法有兩種。

**一次想做完全部。**想在單一個工作階段裡把整件任務收掉，做到一半氣力用盡。

**記憶斷掉。**新工作階段裡的代理，對上次發生過什麼一無所知。每一次都從零開始。

這等於輪班制的團隊完全沒有交接，每一班都是新人帶著白紙來上班。

解法普通到讓人愣一下。就是讓它做人類團隊早就在做的事³。

負責初始化的代理先理解整件任務，再依功能拆開。負責寫程式的代理一次只做一個功能，跑測試、commit、更新進度檔。下一個工作階段先讀進度檔，再接著做。

說穿了，就是把記憶放在代理腦袋外面。git紀錄、進度備註、測試結果。上下文換了，這些也不會消失。代理不必全部記住，只要能從寫下來的東西把狀態還原就夠了。

能跑起來的系統，差在三個原則

這次實驗做出來的harness（圍繞代理的鷹架與控制環境），核心想法不綁特定模型或工具。

原則1。預設為未通過。

所有成功標準一開始都設成「尚未達成」。代理自己宣布「做完了」，不能算完成。必須有證據證明它真的達成。

沒有這一層，代理會給自己的作業打分數，而且永遠打滿分。「測試通過了（其實沒跑）」會變成日常。用結構把過度自信堵住，是這個想法。

原則2。把評分的人格分開。

過不過的判定，交給另一個、帶著全新脈絡、不是動手做那一個的評分角色。這個評分角色不能改東西。它能做的只有回傳通過或失敗，以及理由。

和人類團隊裡，寫程式的本人不負責審查自己寫的程式，是同一套道理。寫的人離成果太近，看不見缺陷。

Anthropic的文章在這一點上用詞很重。沒有評分角色的harness，會在最前線模型產出平庸結果時，安靜地失敗³。因為沒有報錯，所以察覺不到。這點很可怕。

原則3。讓它自己寫交接備註。

每次commit都更新進度檔。做了什麼、還剩什麼、下一班該知道什麼。單是這個習慣，就能把每次歸零的系統，變成會往上疊的系統。

讓代理讀什麼、讀完的結果交給誰，這類管控的設計，我也寫在Cloudflare OS為什麼開源。權限從零開始，讀過的東西留下紀錄。想法指向同一個方向。

不過，不是什麼都該做成代理

反方向的發現也放在這裡。

名為「Agentless」的研究顯示，不用自主代理，只靠找出問題位置、修改、驗證修補，這三步管線，就能以低成本拿到很高的成果⁴。

該學的不是「代理一定比較好」。而是複雜度要對上任務。單純的問題，單純的機制會贏；又複雜、又拉得很長的問題，複雜的代理才划得來。

而**自己現在站在哪一邊，這件事本身就佔了能力的大半。**打一根釘子，不必先組一隻機械手臂。

另一方面，也有研究把環境的重要性撐起來。普林斯頓大學的SWE-agent指出，模型是一種新型的電腦使用者，需要為它專門設計的介面。不要把給人用的編輯器原封不動丟給它，而是給它依代理動作方式最佳化過的工具，結果是模型本身沒改，表現卻上去了⁵。

harness不是模型的配件，而是系統的一半。

從哪裡開始

寫長了，收一下。

人決定規劃的七成，AI決定執行的八成。專業不會變得沒價值，它會以產出五倍的差距出現。能交出去的任務長度持續倍增，最近是四個月倍增一次。拉開差距的不是模型，是放在它周圍的環境。

實務上，我認為順序是這樣。

第一。交出一個會完結的小任務，然後看。不是「寫一個函式」，而是「修好這個bug，寫測試證明它修好了，兩邊都commit」。用有起點、有中段、有終點的單位交出去。再看指示和成果在哪裡偏掉。

**第二。解釋過兩次以上的規範，寫進檔案。**技術堆疊、不能碰的地方、測試怎麼寫、commit的慣例。寫一次，之後每次都會被讀到。重複說明的時間會消失。

**第三。導入進度檔，同一件任務跑兩次。**有交接和沒有交接，比較第二次開頭會發生什麼。外部記憶的效果，沒親身感覺過，不容易信。

**第四。把評分角色分開。**沒有寫入權限，也不知道作業歷程。工作只有讀成果、回傳通過或失敗，以及理由。校正很單純：**拿一件你明知會失敗的任務、一件你明知會成功的任務，兩邊都跑。**前者打掉、後者放行，就可以信。

把程式碼庫當成結構來持有的事，寫在圖工程是什麼。Claude Code的具體功能，整理在Claude Code完整指南。

老實說，這份研究最讓我受到鼓勵的，是職種這一段。人數最多的十個職種，全部落在軟體工程師上下七個百分點以內。生效的不是會不會寫程式，而是對自己的工作知道得夠深。

會計資深把月底結帳交出去的時候，業務王牌把提案書交出去的時候，分出高下的是同一組三個原則。**用證據確認。換一雙眼睛看。留下能交接的形狀。**代理工程，我不認為只是工程師的事。

若想討論AI運用的設計，或是公司內部該如何建立交辦機制，WARP的想法或許可以參考。個別諮詢請從這裡聯繫。

---

Footnotes

1. Anthropic「Agentic coding and persistent returns to expertise」（Zoe Hitzig、Maxim Massenkoff、Eva Lyubich、Shaoyi Zhang、Ryan Heller、Peter McCrory，2026年6月16日公開）。以保護隱私的方式，分析2025年10月至2026年4月、約23萬5,000人所產生的約四十萬次對話工作階段。「people make about 70% of the planning decisions but only 20% of the execution decisions」、工作階段內容占比（撰寫、修改、測試程式碼約56%（撰寫25%、修改26%）、操作軟體17%、規劃與探索14%、分析與撰寫文件13%）、除錯工作階段占比從33%降到19%、單次工作階段估計價值上升27%且依類型為建構43%、操作34%、修改32%、驗證成功率在新手評價為15%、中級以上為28%到33%、「Sessions rated expert reach verified success more than twice as often as those rated novice」、出狀況時的成功率新手4%、專家15%、單次工作階段產出新手約600字、專家約3,200字、依職種的驗證成功率在軟體相關職30%、其他職種26%，以及「Every one of the ten largest occupations in our dataset lands within seven points of software engineers」，皆出自該研究。https://www.anthropic.com/research/claude-code-expertise ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰

2. METR「Measuring AI Ability to Complete Long Software Tasks」及相關更新。任務視野的定義是：就代理能以特定成功率解出的任務，換算成人類專家所需的時間。以約230個任務（多半是寫程式，一部分是一般推理）測量，50%任務視野從2019年的4秒延伸到2026年超過16小時，長期約每七個月倍增一次。不過2024年到2025年變成約每四個月倍增，若這個速度持續，推估2027年可達到一個月尺度的任務。依模型看，GPT-2為2秒、Claude 3.7 Sonnet為50分鐘、o3約2小時、Opus 4.6約12小時。https://metr.org/blog/2025-03-19-measuring-ai-ability-to-complete-long-tasks/ ／ https://theaidigest.org/time-horizons ↩ ↩² ↩³ ↩⁴

3. Anthropic「Effective harnesses for long-running agents」（工程部落格）。代理必須在沒有記憶的離散工作階段裡作業，上下文視窗有限，複雜專案無法在單一視窗完成；第一次執行時負責把環境備好的初始化代理，以及在各工作階段漸進做出進度、為下一個工作階段留下清楚成果的寫程式代理，這樣的組成；以及沒有評分代理的harness，會在最前線模型產出平庸結果時安靜地失敗，以上皆出自該文。https://anthropic.com/engineering/effective-harnesses-for-long-running-agents ↩ ↩² ↩³

4. Xia et al.「Agentless」（arXiv:2407.01489）。不使用自主代理，只靠找出問題位置、修改、驗證修補這三階段管線，就能以低成本拿到高成果的研究。https://arxiv.org/abs/2407.01489 ↩

5. Yang et al.「SWE-agent」（arXiv:2405.15793）。普林斯頓大學研究團隊的論文。指出AI模型是一種新型的電腦使用者，需要為它專門設計的介面；給代理依其動作方式最佳化過的工具，不必改模型本身，表現就會上升。https://arxiv.org/abs/2405.15793 ↩