企業的廚房不養會聊天的機器人：BizBuddy 教我們的一堂備菜課

10 月 4 日，掘金上出現一篇技術長文，作者長弓三石分享了他們用純 Java 打造企業級 Agent 平臺「BizBuddy」的設計與取捨。文章一開頭就問了一個很實際的問題：為什麼要把智慧體內核放進一個成熟的 Java 中臺裡，而不是另起一套 Python 服務。

這問題聽起來離廚房很遠，其實一點也不。你若在家裡辦過一桌菜，就懂那種為難：是要新買一套爐具、另闢一個竈臺，還是把新的那道菜，塞進本來就運轉順暮的廚房動線裡。

Demo 像家宴，企業像中央廚房

文章裡有句話很扎實：過去兩年，幾乎每個團隊都搭過 Agent Demo。接一個大模型 API，掛幾個工具，能對話、能查資料。但 Demo 到生產之間，隔著幾道很硬的牆。

這就像你在自家廚房炒一盤蛋給家人喫，和每天出三百個便當是兩回事。作者列出的那幾道牆，廚房裡全有對應：權限，是誰能進後廚、能開哪個冰櫃；可控的寫操作，是讓菜直接出餐口之前，總要有人試味道、點個頭；審計，是這道菜用了哪些料、誰驗的、成本多少，出了問題要能回頭查。還有帳號、組織、調度、檔案、訊息推送這些「無聊但必要」的底盤能力，等於中央廚房裡的水電瓦斯與進貨帳本，不該每開一家新店就重拉一次管線。

作者的核心主張是：企業要的從來不是一個會聊天的機器人，而是一個可運營的智慧業務運行平臺。翻成餐桌話，企業要的是一間能天天開火的中央廚房，不是一段會講菜的影片。

同一口爐，同一鍋湯

技術選型是全文最有味道的部分。內核選了 AgentScope 的 Java 版（2.0.3），底座用了 RuoYi-Vue-Plus 6.0.0。作者反覆強調一個詞：同一個 JVM。

同一行程、同一套權限與事務，不需要跨語言的邊界。這就像所有的菜都在同一口爐上做，湯是那鍋湯，調味架是那個調味架，師傅轉身就拿到醬油，不必繞到隔壁棟借廚房。AgentScope 提供的工程能力，也全是後廚的硬功夫：工具循環像「看鍋、下料、嘗味」的節奏；中間件像開工前先在白板上寫好今天日期和現有食材；權限三態 ALLOW、ASK、DENY，則是有些菜徒弟可以直接炒，有些必須喊一聲主廚來確認，有些爐子根本不許碰。

這套「排班與分工」的思路，我們在先前聊廚房裡那套只看鍋、不動鏟的排班表時也碰過。差別在於，那次是廚房裡多了一個幫手，這次是整間廚房要照著企業的規矩重新開張。

為什麼不另起 Python 的竈

作者沒有否定 LangGraph 或 Dify，只是點出一個現實：當企業的存量是 Java 中臺時，硬塞一個 Python 運行時進來，權限要跨程序同步，事務要自建一致性邊界，構建部署要顧兩套，連除錯的斷點都會在中途斷掉。

廚房版本更好懂。你家樓下市場的攤商都用臺斤、都收現金，你偏要開一家只收外幣的店，每天對帳就先耗掉半天。不是外幣不好，是那條換匯的隊，天天都要排。文章裡那句「對底座是疊加而非替換」，放在餐桌上是同樣的老智慧：新的那道菜，用家裡本來的鍋鏟做就好，存量那桌菜照樣上。

收在一個備料的道理

這篇文章讀完，最記得的並不是哪個框架，而是那個先後順序：先把水電、帳本、權限這些無聊的東西顧好，再談聰明。這跟我們一直相信的備料功夫比模型更決定一桌菜是同一件事。

下次你在廚房裡想把某道新菜搬上日常餐桌，不妨也先問那三個問題：誰可以動這鍋？出鍋前誰試味？出了問題，帳本查得到嗎。這三關都過了，那道菜才算是真正住進了你家廚房，而不是曇花一現的 Demo。