跳至主要内容

為什麼公司推不動 Agentic AI:不是技術問題,是四道組織的牆

過去一年,我在工作中把 agentic AI 用進實際開發流程,也在 COSCUP 分享過這個題目。從技術社群往外看,agentic AI 是下一波生產力革命;但從公司內部往裡看,大多數導入會卡住——而且卡住的地方,幾乎都不在技術。

真正讓一個「用 AI agent 取代某個模組開發」的提案推不下去的,是幾件很人性的事:管理層覺得不好管、出事的時候權責不清、同事擔心自己被取代;而就算真的上線了,還有一道更少人談、卻更貼近工程現場的牆——agent 會拆解一個人的角色,把責任悄悄搬到 code review 這個沒人準備好的位置。這幾件事,我都親眼看過,而學界其實也早就把它們寫成了論文。

第一道牆:管理層覺得「不好管」​

當你提議讓一個 agent 自主接手某段開發工作,主管第一個反應通常不是「準不準」,而是「這東西我要怎麼控制」。

這不是保守,是合理的直覺。傳統程式壞了,我有 log、有 stack trace、有測試可以定位問題;但 agent 的推理過程是個黑箱,它做了錯誤決定,你常常說不清楚是哪一步壞掉。一個無法被觀測、無法被除錯的系統,對任何要為結果負責的主管來說,就是一個不敢放進正式流程的系統。

這正是學界點出的核心障礙之一。一份 2026 年針對軟體工程實務的訪談研究(16 位受訪者、12 家公司)就發現 [1],這些公司卡在一個「能力—部署驗證落差」:有能力做出實驗性的高階 AI,卻因為缺乏足夠的產出驗證機制而無法放進生產流程,最後只能靠人來把關。這個落差背後有四個反覆出現的障礙:LLM 的 context window 限制、在專有語言與協定上表現不佳、非決定性與品質標準不相容,以及資料機密性顧慮。換句話說,管理層的猶豫不是情緒,是對一個「行為無法預測、產出無法驗證」系統的正常風險反應。而另一份橫跨工程與製造業、30 多場訪談的研究更點出 [10]:阻礙導入的往往不是模型能力本身,而是破碎的資料、嚴格的資安與法規要求,以及缺乏 API 介面的老舊工具鏈——治理結構還沒跟上 agent 的能力。

第二道牆:出事的時候,沒人知道該誰負責​

這是所有牆裡最致命的一道,產業與治理討論甚至給了它一個固定名字:accountability gap(問責落差)——IBM 就以此為題 [13],點出企業面對 agent 時,常缺乏監控行為、審查自動化決策、以及在系統造成損害時歸屬責任的能力。

一個 agent 可以被部署、被監控、甚至被稽核,但這些都無法回答一個最基本的問題:當它做錯事、造成損失時,誰要負責?當責任是隱性、而非明確指派給某個人時,治理就會失效。NIST 的 AI 風險管理框架相關討論因此主張 [14]:在 agent 被允許行動之前,就必須指派一個具名的業務與技術負責人。

世界經濟論壇講得更直白 [15]:AI agent 缺乏一般員工天生具備的法律問責、道德責任與聲譽誘因,後果不會自然落到誰頭上,治理必須主動去補這個缺口。

其實經濟學早就給了這個困境一個精準的名字,而且是個絕妙的雙關:principal-agent problem(委託代理問題)。這套理論講的是——你(principal)委託一個 agent 替你做事,但你面對兩個先天障礙:一是你無法完全觀察它到底做了什麼(資訊不對稱),二是它的目標未必和你一致。經濟學給的傳統解法是誘因契約:用獎金、考績、聲譽把 agent 的利益綁到你的利益上,讓它「為了自己好」也會把事情做對。

問題來了。AI agent 恰好也叫 agent,但它把這整套機制的兩根支柱同時抽掉了:它的推理是黑箱,你無法觀察(這正是第一道牆);它沒有自身利益、沒有考績也沒有聲譽,你無法用誘因約束。於是管理層那股說不清的不安,有了教科書級的名字——你請了一個 agent,卻既監督不了它、也沒有任何契約能綁住它。 這不是新問題,是一個經典經濟學難題,被 AI 推到了極端。而所謂「指派具名負責人」,本質上就是把一個無法被誘因約束的 agent,重新掛回一個可以被誘因約束的人身上——讓那套失效的契約機制,透過人重新接地。

