AI Agent 跨不進 production 的真相：四道關卡、九成企業不及格，跟賺這條溝錢的人

TL;DR

• 過去三個月我聽了七集 podcast，講的人有 AWS 高管、Redis 的 AI product lead、做了四十年企業架構的老兵、三家 infra 新創創辦人、兩位資安從業者，結論收斂成同一句話：AI Agent 的瓶頸不在模型智力，在 demo 到 production 之間那道溝。
• Eric Broda 把溝講得最白：所有企業應用都會被三個 gatekeeper 擋下來，CSO 問 security、營運長問 observability、企業架構師問 distributed computing。這三題 demo 影片裡一題都不會出現。
• Context 是第一道關卡：agent 自主工作時間每六個月翻倍，現在約一小時，naive RAG 那種一次性預載的架構已經撐不住。Redis 的答案是 materialized view 加 semantic layer 的 Context Engine。
• 驗證的正解反直覺：不是讓 AI 更聰明，是別讓它看到不該看的。HappyRobot 談判的底價根本不放進 context window；AWS DevOps Agent 內部準確率 85% 到 95%，工程師的角色從調查變成審計。
• 安全最慘烈：Anthropic 五月底發布的 Zero Trust for AI Agents 框架分成 Foundation、Enterprise、Advanced 三層，Practical AI 主持人直說九成以上企業連最低標 Foundation 都沒做到。
• 基建要整層重做：Daytona 60 毫秒開一台 sandbox、單日峰值近 85 萬台、月成長 74%；Railway 自建 bare metal 機房三個月回本、毛利七成以上。agent 要的跟人類一樣，只是要快一千倍、並行一千個。
• 這條溝已經有人在賺錢，而且賺的都是「溝」的錢，不是模型的錢。時間表參考 Broda 的判斷：16 到 18 個月內 agentic process automation 爆發。

昨天上架的 Software Engineering Daily，AWS Agentic DevOps 負責人 Neha Goswami 描述了一個很有畫面的場景：凌晨三點 alarm 響，工程師被 page 醒，但這次打開 ticket 看到的不是一片混亂的活躍事故，是 agent 已經整理好的時間軸、涉及的系統、根因假設、推理過程跟建議的緩解步驟。工程師做的事從「從零開始調查」變成「審計 agent 的工作」。內部測試準確率 85% 到 95%，加上團隊自己的 runbook 可以推到高九十。

這聽起來像 AI Agent 終於走進 production 的證據。但把我過去三個月聽的七集 podcast 攤開來拼，會發現 AWS 這個案例之所以值得講，正是因為它是少數。絕大多數企業的 agent 還卡在同一條線上：demo 很炫，production 上不去。講的人身分完全不同，有大廠高管、有創辦人、有在銀行做了四十年架構的顧問、有天天泡在國防資安現場的工程師，但他們描述的是同一道溝。

這篇就是把七條線拼成一張圖：那道溝到底由什麼組成，我拆成 context、驗證、安全、基建四道關卡，最後看誰已經在賺這條溝的錢。

一、溝是真的：lab 跑得起來，production 上不去

Eric Broda 在科技業做了快四十年，主要幫大銀行跟保險公司做架構，三月剛出了《Agentic Mesh》這本書。他說客戶最常抱怨的一句話是：「我做的 demo 在 lab 裡跑得好好的，但就是 ship 不到 production。」

原因很簡單，但被嚴重低估。所有 enterprise 應用都會被三個 gatekeeper 擋住：CSO 會問「你怎麼做 trust 跟 security」；營運長會問「我看不看得到這東西在做什麼，traceability 跟 observability 怎麼接進我的 ops infrastructure」；企業架構師會問「你 distributed computing 的設計合不合理」。

而寫 agent 的人通常是兩種：PoC 階段的新手，或極其聰明但對 enterprise-grade 沒概念的資料科學家。Broda 講得很直接：「我見過的資料科學家大部分都是天才，但他們不懂上 production 要過幾關。」這個 mismatch 才是真正的卡點，不是模型不夠聰明。

