# 策展 · X (Twitter) 🔥🔥🔥🔥

> 📖 本站完整內容索引（documentation index）：[llms.txt](/llms.txt)

> 作者：Addy Osmani (@addyosmani) · 平台：X (Twitter) · 日期：2026-07-09

> 原始來源：https://x.com/addyosmani/status/2074927530482835916

## 中文摘要

# 掌握外迴圈 (Outer Loop)

在過去的一年裡，關於 Agentic 程式開發的討論已經轉向了 harness 與迴圈、機隊 (fleets) 以及軟體工廠。我個人的淺見是，工程師必須掌握「外迴圈」——即對這些系統負起當責。隨著 Fable 和 GPT-5.6 等強大模型問世，這一點只會變得更加重要。

![這張圖片探討了未來工程師在自動化代理（agents）普及後的角色轉變，強調決策與驗證的重要性。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/970d4ed09d2255b2.jpg)

<details class="chart-data"><summary>展開畫面重點</summary><div class="me-note">圖片為黑底白字（部分文字為黃色與紫色）的文字簡報，內容如下：
- 左上角標題：THE FUTURE OF ENGINEERING
- 主文內容：The engineer of the future will choose what is worth doing, then own the evidence, understanding and verdict for work increasingly automated by agents.
- 左下角署名：@addyosmani</div></details>

Agent 擁有槓桿效應，而槓桿效應會帶來義務。必須有人能夠精確解釋發生了什麼變更、為什麼它是安全的，以及如果出錯了會發生什麼事。否則，它們的行為就無法被正當化。這也使得組織不太可能從一開始就要求使用它們。

因此，我想談談三個術語。首先是「品質」(Quality)，指的是我們在讓系統上線前所設置的所有檢查。這些檢查會產生證據，而我們從這些證據中得出「裁決」(Verdict)。

第二個術語「裁決」，指的是在工作進入我們依賴的系統之前所做的最終決定：我是這些內容的產線製作人。我經營的團隊，其產出的工作成果都是以我的名義發布的。模型或許寫出了那一行程式碼，但裁決權在我。未經我的決定，我團隊的工作成果絕不會進入我們依賴的系統。裁決就是生產決策：我們應該發布、阻擋、重新導向、縮減回應範圍、增加防護機制，還是直接拒絕？

第三個術語「可答責性」(Answerability)，指的是一種保證，即如果有人詢問，我能夠解釋原因。

換句話說：我們的 Agent（我將其定義為模型加上由檔案、工具、記憶、skill、沙盒、權限、可觀測性與復原機制組成的 harness）是執行我們迴圈（我將其定義為調查、實作、驗證，然後重複）的核心。這也是建構我們軟體工廠的基礎。

![本圖展示了「Harness Engineering」的概念架構，說明如何透過周邊系統將 AI 模型轉化為具備實作能力的代理（Agent）。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/27d53c973a8add3b.png)

<details class="chart-data"><summary>展開畫面重點</summary><div class="me-note">圖表標題：THE AGENT IS THE SYSTEM AROUND THE MODEL
主標題：HARNESS ENGINEERING
副標題：The scaffolding that turns a model into an agent.

架構核心公式：agent = model + harness
架構組成（harness）：prompts, tools, state, constraints, feedback loops

圖表組件說明：
- 中央區塊：MODEL（標示為 one chip on the board），功能為 reasons / decides。
- 左側輸入/控制區塊：
    - CONTEXT (rules, memory)
    - CONTROL (plans, routing)
    - FAILURE (agent slipped)
- 右側輸出/執行區塊：
    - ACTION (tools, MCPs)
    - PERSIST (files, git)
- 外部反饋與規則區塊：
    - OBSERVE (tests, logs)
    - HOOKS (block, retry)
    - RATCHET (new rule)

箭頭流向：
- FAILURE 指向 CONTEXT。
- CONTEXT、CONTROL 指向 MODEL。
- MODEL 指向 ACTION、PERSIST、HOOKS。
- HOOKS 指向 RATCHET。
- RATCHET 指向 MODEL。
- OBSERVE 指向 MODEL。
- FAILURE 與 OBSERVE 之間有循環箭頭。

來源標註：Source: addyosmani.com/blog/agent-harness-engineering</div></details>

![這是一張關於「循環工程（Loop Engineering）」的架構圖，強調透過設計系統循環來取代單純的提示詞工程。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/16119b4f8828cc82.jpg)

