同一個 agent,在你的網路裡

託管服務依據你寫的描述來回答。有些問題沒辦法這樣回答,因為答案在即時系統裡——上週有多少訂單延誤、這個客戶的帳有沒有逾期。補上這個缺口有兩種做法,它們在信任光譜上的位置不同。

Enterprise 方案,託管。 agent 呼叫你運行的 MCP 伺服器。你開放任何有意義的工具——查詢端點、庫存檢查、CRM 查詢——agent 在有人提問時從我們的雲端呼叫它們。你的源資料留在你的網路裡;只有每次工具呼叫的回應會跨越界線。如果你接受那些資料離開、又不想維護任何 kavilo 基礎設施,這是對的選擇。

自行託管。 對那些什麼地方都不能送那份資料的人,同一個 agent 跑在你的網路內、緊鄰資料,服務你的內部網路。它比你想的簡單:資料庫橋接在同一個進程內,所以沒有第二個服務要部署,也沒有多餘的 port 要開。

什麼都沒暴露

你的內部網站和 agent 都在你的網路內,所以沒有隧道、沒有公開主機名稱、沒有入站防火牆規則。這是那種「沒有入站」不算緩解措施、而是現況的部署——外面根本沒有任何東西在監聽。

結構上就是唯讀的

橋接只接受一條唯讀的 SELECT(包含 WITH … SELECT),缺少列限制時會補上。這是在查詢路徑上強制執行的,不是禮貌地請求模型照做——而且它仍該放在一個沒有寫權限的資料庫角色之後,因為授權是一種控制,檢查是第二道防線。

什麼會離開,直說

• 搭配遠端模型供應商——我們的、OpenAI、Anthropic 或其他你設定的供應商——該供應商會看到對話、你的 schema、agent 寫的查詢,以及這些查詢傳回的列。
• 搭配本機推理,跑在你自己的硬體上,什麼都不離開。不是 schema,不是列。

這是真正不同的安全姿態。如果你的要求是任何一列都不能跨越界線,就用本機推理——同一份設定照用,只改一個供應商設定。別讓任何人跟你說託管選項等價,包括我們。

這個二進位檔裡有什麼

不是我們的門市。你跑的這份建置沒有付款處理、沒有註冊流程、沒有編譯進去的價目表——那些只存在於執行這個網站的那份建置裡。這是刻意畫的界線:在你網路內的 agent 執行環境不該包含 Stripe 用戶端,「為什麼會包含」是對任何供應商都合理的問題。

各部署的定位

兩行自行託管用的是同一套 kavilo 部署。從遠端模型換到本機推理,是供應商設定的變更,不是資料遷移。

開始

這不是自助式服務——得先談談你的資料和你的網路。與我們聯繫。