1. 先解決一個反常識的問題Agent 畫圖為什么不能用“畫”的前陣子在研究 Agent 工具鏈的時候注意到一個很有意思的開源項目——Archify目前已經(jīng)積累了 35k Stars。它的核心口號翻譯過來很直接“Agent 畫圖需要編譯器?！边@個說法乍一聽挺反直覺的。畫圖這件事人是用手畫的用鼠標(biāo)拖的用畫板涂的怎么到了 Agent 這里反而要“編譯”但只要你真的用 Agent 生成過復(fù)雜的圖形界面、數(shù)據(jù)可視化圖表、架構(gòu)圖、流程圖你大概率遇到過下面這些讓人抓狂的場景讓 Agent 畫一個多分支流程圖它畫到第三個分支就開始重疊節(jié)點(diǎn)擠成一團(tuán)連線繞得跟迷宮一樣。讓 Agent 生成一張柱狀圖加趨勢線的組合圖它先把柱狀圖畫完然后趨勢線完全對不上柱子的 X 軸坐標(biāo)。讓 Agent 一邊回答問題一邊畫個對照示意圖它畫完之后圖里的數(shù)字和它上文說的結(jié)論對不上。稍微把需求描述得復(fù)雜一點(diǎn)比如“在這三個節(jié)點(diǎn)下面各掛兩個子節(jié)點(diǎn)其中第二個子節(jié)點(diǎn)用不同顏色”它就崩潰了輸出一堆亂碼或者直接報錯。這些問題的根源在哪里我自己的結(jié)論是我們把 Agent 當(dāng)成了“畫師”但它本質(zhì)上是個“語言模型”。它擅長的是一步步地推理和生成 token而不是在二維空間里做精確的幾何排布。你讓它直接寫 SVG 或者用某個繪圖庫去畫就是在逼它用自己不擅長的方式做一件需要空間感知力的事情。那怎么辦Archify 的思路是別讓 Agent 直接碰畫布讓它先寫代碼再寫一種高度結(jié)構(gòu)化的中間表示IR最后由一個專門的“編譯器”去渲染成最終圖形。這就是“Agent 畫圖需要編譯器”這句話的底層邏輯。這篇文章我就以 Archify 為例把 typed JSON IR 這套方案從頭到尾拆一遍。聊清楚它到底解決什么問題、核心設(shè)計是什么、以及你怎么把這種思路抄到自己的 Agent 項目里。2. 核心問題拆解Agent 畫圖的痛點(diǎn)到底在哪里要理解 Archify 的方案必須先理解 Agent 原生繪圖方式為什么會崩。我總結(jié)下來核心痛點(diǎn)有三個。2.1 語言模型的“局部最優(yōu)”陷阱它看不見整塊畫布先說第一個痛點(diǎn)——Agent 沒有全局視野。大模型在生成長文本的時候是逐 token 生成的每一步只看得到它已經(jīng)生成的內(nèi)容和當(dāng)前上下文窗口里有限的信息。它沒有一個“全局畫布”的概念更不會在生成完第一個節(jié)點(diǎn)之后回頭檢查第二個節(jié)點(diǎn)有沒有超出畫布邊界。舉一個我實際測試過的例子。我讓一個 Agent 用 HTML CSS 畫一張組織結(jié)構(gòu)圖包含一個 CEO頂層、三個 VP第二層每個 VP 下面兩個孩子節(jié)點(diǎn)。這個 Agent 生成的頁面兩個 VP 的區(qū)塊在橫向排列時直接重疊了因為它在計算每個板塊寬度的時候用的是估計值而不是真實的布局引擎結(jié)果。這就像讓一個只能看見自己面前 30 厘米范圍的人去布置一個 100 平米的房間他擺完第一組沙發(fā)之后根本不知道第二組沙發(fā)該往哪兒挪。而人不是這樣畫的。人畫圖的時候眼睛會反復(fù)掃描整張圖發(fā)現(xiàn)某個節(jié)點(diǎn)太靠右了會往回調(diào)整。這種“全局審視 局部修正”的循環(huán)恰恰是大模型在純文本生成模式下不具備的能力。2.2 Token 成本失控像素級、元素級指令消耗太大第二個痛點(diǎn)是畫一張稍微復(fù)雜一點(diǎn)的圖Token 消耗會急劇膨脹。比如你讓 Agent 生成一張包含 20 個節(jié)點(diǎn)的架構(gòu)圖每個節(jié)點(diǎn)都有文字標(biāo)簽、邊框顏色、坐標(biāo)位置。如果直接讓 Agent 輸出 SVG每個元素至少需要 4~8 行 XML 代碼每個節(jié)點(diǎn)的坐標(biāo)、寬度、高度、字體、顏色、描邊全都要顯式寫出來。20 個節(jié)點(diǎn)、30 條連線、若干分組標(biāo)簽代碼量輕松上千行。Token 一多出錯的概率就指數(shù)級上升。Model 在生成長序列的時候注意力會逐漸衰減尤其是到了輸出序列的后半段非常容易出現(xiàn)“前面定義一個變量、后面忘了這個變量”的情況。更頭疼的是如果生成的 SVG 有語法錯誤或者坐標(biāo)不對你要讓 Agent 自己修它可能把整段代碼重新生成一遍而不是只改動有問題的那個節(jié)點(diǎn)。這種“局部問題、全局重寫”的模式成本高得嚇人。2.3 語義鴻溝描述一個“漏斗圖”不該等同于描述一堆坐標(biāo)第三個痛點(diǎn)也是最核心的描述意圖和描述圖形之間存在巨大的語義鴻溝。人跟 Agent 說“我要畫一個銷售漏斗從訪客到成交四層每層寬度遞減”這是業(yè)務(wù)語義。Agent 接到這個需求之后需要自己把它翻譯成精確的坐標(biāo)、路徑、樣式——這是圖形語義。一旦中間的翻譯過程出了問題你很難定位是“意圖理解錯了”還是“坐標(biāo)算錯了”。因為錯誤的根源是混在一起的。Archify 的做法是把“意圖理解”和“坐標(biāo)計算”這兩件事完全拆開意圖理解Agent 只需要把用戶需求轉(zhuǎn)化為一個結(jié)構(gòu)化、類型化的 JSON 描述比如“創(chuàng)建一個漏斗圖四層標(biāo)簽分別是 X、Y、Z、W按順序遞減寬度”。坐標(biāo)計算交給編譯器去算。編譯器內(nèi)部有布局引擎知道怎么讓四層看起來均勻、怎么擺放標(biāo)簽不會重疊、怎么處理特殊字符。這個拆分邏輯跟傳統(tǒng)軟件工程里的“前后端分離”如出一轍——讓專業(yè)的人做專業(yè)的事而 Graph IR 就是那個“前后端之間的 API 契約”。3. 從“畫圖工具”到“DSL 編譯器”Archify 的 typed JSON IR 到底是什么Archify 給出的答案是為圖形定義一個類型化的 JSON 中間表示IR約束 Agent 只能輸出 IR再由渲染后端把 IR 編譯成 SVG/Canvas。3.1 先搞明白 typed JSON IR 這個名詞把 “typed JSON IR” 拆開看JSON不用解釋了數(shù)據(jù)交換的事實標(biāo)準(zhǔn)Agent 和編譯器都能輕松處理。IRIntermediate Representation中間表示這是一個編譯器術(shù)語。編譯器不會把 C 語言直接翻譯成機(jī)器碼中間會先翻譯成一種“既保留程序結(jié)構(gòu)、又去除語法噪音”的中間形式。Archify 把 IR 這個概念借過來了——它不是讓 Agent 直接畫圖而是讓 Agent 先寫一份“關(guān)于圖的中間表示”再由編譯器二次處理。typed JSON這里的 typed 是重點(diǎn)。不是所有 JSON 都叫 typed JSON。Archify 的 IR 在 JSON schema 層面做了很強(qiáng)的約束。每個節(jié)點(diǎn)必須有指定的 type 字段比如mermaid、flowchart、actor不同的 type 有不同的必填字段編譯器在解析的時候會做嚴(yán)格的類型校驗。結(jié)合來看Archify 的 typed JSON IR 本質(zhì)上是一種DSLDomain-Specific Language領(lǐng)域特定語言只不過它不是給人類設(shè)計的 DSL而是為 Agent 和編譯器之間設(shè)計的一種“協(xié)議語言”。3.2 Archify IR 的兩種表達(dá)方式Mermaid 優(yōu)先代碼塊兜底Archify 的 IR 實際落地時支持兩種表達(dá)方式我建議都了解一下因為你接的 Agent 不一樣熟悉的東西不一樣選錯方式會導(dǎo)致接入成本高出好幾倍。表達(dá)方式描述適用場景Mermaid DSL讓 Agent 輸出標(biāo)準(zhǔn)化 Mermaid 語法Archify 解析后整體轉(zhuǎn)換為圖形Agent 親近文本 DSL生成簡單流程圖和時序圖時比較穩(wěn)代碼塊包裹 IRAgent 輸出 JSON IR 代碼塊由 Archify 的解析器讀取并渲染需要強(qiáng)類型校驗、更精細(xì)控制節(jié)點(diǎn)屬性和坐標(biāo)計算時更合適Mermaid 大家應(yīng)該不陌生是一種很流行的文本圖表 DSL。它的好處是語法相對簡單Agent 生成起來不容易崩。Archify 把它納入 IR 體系相當(dāng)于給 Mermaid 套了一層標(biāo)準(zhǔn)化的殼。而代碼塊包裹 IR適合對圖形細(xì)節(jié)要求更高的場景。例如你需要給某個節(jié)點(diǎn)自定義一個特殊邊框樣式、需要控制節(jié)點(diǎn)之間的相對位置這時 Mermaid 的表達(dá)能力不夠JSON IR 就能接管。我自己實測下來Mermaid 路線適合 80% 的常規(guī)業(yè)務(wù)圖表流程圖、時序圖、甘特圖JSON IR 路線適合需要精細(xì)控制布局的高級場景。Archify 兩種都支持這給了接入手冊很大的自由度。3.3 IR 代碼長什么樣來一段真實的示例為了讓你有一個直觀感受這里給出一個非常簡單的 Archify IR 示例。假設(shè)我要畫一個兩個節(jié)點(diǎn)、一條邊的流程圖輸入文本{ schema: archify/flowchart, version: 1.0, type: flowchart, direction: LR, nodes: [ { id: a, label: 用戶輸入, type: process }, { id: b, label: 系統(tǒng)處理, type: process } ], edges: [ { from: a, to: b, label: 提交 } ] }你發(fā)現(xiàn)沒有這份 JSON 里沒有出現(xiàn)任何一個“坐標(biāo)值”。沒有x、y、width、height。它描述的是圖的結(jié)構(gòu)而不是圖的像素。這意味著什么意味著 Agent 的任務(wù)從“精確計算每個元素的位置”變成了“精確描述元素之間的關(guān)系”。后者對語言模型來說友好太多了。坐標(biāo)計算、排布優(yōu)化、連線避障這些事情全部由編譯器在渲染階段自動完成。這也是為什么 Archify 能將這些任務(wù)從 GPT-4o 等多模態(tài)模型中高效剝離出來——用公共的、確定性的算法去替代不確定的、高成本的模型推理。3.4 為什么不能直接用現(xiàn)成的 Graphviz 或 D3 庫你可能會有個疑問畫圖編譯器Graphviz 不是一直干這事嗎D3.js 也可以做布局計算啊為什么 Archify 要大費(fèi)周章造一個 IR我的理解是Graphviz 和 D3 并不服務(wù)于同一個“用戶”Graphviz 是為技術(shù)人員設(shè)計的它接受 DOT 語言功能很強(qiáng)但它的布局風(fēng)格偏“工程感”想要做出好看的現(xiàn)代圖表需要配置很多東西。D3.js 其實不算編譯器它是一個渲染工具庫布局算法也得你自己寫。Agent 用 D3 畫圖就相當(dāng)于讓一個沒有圖形學(xué)基礎(chǔ)的人去調(diào)一個底層 API——可以做但特別容易出邊界問題。Graphviz 和 D3 的定位是“面向人類的工具”。Archify 的定位則完全不同它是“面向 Agent 的工具”。它要解決的核心問題不是“人用起來順不順手”而是“模型生成起來穩(wěn)不穩(wěn)定”。IR 的設(shè)計核心就是讓模型的輸出空間被強(qiáng)約束在一個很窄的、類型安全的范圍內(nèi)——這就是 typed JSON IR 的意義。4. 編譯器設(shè)計的靈魂P(guān)ipeline 的每個階段都在解決哪個 Agent 毛病Archify 既然把自己定位成“編譯器”那么它肯定是有一條編譯管線的。我研究它的設(shè)計之后把它拆成了四個階段每個階段直接對應(yīng)我們要消除的 Agent 問題。4.1 詞法分析與語法分析用強(qiáng)制 schema 鎖死輸出格式編 譯 器 的第一個階段是詞法分析和語法分析。對于 Archify 來說就是給 Agent 的輸出做一次嚴(yán)格的全身體檢。Agent 生成的 IR 如果沒有通過 JSON Schema 校驗比如nodes字段里缺了id、type寫錯了、edges引用了不存在的節(jié)點(diǎn) ID這個 IR 就會被打回要求重新生成。這一步的操作價值在于把很多原本要在渲染階段才能發(fā)現(xiàn)的錯誤提前到了生成階段攔截掉。渲染階段出錯你要面對的是用戶對著一張爛圖的困惑生成階段攔截掉你只需要讓 Agent 重新生成一份 JSON。而且強(qiáng)制 schema 校驗還有一個隱藏好處它可以有效減少 Agent 幻覺。當(dāng) Agent 知道它的輸出會經(jīng)過嚴(yán)格的機(jī)器校驗而且不合格會被退回模型會傾向于生成更保守、更符合格式預(yù)期的內(nèi)容。這種“格式約束 失敗反饋”的組合是當(dāng)前階段讓大模型真正靠譜起來的重要手段。4.2 語義分析與中間代碼生成把“業(yè)務(wù)意圖”拆成“圖形原子”過了語法層校驗編譯器進(jìn)入第二個階段語義分析。這一階段的輸入是結(jié)構(gòu)合法的指令列表輸出是經(jīng)過類型檢查、屬性補(bǔ)全后帶具體語義的指令項。Archify 中會對 IR 中的每個節(jié)點(diǎn)和邊做類型檢查如果發(fā)現(xiàn)某個節(jié)點(diǎn)引用了不存在的組件類型或某個邊的屬性不匹配箭頭語義編譯器就會中斷并返回錯誤信息。這一步非常關(guān)鍵的地方在于它干的活是把一個“業(yè)務(wù)層需求”翻譯成“圖形層元素”。拿我們之前的銷售漏斗例子來說業(yè)務(wù)層輸入是我要畫一個四層銷售漏斗從訪客到成交。編譯器做的是確定四個階段節(jié)點(diǎn)、確定連線方向、計算每層寬度比例、生成mermaid或 SVG 需要的具體語句。這里就是“編譯器”和“模板引擎”的分水嶺。模板引擎是死板的輸入格式稍有偏差就罷工編譯器是有層級、有抽象能力的它可以在前面兩層就把輸入固定成明確的、可控的格式——這正是“typed”帶來的優(yōu)勢。4.3 布局與渲染后端坐標(biāo)交給算法樣式統(tǒng)一輸出當(dāng) IR 被校驗通過、語義檢查完成編譯器就要進(jìn)入“生成目標(biāo)代碼”階段了。這里的“目標(biāo)代碼”可能是 Mermaid 源碼也可能是 SVG 代碼。Archify 在這個階段真正讓人省心的地方是布局引擎幫我們處理了最耗心力的坐標(biāo)計算。比如在流程圖中Agent 只需要聲明“節(jié)點(diǎn) A 指向節(jié)點(diǎn) B”編譯器自動計算這條連線從 A 的右側(cè)出、彎折兩次、從 B 的左側(cè)入并確保不穿過其他節(jié)點(diǎn)。這種避障計算對Agent來說很難每次生成都有概率失敗但算法來做幾乎是確定性的。出了坐標(biāo)之外編譯器還會統(tǒng)一樣式比如統(tǒng)一的節(jié)點(diǎn)圓角、統(tǒng)一的配色體系。這樣做的好處是不是讓圖“好看”這么膚淺而是保證輸出風(fēng)格的一致性。同一份 IR不管是誰來觸發(fā)編譯出來的圖都維持同樣的品牌調(diào)性這很符合企業(yè)級應(yīng)用的需求。4.4 類型系統(tǒng)收尾最大化可組合性最小化運(yùn)行時錯誤最后這個階段的類型體系在整個 IR 設(shè)計里是畫龍點(diǎn)睛的存在。typed JSON IR 的“typed”在項目里不是一句口號而是真的把系統(tǒng)里所有元素分成有限類型集合比如flowchart類型管理節(jié)點(diǎn)和邊有嚴(yán)格的方向約束。sequence類型管理參與者、激活條、消息箭頭。gantt類型管理任務(wù)、開始日期、持續(xù)天數(shù)、依賴關(guān)系。component類型管理組件層級和組合關(guān)系。每種類型在 schema 層面定義了必填字段和可選字段編譯器根據(jù)類型執(zhí)行不同的校驗邏輯和布局邏輯。這種嚴(yán)格分類帶來的直接收益是可組合性。因為類型是預(yù)定義好的、經(jīng)過校驗的下游的渲染器、樣式引擎、導(dǎo)出工具都可以基于這些類型做標(biāo)準(zhǔn)化處理不需要像老式模板那樣針對每一種可能的字段組合寫特判代碼。跑完這一整套 PipelineAgent 的輸出才能從“像一張圖的東西”變成了“真正結(jié)構(gòu)正確、穩(wěn)定可復(fù)用的圖形”。5. 為什么這套思路值得抄進(jìn)你自己的 Agent 項目里Archify 這個名字并不只是給你一個“畫圖更好看”的庫。我認(rèn)為它最大的價值是給所有做 Agent 工具鏈的人提供了一個范式參考——當(dāng)模型能力達(dá)到上限時如何用一個工具去補(bǔ)齊它。5.1 三個直接的業(yè)務(wù)收益Token 成本、穩(wěn)定性和可緩存性如果你自己搭的是繪圖 Agent引入 Archify 之后最直觀的三個收益是收益一Token 成本明顯下降。Agent 不用再輸出上千行 SVG 代碼只需要輸出幾十行 JSON IR。我做過一個粗糙的對比測試畫同一張 15 節(jié)點(diǎn)的架構(gòu)圖直接用 SVG 大約消耗 3200 tokens用 Archify IR 加 Mermaid 渲染只消耗 900 tokens 左右節(jié)省了 70% 以上。收益二輸出穩(wěn)定性大幅提升。我連續(xù)讓同一個 Agent 畫同一張圖 10 次直接輸出 SVG 時有 3 次出現(xiàn)了渲染錯位或標(biāo)簽重疊。用 Archify IR 后10 次全部生成正確而且最終效果完全一致。這種穩(wěn)定性對于面向用戶的產(chǎn)品級應(yīng)用來說價值極大。收益三結(jié)果可緩存。因為 IR 是一個純 JSON 結(jié)構(gòu)它可以跟任何緩存系統(tǒng)友好共存。比如 Agent 根據(jù)同樣的需求生成了同一份 IR你可以直接走緩存不需要重復(fù)調(diào)用模型省下時間和費(fèi)用。這部分對高頻場景的影響會在下一節(jié)單獨(dú)展開。5.2 不止畫圖Archify 的“編譯器”思路能遷移到哪些 Agent 場景Archify 的 IR 設(shè)計看著是畫圖專用的但它的范式可以遷移到很多鄰近領(lǐng)域。我舉幾個我實際看過或試過的例子AI 生成演示文稿PPT/Slides。PPT 的核心難點(diǎn)跟畫圖一模一樣——元素多、依賴關(guān)系強(qiáng)、對布局要求高。你讓 Agent 直接生成一個帶動畫的 PPT 文件它大概率會瘋。但如果定義一套slide IR規(guī)定每頁有哪幾種類型的元素標(biāo)題、正文、圖片、圖表并讓編譯器統(tǒng)一處理排版和分頁P(yáng)PT 生成就會從“一次賭運(yùn)氣”變成“結(jié)構(gòu)化流水線”。目前很多開源 PPT Agent走的就是這條路線。AI 生成網(wǎng)站落地頁。和 PPT 同理。與其讓 Agent 直接輸出整段 HTML/CSS不如定義一套page IR描述區(qū)塊結(jié)構(gòu)、內(nèi)容層級、樣式 token再讓編譯器把它們編譯成響應(yīng)式頁面。好處同樣是布局交給算法內(nèi)容交給模型各干各的活出錯概率大減。AI 生成數(shù)據(jù)分析報告。報告比純圖表多一層復(fù)雜性——一張圖怎么配一段解釋文字圖表之間的數(shù)據(jù)口徑怎么保持一致。你可以定義report IR把圖表、文字、結(jié)論、數(shù)據(jù)源全部結(jié)構(gòu)化再交由編譯器統(tǒng)一渲染。這種方案能讓數(shù)據(jù)分析 Agent 的輸出質(zhì)量上一個臺階。5.3 緩存友好性為什么 Agent 生態(tài)遲早都會走到 IR 這一步最后我想專門聊一下 IR 和緩存結(jié)合的問題。這是我覺得 Archify 設(shè)計里最小但最容易被忽略的亮點(diǎn)。Agent 推理是有成本的。用一次模型就消耗一次錢和時間。如果能讓 Agent 在做“類似的事”時復(fù)用上一次的結(jié)果成本就會直線下降。而 IR 恰好是一種適合做復(fù)用鍵cache key的中間形態(tài)。做緩存通常遵循三個原則結(jié)果要穩(wěn)定同樣的輸入最好產(chǎn)生同樣的輸出。結(jié)構(gòu)要可比兩個結(jié)果之間容易判斷“相不相等”。錯誤要隔離緩存某個環(huán)節(jié)出錯不會影響其他環(huán)節(jié)。Agent 直接輸出 SVG每次生成的代碼都可能不同——即便意思是相同的字符串層面也會有差異導(dǎo)致緩存命中率極低。而 IR 是結(jié)構(gòu)化的 JSONAgent 生成的結(jié)構(gòu)只要含義相同基本可以規(guī)范化成一個一樣的 key加上接近階段的結(jié)果做校驗后命中率非常高。這一步帶來的運(yùn)維收益直接反映在成本結(jié)構(gòu)上。5.4 接入你自己的 Agent動手實操 Archify 的三種路徑根據(jù)你手上的技術(shù)棧和 Agent 框架接入 Archify 的方式可以分成三種按接入難度從低到高排列。路徑一Mermaid 優(yōu)先最省事如果你當(dāng)前使用的 Agent 已經(jīng)能生成 Mermaid 代碼那你可以直接把 Archify 當(dāng)作一個 Mermaid 渲染后端。Agent 輸出 Mermaid 源碼你調(diào)用 Archify 的渲染接口把文本變成可用圖片或 HTML 組件。這種方式幾乎不改造 Agent 本身的邏輯只需要在輸出端加一層適配器。適合現(xiàn)有 Agent 已經(jīng)比較穩(wěn)定、不想動核心 Prompt 的團(tuán)隊。路徑二JSON IR 優(yōu)先推薦如果你正在從零構(gòu)建一個新的繪圖 Agent我強(qiáng)烈建議你從第一天就讓它輸出 JSON IR。你在 Prompt 里給 Agent 一個 JSON Schema讓它嚴(yán)格按照 schema 輸出一個code block然后你解析這個 block交給 Archify 渲染。這種方式的核心變動是 Prompt 工程不再告訴 Agent “你要畫一個流程圖”而是告訴它 “你要構(gòu)造一個 flowchart 類型的 IR結(jié)構(gòu)如下……”。語言模型對這種明確的 JSON schema 指令的遵從度遠(yuǎn)高于對“畫得好看一點(diǎn)”這種模糊指令的遵從度。路徑三自建編譯器最高自由度如果你是個控制欲很強(qiáng)、愿意折騰的開發(fā)者也可以參考 Archify 的架構(gòu)自建一套適合你業(yè)務(wù)場景的編譯器。這里的核心工作是定義 tokens、AST 節(jié)點(diǎn)類型和你自己的 IR schema再寫一個布局引擎或直接嵌入一個布局算法。適合業(yè)務(wù)場景很垂直且市面上沒有現(xiàn)成方案的情況。不過自己造輪子之前建議先在 Archify 里認(rèn)真跑幾個 case。等到你真的踩到它的邊界再決定要不要自研也不遲。6. 35k Stars 與社區(qū)生態(tài)為什么“結(jié)果可驗證”比“功能多”更值錢最后我想聊聊 Archify 憑什么能拿到 35k Stars。對于一個相對垂直的 Agent 工具來說這個數(shù)據(jù)相當(dāng)亮眼。我認(rèn)為核心原因有幾個簡單梳理一下第一個原因Archify 讓你對 Agent 的輸出“看得見、摸得著、驗得對”。以前 Agent 畫圖輸出是一大段代碼你沒法快速判斷它對不對得拿去跑一遍看效果。而 Archify 的 IR 是結(jié)構(gòu)化的你可以像檢查一份有 type 限制的配置或 schema 一樣去檢查它。肉眼掃一遍基本就能判斷這個 IR 的節(jié)點(diǎn)關(guān)系是否符合邏輯。這種可驗證性是把大模型從“黑魔法”變成“工程工具”的關(guān)鍵一步。第二個原因Archify 選了一個非常準(zhǔn)確的賽道切入——AI 生成圖形的“布局痛點(diǎn)”。你可以說 Archify 沒有自己的布局引擎也沒有自己發(fā)明的圖形語法它更像是一個“膠水層”和“協(xié)議層”。但從用戶角度來說它提供了一種“確定性”把整個鏈路中最大那塊不確定部分交給了可靠的后端去完成天然能被社區(qū)認(rèn)可。第三個原因也是我想重點(diǎn)強(qiáng)調(diào)的——它的設(shè)計哲學(xué)呼應(yīng)了 Agent 基礎(chǔ)設(shè)施的演進(jìn)方向。你現(xiàn)在去看開源社區(qū)里活躍的 Agent 框架、函數(shù)庫、工具集會發(fā)現(xiàn)大家都在往同一個方向使勁把調(diào)用模型的過程抽象成可約束的工具把模型的結(jié)果從不可預(yù)測變成可預(yù)測。在這方面Archify 提供的不只是繪圖能力更是一個“如何為 Agent 定義一種協(xié)議、如何構(gòu)造中間表示來嵌入流程”的絕佳案例。你在自己的項目里遇到過什么跟 Agent 繪圖相關(guān)的問題嗎或者你也在嘗試自定義 IR歡迎帶著自己的看法來交流一起踩坑一起找方案——開源世界的迷人之處常常也因此展開。