我自己的體會是:人願意為自己的判斷負責,是因為他跑不掉——會被檢討、會影響考績、會有職涯後果。agent 沒有這些。所以當一段流程從「某個工程師負責」變成「某個 agent 負責」,責任其實不是轉移了,而是憑空蒸發了。這才是主管真正害怕的東西。

而且更麻煩的是:就算你想指派一個負責人,你會發現責任根本不是一個「點」,而是一條「鏈」。寫這個 agent 的人、review 它產出的人、按下 merge 的人、設定那些自動檢查規則的人——每一關都碰過那段程式碼。出事時,每個人都能合理地說「不全是我」。這在應用倫理學裡有個既有的名字叫「眾手問題(problem of many hands)」:當一個結果是由許多人共同促成時,反而變得沒有任何單一個人能被清楚地究責。

這裡要先擋掉一個很常見的誤解:有人會說,那我讓另一個 agent 去審這個 agent 的產出不就好了?——確實,業界的 loop 實作裡,「找錯」這個動作(verification)已經常常交給第二個 agent 當 reviewer。但這不但沒有解決問責問題,反而更清楚地印證了它。因為即使在那些高度自動化的實作裡,最後按下 merge 的仍然是人。換句話說:agent 可以自動化『找錯』,但不能自動化『放行負責』。 verifier 是 causal 那一側,可以層層外包給 agent;accountability 是對外負責那一側,它不會消失,只會被推到那個「決定要不要相信這層 agent review」的人身上。你多疊幾層 agent review,問責的錨點不會消失,只會往上移一格,最後還是停在一個人身上。

我覺得對這件事必須誠實:沒有一個乾淨的正確答案,任何說「就該是某某人」的說法都是在簡化。 但它可以被拆解。關鍵是先分開兩種常被混為一談的責任:一種是 causal responsibility(誰的疏漏造成了 bug),這往往是多因、要事後查;另一種是 accountability(誰對外負責),這是制度事先指派的,不該等出事才吵。組織的痛苦多半來自:他們以為在找前者(誰的錯),但真正缺的是後者(誰負責)——而後者本來就不必等於犯錯的那個人。就像飛安,機長對整架飛機負責,不代表每顆螺絲都是他鎖的。

務實的做法不是選出「唯一該負責的人」,而是讓那條鏈上每一關對自己那關的決定負責:設計 agent 與自動檢查的人,負責「能力邊界」——這個 agent 被授權做什麼、檢查涵蓋什麼,合不合理;review 的人,負責「當次判斷」——在他看到的資訊範圍內,這個變更該不該過;按 merge 的人,負責「放行決定」——那道最終的閘。這比硬指定一個總負責人更公平,也更能稽核。而這也正是為什麼「merge 權專屬人類 + 不可竄改的稽核日誌」如此關鍵:與其事後吵誰的錯,不如事前讓每個決定都留下具名軌跡。出事時不是靠吵,是靠翻 log 往上追每一層。

值得補一句:飛機有機長,但 agent 的 pipeline 天生沒有——它缺的正是那個「對整體放行負責」的角色。所以 merge authority 不是本來就存在、我們去指定的,而是我們刻意造出來的機長。這也點出為什麼「讓 agent 全自動 merge」在責任上這麼危險:那等於是一架沒有機長的飛機。順帶一提,這條鏈上最難追的其實是「沒人設那道該有的檢查」——因為缺席的東西不會報錯,你甚至不會發現少了什麼;修法一樣是分層:把必要檢查設成組織層級強制、任何略過都留下具名軌跡,讓「這裡沒有檢查」從無人負責的真空,變回一個有人具名的決定。

第三道牆:同事擔心被取代​

技術面談完、治理面談完,最後這道牆最安靜,卻最難拆。

當你要求團隊「用 AI 來分擔一部分工作」,你以為你在講效率,但第一線工程師聽到的,可能是組織正準備取代這個角色的訊號。這種感受會轉成沉默的抵抗——表面配合,實際上繞過它、把它當花瓶,採用率自然上不去。