<details class="chart-data"><summary>展開畫面重點</summary><div class="me-note">圖片標題為「LOOP ENGINEERING」，副標題為「Design the loop, not the prompt.」。
圖表定義循環公式為：loop = goal + cadence + isolated work + verification + state。
核心區塊為「RECURSIVE GOAL」（iterate until done）。
圍繞核心的流程區塊包含：
1. VERDICT (owns outer loop)
2. AUTOMATE (cadence finds work)
3. STATE (memory lives outside)
4. ACT (agents in worktrees)
5. LEARNING (tomorrow reads today)
6. VERIFY (maker != checker)
7. ISOLATION (parallel, no chaos)
8. DECIDE (ship, block, queue)
底部文字為「Loops change the work. They do not delete the engineer.」。
來源標註為：addyosmani.com/blog/loop-engineering。</div></details>

![這是一張展示「代理軟體工廠（Agentic Software Factory）」運作流程的架構圖，強調人類判斷在軟體開發生命週期中的關鍵槓桿作用。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/a36d51a1df0b0c80.jpg)

<details class="chart-data"><summary>展開畫面重點</summary><div class="me-note">該圖表描述了軟體開發的自動化流程，包含以下區塊與文字：
- 標題：THE SOFTWARE FACTORY, WITH THE LIGHTS ON / AGENTIC SOFTWARE FACTORY
- 輸入源：product intent、incidents、user feedback（下方註記：stuff worth doing）
- 核心處理單元：agent inner loop，包含 guide / context、generate、verify / solve（下方註記：sandbox, traces, tests）
- 產出與驗證：evidence（包含 tests、diff summary、risk notes）
- 決策點：human verdict（包含 ship / block / redirect），此處為人類判斷的關鍵點。
- 系統回饋：monitor 與 users 互動，並回饋至 agent inner loop。
- 警示區塊：lights off fails here（指向 human verdict）。
- 核心理念：
    - The win is not removing people from the loop.
    - The win is moving human judgment to the highest leverage checkpoint.</div></details>

而在這座工廠的核心，存在著一道謹慎的界線，區分了系統內部與外部。在系統內部：我們收集輸入（來自產品團隊的意圖、對先前已發布工作的了解、近期發生的事故，或是來自使用者的具體回饋）。Agent 迴圈會調查任務、執行計畫並驗證結果。接著，證據會跨越那道界線。一位負責該依賴系統的人類會查看證據，並決定是否繼續進行。

![這張圖表說明了「高代理權（High Agency）」概念下，AI 代理（Agent）的執行迴圈與工程師的問責迴圈之間的邊界關係。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/22c6c1f81c036136.png)

<details class="chart-data"><summary>展開畫面重點</summary><div class="me-note">圖表標題：WHAT "HIGH AGENCY" MEANS NOW
主標題：THE LOOP BOUNDARY IS EVIDENCE
副標題：Agents run capability loops. Engineers own agency loops.

左側區塊：01 AGENT INNER LOOP (capability: do work, return evidence)
- INVESTIGATE: inspect, search, plan
- IMPLEMENT: change, refactor, generate
- TEST: run checks, compare results
- REPORT: summarize what changed

中間區塊：BOUNDARY EVIDENCE (diff, tests, logs, why)
- 箭頭從 REPORT 指向 EVIDENCE，再指向右側的 VERIFY。

右側區塊：02 ENGINEER OUTER LOOP (agency: decide what earns production trust)
- DECIDE: is this worth doing?
- VERIFY: is the evidence enough?
- APPROVE: ship, block, or redirect
- OWN: carry the consequence

底部說明：
- 虛線箭頭從右側的 OWN 指回左側的 REPORT，標註文字：constraints and learning feed the next run
- 總結文字：The inner loop is capability. The outer loop is accountability.
- 流程總結：Investigate · implement · test · report crosses into decide · verify · approve · own.</div></details>

朋友們，這就是我們試圖做出的轉變。過去，我們的 Agent 執行的是執行迴圈的內迴圈。現在，它們負責執行內迴圈，而工程師則掌握外迴圈。

![這張投影片探討了「高代理能力（High Agency）」在現代軟體開發中的定義，強調 AI 代理與工程師在開發流程中的分工。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/9a009a9eb827b957.png)

<details class="chart-data"><summary>展開畫面重點</summary><div class="me-note">畫面為一張深色背景的簡報投影片，上方標題為「WHAT "HIGH AGENCY" MEANS NOW」。中央文字內容如下：
「Agents run the inner loop.」
「Engineers own the outer loop.」
左下角標註署名為「@addyosmani」。</div></details>

在系統內部，我們的 Agent 其實只做一件事：能力 (Capability)。調查任務、執行計畫、測試結果並回報的能力。這就是模型的能力。正如我們所說，那個未來已經到來。

在系統外部，也只有一件事：代理權 (Agency)。決定、驗證、批准與當責的代理權。

