別再教代理怎麼做了——OpenProse 的 Dan Barrett、Raymond Weitekamp 與 Jose Montes de Oca

Dan Barrett 是 OpenProse 的創作者，他主張 AI 工程的下一層不是提示（prompting）、上下文（context）或 harness 設計，而是撰寫宣告式的「合約」（contract）：只要寫清楚想要的結果，讓任何 agent harness 自行想辦法達成。這場對談大部分時間其實是在實機示範這個想法：一套純 Markdown 的「語言」，由 Claude Code 或 Codex 編譯；一個事件驅動的託管應用（run.prose.md），把 GitHub webhook 和 cron 排程轉成多代理（multi-agent）任務；以及一套鎖定銀行業的計量模型檔案工作流程。標題的「別再告訴 agent 怎麼做」是技術論述的主軸，但大約一半的節目時間是產品展示與觀眾問答，而不是一套獨立的論點。

與 Barrett 同場的還有 Raymond Weitekamp，他打造了託管的 run.prose.md 應用，自稱是博士、連續創業者，正在做「harness 工程」；以及 Jose Montes de Oca，早期 Google Cloud 工程師，多半是插話補充。三人借用經典軟體工程模式——組合優於繼承、宣告式優於命令式、規格驅動開發——套用到代理工作流程（agentic workflow）上。讀者讀完應該能清楚掌握 OpenProse 是什麼、不是什麼，具體的企業用例（計量模型的法規檔案，Barrett 估計大型銀行每年在此花費 1,000 萬至 5,000 萬美元），以及團隊自己點出的未解問題：驗證、成本，以及這種模糊的「AI 即編譯器」做法能否做到可靠。

OpenProse 是一份 Markdown 合約，由你現有的 harness 編譯

核心主張是：「程式」就只是文字——一個巨大的提示——而執行環境本身也是一個提示。Weitekamp 要大家記住兩件事：「它就是 Markdown」以及「它是事件驅動的……我們不是在聊天」。核心（kernel）是一個開機載入器（bootloader）式的 Markdown 檔，索引 agent 所需的其他檔案；程式則是第二個 Markdown 檔，宣告輸入、輸出、子代理、指派的技能與工具，以及這次執行必須滿足的合約。用 Weitekamp 的話說，agent 會被告知：「你就是編譯器。這不是比喻。」

這套設計刻意不擁有 harness。Claude Code 和 Codex 各有不同的子代理系統，所以 OpenProse 站在上一層，讓宿主 harness 負責執行。Weitekamp 稱之為「後設 harness……我們要你帶自己的 harness 來」。完整的系統提示／技能檔很大——Barrett 說「接近 7 萬個 Token，8 萬個 Token」，並表示隨著 agent 變聰明，他們正試著把它縮短。核心公開發布、可下載；託管應用的前置設定（front matter）可以匯出成純 Markdown，再上傳到別處，維持可組合性。

| 層級 | 內容 | 由誰擁有 |
|---|---|---|
| 核心（Kernel） | Markdown 開機載入器／操作指令與最佳實務索引 | OpenProse，公開發布 |
| 程式（Program） | Markdown 合約：輸入、輸出、子代理、技能、工具、成功條件 | 使用者或其 agent |
| Harness | Claude Code、Codex，或具備子代理的內部 agent 執行環境 | 客戶 |
| 託管應用（run.prose.md） | 任務 = 合約 + 觸發條件（webhook 或 cron） | Weitekamp |

執行複雜程式的門檻據稱不高：需要子代理與隔離的上下文，再加上 Bash（不過 Weitekamp 指出，在 code 模式下用 VM 隔離環境也能替代）。團隊把這套做法定位成 DSPy 的反面：DSPy 把每次 LLM 呼叫都隔離在具型別、確定性的介面之後，OpenProse 則「讓一切留在模糊地帶」，信任強大的模型來當編譯器。Weitekamp 也坦承隨之而來的弱點：「如果你拿 Haiku 來跑，或拿 Fable 來跑，結果會天差地遠。」

宣告結果，再選擇性固定做法以降低成本

Barrett 的框架是：過去叫提示的技能，如今已變成「合約建立或合約組合」。他勾勒的演進史是：先有下一個 Token 預測式的提示，接著是手動把 RAG 結果和工具呼叫塞進上下文（「上下文工程」），然後是 harness 代勞這些塞入動作，現在則是能自我修改的 harness 拓撲來管理子代理——他引用當天早上 Anthropic 一場談「flows」的簡報。如果提示、上下文、harness 都逐一被解決了，剩下的問題就是：如何把你想要的東西講清楚。