這在組織行為領域有大量實證。被引用最多的 STARA awareness 框架發現 [2]:員工對「智慧科技、AI、機器人、自動化」的覺察程度越高,與越低的組織承諾、職涯滿意度,以及越高的離職意圖相關。更值得高層注意的是,一份系統性回顧指出 [3],這些負面態度往往不只是怕失業,而是感受到專業身分認同受到威脅——AI 打亂的不只是任務,還有那份賦予工作意義的心理契約。

而且這裡有個很反諷、卻天天在發生的機制:當你「請」一位資深工程師去訓練或校準那個要接手他工作的 agent,你等於在要求他親手加速自己的邊緣化。他心裡很清楚這件事,於是抵抗會用最難察覺的方式呈現——不是拒絕,而是「配合但不投入」:給的訓練資料淺一層、發現 agent 的錯不主動回報、把最關鍵的隱性知識留在自己腦袋裡不寫進 skill。你看到的是採用率上不去,實際發生的是最該被數位化的那批專業判斷,被沉默地扣住了。

對工程師這種身分認同特別強的職業,這一點會被放大。你動的不是他的工時,是他之所以是他的那個東西。這也是為什麼第三道牆不能用「溝通」或「加薪」硬拆——它要的是讓工程師在這場轉變裡贏得新位置,而不只是被安撫。這一點會直接連到後面的解方:讓他從「被 agent 取代的人」變成「定義 agent 邊界的人」。

不過有一件事主管很容易誤判:員工不是鐵板一塊的「集體抗拒」。事實上團隊內部本來就分派——這不是新現象,Rogers 的創新擴散理論早在 1962 年就把採用者分成創新者、早期採用者、早期大眾、晚期大眾與落後者 [18]。近期一份針對開發者使用 AI 工具的實證研究更把工程師分成三群 [19]:熱衷者、務實者、謹慎者,他們在使用廣度、對生產力與品質的感受、以及未來採用意願上都明顯不同。換句話說,你的團隊裡同時有改革派和保守派,而 agent 不會抹平這條裂縫,只會讓它浮現、甚至加深。

這對高層其實是個槓桿,而不是麻煩。真正的錯誤是把力氣全花在「安撫保守派」;更有效的做法是先識別並賦權改革派——他們往往是團隊裡的意見領袖,由他們示範、由同儕之間橫向擴散,說服力遠高於主管由上而下強推。務實者會在看到成功證據與組織支持後才跟進,謹慎者則需要更多時間與保證。你要做的不是要求所有人同一天上車,而是讓改革派先跑、把路跑出來給其他人看。

第四道牆:當 agent 拆解你的角色,誰在 approve 那個 PR?​

前三道牆講的是「要不要用」,但真正上線之後,還有一道更細、也更少人談的牆:agent 不是乾淨俐落地取代一個人,而是把一個角色拆開再重組——而這個重組,會悄悄地把責任搬到一個沒人準備好的位置。

學界對這件事的描述比我原本想的精準。有研究主張 [4],把 AI 的影響簡化成「取代 vs 增強」是不夠的;真正發生的是「任務串接(chaining)」:AI 一方面把原本人工的步驟拉進單一任務裡,縮小需要人直接處理的範圍、在角色內部移轉責任;另一方面降低跨越工作邊界的成本,讓「重畫那條邊界、把活動在角色之間重新分配」變得合理。也有研究把一個職位拆解成執行、搜尋、協調、判斷、當責幾種成分 [5],主張 agent 接走前段(執行、搜尋、草稿),而人應該保留脈絡、判斷與當責。兩種講法指向同一件事:一個工程師的工作被拆開,agent 接走了前面幾塊——但「當責」這一塊,沒有跟著消失,它只是被擠到流程的下游。

那它被擠到哪裡了?Code review。

這是我自己這一年最深的體會,而學界剛好給了佐證。當 agent 大量生成程式碼,瓶頸就從「寫程式碼」移到「審查 AI 生成的程式碼」——而且每一個 AI 建議都得帶著懷疑去讀,直到被證明正確。有研究把這稱為「監督負擔(oversight burden)」[8],並指出它是 AI 導入軟體工程最常被低估的隱藏成本,有時消耗的力氣比省下的還多。