規模再放大一層，問題會變質。Jensen Huang、Andy Jassy 都講過同一句話的變體：未來每個企業裡會有幾十萬甚至上百萬個 agent。到這個數量級，就不是「怎麼做出一個好 agent」的問題了，是 distributed computing 跟 ecosystem 設計的問題。一個 Python 程式裡塞幾個 agent 跑在你的 MacBook 上，跟一千個 agent 在 K8s 上互相溝通、跑 long-running conversation、管理 state，是兩個世界。大家現在都在用 framework 寫第一種。

Redis 的 AI product lead Simba Khadder 給了一個很好的分層判斷，我認為是 2026 年 engineering leader 最需要的能力：「我所有 demo 都是 vibe code 的，但我不會 vibe code 資料庫。」demo 跟一次性工具可以快，database core 跟企業架構需要 spec、architecture review、behavior test。速度和嚴謹不衝突，你要清楚哪個層級適用哪一種。企業導 agent 卡關，往往就是把 demo 那套方法論直接搬進了需要嚴謹的層級。

而且這道溝正在被 AI 自己拉大。Neha 開場的框架很精準：AI coding agent 讓程式碼產出速度暴增，code review 堆積更多、部署壓力更大，下游的 DevOps 變成第一個承壓點，所以 agentic 對 DevOps 來說「既是催化劑也是解藥」。上游生產越快，這道溝沒補好的代價就越大。

順帶回答一個常見問題：那能不能做一個超大的 mono-agent，把所有 context 塞進去，繞過 ecosystem 的複雜度？Broda 直接套 Conway's Law：沃爾瑪幾百萬員工不會用一個人從頭管到尾，因為決策要靠近行動點。巨型單體是拿 agility 換 cost，大公司一旦多部門多業務線，就跟跨部門 monolith 一樣，永遠搞不清楚誰 own，技術債指數成長。agent 架構該切成 fleet 跟 ecosystem，不要做巨型單體。

這些觀察跟 Box CEO Aaron Levie 之前講的完全一致：問題不是模型不夠聰明，是資料混亂、權限複雜、agent identity 是全新挑戰，細節可以回頭看我之前整理的那篇。接下來四道關卡，就是把「溝」拆開來看。

二、第一道關卡 context：agent 能自主一小時後，naive RAG 就死了

先丟一個數字。一年前 agent 能自主工作五分鐘，現在大約一小時，Anthropic 估每六個月翻倍。也就是說再過一年，它可以自己跑四小時沒人看。

Simba 的觀察是，這波進步不是模型「智力」暴增，是 post-training 的 RL 讓 agent 能維持更長的 coherence，「持續工作的耐力」大幅提升。結果就是 naive RAG 撐不住了。以前的套路是把 knowledge base 切塊、embed、一次 retrieval 塞進 context window，但 agent 要連續工作一小時以上，你根本預測不到它接下來需要什麼。Context window 夠大也沒用，瓶頸早就從「塞得下多少」變成「如何動態取得」。

Redis 的答案叫 Context Engine，四個支柱：agent 要能自主 navigate 跟 retrieve；資料永遠最新；取用要快（每次 tool call 跑三分鐘 Spark query，體感就徹底不像 agent 了）；context 會隨時間變好。實作核心是 materialized view 疊 semantic layer。這裡有個關鍵：別讓 agent 直接打 production DB。很多團隊第一個反應是給 agent 直接連 Postgres，Simba 的反應是「那是生產資料庫，你確定？」主持人立刻接了一句「它是不是把資料庫刪了」。正確做法是用 ETL 建 materialized view，疊一層 semantic layer，compile 成 agent 能呼叫的 tools，順便拿到 row level ACL、agent level RBAC 這些企業真正在乎的東西。

