After Code is Complete, What Does AI Take Over: YC W26 Operations/Testing/Automation/Agent Infrastructure 22 Companies Fully Dissected

撰文：朗瀚威 Will

這是 YC W26 系列分析的第五篇。上一篇拆了 AI 編程工具和"Claude Code for X"（12 家），這篇看開發鏈條的另一半——程式碼寫完之後的一切：運維、測試、工作流自動化、Agent 開發基礎設施，共 22 家。

程式碼只是開始

上一篇我們講了 AI 怎麼改變"寫程式"。但寫程式只是軟體開發的一部分——程式碼寫完之後，還有部署、運維、值班、測試、bug 修復、工作流自動化，每一步都需要人。

YC W26 的 22 家公司正在做的事情是：把"程式碼寫完之後"的每一個環節都交給 AI agent。

凌晨 3 點生產環境告警？IncidentFox 在你睡覺的時候自動查日誌、定位根因、準備修復腳本，你醒來只需要 review 和批准。用戶發現了 bug？Lucent 24/7 自動看會話回放，比用戶先發現問題。需要把一個 Excel 裡的審批流程自動化？Bubble Lab 一句話搞定。

這 22 家可以分成 4 組：AI 運維/SRE（5 家）、AI 測試/QA（2 家）、AI 工作流自動化（7 家）、Agent 開發基礎設施（8 家）。

先說結論：4 條可以直接帶走的判斷

1、IncidentFox 是這 22 家裡產品最完整的。兩個前 Roblox 工程師（支撐過 1 億+日活的基礎設施），開源，300+預置集成，不到 1 天部署。核心差異化不是"用 AI 分析日誌"（誰都能做），而是"自動發現你的技術棧並自動生成集成"——省掉了最痛苦的接入工作。

2、AI 運維（5 家）和 AI 測試（2 家）合在一起做的事情是：把"程式碼品質保障"從人力密集型變成 agent 密集型。傳統的運維值班、bug 排查、回歸測試都需要工程師大量時間。這 7 家公司的賭注是：agent 能比人更快發現問題、更快定位根因，而且 7 x 24 不休息。

3、工作流自動化（7 家）是這批裡最雜但用戶最廣的一組。它們的共同點是"讓不寫程式的人也能用 AI 自動化工作"——RamAIn 用計算機視覺操作任何軟體，Bubble Lab 一句話建立自動化流程，Jinba 用聊天自動化企業工作流。這組面向的不是開發者，而是所有知識工作者。

4、Agent 開發基礎設施（8 家）是最"meta"的一組——給造 agent 的人造工具。Emdash 做開源 agent 開發環境，Overshoot 做 AI 視覺應用平台，Glue 做 agent 介面設計畫布。這組的邏輯和 Fintech 那篇裡講的"agent 經濟基礎設施"一樣：當 agent 數量爆發時，造 agent 的工具就成了剛需。

子賽道一：AI 運維/SRE——IncidentFox、Mendral、Corelayer、Sonarly、Lucent

5 家公司在做同一件事的不同切面：用 AI 替代運維工程師。

IncidentFox

官網連結：

AI SRE agent——自動分診、調查和修復生產事故，住在 Slack 裡。

核心資料：開源（Apache 2.0），GitHub 420+ stars，300+預置集成，支持 Kubernetes/AWS/Grafana/Prometheus/Datadog/PagerDuty/GitHub

商業模式：開源核心+企業版（安全沙箱、憑證代理、多團隊管理）。部署時間<1 天

團隊亮點：Jimmy Wei——前 Roblox（做社交通訊功能，服務 1 億+日活），之前在 Meta FAIR 做多方對話式 AI 研究，Cornell CS。Long Yi——前 Roblox 狀態基礎設施團隊（資料庫基礎設施，支撐 1 億+日活）。兩個人一個造 AI，一個做運維，經歷完美互補

競品/風險：PagerDuty、Incident.io（融了$50 M+）、Datadog、ServiceNow 都在往 AI 運維方向擴展。但 IncidentFox 的差異化在於"自動生成集成"——其他工具要你花幾周手動接入內部系統，IncidentFox 分析你的程式碼庫和歷史事故後自動生成

其他亮點：SOC 2 合規。每個調查跑在隔離容器裡，agent 看不到原始密鑰。還出了 Claude Code 插件，給個人開發者用

IncidentFox 的核心洞察是：AI 運維工具失敗的原因不是模型不夠強，而是整合不夠深。你的支付團隊用自研的 Kafka 管道，你的基礎設施團隊用自研的部署系統，你的 ML 團隊用自研的模型服務——通用 AI 工具根本接不進去。IncidentFox 的做法是：分析你的程式碼庫和事故歷史，自動發現缺什麼整合，自動生成。人類只需要審批。

Chris Lu 在推文裡提到 IncidentFox 的描述是"AI SRE 工程師獨立修復生產事故"。這個定位對運維工程師來說既是福音也是威脅。

Mendral（0.9 萬月訪問）做 AI DevOps 工程師。和 IncidentFox 的"事後修復"不同，Mendral 更偏"日常運維"——持續集成、部署管理、環境配置這些每天要做的事情。