更關鍵的是責任的落點。一篇探討 AI 時代 code review 未來的問卷研究(100 位開發者、5 家公司)指出 [6],開發者普遍預期 code review 不會消失,反而會投入相同或更多心力、審查更廣的產出;而幾乎所有人都預期 LLM 會成為 review 過程的主動參與者。順著這個趨勢,另一篇提出 agentic code review 架構的論文(Kamalı 等,2026)描繪了一個未來 [7]:reviewer 會從「親手檢查的人」轉變成「監督一群 agent 的操作者」。把這兩篇放在一起看,方向很清楚——review 這件事不會被 agent 取代,而是被推到更上層:人不再逐行看,而是負責監督那些替他看的 agent。

把這件事翻成白話給高層聽:當 agent 寫的模組出事,責任不會停在 agent 身上,它會一路往下滑,停在按下 approve 的那個 reviewer 手上。 這代表兩件事——第一,code review 從一個「衛生習慣」升級成整條流程的責任錨點,它比 agent 沒上線前更重要,不是更不重要;第二,如果公司沒有想清楚這件事,等於是在讓某個工程師默默承擔一個他可能根本沒能力完整審查的 AI 產出的全部後果。這對那個 reviewer 不公平,對公司也是沒有設防的風險。

這不只是理論。Stripe 公開了一個很有代表性的案例 [17]:它的內部自主編碼 agent(代號 Minions)每週產出超過 1,300 個「零人類手寫程式碼」的 PR,但每一個仍然由人類 review 後才 merge——人沒有離開流程,只是座位變了:從寫 code 的人,變成 review code 的人。更值得玩味的是,那個案例裡有一個反直覺的重點:讓它能規模化的關鍵幾乎與模型強弱無關,而是 Stripe 多年前為「人」打造的開發基礎設施——沙箱化的 devbox、完整測試套件、CI 與確定性檢查關卡。用他們工程師的話說,如果你的開發環境、測試基礎、回饋迴圈夠紮實,agent 才享受得到;不夠紮實,再強的模型也救不了。這背後的教訓,對高層特別重要——對 loop 化的工作來說,一道紮實的驗證關卡,比單純堆更強的模型更關鍵。 換句話說,決定這件事能不能規模化的,不是 AI 多聰明,而是你的責任關卡設計得多好。

這裡還藏著另一個經濟學機制,主管必須看懂:moral hazard(道德風險)。它講的是——當一個人不必承擔自己行為的後果時,他就會不知不覺地承擔過多風險、或怠於盡責。把 agent 產出全自動 merge、或讓 review 淪為橡皮圖章,就是教科書級的道德風險溫床:當按下 approve 的人心裡清楚「反正責任分散、出事也查不到我頭上」,他審查的誠實程度就會系統性地下滑——不是因為他壞,而是因為誘因結構默許他鬆懈。這正是「責任蒸發」在組織層面的真實後果:問責一旦被稀釋,監督品質就會跟著滑落。 反過來說,這也說明了為什麼「具名 + 不可竄改的稽核軌跡」不是官僚繁文,而是修復誘因——它把後果重新綁回做決定的那個人身上,讓他有理由認真審。

而 moral hazard 還有一個更上游、也更常被主管親手製造的版本:把「用 AI 加速」直接變成考績 KPI。 立意通常是好的——主管想推動採用,於是獎勵「AI 建議接受率」「PR 數」「交付速度」這類看得見的數字。但這會踩進經濟學裡的 Goodhart's law:當一個衡量指標變成考核目標,它就不再是好的衡量指標。有評論講得很白 [16]:如果把「AI 建議接受率」設成 KPI,你等於在獎勵工程師盲目接受低品質的 AI 程式碼——實質上是在衡量他願不願意關掉批判性思考。求快的指標,反而系統性地製造了求快的疏漏。

而這股「由上而下的誘因扭曲」還有一個更難啟齒的極端:有時主管急著推 agent,真正的動機不是效率,而是繞過人。一個對現有團隊失望、或早就受夠某些難管資深工程師的主管,可能把 agent 當成「終於可以不必靠這些人」的解方——與其修復一個他覺得修不動的團隊,不如引入一個外部力量來重整他管不動的秩序。這比基層的消極抵抗更危險,因為它來自握有決策權的那一端,會悄悄把 agent 從「協助團隊的工具」變成「取代團隊的藉口」。所以在設計任何 KPI 或導入計畫之前,高層值得先對自己誠實地問一句:我推這個 agent,是為了讓團隊更強,還是為了不必再面對這個團隊?

