整個框架的移植：Imp v0.5 把 DSPy 的自我改良提示帶進 Elixir 的 BEAM

本週最有意思的語言模型框架發布，不是來自舊金山，也不是北京，而是來自一個名為 deepfates/imp 的 GitHub 儲存庫。它在 2026 年 9 月 27 日登上 Hex——Elixir 的套件註冊庫。Imp v0.5 自我定位為 DSPy 的完整移植。DSPy 是那套宣告式、可自我改良的提示框架，它改寫了 Python 開發者對 LLM 程式設計的想像；而 Imp 把它搬到了 BEAM 上——那個支撐 Erlang、Elixir，以及 WhatsApp 那套出了名打不掛的訊息基礎架構的虛擬機。

如果你從沒寫過 Elixir，這件事的意義可能不太明顯。但如果你曾在 Python 裡試圖同時跑幾百個長壽命 LLM agent，然後眼睜睜看著 process 表爆炸，你就懂了。

DSPy 究竟解決了什麼

DSPy 的核心洞見是：手寫提示是缺乏管理的組態。你寫一段指令、貼進模板，然後祈禱模型照你的意思解讀。模型一換、任務一變，那段文字就默默腐爛。DSPy 用「宣告式、帶型別的程式」取代這種做法：你宣告每個步驟的輸入與輸出——像 "issue -> kind: enum[bug, feature, question], summary" 這樣的簽名——框架負責編譯提示、解析回覆，並依宣告的型別驗證輸出。

第二半的想法則是最佳化器。與其讓人類在半夜調字，你交給框架一批標記好的範例和一個評量指標，最佳化器自己去搜尋更好的指令。這個家族的旗艦是 GEPA——一個反思式的演化最佳化器：它執行程式、閱讀失敗痕跡，再用一個更強的「反思模型」改寫程式自己的指令。GEPA 背後發表的基準測試報告稱，它平均比 GRPO 類的強化學習調校高出約 10%，卻只需 35 分之一的 rollout 次數——把提示工程從民俗偏方變成可量測的工程紀律。

Imp 帶了什麼到 BEAM

兩半 Imp 都移植了。一個任務就是一條簽名，透過 Imp.predict、Imp.chain_of_thought 或 Imp.react 組合——簽名不變，推理策略可換。最佳化器陣容涵蓋整個 DSPy 譜系：LabeledFewShot 與 BootstrapFewShot 挑選範例、MIPROv2 對指令與範例做聯合搜尋、SIMBA 從程式自身表現好壞的嘗試中學習規則、GEPA 負責反思式指令改寫，當你想訓練權重而非文字時還有微調與 GRPO。成果是可以檢視的：最佳化後的程式能序列化成 JSON，也能以 diff 形式審閱。

真正新穎的部分——也是這不只是一場翻譯練習的原因——在於 agent 的執行方式。在 BEAM 上，一個 agent 就是一個 OTP process。Imp.start_run/3 把程式啟動成一個獨立、受監督的 process，你可以觀察它、終止它，並逐一授權它的工具呼叫。文件示範了一個 authorize 函式，拒絕任何目標 URL 不在 https://raw.githubusercontent.com/ 之內的工具呼叫——能力受限的 agent 是函式庫層級的原語，而不是平台的功能賣點。

失敗語意同樣很「BEAM」。模型請求會被你設定的截止時間強制截斷；一個可能已經產生副作用的工具呼叫會被回報為「未知」，絕不默默重試——這是資料庫工程師花整個職涯學習的 at-most-once 紀律，如今套用在 LLM 工具使用上。每次執行都會發出結構化事件流（:run_started、:tools_sent、:model_request、:tool_call、:tool_result、:run_finished），事後可完整稽核。

除了 ReAct，Imp 還內建 RLM（處理遠超上下文視窗的輸入）、CodeAct 與 program-of-thought 模式（以小型沙箱表達式做計算）、MCP 用戶端支援（匯入你核可的 MCP 伺服器工具），以及 ACP 對外服務（任何 Imp 程式都能以 agent 身分出現在 Zed 裡）。模型供應商透過 ReqLLM 存取，舉凡 OpenAI、Anthropic、本地模型都能用。最佳化器甚至能與 agent 組合：GEPA 可以反思整段 agent 執行過程，改寫引導它的指令——包括工具描述——另有「Optimize Anything」後門，凡是你能評分的文字或 JSON 都能改寫。

為什麼執行環境對 agent 至關重要

業界的 agent 技術棧正收斂於「Python 加沙箱加重試迴圈」，而大家回報的各種失敗模式——殭屍 process、副作用工具被默默執行兩次、無法觀察的執行過程——其實是執行環境的失敗，不是模型的失敗。BEAM 正是為這類問題而設計的：數百萬個輕量 process、把元件重啟回已知良好狀態的監督樹、每個 process 獨立的垃圾回收，以及搶先式排程，讓一個失控任務不會餓死其他所有工作。

Imp 的賭注是：agent 時代終究會想要一個 actor 模型的執行環境，就像網頁伺服器時代在 C++ 伺服器一再倒塌時發現了 Erlang。Elixir 能否成為 agent 語言，取決於 Python 難以撼動的生態重力；但一個附帶受監督 process、截止時間強制、未知副作用回報的完整 DSPy 移植，已經移除了嘗試它的最大技術藉口。

必須講清楚的但書

Imp 0.5 是實驗性版本，這是它第一次登上 Hex。README 直接明說：API 可能變動，最佳化器也還需要大規模基準測試——那些漂亮的 GEPA 數字來自 DSPy 自己的論文，不是 BEAM 上的重製結果。它需要 Elixir 1.19 以上、C 與 C++ 編譯器（給 jaxon、erlexec 兩個原相依套件），首次編譯還需網路下載 rebar3 外掛。發布隔天的下載數是 93——標準的早期採用者數字，Hex 上 0 個相依套件也說明了還沒有人的正式環境押在它上面。

它也不是 Elixir 在這個領域的第一個實驗：gepa_ex 四月就發布過無頭版的 GEPA 移植，DSPex 也探索過類似地帶。Imp 的差異化在於完整性——簽名、模組、完整最佳化器家族、檢索、agent 迴圈、MCP、ACP——打包成一個連貫的 MIT 授權函式庫，而不是某一片切角。

結論

十五年來，BEAM 的推銷詞是「你不用去想的並發」，而業界多半真的不去想。agent 是第一個主流工作負載，讓這個執行環境的核心能力——監督、隔離、訊息傳遞、部分失敗——與需求一一對上。Imp v0.5 是在這片土地上插下的早期、誠實、文件完善的旗子：把我們手上最好的提示工程框架，搬到我們手上最好的並發執行環境上，看看會壞在哪裡。對 Elixir 團隊，它現在一条相依套件就能裝（{:imp, "~> 0.5"}）；對其他人，它也值得純粹當成設計參考來讀——看看 agent 執行環境究竟該承諾什麼。