semantic layer 這層還有個設計哲學值得記。Simba 觀察到很多表格 schema 是為 compute 最佳化設計的，denormalized 到連人類都讀得痛苦，agent 時代需要的是「人類好讀、agent 也好讀」的另一種 schema。他的推論很有意思：ORM 為什麼比 raw SQL 流行？不是效能，是好 reason about。GraphQL 為什麼沒幹掉 REST？因為給了太多 freedom，人類寫不好。但 agent 會很愛 GraphQL 那種彈性，前提是你不真的給它一個 GraphQL server，它會寫出很爛的 query 打爆你。正解是把 ORM 的「容易 reason」加上 GraphQL 的「彈性」，套在 materialized view 上，就是 Context Engine 的完整形狀。

第四個支柱「context 會變好」最容易做壞。Simba 的 mental model 是：memory 不是 agent 同步寫入資料庫那麼單純，大部分有意義的記憶更新是 async 發生的，要有背景 process 持續把原始 trace 抽成可用的記憶，處理壓縮、衰減、矛盾取捨。他自己用 ChatGPT 規劃婚禮，婚禮結束很久之後它還在提醒「你的婚禮快到了」，這就是沒有 temporal decay 的經典壞法。

同一道關卡，HappyRobot 從應用端給出了另一半答案。這家幫貨運物流部署 AI 員工的公司，客戶包含全美前十大貨運經紀商裡的九家。他們的判斷是：真正的護城河不在模型，在「執行工作時累積下來的 context」。很多企業都在等資料清乾淨了才敢讓 agent 上工，共同創辦人 Luis Paarup 認為順序錯了：你是透過讓 agent 真的去執行工作，順手把資料源一步步清乾淨的。系統裡一筆貨運紀錄本身沒什麼意義，每家公司都長一樣；真正有意義的是「這家企業拿到這筆紀錄之後會怎麼處理」，那些散落在會議記錄、email、隨口對話裡的部落知識，軟體從來沒抓到過。

他們還有一個「工作金字塔」的框架：底層是量大值低的重複雜事，頂層是真正驅動營收的決策。所有人都卡在底層搶著自動化一個小角落，爬不上去的原因就是 context 不夠：你要往上爬，得先跨頻道、跨部門把 context 抓起來。維修 agent 打電話問卡車什麼時候修好，看起來是孤島任務，但越早知道卡車修好，就能越早把它當運力賣出去。「維修」跟「銷售」是綁在一起的，只有共享的 context 層看得到這件事。

Simba 那句收尾的狠話值得抄下來：「Attention Is All You Need」把我們帶到今天，但接下來做真產品的人，應該假設 attention 是別人的事，真正的護城河全部都在 context。

三、第二道關卡驗證：確定性沒有死，只是搬家了

企業第二個過不去的坎：LLM 是機率性的，企業流程要的是確定性。這七集裡有三個人給了同一個方向的答案，而且都反直覺：不是把 AI 變得更可靠，是重新安排「哪些事根本不交給 AI」。

最漂亮的案例是 HappyRobot 的談判設計。物流業最怕的問題：語音 AI 談運價時亂喊數字，或直接把公司能接受的底價（max buy）吐出來。他們的解法是架一層 proxy，只餵 agent 真正需要的資訊。那個底價？根本不放進 context window。談判邏輯用外部演算法跑，AI 只能像真人一樣開口：「這個價格我得問一下我老闆。」說白了，你不需要讓 AI 看到它不需要看的東西。真實世界一定有人想 jailbreak 你的 agent 套出底價，護欄先做好，C.H. Robinson 這種大客戶才會信你。

AWS DevOps Agent 的流程設計把「人類當審計者」這件事講得最具體。團隊先設定好 resolver group 跟資源，agent 預先建立系統拓撲圖；alarm 超過閾值時系統自動切 ticket、同時 page 工程師，agent 在工程師被叫醒的同時開始沿著拓撲推理。剩下那 5% 到 15% 的失敗案例，通常是 agent 錯誤關聯了資料，工程師審計時會發現假設不對，責任仍然在人身上。這個分工不是把人踢出迴圈，是讓人做更高層次的判斷。還有一個很實際的小功能叫 triage agent，專門做事件去重：五張 ticket 可能只有一個根因，agent 幫你合併，這對按 active agent task hours 計費的帳單也有直接影響。