而這裡有個沒有免費午餐的兩難:有論文指出 [9],「什麼都審」會造成速度崩潰,審查成本吃掉 agent 帶來的全部生產力;「什麼都不審」則造成不可稽核、不合規的程式碼。所以答案不是二選一,而是依風險分級的人類監督——高風險的變更綁緊人審與具名責任,低風險的才放手。這也剛好呼應了前面三道牆:可觀測、具名負責、把人放回迴圈裡。

一條被 agent 放大的舊斷層:Security 對上 RD​

還有一條伏線值得點一下。前面第二道牆講的分層負責、能力邊界、強制 gate——這些其實全都落在一條公司裡由來已久的斷層線上:security 要關卡與管控,RD 要速度與自主。這個對立在學界有實證記錄:一篇 DevSecOps 系統性回顧發現 [11],「人」的最大挑戰就是開發與安全團隊的衝突,開發者覺得被評判、被剝奪自主權;另一篇則點出根源是目標函數不同 [12]——RD 要盡快上生產,security 要徹底評估,兩邊都在做「對」的事,只是定義不同。所以這是結構性對立,不是溝通問題。

而 agent 讓這條斷層線的位置變了。過去 security 擋的是「RD 有把握的 code」,所以 RD 覺得被找碴;但現在雙方要一起面對「連 RD 自己都沒把握的 AI 產出」。這是 RD 第一次和 security 有了同一個敵人——那道 gate 從「管制 RD」變成「保護 RD」,保護那個否則要獨自扛下 AI 產出後果的工程師。這也是為什麼我下面的解方能成立:它們表面上是 security 的要求,實際上是在替 RD 分攤責任。誰能讓團隊看懂這個轉變,誰就能把最深的一道阻力轉成推力。

那該怎麼辦?——四個抓手,而非答案​

我不打算假裝有完整解方,但這一年下來,我認為值得往這四個方向想:

第一,先讓 agent 可被觀測,再談自主。 具體的門檻是:agent 做的每一個動作——呼叫了哪個工具、改了哪個檔案、根據什麼決定——都要能對到一行可追溯的 log,就像你除傳統 bug 時翻的那種。這裡要誠實:可追溯不等於可理解,一行 log 告訴你 agent 做了什麼,不保證你懂它為什麼那樣決定——推理黑箱短期內不會消失。但這正是重點:既然你無法完全看穿它的「想法」,你至少要能完整重建它的「行為」。做不到這件事之前,別談自主。人類審核關卡在這階段不是自主性的敵人,而是讓 agent 有機會被接受的入場券。先求追得回,再求放得開。

第二,把「分層具名」當成部署的前置條件,而不是事後補件。 別再問「到底誰才是那個唯一該負責的人」——沒有這個人。要做的是讓鏈上每一關的決定都具名、都留痕:誰授權了這個 agent、誰 approve、誰 merge、當時通過了哪些檢查。問責落差不是技術能補的,是制度要先把責任分層設計好的。出事時你要能翻 log 往上追,而不是圍在會議室裡吵。

第三,讓工程師親手寫下 agent 的能力邊界清單。 「讓員工參與」講起來像口號,落地的抓手是一份具體的東西:讓原本做這塊的工程師,親手定義這個 agent 的 allowlist / denylist——它能碰哪些檔案、能呼叫哪些 API、哪些操作一定要人審。這不是我憑空想的格式;業界實作 loop 時,已經有人把這寫成 agent 設定檔裡一個固定的「Stop 區段」,白紙黑字列著「絕不 merge、絕不刪除、絕不 push 到 main、不確定的一律丟給人看」——而且他們的經驗是:你沒寫進去的紅線,總有一天 agent 會替你踩過去。這剛好接回第二道牆的分層負責:原本做這塊的工程師,本來就是最有資格定義「能力邊界」那一層的人。於是他的角色從「寫 code 的人」升級成「定義 agent 該怎麼寫 code 的人」——這不是安慰,是真的職能升級。抵抗會鬆動,不是因為他被邀請開會發言,而是因為他手上真的握有一份能喊停的規則。