你看，我們談論的依然是程式碼。它只是需要存在於一個合適的地方，並由知道自己在做什麼的人來執行。

AI 程式碼的潛力已不再是邊緣化的。在 2026 年的 Sonar 調查中，我們詢問團隊 AI 輔助提交的程式碼佔比。比例雖小但意義重大。幾位受訪者表示，他們預期 AI 輔助提交的比例將大幅成長。Sonar 的《2026 程式碼現況報告》發現，42% 的提交程式碼是由 AI 生成或在 AI 大幅輔助下完成的，且預期該比例將持續成長，而非停滯。

![根據 Sonar 調查報告，AI 生成或輔助的程式碼佔比已不再邊緣，目前已達 42%，預估到 2027 年將攀升至 65%。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/c3f6afb11f367347.jpg)

<details class="chart-data"><summary>展開數據表</summary><table><thead><tr><th></th><th>2023</th><th>2024</th><th>now</th><th>2026 est.</th><th>2027 est.</th></tr></thead><tbody><tr><td>AI code share</td><td>6%</td><td>19%</td><td>42%</td><td>55%</td><td>65%</td></tr></tbody></table></details>

換句話說，創造變得更便宜了。稀缺的資源變成了審查、驗證、理解與維護。

我們提升生成速度的速度，快過了我們提升控制速度的速度。因此，我們面臨著信任與驗證之間的落差。我們對談的許多人仍對 AI 程式碼表達了一定程度的不信任。然而，似乎很少有人持續將這種不信任納入他們的驗證流程中。

![調查顯示，高達 96% 的開發者不完全信任 AI 生成的程式碼，但僅有 48% 會在提交前驗證，顯示出兩倍的信任落差，且有 38% 的人認為審查 AI 程式碼比人類程式碼更花時間。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/2db5c04df40a53ce.jpg)

<details class="chart-data"><summary>展開數據表</summary><table><thead><tr><th></th><th>Always verify AI code before committing</th><th>Say reviewing AI code takes longer than human code</th></tr></thead><tbody><tr><td>Do not fully trust AI-generated code = 96%</td><td>48%</td><td>38%</td></tr></tbody></table></details>

這是一個危險的處境。我們需要更便宜、更清晰的方法來驗證 AI 程式碼的可信度。

如果你查看 GitLab 2026 年 6 月的報告，你會發現治理問題已經轉移了。GitLab 的 AI 當責研究顯示，審查與驗證是目前使用 AI 時的瓶頸；更令人擔憂的是，治理通常發生在程式碼建立之後，也就是在我們已經接受風險並失去所有權控制之後。今天，重點不僅僅是控制，而是我們對系統設定了什麼限制。重點在於我們將如何透過證據來檢查工作，以及我們將如何讓團隊負起責任。重點在於誰將擁有 AI 生命週期的哪個部分。

![根據 GitLab 2026 年 6 月的 AI 問責制研究，高達 92% 的受訪者面臨 AI 生成程式碼的治理挑戰，其中審查與驗證（85%）及生成後的治理（84%）已成為最主要的瓶頸，顯示程式碼生成的發展速度已超越了控制能力。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/3e80ae36423807da.jpg)

<details class="chart-data"><summary>展開數據表（1）主要統計</summary><table><thead><tr><th></th><th>Governance after creation is the challenge</th><th>AI code risks new technical debt</th><th>Adopted AI faster than policy</th><th>Cannot reliably distinguish AI vs human code</th></tr></thead><tbody><tr><td>Review/validation is now the bottleneck = 85%</td><td>84%</td><td>82%</td><td>80%</td><td>43%</td></tr></tbody></table></details><details class="chart-data"><summary>展開數據表（2）總體挑戰</summary><table><thead><tr><th>項目</th><th>數值</th></tr></thead><tbody><tr><td>Report some governance challenge with AI-generated code</td><td>92%</td></tr></tbody></table></details>

因此，本系列最後的區別在於流程與品質。品質是「反壓」(back pressure) 的概念。我們是字面意義上的理解。我們不想賦予 Agent 它們所能行使的全部自主權。我們只想賦予它們足夠的自主權，讓我們有足夠的反壓來阻止它們、規範它們、檢查它們的工作，並確保我們的人性。

一般的工程實務會運用許多訊號來指示正在進行的工作是否正確。型別檢查、測試、Hook、沙盒限制、稽核日誌、監控。我們的工程系統充滿了這類訊號，它們用來提供足夠的反壓，以保持系統的誠實。

因此，只要我們的 Agent 能發出這些相同的訊號，我們就能信任我們一般的工程實務能提供適當的反壓。