Corelayer（0.4 萬月訪問）做"用資料調試的 AI 值班工程師"。強調的是資料驅動的調試——不是猜測問題在哪裡，而是用指標和日誌自動關聯。

Sonarly（0.2 萬月訪問）做生產告警 AI 工程師。更聚焦在告警處理——把海量告警分類、去重、關聯，找出真正需要人關注的那幾條。

Lucent（1.6 萬月訪問）做自動看會話回放檢測 bug 的 AI——不從程式碼層面找 bug，而是從用戶體驗層面找。AI 24/7 觀看用戶的會話錄像，自動發現卡頓、報錯、異常流程，然後在 Slack 和 Linear 裡建立 bug 工單並附上完整的復現上下文。

創始人 Alisa Rae 的故事本身就值得講：澳洲人，之前 bootstrap 創辦並賣掉了一個教育科技公司，是 MagicBrief 的 2 號員工（後被 Canva 收購），在 Atlassian 做過富文本編輯器。第一次申請 YC 被拒，建議"找個聯合創始人"。她堅持 solo 路線，融了$2 M 種子輪，第二次申請入選。已被 30+家 YC 公司使用，創始人反饋：“第一周就發現了 7 個從沒見過的 bug”、“第一周就回本了”。94%的用戶遇到 bug 不會報告，直接流失——這就是 Lucent 存在的理由。

5 家的共同邏輯：運維工程師的大部分時間不是在"修問題"，而是在"找問題"。從數十個監控系統裡關聯信號、翻日誌、查最近的部署變更——這個調查過程佔了平均修復時間的 80%。AI agent 能同時查所有資料源、秒級關聯，把"找問題"的時間從小時級壓縮到分鐘級。

子賽道二：AI 測試/QA——Canary、Ashr

2 家公司做 AI 測試。

Canary做"第一個理解你程式碼庫的 AI QA 工程師"。關鍵詞是"理解程式碼庫"——不是通用的測試工具，而是先讀懂你的程式碼邏輯，然後針對性地生成測試用例。傳統的 AI 測試工具生成的用例往往和實際程式碼脫節。

官網連結：

Ashr做 agent 自動化多模態測試。"多模態"意味著不只測文字界面，還測圖像、影片、語音等互動。隨著 AI 應用越來越多地使用多模態輸入輸出，測試工具也需要跟上。

子賽道三：AI 工作流自動化——RamAIn、Bubble Lab、Jinba、Ressl AI、EigenPal、Carson、Crow

這是面向最廣的一組——用戶不是開發者，而是所有需要自動化工作的人。

RamAIn

官網連結：

“世界上最快的電腦使用 agent”——教 AI 像人一樣操作你的電腦，在瀏覽器和桌面應用之間搬資料。

核心資料：3.5 萬月訪問，已有採購、保險、醫療、財務團隊在用。幾天內完成部署

團隊亮點：兩個 IIT Delhi 學生——CEO Shourya 之前在 McKinsey 做企業 AI 項目，創辦過 Genoshi（AI 工作室，bootstrap 做到六位數收入），還是 FIDE 國際象棋 2118 分選手，代表印度參加過 17 國比賽

商業模式：企業級——在遺留系統、桌面應用和網頁入口之間自動搬運資料。採購團隊（ERP+供應商入口）、保險經紀（承保商入口）、醫療機構（電子病歷+實驗室入口）、財務團隊（收入週期管理）都是目標客戶

競品/風險：Anthropic 的 Computer Use、OpenAI 的 Operator 是最大威脅。RamAIn 的差異化在於"預訓練在特定界面上"——通用 CUA（截圖→視覺模型→決策→重複）又貴又慢又不穩定，RamAIn 先學會你的界面再自動化。還有"自愈"能力——UI 變了不會崩，這是傳統 RPA 的致命傷

Bubble Lab（1.9 萬月訪問）做"一次提示，永久自動化"。把重複的工作流程用一句話變成自動化流程。定位比 Zapier 更簡單——Zapier 你還需要配置觸發條件和步驟，Bubble Lab 你只需要描述你想自動化什麼。

Jinba（1.7 萬月訪問）做"透過聊天自動化任何企業工作流"。面向企業，在聊天界面裡觸發審批、資料流轉、系統對接等工作流。

Ressl AI（1.7 萬月訪問）做 ERP/CRM 配置 agent。企業上了 Salesforce 或 SAP 之後，配置和定制是一個巨大的工程。Ressl AI 用 AI agent 來做這些配置工作。

EigenPal（0.9 萬月訪問）做企業 AI 文件工作流。Carson 做桌面 AI 工作空間（我們在 OpenClaw 那篇裡已經詳細拆過，這裡不重複）。Crow（2.5 萬月訪問）做"讓用戶透過聊天控制你的應用"——給任何 SaaS 產品加一個 AI 聊天層，用戶不用學界面操作，直接用聊天完成任務。