第四,把 code review 當成責任錨點,並用一條清楚的線分級。 承認一件事:當 agent 拆解了角色,按下 approve 的那個人就是責任落地的地方。與其讓它默默發生,不如明講,而且把「風險」講具體:碰生產資料、動到權限或安全邏輯、改對外介面的變更,一律綁具名 reviewer 人審;純內部工具、測試、文件這類的才自動放行。線畫在哪可以再議,但一定要有一條明文的線,而不是靠感覺。並且全程保留可稽核的決策軌跡。這不是拖慢 AI,而是讓速度不會繞過責任。

正本清源:這些牆,其實都不是 agent 蓋的​

寫到這裡,我想退一步,把一件最容易被誤會的事講清楚,免得這篇文章被讀成「所以 agent 是麻煩製造者」。

回頭看這五道關卡——管理層覺得不好管、出事沒人負責、員工怕被取代、角色被拆解重組、security 對上 RD——沒有任何一個是 agent 發明的。

管理層一直都不擅長管理他們看不透的東西,只是過去那個黑箱是「某個資深工程師腦袋裡的默契」,現在換成了模型的推理。責任歸屬一直都是一團「眾手問題」,只是過去靠隱性默契勉強運轉(「這 module 是你的」),沒人逼你把它明文化。被取代的焦慮,從工業革命到 ERP 導入到外包,每一波技術浪潮都出現過。角色與 R&R 的邊界,本來就會隨著工具改變而重畫。而 security 和 RD 的目標衝突,在 DevSecOps 這個詞出現之前就存在了幾十年。

換句話說,agent 不是這些病的病因,它是顯影劑。 它真正做的,是把公司平常靠人與人之間的默契、資歷、模糊地帶勉強糊住的那些裂縫,一次性地、無情地照亮。一個治理健康的組織,導入 agent 會照出幾道細紋;一個本來就靠默契在硬撐的組織,導入 agent 會照出一整面裂牆。

這對高層其實是個好消息,而不是壞消息。因為它意味著:你為了讓 agent 能安全運作而被迫做的每一件事——把責任分層講明、把紅線寫成清單、把檢查設成強制、把 security 和 RD 拉到同一張桌子——沒有一件是只對 agent 有用的。 它們是你的組織本來就該有、卻一直沒動力去做的基本功。agent 只是終於給了你一個非做不可的理由。

所以真正的問題,從來不是「我們要不要用 agent」,而是那個更難、也更值得的問題:我們願不願意藉這個機會,把那些一直被默契掩蓋的洞,一個一個補起來。

Agentic AI 沒推動,很多時候不是因為它不夠強,而是因為它照出了公司在治理、權責、人心與角色分工上本來就存在的空洞。技術會繼續進步——但這幾道牆從來都不是 agent 蓋的,也只有組織自己能拆。

參考資料​