信任我們的系統並不代表我們不需要人類參與迴圈。這只是意味著人類不需要處於內迴圈中。我們希望他們處於限制迴圈（我們應該設定哪些輸入、架構、指令或不變量？）、取樣迴圈（我們應該取樣並審查多少輸出？）、稽核迴圈（我們應該保留什麼證據，以及如何確保我們的稽核日誌有效？），以及所有權迴圈（我們應該擁有生產界線的哪個部分）。

但人類不需要處於內迴圈中。

Agent 的產出速度可以超過你的審查速度。

![這張圖片探討了 AI 代理（Agent）在軟體開發交付速度上超越人類審核能力的現況，並引發關於人類開發者價值定位的思考。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/0454229ff5461a05.jpg)

<details class="chart-data"><summary>展開畫面重點</summary><div class="me-note">圖片為黑色背景，右側帶有模糊的數位字元與光暈效果。畫面中央顯示以下文字：
「The agent can ship more than you can review.」
「So what are you still for?」
左下角標註有「@addyosmani」。</div></details>

而稀缺的資源是你核心的人類判斷力，並由日誌或測試等品質訊號所輔助。

2026 年 6 月的 AI 報告顯示，在實驗環境中，以小時為單位的 Agent 委派已基本實現。OpenAI 今年關於 Agent 與未來工作的研究是這些想法的重要來源。因此，隨著我們的系統開始產出超過我們審查能力的工作量，我們需要開始思考如何建立這個所有權界線。

![數據顯示長期代理人的授權深度已成現實，大於 30 分鐘與 1 小時的人類等效任務分別達到 80.6% 與 70.2% 的比例，而大於 8 小時的任務亦有 25.6%。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/3bc71d065a545a3c.jpg)

<details class="chart-data"><summary>展開數據表</summary><table><thead><tr><th>項目</th><th>數值</th></tr></thead><tbody><tr><td>&gt;30 min human-equivalent task</td><td class="rank-bar num bar-w-100"><span class="bar-val">80.6%</span></td></tr><tr><td>&gt;1 hour human-equivalent task</td><td class="rank-bar num bar-w-90"><span class="bar-val">70.2%</span></td></tr><tr><td>&gt;8 hours human-equivalent task</td><td class="rank-bar num bar-w-30"><span class="bar-val">25.6%</span></td></tr><tr><td>p99 internal daily active users agent turns per day by June 2026</td><td class="rank-bar num bar-w-0"><span class="bar-val">&gt;60h</span></td></tr></tbody></table></details>

這就是當責發揮作用的地方。

因為對於長週期的 Agent 而言，在小時級別的時間跨度內所做的決定就是決定。並非所有的決定都會被記錄下來。你無法將它們全部追溯到輸入的 token。如果你只是單純信任你得到的輸出就是當前問題的正確選擇，那麼你需要花費數百甚至數千小時的人力來重建導致該結果的決策鏈，這將變得不可能。因此，再次強調，當責必須成為我們系統設計的核心。

## 三個隱形成本

此外還有三個隱形成本：

認知投降 (Cognitive surrender) ~ 盲目接受 AI 給你的東西。當你將工作委派給 Agent 時，工作本身看起來可能像是 Agent 的成果。但實際上這是你的工作。這是你的聲譽。這是你的責任。而且是你的軟體在輸出中承受了缺陷。也是你的軟體需要修改以反映該輸出。因此，Agent 的輸出變成了你的答案。隨之而來的是所有的當責。沃頓商學院 (Wharton) 的研究在 AI 正確時令人安心，但當它出錯時，消息就不那麼好了。當 AI 出錯時，近四分之三的人仍然接受了它，並且比沒有 AI 時感覺更自信。

![這張圖表探討了「認知投降」現象，指出當 AI 提供錯誤資訊時，有 73% 的使用者會盲目接受並對其答案感到更加確信。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/69bd831abff5d358.jpg)

<details class="chart-data"><summary>展開畫面重點</summary><div class="me-note">畫面為黑底白字與黃色重點文字的簡報投影片，內容如下：
- 標題：Cognitive surrender.
- 副標題：When you blindly accept what AI gives you and stop critical thinking.
- 統計數據：73% accepted the wrong answer when the AI was wrong, and felt more sure. Wharton, 1,372 people.
- 左下角署名：@addyosmani

畫面重點在於警示使用者在使用 AI 時應保持批判性思考，避免產生「認知投降」，並引用了沃頓商學院（Wharton）針對 1,372 人的研究數據，強調使用者在 AI 給出錯誤答案時，反而會表現出更高的信心。</div></details>