Neha 還給了一個更系統性的說法：確定性沒有消失，是被「注入」到三個地方。第一是權限邊界，agent 預設唯讀，擴權必須是使用者有意識的決定；第二是自動化測試，agent 建議的改動先進測試環境驗證；第三是 automated reasoning，用數學方式建模系統狀態、偵測非預期的 drift，跟 LLM 是完全不同的技術路線，剛好互補。這跟我之前寫的 formal methods 變成 agent 防護牆是同一個趨勢：agent 做的決策越多，你越需要一個非機率性的機制兜底。

第三塊拼圖是 Broda 講的 explainability，我認為是整個驗證題裡最被低估的。現在大家都會做 traceability，conversation ID、correlation ID 一應俱全，但那些只能告訴你「事後發生了什麼」，回答不了「agent 本來想做什麼」。他的提案：每次請求進來，agent 把 task plan 結構化記下來，要拆哪些步驟、叫哪些 sub-agent、用哪些 tool 全部 log，事後跟 observability log 對照，你就看得到「想的」跟「做的」差在哪。延伸效益是 task plan 是結構化的、可以驗證，比只看最終輸出的 agent 測試強太多。

最後補一個工程團隊內部的視角。Simba 的 heuristic 是 behavior test 決定一切：behavior test 寫對、跑過了，code 就是對的，race condition 重要就寫進去，沒寫就是不夠重要。而他自己用 BugBot 的經驗是每次都抓出人眼看不到的 race condition，「我看它怎麼推的，我就放棄了，我這輩子不可能靠人眼把這些線索串起來」。AI 寫 code 的速度早就快到沒人真的在看 code，驗證的重心本來就該從人眼 review 移到結構化的驗證機制上。

把三條線疊起來，驗證這道關卡的解法其實很一致：AI 負責機率性的推理，確定性交給權限邊界、外部演算法、結構化測試。人類的角色從執行者變成審計者。

四、第三道關卡安全：你自己放進來的 agent，可能比駭客危險

如果 context 跟驗證是工程問題，安全就是意識問題，而現況慘到有具體數字。

Anthropic 五月底發布了 Zero Trust for AI Agents 框架，Practical AI 那集找了兩個背景夠硬的人來拆：Prediction Guard 創辦人 Daniel Whitenack 跟洛克希德馬丁的 AI 研究工程師 Chris Benson。傳統資安是 perimeter-based，牆內都信任；Zero Trust 假設威脅已經在牆內，每個請求都重新驗證。這概念不新，NIST 2020 年就發過文件。問題是套到 agent 上難度整個跳級，因為 agent 會自己解讀指令、自己設法達成目標、跨對話保留 context，攻擊面又大又活。

框架引進兩個詞值得記：blast radius，這個 agent 失控能造成多大破壞；least agency，OWASP 提的概念，agent 需要多少權限就給多少，多一點都不行。威脅清單裡最有畫面的是 prompt injection 的間接版本：Daniel 幫別家公司出面試題，在 PDF 裡用白色文字藏了大半頁指令，要應試者的 Claude Code 做出跟題目相反的事，純粹想看有沒有人抓得到。這聽起來像惡作劇，但你的 agent 連著公司信箱，一封夾帶隱藏指令的附件就能把它牽著走。再加上 memory 下毒（往向量資料庫塞假資料，已被證實可行）、惡意 MCP server、agent 隨手生出權限過大的子 agent，傳統資安漏洞一個都沒消失，上面還疊了一層會自己亂跑的東西。

Anthropic 的解法設計得很務實，每個防禦面向切三層：

層級	定位	白話
Foundation	最低可行標準	至少做到這個，不然整個裸奔
Enterprise	企業級	真正在營運、需要韌性的公司該做的
Advanced	進階	高度監管環境，或當成努力目標