7 家的共同邏輯：AI 編程降低了"寫程式"的門檻，但大多數工作根本不需要寫程式——需要的是把現有工具串起來、把重複流程自動化。這組公司做的就是"不寫程式的自動化"。

子賽道四：Agent 開發基礎設施——Emdash、Overshoot、Cardboard、Glue、Sila、Valgo、SideKit、Wideframe

給造 agent 的人造工具。

Emdash（2.3 萬月訪問）做開源 agent 開發環境——6 萬+下載，2430 GitHub stars。支持並行跑多個編碼 agent，任意模型供應商。和上一篇講的 1 code 定位接近但更強調開源和模型無關性。

官網連結：

Overshoot（1.6 萬月訪問）做 AI 視覺應用平台——幫開發者構建和運行 AI 視覺應用。隨著多模態模型普及，"能看圖的 AI 應用"是個快速成長的品類。

Cardboard（0.7 萬月訪問）做 agent 影片編輯器。AI agent 可以自動剪輯、拼接、添加字幕和特效。影片製作傳統上需要專業技能和昂貴軟體，Cardboard 想把門檻降到"告訴 agent 你想要什麼效果"。

Glue 做 agent 介面設計畫布——當你的 AI agent 需要一個前端介面時，Glue 幫你設計。隨著越來越多的 agent 需要可視化的操作面板，這個需求會增長。

Sila 做 agent 工作區訊息——給 agent 之間的通訊提供基礎設施。當多個 agent 需要協同工作時，它們之間怎麼傳遞資訊？Sila 解決這個問題。

Valgo（0.3 萬月訪問）做自主系統演算法安全驗證。SideKit（0.2 萬月訪問）做移動應用部署一站式方案（這批裡少見的非 AI 公司）。Wideframe 做影片編輯 AI 協作者。

22 家放在一起看

幾個觀察：

第一，AI 運維（5 家）是這 22 家裡產品成熟度最高的一組。IncidentFox 已經開源、有 300+集成、SOC 2 合規。這不是偶然——運維是 AI 最容易證明價值的場景之一：修復時間從幾小時降到幾分鐘，直接可衡量。

第二，工作流自動化（7 家）面對的最大競爭不是彼此，而是現有的自動化工具——Zapier、Make、n8n。AI 的加入讓這些工具"更智能"，但現有工具也在快速加 AI 功能。7 家小公司要在 Zapier（估值超$50 億）面前活下來，需要找到足夠窄的切入點。

第三，Agent 開發基礎設施（8 家）是最長期的賭注。現在 agent 的數量還不夠多，基礎設施的價值還不明顯。但如果 agent 經濟真的爆發（Fintech 那篇裡我們已經看到 Sponge 在給 agent 開銀行帳戶），造 agent 的工具鏈就會成為下一個雲基礎設施級別的機會。

第四，這 22 家全是 B2B。和這個系列所有篇目一樣——YC W26 是一個徹底的 B2B batch。AI 工具賣給企業和開發者，不賣給消費者。

對中國團隊的啟示

第一，AI 運維在中國的需求巨大。中國的網路公司（字節、阿里、騰訊、美團）運維規模不比美國小，但運維工具的 AI 化程度還不高。國內的監控系統（阿里的 ARMS、字節的 APMPlus）還沒有像 Datadog 那樣大力推 AI 功能。如果有團隊做"中國版 IncidentFox"——接入國內主流監控系統、支持中文日誌分析、理解國內技術棧，市場是存在的。

第二，工作流自動化在中國有一個特殊場景——钉钉和飞书。這兩個平台是中國企業的核心工作入口，但它們的自動化能力還比較初級。如果有團隊做"钉钉/飞书裡的 AI 工作流自動化"（類似 Jinba 對 Slack 做的事情），會比從零搭建一個新平台更容易起量。

第三，Agent 開發工具在中國還是空白。美國已經有 Emdash、Glue、Sila 在做 agent 開發鏈條的各個環節，中國還沒有對等的工具。隨著國內 agent 開發者增多，這個市場會打開。

可以帶走的判斷

1、AI 運維的核心瓶頸不是模型能力，而是整合深度。IncidentFox 的"自動生成整合"思路值得所有做企業 AI 工具的團隊學習——你的 AI 再聰明，如果接不進客戶的系統，就什麼都做不了。

2、"不寫程式的自動化"正在成為一個獨立品類。RamAIn（3.5 萬月訪問）、Bubble Lab（1.9 萬）、Crow（2.5 萬）的流量說明需求是真實的。這些工具面向的不是開發者，而是所有知識工作者——這個市場比開發者工具大 10 倍。

3、Agent 開發基礎設施是"長期正確但短期不賺錢"的方向。就像 2010 年做雲基礎設施一樣——當時雲上的應用不多，基礎設施看起來過剩。但當應用爆發後，基礎設施成了最賺錢的層。Agent 基礎設施可能會重複這個故事。

4、這 22 家加上上一篇的 12 家，DevTools 賽道總共 34 家——是整個 W26 最大的賽道。這反映了一個事實：AI 首先改變的是"造軟體的方式"，然後才是其他行業。開發者工具是 AI 的"本壘"。