認知債 (Cognitive debt) ~ 對如何解決問題的理解與記憶的侵蝕。當你將工作委派給 Agent 時，你將所有的思考工作都卸載給了 Agent。雖然自己思考一切需要時間與精力，但在龐大的程式庫上進行思考，當你試圖攀爬學習曲線時，所需的資源是無法取得的。因此，你得到的輸出往往是你自己無法達到的。Agent 的規劃時間跨度越長，Agent 產出的程式碼與你對其理解之間的差距就越大。差距會累積。債務會增加。而攀爬學習曲線的成本幾乎呈指數級成長。Anthropic 有一項隨機對照試驗，研究依賴 AI 寫程式的工程師是否與親自寫程式的工程師理解得一樣好。結論很悲觀：在理解力測驗中，使用 AI 的工程師得分比沒使用的人低了 17 個百分點，分別是 50% 對上 67%。

![這張圖表探討了「認知債」的概念，並引用數據指出透過 AI 生成程式碼學習會降低理解力。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/6ef7b5448a66e559.jpg)

<details class="chart-data"><summary>展開畫面重點</summary><div class="me-note">圖片內容如下：
- 標題：Cognitive debt.
- 定義：The erosion of your understanding and memory around how to solve problems.
- 數據重點：17% lower comprehension when you learn through AI-generated code, 50% vs 67%. Anthropic, 52 engineers.
- 底部署名：@addyosmani</div></details>

還有編排稅 (Orchestration tax) ~ 現在啟動大量 Agent 很簡單，但你的認知頻寬並不會以同樣的方式平行化。引導你的 Agent 遠離最糟糕的行為、整理 Agent 產出的工作以識別需要你注意的部分、指導它優先處理你關心的工作、在讓它執行之前驗證你最重要的限制條件與最危險的假設……

所有這些都需要工作，而且無法自動化。

人類的判斷力是無可取代的。

![這張投影片定義了「編排稅」（Orchestration tax）的概念，指同時管理多個 AI 代理時所產生的邊際效益遞減與認知負擔。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/e138742df54b1636.png)

<details class="chart-data"><summary>展開畫面重點</summary><div class="me-note">圖片為一張深色背景的簡報投影片，文字內容如下：
「Orchestration tax.」
「The diminishing returns and cognitive drain experienced when managing parallel AI agents at once.」
左下角標註有署名：@addyosmani</div></details>

Brownfield（既有系統）在這裡特別危險，因為你必須稽核的系統行為並不存在於程式碼中。它存在於那些「傷痕」裡。

解決方案？在架構決策中將注意力列為優先事項。使用 worktrees、範圍與證據來減少初始計畫與最終產出工作之間的耦合。為解決無法執行的步驟設定時間限制。並讓軟體中的變更嚴格採取「選擇性許可」(opt-in permission) 模式。

Alpha、衰退 (decay) 與品味 (taste)：這是塑造跨領域職業生涯與績效的三個核心模式。

![這張圖表定義了 AI 模型競爭中的兩個關鍵指標：「Alpha」代表相較於現有模型的優勢差距，而「Decay」則代表競爭對手追趕上該優勢的速度。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/824b15bb846433fe.png)

<details class="chart-data"><summary>展開畫面重點</summary><div class="me-note">圖片為黑色背景，以黃色、白色與紫色文字呈現關於 AI 模型競爭的定義：
- Alpha is the gap.
- Alpha: what makes you meaningfully better than what current models can do.
- Decay: how fast the models catch up.
左下角標註有署名：@addyosmani</div></details>

Alpha 是競爭中由最高成就者所佔據的領先部分，也就是當你進行最高價值遊戲操作時的狀態。衰退是每個人透過重複與觀察他人所學到的既定模式（如果你喜歡，可以稱之為平原期）。品味是我們能感知 Alpha 領先或衰退變化的最早時刻。這是我們在任何跡象發生前，對即將到來之事物的判斷。Paul Graham 的觀點是，當任何人都能製作任何東西時，選擇製作什麼變得更重要；而 Mitchell Hashimoto 的定義則是操作性的：在尚無客觀指標存在時，做出高品質的定性判斷。從現在起，品味驅動一切：Alpha 的轉變就是品味的改變。而衰退之所以會消失，是因為我們開始品味到不同的東西。

![這是一張探討「品味（Taste）」在產品開發與創新中價值與影響力的文字敘述圖片。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/a9ee2a5d16e0febb.png)

<details class="chart-data"><summary>展開畫面重點</summary><div class="me-note">圖片背景為黑色，文字內容如下：
「Taste is the judgment before the metric exists.
Hard to create. Easy to copy.
Valuable because it decides what everyone copies next.」
左下角標註有帳號名稱：@addyosmani</div></details>

