我試了十幾個智能體，多數進了墳場

「每一個都因為意想不到的原因死掉。」這是作者在運行了十幾個智能體后寫下的結論。不是理論推演，是凌晨3點被報警吵醒后的真實記錄。

從指揮到編舞：運行多智能體的真相

作者把一臺二手Linux服務器叫「悟空」，塞在衣柜里常年開機。上面跑過十幾個智能體系統——如果算上子進程、重試任務，實際數字更高。他停止計數的時候，「墳場」里的已經比活著的多。

業界愛用「編排（orchestration）」這個詞。作者覺得該叫「編舞（choreography）」。

編排像指揮讀譜，每個聲部按部就班。智能體不讀譜。它們靠節奏協作，而節奏脆弱得很——凌晨3點一個智能體的上下文窗口被擠爆，早上整個舞蹈就亂了。四個智能體能同步跑幾周，然后一個踩了另一個的臺詞，整套動作得從地板上撿起來重排。

工具選擇也藏著陷阱。用Claude Code驅動智能體是一種手感，換OpenHands這種開源編碼智能體是另一種，直接調原始模型API又完全不同。難度不會消失，只是轉移位置： polished界面把硬骨頭藏起來，等到凌晨故障時才咬你；粗糙的工具讓你全程感受每個毛邊，累歸累，至少知道邊界在哪。

同一臺機器上跑多個智能體、讓它們互相通信、保持節奏、維持存活——這事兒新到連標準做法都沒有。作者說自己尤其沒搞懂。

三大死因：遺忘、循環、沉默

作者給墳場里的智能體做了尸檢，死因高度一致。

第一是遺忘。「每一個都忘了。」這是他能寫的最誠實的句子。你精心設計指令、記憶、角色、目標，它們跑一天、一周、一個月，回來一看，已經忘了該干什么。不是你指令寫錯，是攜帶的上下文被壓縮求生，而承重細節總是最先被扔掉。

第二是循環。智能體調用工具A，A調用B，B又調回A，循環到速率限制或賬單喊停。有時候限制是你的，有時候賬單也是你的。

第三是靜默崩潰。這是最痛的——凌晨2點死掉，把錯誤日志寫進沒人看的文件，然后躺尸幾天，你還以為它在干活。

為什么這件事值得科技從業者盯著

智能體被談論得太多，被真正運行得太少。作者的衣柜服務器成了一個微觀實驗場：當多智能體系統從演示視頻走進7×24小時運行時，理論優雅性讓位于工程殘酷性。

上下文壓縮、工具鏈嵌套、故障可觀測性——這些不是邊緣案例，是日常死因。而「標準做法」的缺失意味著，現在入場的人不是在應用成熟技術，是在共同摸索邊界。

作者最后留了句話：這也是一封求助信。墳場還在擴大，活著的還在掉節奏，而編舞的人還沒找到不讓舞步散架的方法。