關鍵面向包含 agent 身分與認證（Foundation 是每個 agent 一個獨一無二的加密識別碼，Advanced 是硬體綁定憑證）、預設拒絕的存取控制、可觀測性加行為監控、完整性與復原。但整集最重要的一句話是 Daniel 說的：九成以上的企業現在連 Foundation 都沒做到。這份文件對多數公司是理想目標，不是現況。

這裡跟 Broda 的 KYA（Know Your Agent）框架剛好接上。你信任銀行櫃員開戶，是因為 HR 走過 background check、training、performance review，那為什麼對 agent 這麼放心？KYA 直接抄 KYC 的功課：每個 agent 要有 persistent identity，有了 identity 才能給 permissions 跟 roles，加上 explainability log，然後你就可以對 agent 做 performance review。Broda 更遠的想像是 UL 那種第三方認證：拿起一個 agent 翻過來，底下有個 logo 告訴你「這東西不會把你的 data center 燒掉」。

那為什麼還是得導？因為攻擊方也拿到了一樣的武器。駭客手上也有 agentic coding 能力，攻擊的速度和規模呈指數級膨脹，當漏洞被利用的時間線從幾個月壓縮到幾分鐘，你不可能靠「半夜把資安長叫醒批准關機」這種流程。Daniel 把這叫 forcing function：你被逼著導入自主 agent，因為只有 agent 追得上 agent 的攻擊速度。用 agent 防守、同時管好自己的 agent 不造反，這就是 Zero Trust 要解的題。

五、第四道關卡基建：agent 要的跟人類一樣，只是快一千倍

前三道關卡都過了，還有最底層的一道：現有的雲端基建根本不是為 agent 設計的。

Railway 創辦人 Jake Cooper 的說法我覺得最精準。被問「agent 要的跟人類有什麼不一樣」，他的答案是「沒太多不一樣」：版本控制、分支環境、observability、讀寫檔案、fork 一份 production 的 read-only copy 出來實驗，這些人類工程師早就要了。差別在 agent 要快一千倍、要能並行跑一千個。壓縮到這種規模，整個 stack 的假設被打掉重練：Kubernetes 不夠快、Envoy 不夠輕、CI/CD 那套會直接融化。

Daytona 是這個論點最好的實證。他們本來做人類工程師的 dev environment，把現有 infra 包成 sandbox 給二三十個寫 agent 的人試，每一個都說「不行，這不是我要的」。創辦人 Ivan Burazin 當時跟所有人一樣，以為 agent 用的 infra 跟人類差不多，反正都是 EC2 跟 VM。市場說：不是。重做之後的版本，每場 15 分鐘的 demo call 全部變成 30 分鐘，每個人都說「給我 API key」。現在 Daytona 月成長 74%，最大客戶單日跑近 85 萬個 sandbox：60 毫秒開一台、75 秒同時開五萬台，跑在 bare metal 上、自己寫 scheduler。Ivan 的比喻是把 lambda 跟 EC2 的優點縫在一起：agent 要 lambda 的秒級開機，又要 EC2 的 pause/resume 跟持久狀態，是「闔上筆電去喝咖啡，回來打開繼續」那種互動模型。

agent 的用量曲線也跟人類不一樣，Daytona 內部切成兩類：long-running agent 跟人類一樣 follow the sun，中午尖峰、週末降一半；RL 跟 evals 是鋸齒狀超級尖峰，研究員半夜下 job，瞬間吃滿五萬到十萬個 CPU，跑完歸零。所以 Daytona 的平均利用率只有 15%，尖峰衝到 90%，你必須為峰值 over-provision。這種 workload 形狀，公有雲的計價跟排程模型都接不住。

經濟結構上也有一個值得注意的翻轉：自建硬體回來了。Railway 大部分流量跑在自家 bare metal 機房，同樣的工作負載放雲端要花的錢，自建三個月就賺回來，硬體折舊四年，毛利衝上七成以上，買硬體用的還不是股權而是 data center debt，拿伺服器當抵押跟銀行借。Jake 那句「VC 是你能拿到的最貴的融資」是題外話，但這個結構是他敢提供「並行跑一千個 agent」體驗的底氣。當 agent 的用量是人類的千倍規模，單位成本就是產品力本身。