下一步？將你的品味操作化。如何做？給它一個名字，反映出你試圖從邊緣系統 (limbic) 轉移到意識層面的東西。在評論與範例中練習它。將其背後的邏輯明確化。

![這張圖表探討了技術能力隨時間演進的「衰退（Decay）」現象，區分了已自動化與尚需人類判斷的領域。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/53c0cbb1fc2edfa0.jpg)

<details class="chart-data"><summary>展開畫面重點</summary><div class="me-note">圖片內容為一段關於技術能力演進的文字敘述，標題為「THE TEST: IS IT A CAPABILITY? THEN IT DECAYS」。內容分為兩部分：

第一部分（已衰退的能力）：
- Speed: gone. 600 lines while you find coffee
- Recall: gone. it's a context window now
- Verification: automating. and we were the weak link

第二部分（未來可能的能力）：
- Eventually? Maybe?
- Taste: alpha. resets every release. Will take longer to decay.
- Judgment: a slope rather than a wall

左下角署名為 @addyosmani。</div></details>

並持續做出能為你所在產業帶來最持久競爭優勢的操作。那是什麼？持續將優勢向上提升，從單純執行任務，轉變為傳授任務、系統化任務、決定何時執行任務，並對結果負責。

![一張以黑色為背景，探討人工智慧與人類責任關係的視覺設計圖。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/6a094f649a769ec7.jpg)

<details class="chart-data"><summary>展開畫面重點</summary><div class="me-note">畫面頂部文字為「ONE QUESTION: WHAT CAN THE AGENT DO?」。
畫面中央主要文字為：
「Stop asking what AI can't do.」
「Ask what only a human can be answerable for.」
背景底部呈現由 ASCII 字元（如 X、8、S、#、@、+ 等）組成的抽象紋理，帶有從底部向上延伸的紅色光暈效果。</div></details>

每個人都是開發者，但並非每個人都是工程師。工程是開發者在擁抱更嚴格的工作紀律時所轉變成的模樣：徹底且邏輯嚴密的推理、對限制與取捨的考量、對風險與暴露面的認知，以及實際的當責。

![這是一張探討開發者與工程師定義差異，並引導思考工程師如何保持高效與負責的文字圖卡。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/2dff1706ffb1cd94.png)

<details class="chart-data"><summary>展開畫面重點</summary><div class="me-note">圖片內容為黑色背景上的白色文字，左下角有署名「@addyosmani」。完整文字轉錄如下：
「Everyone is a developer now.
That doesn't make them an engineer.
What should engineers avoid to stay effective and accountable?」

畫面重點在於區分「開發者（developer）」與「工程師（engineer）」的概念，並提出一個反思性問題，目的是探討工程師為了維持工作效能與責任感，應當避免哪些行為或習慣。</div></details>

未來，人們將離開工程的行政工作，並在工程變得更具挑戰性時擁抱新興的角色。這些角色與工藝精神脫鉤，但明確了每個人所做的事情。將會有負責原型設計的人。負責建構的人。負責清理的人。負責成長的人。負責維護的人。

![這張圖表探討了未來職涯發展的趨勢，強調個人對系統的掌控權比職稱更為重要。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/fef112ce07f1c643.png)

<details class="chart-data"><summary>展開畫面重點</summary><div class="me-note">圖中文字內容如下：
- 頂部標題：THE FUTURE OF CAREERS
- 第一段核心觀點：Roles are unbundling from craft and rebundling around ownership.（職位正從工藝中解構，並圍繞著「所有權」重新整合。）
- 流程關鍵詞：Prototype. Build. Sweep. Grow. Maintain.
- 第二段核心觀點：The title matters less than the part of the system you can own.（職稱的重要性不如你所能掌控的系統部分。）
- 左下角署名：@addyosmani</div></details>

人類也在另一個方向上掌握著系統的邊緣。在另一個方向上增加 Alpha：選擇什麼值得做、定義執行時的限制條件、決定證據是否足以繼續進行，以及關心結果。無論是一個團隊還是一百個團隊，這都是只有人類才能掌握的邊緣。

當責將擴展這座工廠。就像注意力和品味一樣，當責也是使一切運作的三個二元性之一。沒有當責，就沒有規則。沒有與質疑者的爭辯。沒有取捨。沒有風險。沒有安全網。如果沒有人對決策的後果負責，那麼高代理權只會帶來混亂。

![這是一張關於「當代理（agents）表現優異後，問責制（accountability）如何成為擴展關鍵」的演示簡報。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/6c45534cd1ae4d28.jpg)