學術論文(同儕審查 / 預印本)

  1. Apostolou, S. A., Bosch, J., & Holmström Olsson, H. (2026). Agentic AI in Industry: Adoption Level and Deployment Barriers. arXiv:2605.14675. https://arxiv.org/abs/2605.14675 — 對 12 家公司 16 位實務者的訪談研究,提出「能力—部署驗證落差」,四個障礙為:LLM context window 限制、專有語言/協定表現不佳、非決定性、資料機密性。(對應第一道牆)

  2. Brougham, D., & Haar, J. (2018). Smart Technology, Artificial Intelligence, Robotics, and Algorithms (STARA): Employees' perceptions of our future workplace. Journal of Management & Organization, 24(2), 239–257. https://doi.org/10.1017/jmo.2016.55 — STARA awareness 原始論文。實證發現對智慧科技/AI/自動化的覺察程度越高,與越低的組織承諾、職涯滿意度,越高的離職意圖、犬儒與憂鬱相關。(對應第三道牆)

  3. Bankins, S., Ocampo, A. C., Marrone, M., Restubog, S. L. D., & Woo, S. E. (2024). A multilevel review of artificial intelligence in organizations: Implications for organizational behavior research and practice. Journal of Organizational Behavior. https://doi.org/10.1002/job.2735 — 多層次系統性回顧。指出害怕 AI 的員工常擔憂被取代、技能與職涯受損,導致投入、承諾與安全感下降,並增加抗拒與離職。(對應第三道牆)

  4. Chaining Tasks, Redefining Work: A Theory of AI Automation. (2026). arXiv:2606.15960. https://arxiv.org/abs/2606.15960 — 主張「取代 vs 增強」二分法不足,AI 透過任務串接(chaining)在角色內部移轉責任、並使工作邊界被重新劃分。(對應第四道牆:角色拆解)

  5. The Integrator Advantage: Controlled Agentic AI for Small and Medium-Sized Companies. (2026). arXiv:2606.16649. https://arxiv.org/abs/2606.16649 — 將角色拆解為執行、搜尋、協調、判斷、當責等成分,主張 agent 接手前段、人保留脈絡與責任;正確問題是「哪些人力時間能被放大」而非「誰被取代」。(對應第四道牆)

  6. Dorner, M., Bauer, A., Šmite, D., Thode, L., Mendez, D., Britto, R., Lukasczyk, S., Zabardast, E., & Kormann, M. (2025). Quo Vadis, Code Review? Exploring the Future of Code Review. arXiv:2508.06879. https://arxiv.org/abs/2508.06879 — 100 位開發者、5 家公司的問卷研究。開發者預期 code review 不會消失,反而投入相同或更多心力、審查更廣的產出,且幾乎都預期 LLM 成為 review 的主動參與者。(對應第四道牆)

  7. Kamalı, H. Ö., Tuna, E., Haratian, V., & Tüzün, E. (2026). Rethinking Code Review in the Age of AI: A Vision for Agentic Code Review. arXiv:2605.17548. https://arxiv.org/abs/2605.17548 — 願景論文,主張 reviewer 從「親手檢查者」轉為「agent 的監督操作者」,並提出跨階段攜帶 context 的框架。(對應第四道牆)

  8. Garousi, V. (2026). Human Oversight and Overload: Two Hidden and Costly Burdens of AI-Assisted Software Engineering. arXiv:2606.05770. https://arxiv.org/abs/2606.05770 — 提出兩個被低估的負擔:對 AI 產出的持續人類監督需求,以及 AI 建議洪流造成的認知過載。(對應第四道牆)

  9. Governed AI-Assisted Engineering: Graduated Human Oversight for Agentic Code Generation in Regulated Domains. (2026). arXiv:2606.22484. https://arxiv.org/abs/2606.22484 — 提出 GAIE 框架與 Oversight Classification Model(OCM),依法規影響、客戶接近度、可逆性、資料敏感度把任務路由到三種監督層級(human-in-the-loop / human-over-the-loop / automated-with-monitoring)。(對應第四道牆與解方)

  10. Agentic AI in Engineering and Manufacturing: Industry Perspectives on Utility, Adoption, Challenges, and Opportunities. (2026). arXiv:2604.09633. https://arxiv.org/abs/2604.09633 — 30+ 場訪談的探索性研究,指出導入障礙主要不是模型能力,而是破碎資料、資安法規要求、缺 API 的老舊工具鏈,以及跟不上的治理結構。(對應第一道牆)

  11. Rajapakse, R. N., Zahedi, M., Babar, M. A., & Shen, H. (2021). Challenges and Solutions When Adopting DevSecOps: A Systematic Review. arXiv:2103.08266. https://arxiv.org/abs/2103.08266 — 系統性回顧,發現「人」的最大挑戰是開發與安全團隊的衝突:開發者感到被評判、被剝奪自主權。(對應 Security vs RD 斷層)

  12. Collaborative Application Security Testing for DevSecOps: An Empirical Analysis of Challenges, Best Practices and Tool Support. (2022). arXiv:2211.06953. https://arxiv.org/abs/2211.06953 — 實證分析,記錄開發與安全團隊因目標函數不同(交付速度 vs 徹底安全評估)而採取對抗姿態。(對應 Security vs RD 斷層)