通訊層也一樣要重做。Broda 的架構判斷是：兩個 agent 之間用 HTTP request/response 撐不久。HTTP 是同步的，但 agent 之間是 long-running conversation；加 endpoint 要做一堆 network configuration；狀態斷掉就斷掉，沒有原生的 replay。換成 Kafka 那種 event streaming backbone 就不一樣了：topic namespace 統一、新增 topic 不用動網路、pub/sub 天然適合「不知道誰會接」的場景、事件還能 replay。A2A 跟 MCP 這兩個 protocol 都會留下來，但都不是終點。

還有一整排空缺等著被填：GitHub 的 sync 延遲對 agent 太慢，有客戶把整個 codebase dump 成 JSON 丟 S3 當自己的 git；有公司一天跑一千個 PR，所有 CI provider 都被卡到排隊；Ivan 還點名 computer use 是 agent 的 god app，美國知識工作的時間市場約 10 兆美金，大量工作還鎖在 Windows 傳統 app 裡，所以他們押重注做秒級啟動的 Windows sandbox。順帶一提 Mac OS：授權限制讓一台機器只能跑兩個 VM、license 24 小時內不能換人、snapshot 不能跨機器搬，等於 Apple 自己把幾百億美金的 agentic compute 市場關在門外。

六、誰在賺這條溝的錢

把七集裡出現的玩家跟他們卡的位置排成一張表：

溝的環節	玩家	證據
Context 交付層	Redis（併購 Featureform）	RDI 做 materialized view 同步、Agent Memory Server 開源專案
執行層 context	HappyRobot	前十大貨運經紀商 9 家、DHL 80 國部署 40+ agent、a16z 領投 A 輪加 4,400 萬 B 輪
Agent sandbox	Daytona	月成長 74%、單日近 85 萬 sandbox、2,400 萬美元 A 輪
Agent 原生雲	Railway	300 萬用戶、31% 的 Fortune 500 在用、1 億美元 Series B
事故調查 agent	AWS DevOps Agent	三月 GA、按 active agent task hours 計費
Agent 治理與安全	Prediction Guard 等	Zero Trust 框架剛出，九成企業連 Foundation 都沒做到，全是待開發市場

看這張表有兩個重點。第一，這些公司賺的全是「溝」的錢：沒有一家在賭模型變強，全部在賭「模型再強，企業還是需要 context、驗證、安全、基建這四層」。HappyRobot 有些場景用的還是一年半前的模型，Luis 講得很白：「打電話給司機問他來不來得及，你不需要 PhD 等級的智慧。」智慧早就夠用了，卡住落地的從來是別的東西。他們押重注的地方也很說明問題：不是延遲更低、聲音更真，是 turn-taking，判斷對方講完話沒有。模型越快反而越容易亂插嘴，遇到難的問題該觸發非同步思考、發出一個「嗯」然後真的在想。當大家都在等十兆 token context window 的怪獸模型，他們盯的是「什麼時候該閉嘴」這種真正卡住落地的瓶頸。盯著瓶頸而不是追最性感的指標，這個心法放到任何做 AI 產品的人身上都成立。

第二，商業模式在換軌。Ivan 對「SaaS 公司包 agent 一起賣、營收再加速」潑了一桶冷水：舊營收有 SaaS 的毛利跟黏性，新的 agent 營收很大一部分是過水給 Anthropic、OpenAI 的 token 錢，毛利結構完全不一樣，市場現在還在用 ARR 加速這種 SaaS 時代的指標評價 token consumption 的生意，等大家發現毛利沒跟上，會有一波冷水。這放在 SaaSpocalypse 那波軟體股拋售的脈絡看特別清楚。方向大概是 Benioff 那條 tweet 的路線：把所有產品暴露成 API，seat-based pricing 留給人類，consumption 留給 agent。誰先把計價基礎打好誰先賺。

