Dify：把可觀察性內建進 LLMOps 的開源應用平台
把一個 LLM demo 寫出來不難，難的是把它推上線之後還能活著。prompt 改一版就悄悄退化、RAG 檢索回一堆不相干的片段、agent 在某個分支無限迴圈燒 token，這些問題在 Jupyter notebook 裡看不到，只有在真實使用者的流量下才會浮現。多數自己用 LangChain 從零拼起來的專案，最…
Sim：把 agent 管線畫成可執行圖的視覺化 workflow builder
把 LLM agent 串成多步驟管線這件事，寫過的人都知道兩個痛點：一是流程一長就變成散落在程式碼裡的 if/else 與 prompt 字串，改一個節點要翻好幾個檔案；二是跑壞了很難查，一條鏈跨了五六個模型呼叫與工具，最後只丟回一句錯誤訊息，根本不知道是哪一步的輸入被污染。
Open Agent Platform：疊在 LangGraph 之上的無程式碼 agent 設定層
做 agent 的人大概都遇過同一個岔路：要嘛用 LangGraph 這種 code-first 的框架，把每個節點、每條邊、每個路由條件都寫進 Python，控制力最強但門檻也最高；要嘛選一個純拖拉的無程式碼平台，好上手，但底層那張流程圖被包在黑箱裡，路由邏輯改不動、也搬不走。這中間一直缺一塊：讓非工程師也能配置 a…
AnythingLLM：把 RAG、agent 與文件管理裝進一個自託管 workspace
想在公司內部弄一個「問我們自己文件的 ChatGPT」，通常會撞到一連串選型題：模型接哪家、向量資料庫用哪套、文件怎麼切塊、多人怎麼分權、要不要為了資料不外流而全部自架。每一項都有一堆開源零件可以拼，但拼完你會發現自己在維護的其實是一條 pipeline，而不是一個產品。
AutoAgent：用自然語言驅動的 zero-code LLM agent 框架
現在要組一個能自己查資料、寫程式、跑瀏覽器的 multi-agent 系統，選擇其實不少：LangChain、AutoGen、CrewAI 各有各的抽象層。但這些框架有個共同前提——你得會寫 Python，得懂它的 chain、graph、tool schema 怎麼拼。對非工程背景的人來說，「想要一個會做事的 age…
Human-in-the-loop：AI 系統裡人類介入的設計與時機
把一個模型接上生產環境、讓它自己跑，通常撐不了太久。分類模型會在沒見過的邊界樣本上亂猜、LLM 會一本正經地編造不存在的 API、agent 會在該停手的地方繼續呼叫工具把資料庫改壞。這些狀況的共通點不是「模型不夠強」，而是系統把「不確定」跟「確定」用同一條路徑輸出——模型對一張清楚的貓照片有 99% 把握，對一張模糊…
Raindrop：為 AI Agent 打造的 trace 監控與可觀測性平台
把一個 LLM agent 丟到生產環境跑一週，最麻煩的往往不是它「壞掉」，而是它「看起來沒壞」。API 全程回 200、Slack bot 照常回話、監控面板一片綠，但實際上某個工具呼叫悄悄回了空值、模型把不存在的訂單編號當真、或是在一個 retry 迴圈裡默默燒掉幾百萬個 token。傳統 APM 那套「錯誤率、延…
Cloudflare Workers AI：邊緣 serverless 免費調用 50+ 大模型
做原型的時候，最煩的往往不是寫邏輯，而是「模型放哪裡跑」這件事。想試個聊天機器人，得先去申請一組 OpenAI 金鑰、綁信用卡、算 token 成本；想跑本地開源模型，又得租一台帶顯示卡的機器，開機、裝驅動、拉權重，一套流程走完半天過去了。真正想驗證的那個點子，反而被基礎設施拖住。
ku：Go 寫的鍵盤驅動 Kubernetes TUI，k9s 之外的選擇
在終端機裡管理 Kubernetes 叢集，kubectl get pods -w 加上一堆 -o wide 與 grep 是多數人熟悉的日常，但只要資源一多、命名空間一雜，純命令列的來回切換就會變得瑣碎。這也是 k9s 這類終端使用者介面（TUI, Terminal User Interface）能長年佔據不少工程師…
Nango：800+ API 連接器與託管 OAuth 的開源整合層
任何要對接外部 SaaS 的產品，遲早會撞上同一道牆：每接一個服務，就得重寫一次 OAuth 流程、處理一次 token 刷新、適配一次供應商的分頁與速率限制怪癖。三五個整合還能手刻，等到要對接二三十個 API，整合層的維護成本就會吃掉一大塊工程時間，而且這些程式碼幾乎沒有業務價值，純粹是膠水。