實務建議是宣告終態、把方法留空，因為告訴 agent 怎麼做既浪費智慧也浪費錢。但團隊給的是一個可調旋鈕，而不是教條：你可以先用昂貴的模型寬鬆地跑，擷取 agent 的執行軌跡，再「把它收斂包裝成一套做法」——把流程寫死，讓較便宜的模型也能執行。從「做什麼」走向「怎麼做」，成本就會下降。Weitekamp 補充一個相關功能：把一次「黃金 session」轉成可重複使用的工作流程。他也坦白，這種吸引力有一部分來自期望的位移——新模型第一次跑「讓你驚豔」，之後的表現令人失望，部分原因是標準被拉高了。

「你寫一句話，這些東西就讓那句話成真。所以問題變成：既然你有這麼強大的機器能讓它成真，你現在該寫的那句話是什麼？」——Dan Barrett

Barrett 也劃出何時不該用的界線：一次性的或探索性的工作留在聊天裡就好。OpenProse 是給經常做、必須可靠、可重複、可稽核的工作——這也意味著你早已知道自己要什麼。

事件驅動任務取代聊天，PR 審查是驗證場

Weitekamp 的託管應用把任務定義為合約加觸發條件。目前實作了兩種觸發：webhook（他指出這涵蓋 Slack 應用與 GitHub）和 cron 排程。從觸發開始，工作流程會進行分流——用常駐任務打造他所謂的「程式碼工廠」。系統內建兩個 GitHub 範例：進來的 issue 觸發一個程式，輸入是該 issue、輸出是一個 commit；進來的 pull request 則觸發一個對抗式審查程式。

PR 審查是更有意思的示範，因為它回應了當天早上 Anthropic 工作坊提出的問題：自我審查有偏誤，人類審查也一樣。Weitekamp 逼自己用這套程式來開發 webhook 功能，所以每個功能需求都會觸發一串審查 agent。有些 PR 一輪就過，有些則要「審查 14 輪，才感覺審查 agent 們對齊了」。他展示了一段橫跨三、四天的執行紀錄，裡面有「幾十、幾十、幾十個 PR」，並說明如何用預備環境與正式環境的審查落差當作壓力回饋——開發 agent 在吸收回饋之前，不能認定任務完成。

Barrett 強調這與一般 agent 聊天有何不同：每次審查都是全新 session，對照一份白紙黑字的合約來評分，這就打破了自我感覺良好的迴圈。現場示範時，Weitekamp 請應用內的 agent 寫一個審查 PR 的程式，「就像你是一個不喜歡 AI 生成程式碼的暴躁資深工程師」；agent 起草完成後，部署需要明確點選確認，因為這個任務之後每審一個 PR 都要花錢。任何會收費或花錢的動作都需要確認，Weitekamp 稱之為最佳實務。

flowchart TD
    A["觸發：GitHub PR webhook 或 cron"] --> B["確認花費後部署任務"]
    B --> C["審查子代理 session 1"]
    C --> D{"合約是否滿足？"}
    D -- "否" --> E["開發 agent 修改"]
    E --> C
    D -- "是" --> F["PR 通過，任務完成"]

組合而非繼承，讓複雜度留在區域性

被問到合約能否注入或繼承時，Barrett 把它重新框成組合。多份合約可以注入同一次執行，agent 必須全部滿足。事件驅動的那一半運作起來像 React 式的記憶化（memoization）：元件有上游依賴，上游狀態一變就往下傳遞。團隊做過一套系統，由 agent 判斷上游狀態是否改變、要不要啟動下游工作，但 Barrett 說這樣跑起來很貴——這正是便宜決策模型能派上用場的地方。

另一個可組合性的槓桿，是將多代理工作流程的形狀樣板化。Weitekamp 的例子：一個文章生成程式，有一個父代理決定輸出何時夠好，一個研究子代理接上 Exa CLI 與技能（刻意不使用通用網頁搜尋，以換取速度與成本），一個寫手子代理拿到最近十篇好文章作為風格參考，再加一個文字編輯——全部大約 100 行 Markdown，可能跑上十個小時。他把這對應到 Anthropic 動態工作流程文章裡的六種工作流程形狀（fan-out/fan-in、對抗式審查、迴圈直到條件成立等）：每一種都能寫成 Prose 程式，並在任何 agent 上執行。

Barrett 把這與 n8n 這類拖放式 DAG 建構工具對比。中間合約扮演檢查點——執行滿足了其中一個，就觸發下一個——所以你可以透過組合里程碑，實質上宣告「怎麼做」，同時讓每個 agent 在達成方式上保持彈性。

計量模型檔案是旗艦企業用例

最具體的商業提案是計量模型的法規檔案。Barrett 描述這項重複出現的義務：每個模型都必須每年或在特定事件發生時重新撰寫檔案，內容涵蓋用途、測試條件，以及哪些模型在上游引用它。一家大型銀行大約有 4,000 個模型，Barrett 估計最大型銀行每年在此花費「1,000 萬到 5,000 萬美元」。他說 OpenProse 以遠低於此的成本執行，成果「非常成功」，但也坦承要通過法遵、稽核與監管機關是另一場仗。