<details class="chart-data"><summary>展開畫面重點</summary><div class="me-note">畫面頂部標題為「ACCOUNTABILITY SCALES THE FACTORY」。
中央文字內容如下：
「Accountability is not what remains after agents get good.」
「It is what lets the rest scale.」
畫面底部背景為深紫色，帶有類似程式碼或數據雜訊的字元紋理（如 X、S、8、0、#、@ 等符號）。</div></details>

一個優勢的半衰期是一次發布，但一個簽名的半衰期是一整個職業生涯。簽名就是你在工作上的名字，讓你覺得可以為所發布的內容背書。Skill 帶給你槓桿效應；而當責將槓桿效應轉化為信任。

![圖表指出，隨著模型的不斷發布，速度、驗證與品味等技術優勢的耐用性會迅速衰退，而問責制（accountability）的耐用性則能始終保持在最高水平。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/22ce67cf93932a3a.png)

<details class="chart-data"><summary>展開數據表</summary><table><thead><tr><th>指標</th><th>起始相對高度</th><th>下降速度</th><th>最終相對高度</th></tr></thead><tbody><tr><td>accountability</td><td>最高</td><td>無下降（水平）</td><td>最高</td></tr><tr><td>speed</td><td>高</td><td>極快</td><td>最低</td></tr><tr><td>verification</td><td>中高</td><td>中速</td><td>最低</td></tr><tr><td>taste</td><td>中</td><td>慢速</td><td>最低</td></tr></tbody></table></details>

只有人能選擇。只有人會繼承後果。Agent 可以被要求在政策範圍內安全地選擇、路由、合併與升級，但它們無法繼承後果。

![這是一張探討 AI 代理人決策權與人類責任歸屬的哲學性簡報頁面。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/a1d91d244c6ea938.jpg)

<details class="chart-data"><summary>展開畫面重點</summary><div class="me-note">畫面為黑色背景，中央以白色與黃色文字呈現以下內容：
「The agent can choose.
Only people inherit consequences.」
（其中「consequences」一詞以黃色標示）

頁面底部以較小的字體呈現一行註解：
「Automation executes inside policy. Accountability owns the blast radius.」

這段文字強調了在自動化系統中，雖然 AI 代理人（agent）具備選擇能力，但最終的責任與後果仍由人類承擔，並指出自動化運作需遵循政策規範，而當發生影響範圍（blast radius）時，責任歸屬在於人類。</div></details>

每個程式庫或許都應該附帶某種當責合約，明確說明接受變更時所理解的檢查清單、決策所依據的證據、誰對該變更負責，以及變更被阻擋後的系統狀態。就像這樣：

- 你的注意力和品味

- 你的證據、裁決與所有權

- 你的 Alpha、衰退與品味

## 高代理權 (High agency)

在典型的 Agentic 工作流程中，高代理權是一門藝術，知道何時委派、何時檢查、何時停止，以及何時對流程結果負責。代理權的階梯從低到高：標記潛在問題、調查問題、執行對策、診斷問題、提出解決方案、建議修正，以及解決問題。代理權階梯的高層級是洞察力：發現了問題，但認為不值得修復，然後繼續前進。

![這張圖表展示了「代理階梯」（The Agency Ladder），說明在面對問題時，個人展現主動權與解決能力的七個層級。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1fa63824b0a9dc53.jpg)

<details class="chart-data"><summary>展開畫面重點</summary><div class="me-note">圖表標題：The Agency Ladder - How much of the problem do you own?（代理階梯 - 你對問題的掌控程度有多少？）

階梯層級與對應描述：
7. DISCERN（洞察）："Found it - not worth fixing. Moving on."（發現問題，但判斷不值得修復，繼續前進。）—— 這是稀有的頂峰，知道什麼「不該做」。
6. RESOLVE（解決）："Found it. Fixed it. Looping you in."（發現問題、修復問題，並告知相關人員。）—— 這是值得努力達到的層級。
5. RECOMMEND（建議）："...and here's the one I'd pick."（提出多個方案，並說明我會選擇哪一個。）—— 這是從第一天起就該達到的水準。
4. PROPOSE（提議）："...and a few ways to fix it."（提出問題，並提供幾種修復方法。）
3. DIAGNOSE（診斷）："Here's the problem, and the cause."（指出問題所在及其成因。）
2. EXECUTE（執行）："Hand me the fix - I'll ship it."（給我修復方案，我來執行交付。）
1. FLAG（標記）："There's a problem."（指出有問題。）—— 然後轉身離開，留給別人處理（這是最少主動權的層級）。

圖表底部標註：LEAST AGENCY（最少主動權）
圖表頂部標註：MOST AGENCY（最多主動權）
左下角署名：@addyosmani</div></details>

## 支撐軟體工廠的十二根支柱

