Thoughtworks 於 2026-11-04 發布 Technology Radar Vol.35，共 117 個 blip。它和半年前的 Vol.34 問的不是同一個問題——Vol.34 問「AI 寫得太快，我們還讀得懂自己的程式碼嗎」；Vol.35 問「agent 一次跑好幾個之後，誰審得完、誰付得起」。 技術長 Rachel Laycock 把這個轉折講得最直接：現在的問題「是有沒有人能夠信任、審查並負擔得起它們產出的東西」。
這一期的結構
117個 blip 分布為 Adopt11、Trial49、Assess47、Caution10。四個象限分別是 Techniques（技術）45、Tools（工具）36、Platforms（平台）22、Languages & Frameworks（語言與框架）14。 Thoughtworks 近年把第四環的名稱由 Hold 改為 Caution，語氣從「不要用」調整為「要用請拿出充分理由」。
四大主題
| 主題 | 核心論點 |
|---|---|
| Harness engineering at scale〔規模化的 harness 工程〕 | Agent 周邊的 prompt、工具、記憶、護欄必須當成一套被工程化的系統來管理，含評估、安全、存取控制與維運，而不是散落在各人機器上的設定檔 |
| Human judgment〔人的判斷力〕 | 團隊開始平行跑多個 agent session 和整夜無人值守的建置，審查因此成為瓶頸；擴張之前要先確認審查量能 |
| Beyond frontier models〔不只前沿模型〕 | Open-weight 模型在許多工作負載上已經追上；選模型要看任務、成本、隱私與維運，而不是預設挑最強的 |
| Economics of running AI at scale〔規模化 AI 的經濟學〕 | 成本不只是模型單價，還包含路由、批次、儲存、網路與排程；模型、GPU、儲存與網路都要當成同一層平台上的可程式化資源 |
四個主題其實是同一句話的四個切面：agent 本身已經不是稀缺資源，稀缺的是圍繞它的工程、人的注意力，以及電費。
相比 Vol.34，變了什麼
這是這一期最值得細看的部分——不是哪些 blip 新出現，而是哪些判斷改變了。
升環（Thoughtworks 的信心提高了）
| Blip | Vol.34 | Vol.35 | 改變的理由 |
|---|---|---|---|
| Progressive context disclosure | Trial | Adopt | 「在正經的應用中幾乎已是通例」。做法是讓 AGENTS.md 保持精簡、只放連結，需要時再讓 agent 去查；MCP 工具與 Agent Skills 的完整 context 成本也延後到實際使用時才付 |
| Agent sandboxing（Vol.34 名為 Sandboxed execution for coding agents） | Trial | Adopt | 現在被視為「所有 agent 的合理預設值」。注意這是改名加擴大範圍，從 coding agent 擴及所有 agent，而非單純升環 |
| Mutation testing | Trial | Adopt | AI 生成的測試覆蓋率高、抓蟲能力卻不一定強；刻意注入 bug 是目前少數能驗證測試集真實效力的手段 |
| Feedback flywheel | Assess | Trial | 從 agent session 的成敗中持續改善 prompt、指令與感測器，已有足夠案例 |
| Toxic flow analysis for AI | Assess | Trial | 高權限 agent 與惡意 Skills 的資料路徑分析，從「值得看」變成「該試」 |
| Small language models | Assess | Trial | 與 Beyond frontier models 主題相呼應 |
| OpenSpec | Assess | Trial（Tools） | spec 工具鏈中第一個被 Thoughtworks 推上 Trial 的 |
新增的警告（Caution，10 個中有 7 個是這一期才出現）
Vol.34 的 Caution 講的是「AI 讓事情變亂」；Vol.35 的 Caution 講的是「我們為了應付變亂而發明的做法，本身也出了問題」。這是整期最有價值的一組判斷。
| Blip | 警告內容 |
|---|---|
| Human-in-the-loop theater〔人在迴圈劇場〕 | 「把人留在 agent 的迴圈裡，卻只是一個空的核准步驟，而不是真正的檢查——人核准了他其實沒有能力評估的動作、prompt 或 diff。」這是對整個 human-in-the-loop 共識最鋒利的一刀 |
| Meat proxy〔人肉代理〕 | 把未經閱讀與查證的 LLM 輸出直接轉給同事，等於把驗證成本丟給別人、並規避品質責任。Thoughtworks 說它與 human-in-the-loop theater 的差別是：那個假的是核准，這個假的是作者身分。KDE 的 AI 指引草案把它濃縮成一句「Don’t be a meat proxy」 |
| Agent skill cognitive surrender〔Agent 技能的認知投降〕 | 不理解內容就整批引入社群策展的 skill 庫或重量級 agent 框架。風險有三：團隊失去對系統運作方式的理解、未經審查的 prompt 指令進入執行管線（這是資安風險）、不同來源的 skill 彼此衝突 |
| AI-driven documentation sprawl〔AI 驅動的文件蔓延〕 | Spec-kit、BMAD 這類工具產出大量 Markdown，看起來精美，卻造成品質與進度的假象。文件通常不經過 CI 與自動化品質閘門，於是 repo 累積出「a big ball of documentation mud」。對 agentic 工作流傷害更大：agent 讀到過期的 ADR 與互相矛盾的 spec，既吃 context 又餵錯資訊 |
| Blanket frontier model usage〔一律用前沿模型〕 | 每個任務都丟給最強的模型，忽略成本、延遲與任務實際需要的能力。切換時機建議放在自然邊界（新 session、子代理、規劃轉實作的交接點），因為每個模型有各自的 prompt cache，逐請求切換會把快取打掉 |
| Naive context compression〔粗率的 context 壓縮〕 | 壓縮 prompt 省 token 有三個反效果：打斷 prompt caching（token 變少但帳單更高）、過度壓縮降低 agentic loop 的準確度、以及有些工具自己用 LLM 做摘要，隱藏的延遲與成本把省下的又吃掉。建議先做 context profiling，量測淨成本與任務準確度 |
| Stacked pull requests〔堆疊式 PR〕 | 把大變更拆成一串互相依賴的小 PR，近期因 AI 輔助編碼而流行、GitHub 也原生支援了。Thoughtworks 的判斷很銳利：「堆疊不會製造拆解問題，它只是暴露了本來就存在的問題。」真正該做的是把工作規格化、切分、調整大小，交付成彼此獨立的小單位 |
本站工作流直接命中其中一條
Naive context compression 這個 blip 點名了 RTK（與 Headroom、Tamp 並列）作為常見的 context 壓縮工具。本知識庫的
CLAUDE.md正是全面要求以rtk前綴執行指令。Thoughtworks 的警告不是「不要用」，而是「用之前先量」：確認快取命中沒有被打斷、確認壓縮後任務準確度沒有下降，並優先選擇「壓縮工具輸出但保留原始資料參照」的做法。這一條值得實際驗證，已列入下方待解問題。
延續未變的
Agent instruction bloat、AI-accelerated shadow IT、Coding throughput as a measure of productivity 三個 Caution 從 Vol.34 延續到 Vol.35。MITRE ATLAS 仍留在 Assess。Vol.34 的核心概念 Codebase cognitive debt 沒有再次出現在本期清單上，但在 Grilling 這個 blip 的說明中被明確當成「要對抗的東西」引用——概念沒有退場，而是從主題降為背景假設。
Adopt：11 個全清單
| 象限 | Blip | 要點 |
|---|---|---|
| 技術 | Agent sandboxing | 所有 agent 的合理預設；以 threat modeling 決定隔離強度，搭配最小權限原則 |
| 技術 | Progressive context disclosure | 必要 context 先給，其餘按需載入；可降低 token 成本並對抗 context rot |
| 技術 | Mutation testing | 驗證測試集真實效力，在 AI 生成測試的時代格外重要 |
| 技術 | Path-to-production mapping | 把從提交到上線的每一步畫出來；Vol.35 特別要求把 agent 也納入這張圖 |
| 技術 | Threat modeling | 與 agent sandboxing 配套，決定隔離要做到什麼程度 |
| 技術 | Post-quantum cryptography | 與 AI 無關但同樣列為立即採用；遷移期長，現在不動就來不及 |
| 工具 | OpenAI Codex | 本期升上 Adopt |
| 工具 | OpenCode | 開源 coding agent；也是企業自建 agent 的常見底座 |
| 工具 | mise | 開發環境與工具版本管理 |
| 平台 | VictoriaMetrics | 時序資料庫 |
| 語言與框架 | Open Data Contract Standard（ODCS） | 資料契約的開放標準 |
值得注意：Adopt 的 11 格裡有 6 格在技術象限，而且其中 5 格直接關於 agent 的安全、上線路徑與測試有效性。 Thoughtworks 這一期把採用建議集中在「控制」而非「能力」。
Trial：值得投資的 49 個中的重點
圍繞 harness 的一整組
- Self-improving harness〔自我改進的 harness〕——用 agent 分析執行軌跡與評估回饋，自行提議或實作對 prompt、context 策略、工作流、工具、記憶與 middleware 的修改。這是 Vol.34「feedback flywheel」的下一步：flywheel 仍需人來解讀結果並動手改，self-improving harness 則把這一步也交出去。 Thoughtworks 的建議是做有邊界的實驗並搭配回歸測試，由人設定目標與修改範圍。
- Coding harness for general-purpose agents〔用 coding harness 跑非編碼 agent〕——文件處理、維運支援、遷移規劃這類非編碼 agent，與其從通用框架自建 agent loop，不如直接站在 coding agent 的 runtime 上（Claude Agent SDK、Codex SDK、OpenCode server、Pi 的 SDK 與 RPC 模式）。這些 runtime 已經處理好長任務的 context 壓縮與 session 持久化。代價是控制權較少，換到的是一個被大量實戰測試過的迴圈。
- Subagents for better context management〔用子代理管理 context〕——重點不在平行，而在保護主 agent 的 context：探索過程、工具輸出、重試與中間推理都留在子代理，主線只收摘要。建議同時跑
2到4個；需要同一份程式碼理解的任務要留在同一個 agent 裡，避免每個 agent 各自重建一次。Thoughtworks 誠實標註：這個好處尚未被系統性量測過，證據是從業者的說法而非 token 數據。 - Agent-maintained knowledge bases〔由 agent 維護的知識庫〕——團隊共享知識放在互相連結的純文字檔（常常就是一個 Obsidian vault），由 coding agent 維護。Karpathy 的 LLM Wiki 描述了這個模式的三個部分：agent 只讀不改的原始來源、agent 維護的 wiki、以及指導它怎麼維護的 schema。Thoughtworks 的建議是從個人「第二大腦」走向團隊共用，但生成的知識會與現實脫節，需要定期人工審查，否則就變成上面那條 AI-driven documentation sprawl。
圍繞「人審不審得完」的一組
- Risk-tiered human oversight〔風險分級的人工監督〕——這是對 human-in-the-loop theater 的正面解方。把變更按可能造成的損害分級：最危險或最難回復的由人親手改、中風險的走人工審查、低風險的讓 coding agent 經 CI 自動合併。判斷分級有兩個策略：codebase zones（特定檔案或目錄一律提高審查強度）與 LLM 變更分類（會出錯），Meta 公開的流程兩者並用。
- Unattended overnight agentic builds〔無人值守的整夜建置〕——下班前把一個 feature 等級的任務交給 agent，隔天早上審結果。Thoughtworks 強調這不需要 agent 群，通常一個就夠。真正的價值在它的四個前置條件：沙箱執行、事前規格、回饋感測器、以及一套經過測試的 harness（因為一整夜的產出可能大到無法逐行審查）。做不到的團隊，可以把它當成建設這四項的目標。
- Grilling〔拷問〕——讓 coding agent 在動手前反過來訪談你的計畫，釐清模糊處。代表實作是
mattpocock/skills。它同時對抗 Vol.34 的 codebase cognitive debt：被迫檢視自己的假設，人會得到一份更清楚的實作計畫。 - Managed agents runtime〔託管的 agent 執行環境〕——把交付 agent 從開發者的工作站搬到平台上執行，由平台處理沙箱運算、觸發、憑證、session 狀態與可觀測性。適合長時間的非同步工作。建議把這個 runtime 當成正式環境的基礎設施看待，agent 定義要進版控。
模型選擇
- Open-weight models〔開放權重模型〕——Thoughtworks 說這類模型已到「顯著的轉折點」，點名 DeepSeek、GLM、Kimi 三個家族，並強調要把它們當作廣泛企業工作負載的候選，而不只是省錢方案。理由除成本外還有部署彈性、免於廠商鎖定、以及資料主權。
Assess：先看著的 47 個中的重點
| Blip | 說明 |
|---|---|
| Enterprise harness | 組織層級的共享資源層：skill、工具、內部 context 連接器、核可技術清單、ADR、上線路徑指引、hook、安全政策。類比是「給 agent 用的開發者體驗平台」。Thoughtworks 直說「目前還沒有共識該怎麼做才對」，建議保持「薄而聯邦式」 |
| Harness quality evaluation | 自建的 harness 到底有沒有用？非確定性部分（plugin、skill）用 PluginEval 這類工具評估，確定性部分（護欄）寫測試套件、測試先行開發。建議排程執行，例如每晚或隨 CI |
| Context profiling | 量測 context 實際怎麼被用掉——是上面兩條 Caution（naive context compression、blanket frontier model usage）共同指向的前置動作 |
| Agent pipeline responsibility | 讓 coding agent 一起為「保持建置綠燈」負責。看不到建置狀態的 agent，不可能遵守「紅燈不推」的團隊約定；而讓人複製錯誤日誌貼進對話框，那個人就變成了 meat proxy |
| Semantic review of AI-edited prose | 對 AI 編輯過的散文做語意審查——AI-driven documentation sprawl 的配套 |
| Production-aware coding agents | 讓 coding agent 看得到正式環境的狀態 |
| Tests as data over tests as code | 把測試當資料而非程式碼表達 |
| Local coding models | 本地端編碼模型，與 Beyond frontier models 主題呼應 |
怎麼用這份清單
Vol.34 的讀法仍然成立（見 Vol.34 判讀 末段），但 Vol.35 多了兩個該提醒的：
- Caution 這一環這期的資訊量最大。 它記錄的是「業界已經試過並撞牌的做法」，對沒有大規模 agent 部署經驗的團隊來說，這十條比 Adopt 更省錢——它讓你跳過別人已經付過的學費。
- Adopt 不等於「你現在就該有」。 本期 Adopt 高度集中在控制面（沙箱、威脅建模、上線路徑、突變測試）。如果團隊連第一個 agent 都還沒上線，這些建議的正確讀法是「這些是你擴張前必須先有的東西」，而不是「你落後了」。
- 主題比 blip 持久。 Blip 會在兩期之間改名、合併、消失（agent sandboxing 就是一例），但「harness 要當系統工程」「人的審查量能是新瓶頸」這兩個判斷，會比任何單一工具活得久。
主張 vs 可佐證
- 可佐證：
117個 blip 的四環分布（Adopt11、Trial49、Assess47、Caution10）由四個象限頁面逐一清點後加總得到，與第三方分析報出的數字一致；Adopt11個也與 Thoughtworks 官方新聞稿的說法吻合。發布日期 2026-11-04、四大主題、Rachel Laycock 的引述均出自官方新聞稿。各 blip 的說明與環級均來自 thoughtworks.com 的 blip 頁面。 - 可佐證但須小心：升降環的對照是以 Vol.34 與 Vol.35 兩期的公開清單比對推得，並以 blip 頁面上的「moves to」字樣佐證。Agent sandboxing 一項官方未明說是從 Sandboxed execution for coding agents 升環，blip 頁面只把後者列為相關條目，因此本文標註為「改名加擴大範圍」而非單純升環。
- 主張：有第三方分析指 Spec-Driven Development 本期被列入 Caution，但官方 Techniques 象限的 Caution 清單中並無此條，本文因此不採用。「Caution 比 Adopt 更有價值」「主題比 blip 持久」是本站的判讀，不是 Thoughtworks 的說法。
- 這張雷達的性質：Technology Radar 是 Thoughtworks 技術顧問委員會（TAB）依據自身客戶專案的工程意見，不是統計抽樣，也不是學術研究。它的價值在於樣本來自真實交付而非問卷，它的限制在於樣本偏向 Thoughtworks 服務的客戶型態。
🔍 待解問題
- RTK 這類 context 壓縮工具在本知識庫的實際工作流中，淨成本是正是負？Thoughtworks 的警告指向 prompt cache 失效——本站尚未實際量測過。
- Enterprise harness「薄而聯邦式」的具體邊界在哪？哪些該集中、哪些該留給團隊，Thoughtworks 自己也說沒有共識。
- Self-improving harness 與 feedback flywheel 的界線，在實務上會不會只是「人介入的頻率」差異而已？
- Vol.36（預計 2027 年上半年）——risk-tiered human oversight 與 managed agents runtime 會不會升 Adopt？
🕒 更新紀錄
- 2026-11-09 — 建立本篇。來源為 Technology Radar Vol.35（2026-11-04）官方網站四象限頁面、個別 blip 頁面與官方新聞稿。
來源：
- Technology Radar Vol.35 — Thoughtworks, 2026-11-04（Techniques、Tools、Platforms、Languages & Frameworks）
- As AI agents scale, Thoughtworks Technology Radar highlights the need for stronger controls — Thoughtworks 新聞稿, 2026-11-04
- 個別 blip 頁面：Agent sandboxing、Progressive context disclosure、Human-in-the-loop theater、Meat proxy、Agent skill cognitive surrender、AI-driven documentation sprawl、Blanket frontier model usage、Naive context compression、Stacked pull requests、Risk-tiered human oversight、Unattended overnight agentic builds、Self-improving harness、Coding harness for general-purpose agents、Subagents for better context management、Agent-maintained knowledge bases、Enterprise harness、Harness quality evaluation、Agent pipeline responsibility、Open-weight models、Grilling、Managed agents runtime