示範在 Codex 上跑，刻意用便宜模型求速度：先 boot the kernel，再用特定程式執行 prose run。輸出是 SOFR 曲線的檔案，選它是因為它是公開模型、不含銀行資料。Barrett 邀請現場計量人員審閱，並說團隊會對照歷史結果做基準測試，也讓現場計量人員為輸出評分。法規要求本身就是用散文寫成的，這正是為何契合度如此自然——那些檔案實質上已經是一份合約。

對受監管機構的策略論點在於部署形態。因為全部都是文字，「我們不需要採購部門，也不需要 IT 部門」——客戶沿用既有的 coding agent、推論服務、防護機制與技術棧，只會收到 Markdown 檔。開源核心（open-core）授權寬鬆，Barrett 說已有數家大型企業在內部以開源模型和自家 harness 執行。被保護的資產不只是資料，還有機構的營運知識——標準作業程式——這是企業不願送到大型實驗室的東西。

Jev 式決策模型是缺失的驗證器與路由器

團隊反覆回到一個缺口：OpenProse 讓 agent 自行宣告「我已滿足合約」，卻沒有任何機制獨立查核。Barrett 說，對照合約做驗證對 Jev 這類決策模型「非常令人興奮」——把理想的合約狀態與混亂的現實狀態相比，回傳通過或失敗。Weitekamp 點出兩個自然的插入點：每個任務結束時跑一個快速便宜的驗證器；以及一個路由器，把所有 GitHub 事件送到正確的任務，而不必由人點選哪個工作流程處理 issue、哪個處理 PR。

Barrett 把這個想法延伸到記憶化問題：一個語意分類器可以便宜地判斷上游依賴何時過期，並觸發所有下游，取代昂貴的 agent 式檢查。他也指出，因為一切都是文字，非常適合強化學習——「這對 RL 來說是全新的世界」——不過團隊還沒做，並說資料量還不夠大到有意義。Weitekamp 補充一個 Token 效率的角度：如果你自己託管模型、擁有那約 10 萬 Token 的字首，就能把它摘要化，或建立更精簡的表徵。

「Jev 化的大時代已經降臨，我們必須正視它。」——Raymond Weitekamp

Weitekamp 懷疑 OpenProse 這種生成式 Markdown 語言本身是否屬於非生成式決策模型的世界；他認為它在後端的定位是驗證器與路由器，而不是語言層。

規格驅動開發與意圖萃取難題

一位觀眾問到規格驅動開發，引來熱烈回應：Barrett 說 OpenProse「幾乎本質上」就是規格驅動開發，並邀請提問者把現有規格與開機核心組合起來，看看兩者會衝突還是互相覆寫。Weitekamp 描述他做過的一項測試：把 Matt Pocock 的「grill me」再接 TDD 工作流程，包成單一 Prose 程式，每個子代理都必須依序載入下一個技能——這是他證明技能串接機制可行的方式。

兩人都承認更難的問題，是把意圖從人們腦中挖出來。Barrett 指出核心裡某個已知路徑下埋了一份最佳實務檔案，列出宣告結果的模式與反模式，並說 agent 可以陪你一起迭代合約，而不是由你從零開始打字。Weitekamp 更長遠的看法是：聊天會爆紅，是因為你什麼都不用懂就能開始；而像 DSPy 這類工具要求你先定義想要的簽章——「你坐下來才發現，喔該死，我其實根本不知道自己想要什麼，對吧？」OpenProse 比 DSPy 寬鬆得多，應用內的 agent 能回答「你能做什麼？」，幾乎能驅動應用裡的一切，凡是會花錢的動作都硬性要求確認。

Barrett 回過頭談使用者輪廓：OpenProse 的使用者中，做營運、產品管理和模型檔案的人比軟體工程師還多，他認為這是因為 Markdown 檔案對非工程師更自然。團隊也把核心的設計歸功於多年工程經驗——處理過擅長與不擅長表達需求的人——加上內部基準測試，以及一套在檢查合規性的同時持續縮小核心的演化流程。

尚未解決的張力，正是團隊自己點出的那個：一套把一切放進「模糊地帶」、信任模型當編譯器的做法，會繼承模型的變異性，而它自己的完成訊號在便宜決策模型坐鎮執行末端之前，是未經查核的。他們描述的這些零件——驗證器、路由器、語意記憶化、文字上的 RL——都還是路線圖，不是已出貨的產品；而企業用例只押在單一垂直領域（計量模型檔案），那裡的產出仍得通過稽核。值得追蹤的是：核心是否隨模型進步而縮小、Jev 式驗證器是否落地，以及受監管機構會不會走開源核心路線在內部自建，而不是採用託管應用。