產業報告與治理框架(非同儕審查,供延伸參考)

  1. IBM (2026). The accountability gap in autonomous AI. https://www.ibm.com/think/insights/accountability-gap-autonomous-ai — 指出企業面對 agent 常缺乏監控行為、審查自動化決策、以及事後歸屬責任的能力。(對應第二道牆)

  2. SPHERE / NHIMG (2026). AI Agent Ownership — An Underlying NIST AI RMF Control. https://nhimg.org/community/agentic-ai-and-nhis/ai-agent-ownership-and-accountability-gaps-in-ai-governance/ — 主張在 agent 被允許行動前,就應指派具名的業務與技術負責人,將 ownership 視為治理的前置控制項。(對應第二道牆)

  3. World Economic Forum (2026). Why autonomous AI demands a new model of organizational authority. https://www.weforum.org/stories/2026/05/autonomous-ai-new-model-organizational-authority/ — 指出 AI agent 缺乏一般員工的法律問責、道德責任與聲譽誘因,後果不是內建的,治理必須補上這些缺口。(對應第二道牆)

  4. Hamade, J. (2025). Beyond the Hype: A Leader's Guide to Software Development Metrics in the Age of AI. Medium. https://medium.com/@justhamade/beyond-the-hype-a-leaders-guide-to-software-development-metrics-in-the-age-of-ai-129cd6d2fa7b — 業界評論。指出若把「AI 建議接受率」設成 KPI,將激勵開發者盲目接受低品質 AI 程式碼,等於在衡量他願不願意關掉批判性思考;主張任何速度指標都要有品質指標制衡。(對應第四道牆:KPI 誘因)

  5. Stripe Engineering (2026), via InfoQ. Stripe Engineers Deploy Minions, Autonomous Agents Producing Thousands of Pull Requests Weekly. https://www.infoq.com/news/2026/03/stripe-autonomous-coding-agents/ — Stripe 自主編碼 agent「Minions」每週產出 1,300+ 個零人類手寫程式碼的 PR,但所有變更仍由工程師 review 後才 merge;規模化關鍵在於既有開發基礎設施(devbox 沙箱、測試、CI 與確定性關卡)而非模型強弱。(對應第四道牆:人被重新配置為 reviewer)

組織行為與技術採用理論(學術)

  1. Rogers, E. M. (1962/2003). Diffusion of Innovations. Free Press. — 經典理論。將採用者分成創新者、早期採用者、早期大眾、晚期大眾、落後者五類;早期採用者具最高的意見領袖地位,是同儕擴散的關鍵。(對應第三道牆:員工派系分化)

  2. AI Tools in Software Development: Developer Perceptions and Usage Patterns. (2026). arXiv:2601.21305. https://arxiv.org/abs/2601.21305 — 實證聚類研究,將開發者分成 Enthusiasts、Pragmatists、Cautious 三群,在使用廣度、感知生產力與品質、未來採用意願上顯著不同,並對應 Rogers 的採用者類別。(對應第三道牆:員工派系分化)

查證與引用狀態說明:

  1. 已逐一查證 arXiv 編號/DOI、標題、作者與年份且相符的:第 1、2、3、6、7、8、9、10、11、19 項;第 13、14、15、16、17 項(IBM、SPHERE、World Economic Forum、Hamade、Stripe/InfoQ)來源均存在且已確認;第 18 項(Rogers, Diffusion of Innovations)為經典書目。Stripe Minions「每週 1,300+ PR、全數人類 review」已由 Stripe 官方工程部落格與多家一手轉述(含 InfoQ 引 Stripe 工程經理公開貼文)證實。
  2. 第 4(Chaining Tasks, Redefining Work)、第 5(The Integrator Advantage)兩項的具體 arXiv 編號本文尚未獨立重新查證確認,故第四道牆對這兩項的引用以「有研究主張」表述,引用前建議先至 arXiv 核對編號與作者,或改引其他已確認來源。
  3. 「眾手問題(problem of many hands)」為應用倫理學既有概念(可追溯至 D. Thompson 等人的討論),本文將其作為獨立概念引用,並未宣稱由上述任何 code review 論文提出。
  4. 「principal-agent problem」「moral hazard」「sin of omission」「Coase 交易成本」「Goodhart's law」等為經濟學/管理學教科書級概念,本文未綁定特定論文;若投正式場合欲具名引用,建議補 Jensen & Meckling(1976)、Holmström(1979)、Goodhart(1975)/Strathern(1997)等原始文獻。
  5. 解方第三點「agent 設定檔的 Stop 區段」敘述,源自一份談 Loop Engineering 的二手業界文章,細節無法完全獨立查證,故行文以「業界實作 loop 時」表述;投正式場合前建議自行找一手來源。
  6. 第 13、14 項為產業/治理文章而非學術論文;第 15、16、17 項為產業報告、公司工程部落格或個人評論。相關治理主張(「具名負責人」「人機協作審核關卡」「速度指標需品質指標制衡」)在 BCG、MIT Sloan Management Review、OECD、EU AI Act(Articles 12–14)等來源亦有一致論述。