Brownfield 是希望擴大規模的工廠所面臨的前線。所有那些聰明的小創新現在可能感覺沒什麼，但生產環境卻是大有不同。在建構全新的系統時，規劃並實作足夠的反壓機制要容易得多，因為你擁有完全的控制權。然而，當你在既有系統中加入智慧 Agent 時，情況就完全不同了。

既有系統包含了生產行為的全部、客戶的未來期望、遷移歷史、發布與預算週期持續時間、未說出口的假設、邊緣案例、資料的怪異之處、操作手冊流程，以及所有在沒有意願維護系統的情況下累積下來的傷痕。

要成為 Brownfield 的管家，需要一種持久的工程實務。必須付出努力將隱性知識轉化為明確的限制條件，使其在團隊之間與世代之間保持一致，將這些知識形式化為測試程序與功能規格，並將這些知識與客觀證據連結起來。同時將失敗轉化為更多的學習。因為如果系統沒有得到它一直以來所需要的照護，一切都會崩潰。

## 新工作就是真實工作

隨著你的擴展，工作會變得更有趣。因為當其他一切都建構完成後，人們會想要建構新的東西。他們會想要運用透過工藝所發展出的 Alpha 與品味，來設計可以嫁接到軟體工廠上的新迴圈。或者，他們會想要建構 Greenfield 系統，運用軟體工廠的所有知識，投入到一個優雅、善意且有原則的努力中。他們會想要設計並實作新的證據形式，以達到新系統的驗證水準。他們會想要照護那些現在變得如此複雜、需要專門關注的 Brownfield 系統。他們會想要設計並管理新的反壓機制。他們會想要設計新的 Agent。並且，他們會想要建構代理權。

![這張圖表探討了自動化技術如何改變工程工作的本質，強調工程師應從基礎任務轉向更高層次的系統設計與維護。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/6e9b1f28aa3a4100.png)

<details class="chart-data"><summary>展開畫面重點</summary><div class="me-note">圖表標題：AUTOMATION MOVES THE FLOOR
主標題：NEW WORK IS REAL WORK
副標題：The job is not to protect the old loop. It is to own the new one.

核心架構說明：
1. 上層三個區塊：
   - LOOP DESIGN：what runs, when, and why
   - EVIDENCE DESIGN：what proves it worked
   - BROWNFIELD CARE：keep real systems healthy
2. 中間核心區塊：
   - ENGINEERING MOVES UP A LEVEL：own the loops, evidence, systems, and consequences
3. 下層基礎區塊：
   - automated task layer：typing · boilerplate · first drafts · routine fixes · repeated checks
   - fewer keystrokes：more surface area
4. 底部區塊：
   - NOT LESS ENGINEERING
   - new bottlenecks：coordination · verification · maintenance · product judgment · incident learning

畫面重點：此圖表展示了自動化如何將工程師從重複性任務（如打字、樣板程式碼、例行修正）中解放出來，並將工程工作的重心提升至系統設計、證據驗證與維護等更高層次的領域，同時指出自動化也帶來了協調、驗證與產品判斷等新的瓶頸。</div></details>

而且，當他們這樣做時，他們會明白這一切都是真實的工作。這是一件好事。

自動化會產生瓶頸。生產中的瓶頸是值得擁有的。因為自動化賦予了我們工業規模的控制力。但工業規模也會產生新的瓶頸。瓶頸從「我們能建構這個嗎？」轉變為「這個應該存在嗎？我們能為它負責嗎？」

我所建議的是一種用於擴展 Agentic 程式開發的實用操作模型。存在內迴圈與外迴圈。內迴圈是執行工作的地方。迴圈被設計得盡可能獨立。將所有的品質保證與驗證放入迴圈內。一旦你設計並驗證了迴圈本身，你唯一需要做的就是透過設置一個反壓機制來賦予自主權，該機制的作用是控制迴圈執行的速率及其操作範圍。並將人類放在他們應有的位置，做出正確的決策。不要將理解視為一種交接或發布閘門，而應將其視為一個決策點，讓人類準備好提供他們的見解。然後，對於每一個存在並回饋到生產環境、新團隊與工程師手中的產出物，留下更好的產出物。

建構工廠；保持運作；讓工作清晰可讀、可驗證、有人負責。

Agent 可以寫出程式碼。但在它到達使用者手中之前，必須有人解釋為什麼它應該存在、為什麼它足夠安全以成為生產環境的一部分，以及當它出錯時他們會怎麼做。

這就是外迴圈的 Agentic 程式開發——這就是現在的工作。

Pangram 已將本文評分為 100% 人類撰寫：https://www.pangram.com/history/ae6caccc-b70f-4336-a019-5c3411516871

## 標籤

Agent, 自動化, 產業趨勢, OpenAI, Fable