至於什麼場景先落地，Broda 給的答案很具體：合規文件處理是甜蜜點，四五百家機構寄來格式完全不統一的文件，agent 能處理 ambiguity、24/7 運作、know-how 留在公司；支付系統先別碰，那需要百分之百 deterministic。他的時間表是 16 到 18 個月內 agentic process automation 成熟，24 到 36 個月 agentic resource management 普及，到時候 HR 的對象會包含 agent：怎麼 onboard、怎麼 train、怎麼考核。

最後講一下人。這道溝跨過去之後，工程組織的形狀會變。Redis 內部的工作流已經重寫：每天有 design session，工程師上來講 interface 長什麼樣、acceptance criteria 是什麼，架構對了「agent 實作出來的東西 98% 是對的」；Simba 自己快一年沒寫過一行 code，但他認為自己變成更好的工程師，因為 agent 最做不好的是「在百萬行 code 裡維持一致的架構」，那才是人該花時間的地方。Railway 一個月燒 30 萬美金在 coding agent 上，Jake 的講法更兇：「還在手寫程式碼就是錯。」AWS 那邊 Neha 的觀察比較溫和但方向相同：SRE 不會消失，簡單的 pattern matching 被 agent 接走，人面對的是 agent 搞不定的複雜場景。角色邊界在模糊化，但角色本身沒有消失。

寫在最後

七集聽完，我的結論可以壓成一句：AI Agent 的 demo 到 production 之間不是一步之遙，是四道關卡，而且每一道都不性感。Trust framework、explainability、event streaming、materialized view、sandbox scheduler，這些東西不會出現在 demo 影片裡，但少一個你都進不了 production。反過來說，正因為不性感，這條溝的錢才輪得到基礎設施公司賺，而不是全被 model lab 拿走。

對台灣讀者，我覺得有兩個切點。第一，台灣企業的 IT 現場跟 Ivan 描述的美國一樣，大量流程鎖在 Windows 傳統 app 跟 Excel 裡，computer use 成熟的那天，先把內部流程盤點清楚的公司會先吃到自動化紅利，而金融、製造這些高監管產業，Zero Trust 那張三層表會直接變成採購 checklist。第二，對做 B2B 的新創，HappyRobot 的路線值得抄：不要做又一個 chatbot，去搶「執行層」，先把活幹起來，context 跟資料護城河是執行出來的，不是等出來的。

接下來 12 到 18 個月我會盯三件事：Broda 那個 agentic process automation 的 16 到 18 個月時間表有沒有兌現；agent 原生工具鏈的空缺（CI、版本控制、Windows sandbox）被誰補上；還有 agent 的第三方認證機制有沒有出現，也就是 KYA 那個「翻過來看 logo」的想像落不落地。這三條線的交點，就是 agent 真正跨過那道溝的時刻。

---

本文整併自 2026 年 4 月到 7 月的七集 podcast：Software Engineering Daily 訪 Redis AI product lead Simba Khadder、訪 Agentic Mesh 作者 Eric Broda、訪 AWS Agentic DevOps 負責人 Neha Goswami；Latent Space 訪 Railway 創辦人 Jake Cooper、訪 Daytona 創辦人 Ivan Burazin；Practical AI 談 Anthropic Zero Trust 框架（Daniel Whitenack、Chris Benson）；a16z Podcast 訪 HappyRobot 創辦人 Pablo Palafox 與 Luis Paarup。

這類把多集 podcast 串成一張產業地圖的深度文，我會持續寫，訂閱 wilsonhuang.xyz 就不會漏掉。

Sources:

• Redis Acquires Featureform
• Agentic Mesh Book - O'Reilly
• Giving Agents Computers - Ivan Burazin, Daytona | Latent Space
• Railway secures $100 million Series B - VentureBeat
• a16z 投資 HappyRobot 公告
• Practical AI | Daniel Whitenack