1. 從五個產(chǎn)品到一套底座WorkBuddy 企業(yè)版套件化的核心命題第一次看到“WorkBuddy 企業(yè)版套件化一個 Agent 底座統(tǒng)管五個產(chǎn)品”這個標題我腦子里蹦出來的第一個畫面不是架構圖而是一個很具體的運維場景公司內部同時跑著五套 AI 工具每套都有自己的賬號體系、自己的模型配置、自己的日志格式運維同事每天在五個后臺之間來回切換改一個超時參數(shù)要登錄五次。這種“煙囪式”的 AI 工具堆疊在 2024 年到 2025 年之間幾乎成了中大型團隊的標配痛點。WorkBuddy 企業(yè)版做的事情本質上就是把這五套東西的“地基”抽出來做成一個統(tǒng)一的 Agent 底座讓上層五個產(chǎn)品變成這個底座上的“租戶”或者“插件”。這個思路聽起來簡單但真正落地的時候涉及的問題遠比“抽個公共庫”復雜得多五個產(chǎn)品的 Agent 能力邊界不一樣有的偏代碼生成有的偏工作流編排有的偏數(shù)據(jù)分析怎么用一個底座同時滿足底座的抽象層次定在哪里才不會既管不住上層、又把自己撐爆我先把結論放在前面套件化的關鍵不在于“統(tǒng)一”而在于“分層”。一個 Agent 底座要統(tǒng)管五個產(chǎn)品它必須把“所有產(chǎn)品都一樣的部分”和“每個產(chǎn)品都不一樣”的部分切得足夠干凈。切錯了底座要么變成一坨誰都不敢改的巨石要么變成一層薄得沒有價值的殼。1.1 為什么是“一個底座”而不是“一套微服務”很多人第一反應是五個產(chǎn)品那就拆成五個微服務共享一個網(wǎng)關不就行了這個方案在傳統(tǒng)業(yè)務系統(tǒng)里沒問題但在 Agent 場景下會踩坑。原因是 Agent 的核心資源不是 CPU 和內存而是模型調用配額、上下文窗口、工具Skill注冊表、會話狀態(tài)。這四樣東西如果每個產(chǎn)品各管各的會出現(xiàn)三個致命問題。第一配額打架。五個產(chǎn)品各自持有模型 API Key各自限流結果就是 A 產(chǎn)品把配額跑滿了B 產(chǎn)品直接 429。企業(yè)版必須有一個統(tǒng)一的配額池和調度器才能把有限的 token 預算按優(yōu)先級分配。第二Skill 重復注冊。熱詞里反復出現(xiàn)skill、skill插件、agent skill說明 Skill 機制是這個體系的核心。如果五個產(chǎn)品各自維護一套 Skill 注冊表同一個“查詢數(shù)據(jù)庫”的 Skill 會被寫五遍改一次要改五處。底座必須提供統(tǒng)一的 Skill Registry。第三會話狀態(tài)割裂。用戶在 A 產(chǎn)品里跟 Agent 聊到一半切到 B 產(chǎn)品上下文全丟了。企業(yè)級體驗要求跨產(chǎn)品的會話連續(xù)性這只能靠底座統(tǒng)一管理 session。所以“一個底座”不是架構潔癖而是被 Agent 的資源特性逼出來的必然選擇。微服務那套“每個服務自治”的理念在共享稀缺模型資源的前提下會直接失效。1.2 五個產(chǎn)品到底共享了什么我把這套套件化拆解下來底座真正需要統(tǒng)管的東西其實就五類我習慣叫它“五件套”共享層具體內容不共享會怎樣模型接入層多模型路由、配額、重試、降級配額打架、成本失控Skill 注冊中心Skill 定義、版本、權限、發(fā)現(xiàn)Skill 重復開發(fā)、版本混亂會話與上下文Session、Memory、上下文壓縮跨產(chǎn)品體驗斷裂身份與權限租戶、用戶、產(chǎn)品級 RBAC權限模型五套、審計困難可觀測性日志、Trace、Token 計量出問題無法定位、成本無法歸因這五類里模型接入層和 Skill 注冊中心是底座的技術核心身份和可觀測性是工程保障會話與上下文是最容易被低估、但用戶感知最強的一層。后面我會逐個展開。1.3 套件化之后五個產(chǎn)品變成了什么這是理解整個架構的關鍵。套件化不是把五個產(chǎn)品合并成一個而是讓它們從“獨立應用”降級為“底座上的配置 少量專屬邏輯”。用一句話概括產(chǎn)品 底座能力 產(chǎn)品專屬的 Prompt 策略 產(chǎn)品專屬的 Skill 組合 產(chǎn)品專屬的 UI。舉個具體例子。假設五個產(chǎn)品里有一個偏代碼的類似 CodeBuddy 的定位一個偏通用辦公的WorkBuddy 本體一個偏數(shù)據(jù)分析的一個偏科研文獻的一個偏工作流自動化的。套件化之后代碼產(chǎn)品 底座 代碼類 Skill 集 代碼專用系統(tǒng)提示詞 IDE 插件 UI辦公產(chǎn)品 底座 文檔類 Skill 集 辦公提示詞 對話式 UI數(shù)據(jù)產(chǎn)品 底座 SQL/圖表 Skill 集 分析提示詞 看板 UI你會發(fā)現(xiàn)產(chǎn)品之間的差異被壓縮到了“Skill 組合 提示詞 UI”這三樣。底座承擔了 80% 的復雜度產(chǎn)品只負責 20% 的差異化。這就是套件化的價值新增一個產(chǎn)品從“重寫一個 Agent 系統(tǒng)”變成“配置一套 Skill 和提示詞”。但這里有個陷阱我必須提醒不是所有產(chǎn)品都適合塞進同一個底座。如果兩個產(chǎn)品的 Agent 交互范式差異過大比如一個是純對話一個是純批處理流水線強行統(tǒng)一底座會導致抽象層被迫做得極其寬泛最后誰都用得不順手。判斷標準是它們的“模型調用 Skill 調用 會話管理”這三件事的形態(tài)是否一致。一致就能共享底座不一致就該獨立。2. Agent 底座的分層設計與 Skill 機制拆解底座怎么分層直接決定了它能撐多久。我見過太多“統(tǒng)一底座”項目死在第二層——抽象做淺了上層產(chǎn)品各自繞過底座直連模型抽象做深了底座變成一個改不動的黑盒。WorkBuddy 這套體系能統(tǒng)管五個產(chǎn)品說明它的分層是經(jīng)過實戰(zhàn)檢驗的。我按自己的理解把它拆成四層并重點講 Skill 機制因為熱詞里skill出現(xiàn)的頻率高得離譜這一定是整個體系的重心。2.1 四層架構接入層、編排層、能力層、資源層接入層負責協(xié)議適配。企業(yè)里五個產(chǎn)品可能用不同的調用方式有的走 HTTP OpenAPI有的走 WebSocket 長連接有的走 SDK。接入層要把這些協(xié)議統(tǒng)一成內部的 Agent 請求格式。熱詞里OpenAPI反復出現(xiàn)說明對外暴露標準 OpenAPI 是這套體系的重要能力——第三方系統(tǒng)可以通過 OpenAPI 直接調用底座能力而不需要理解內部協(xié)議。編排層是 Agent 的大腦負責決定“這一步該調模型還是調 Skill”“上下文怎么組裝”“多輪怎么推進”。這一層是產(chǎn)品差異化的主要戰(zhàn)場但底座要提供的是編排原語而不是替產(chǎn)品做編排決策。比如底座提供“條件分支”“并行調用”“重試”這些原語產(chǎn)品用它們拼出自己的流程。能力層就是 Skill 層。所有可被 Agent 調用的能力——查數(shù)據(jù)庫、調 API、讀文件、畫圖、跑代碼——都注冊在這里。這一層是底座最核心的資產(chǎn)。資源層是模型、向量庫、存儲、計算資源的抽象。這一層要屏蔽具體供應商差異讓上層不關心用的是哪個模型。這四層里編排層和能力層的邊界最容易畫錯。我的經(jīng)驗是編排層只負責“怎么調”能力層只負責“調什么”。一旦編排層開始關心具體 Skill 的業(yè)務邏輯或者能力層開始關心調用順序邊界就破了。2.2 Skill 機制底座的能力單元熱詞里有一堆關于 Skill 的搜索skill插件、agent skill、workbuddy skill、skill編碼193、skill編碼247、測試skill、豆包skill、codex skill、codex論文skill、打斗動作提示詞skill、gemini反重力skill。這些詞說明 Skill 已經(jīng)形成了一個生態(tài)不同來源、不同用途的 Skill 都在往這個體系里接。Skill 的本質是給 Agent 用的函數(shù)。它和普通函數(shù)調用的區(qū)別在于三點第一Skill 必須能被模型“理解”所以它需要自然語言描述description第二Skill 的輸入輸出要能被模型消費所以通常是結構化的 JSON Schema第三Skill 要有權限和配額因為 Agent 可能被誘導調用危險操作。一個 Skill 的標準定義大概長這樣{ name: query_sales_data, description: 查詢指定時間范圍內的銷售數(shù)據(jù)返回匯總結果, version: 1.2.0, parameters: { type: object, properties: { start_date: {type: string, description: 開始日期 YYYY-MM-DD}, end_date: {type: string, description: 結束日期 YYYY-MM-DD}, region: {type: string, description: 區(qū)域可選} }, required: [start_date, end_date] }, permissions: [sales:read], timeout_ms: 10000 }這里有幾個設計要點值得展開。description 的寫法直接決定模型能不能正確調用。我踩過的坑是description 寫得太技術化模型理解不了業(yè)務語義寫得太模糊模型會亂調。好的 description 是“業(yè)務語義 邊界條件”比如“查詢銷售數(shù)據(jù)僅支持最近兩年超過范圍會報錯”。version 字段是必須的。Skill 會迭代如果沒版本管理某個產(chǎn)品依賴舊行為、另一個產(chǎn)品依賴新行為就會互相打架。底座要支持多版本共存產(chǎn)品按需鎖定版本。permissions 是安全底線。熱詞里有agent安全這不是空話。Agent 被 prompt injection 攻擊時最危險的就是它調用了不該調的 Skill。底座必須在 Skill 調用前做權限校驗而不是信任模型的判斷。2.3 Skill 的注冊、發(fā)現(xiàn)與隔離五個產(chǎn)品共享一個 Skill 注冊中心但不是所有 Skill 對所有產(chǎn)品可見。這里需要三層隔離全局 Skill所有產(chǎn)品都能用比如“獲取當前時間”“通用搜索”。產(chǎn)品級 Skill只有特定產(chǎn)品能用比如代碼產(chǎn)品的“執(zhí)行單元測試”。租戶級 Skill企業(yè)客戶自己上傳的私有 Skill只對該租戶可見。隔離靠的是 Skill 的 namespace 和權限標簽。產(chǎn)品在初始化時聲明自己需要哪些 namespace底座只返回可見的 Skill 列表。這樣既保證了共享又避免了污染。Skill 的發(fā)現(xiàn)機制有兩種靜態(tài)注冊和動態(tài)發(fā)現(xiàn)。靜態(tài)注冊是啟動時加載配置文件適合穩(wěn)定的核心 Skill動態(tài)發(fā)現(xiàn)是運行時從注冊中心拉取適合頻繁更新的 Skill。企業(yè)版通常兩者結合核心 Skill 靜態(tài)加載保證啟動速度擴展 Skill 動態(tài)拉取保證靈活性。注意動態(tài)發(fā)現(xiàn) Skill 時一定要做簽名校驗。我見過有團隊為了圖方便允許從任意 URL 加載 Skill 定義結果被注入了一個“讀取環(huán)境變量”的惡意 Skill。Skill 的來源必須可信加載前必須驗簽。2.4 上下文管理最容易被低估的一層會話與上下文管理是套件化里最不顯眼但用戶感知最強的一層。五個產(chǎn)品共享會話意味著用戶在代碼產(chǎn)品里說“幫我看看昨天那個 bug”切到辦公產(chǎn)品時 Agent 還能記得“昨天那個 bug”指的是什么。這需要底座維護一個跨產(chǎn)品的 Memory 層。Memory 的設計有兩個流派全量保留和摘要壓縮。全量保留簡單但 token 成本爆炸摘要壓縮省錢但會丟信息。我的實踐是分層 Memory最近 N 輪對話全量保留更早的對話做摘要關鍵實體人名、項目名、文件路徑單獨抽取成結構化記憶。這樣既控制了 token又保住了關鍵信息。上下文組裝的時候還有個細節(jié)不同產(chǎn)品的系統(tǒng)提示詞要注入到同一個上下文里。如果處理不好會出現(xiàn)“代碼產(chǎn)品的提示詞污染了辦公產(chǎn)品的對話”。解決辦法是給每段上下文打上來源標簽組裝時按產(chǎn)品過濾。3. 從零搭建底座核心模塊的實操過程前面講的是設計思路這一節(jié)我講具體怎么落地。我會按“模型接入層 → Skill 注冊中心 → 會話管理 → OpenAPI 暴露”的順序給出可參考的實現(xiàn)方案。這些方案是我基于常見企業(yè)級 Agent 平臺的實踐總結具體參數(shù)需要根據(jù)你的模型供應商和團隊規(guī)模調整。3.1 模型接入層多模型路由與配額池模型接入層的核心是統(tǒng)一接口 智能路由 配額管理。統(tǒng)一接口讓上層不關心具體模型智能路由根據(jù)任務類型、成本、延遲選擇模型配額管理防止某個產(chǎn)品把預算跑光。先看統(tǒng)一接口的設計。我建議定義一個內部模型調用協(xié)議所有模型都適配到這個協(xié)議class ModelRequest: def __init__(self, messages, model_hintNone, max_tokens4096, temperature0.7, toolsNone, tenant_idNone, product_idNone): self.messages messages self.model_hint model_hint # 上層可以給建議但路由層有最終決定權 self.max_tokens max_tokens self.temperature temperature self.tools tools # Skill 列表轉成模型的 function calling 格式 self.tenant_id tenant_id self.product_id product_id路由邏輯我通常分三級任務類型匹配 → 成本約束 → 可用性降級。任務類型匹配是看這個請求是代碼生成、長文本理解還是簡單問答不同任務用不同模型成本約束是看當前租戶的預算余額余額低就切便宜模型可用性降級是主模型超時或報錯時自動切備用模型。配額池的實現(xiàn)要點是按租戶 產(chǎn)品雙維度計量。只按租戶計量無法知道哪個產(chǎn)品在燒錢只按產(chǎn)品計量無法做租戶級預算。兩個維度都要有才能既做成本歸因又做預算控制。# 配額檢查的簡化邏輯 def check_quota(tenant_id, product_id, estimated_tokens): tenant_quota get_tenant_quota(tenant_id) product_quota get_product_quota(tenant_id, product_id) if tenant_quota.remaining estimated_tokens: raise QuotaExceeded(租戶配額不足) if product_quota.remaining estimated_tokens: raise QuotaExceeded(產(chǎn)品配額不足) return True實操心得配額檢查一定要在調用模型之前做而且要預留 buffer。我見過有團隊在調用后才扣減配額結果并發(fā)請求同時通過了檢查實際消耗遠超預算。正確做法是調用前預扣、調用后按實際用量結算。3.2 Skill 注冊中心從定義到執(zhí)行Skill 注冊中心要解決四個問題定義、存儲、發(fā)現(xiàn)、執(zhí)行。定義用 JSON Schema存儲用數(shù)據(jù)庫或配置中心發(fā)現(xiàn)靠 namespace 過濾執(zhí)行靠沙箱隔離。執(zhí)行環(huán)節(jié)是最需要小心的。Skill 本質上是執(zhí)行任意代碼或調用外部系統(tǒng)如果不隔離一個惡意 Skill 就能拿到整個底座的權限。我的方案是進程級隔離 能力白名單每個 Skill 在獨立進程或容器里跑只能訪問白名單里的資源比如指定的數(shù)據(jù)庫連接、指定的 API 域名。# Skill 執(zhí)行的沙箱包裝 class SkillExecutor: def execute(self, skill_name, params, context): skill self.registry.get(skill_name, context.product_id) if not self.check_permission(skill, context.user): raise PermissionDenied() # 在隔離環(huán)境中執(zhí)行 with self.sandbox(skill.timeout_ms, skill.resource_limits): result skill.handler(params) # 記錄審計日志 self.audit_log(skill_name, params, context) return result審計日志這塊我要多說一句。熱詞里有agent安全企業(yè)級 Agent 的安全審計不是可選項。每次 Skill 調用都要記錄誰調的、調了什么、參數(shù)是什么、結果是什么、耗時多少。出安全事件時這份日志是唯一的追溯依據(jù)。3.3 會話管理跨產(chǎn)品的上下文連續(xù)性會話管理的核心數(shù)據(jù)結構是 Session。一個 Session 包含會話 ID、租戶 ID、參與的產(chǎn)品列表、消息歷史、結構化記憶、創(chuàng)建和更新時間。跨產(chǎn)品連續(xù)性的實現(xiàn)關鍵是Session 與 Product 解耦。Session 屬于用戶不屬于產(chǎn)品。用戶在產(chǎn)品 A 創(chuàng)建的 Session切到產(chǎn)品 B 時可以通過 Session ID 繼續(xù)。產(chǎn)品 B 拿到 Session 后按自己的系統(tǒng)提示詞重新組裝上下文。class Session: def __init__(self, session_id, tenant_id, user_id): self.session_id session_id self.tenant_id tenant_id self.user_id user_id self.messages [] # 全量消息 self.summary # 歷史摘要 self.entities {} # 結構化記憶 self.products set() # 參與過的產(chǎn)品 def add_message(self, role, content, product_id): self.messages.append({ role: role, content: content, product_id: product_id, ts: now() }) # 超過閾值觸發(fā)摘要 if len(self.messages) 50: self.compress()上下文壓縮的觸發(fā)閾值需要調。太小頻繁壓縮丟信息太大token 成本高。我的經(jīng)驗值是保留最近 20 到 30 輪全量更早的做摘要。摘要用便宜的小模型做成本可控。3.4 OpenAPI 暴露讓第三方接入底座熱詞里OpenAPI出現(xiàn)多次說明對外暴露標準接口是剛需。底座的能力要通過 OpenAPI 暴露給第三方系統(tǒng)讓它們能像調用普通 API 一樣調用 Agent。OpenAPI 設計有三個要點。第一認證用標準方案比如 OAuth2 或 API Key不要自創(chuàng)。第二接口要冪等Agent 調用可能重試非冪等接口會出問題。第三流式響應要支持Agent 的輸出是逐字生成的用 SSE 或 WebSocket 推送體驗最好。# OpenAPI 片段示例 paths: /v1/agent/chat: post: summary: 發(fā)起一次 Agent 對話 security: - ApiKeyAuth: [] requestBody: content: application/json: schema: type: object properties: session_id: {type: string} message: {type: string} product_id: {type: string} stream: {type: boolean, default: true} responses: 200: description: 流式返回 Agent 響應注意OpenAPI 暴露的接口一定要做速率限制和配額綁定。第三方系統(tǒng)可能寫出死循環(huán)調用沒有限流會把底座打垮。每個 API Key 綁定一個配額池超限直接拒絕。4. 常見問題與排查技巧實錄套件化落地過程中問題往往不在設計階段而在聯(lián)調和運維階段。我把踩過的坑整理成速查表覆蓋模型、Skill、會話、性能四類問題。4.1 模型接入類問題問題現(xiàn)象可能原因排查方法解決某產(chǎn)品突然大量 429配額被其他產(chǎn)品搶占查配額池實時用量按產(chǎn)品設獨立配額上限響應變慢但無報錯路由到了慢模型查路由日志的模型選擇調整路由權重或加超時成本突然飆升上下文沒壓縮查平均 token 數(shù)調低壓縮閾值模型返回格式錯亂提示詞與模型不匹配對比不同模型的輸出按模型定制提示詞模板這里重點說 429 問題。多產(chǎn)品共享配額池最容易出現(xiàn)的就是“一個產(chǎn)品把配額跑滿其他產(chǎn)品餓死”。解決辦法不是簡單加配額而是分級配額給每個產(chǎn)品設保底配額保證基本可用和彈性配額空閑時可用。保底配額之和不超過總配額彈性配額按優(yōu)先級分配。4.2 Skill 調用類問題Skill 相關的問題最隱蔽因為模型可能“靜默失敗”——它調用了 Skill 但沒告訴用戶。常見問題包括Skill 不被調用description 寫得太差模型沒理解。解決是把 description 改成業(yè)務語言并加 few-shot 示例。Skill 被錯誤調用多個 Skill 的 description 太相似模型分不清。解決是明確每個 Skill 的邊界在 description 里寫“僅用于 X不用于 Y”。Skill 超時外部依賴慢。解決是設合理超時超時后返回降級結果而不是報錯。Skill 權限報錯產(chǎn)品沒聲明對應 namespace。解決是檢查產(chǎn)品的 Skill 聲明配置。實操心得調試 Skill 調用時一定要打開模型的 function calling 日志。很多時候模型“看起來沒調 Skill”其實是調了但參數(shù)錯了。日志里能看到模型生成的原始參數(shù)這是定位問題的關鍵。4.3 會話與上下文類問題跨產(chǎn)品會話最容易出的問題是上下文污染。產(chǎn)品 A 的系統(tǒng)提示詞被帶到了產(chǎn)品 B 的對話里導致 Agent 行為異常。根因是上下文組裝時沒做來源過濾。解決辦法是給每條消息打 product_id 標簽組裝時只保留當前產(chǎn)品的系統(tǒng)提示詞歷史消息按需保留。另外結構化記憶要做租戶隔離不同租戶的實體不能混。還有一個坑是會話過期策略。會話不能永久保留否則存儲爆炸。我的方案是活躍會話保留 30 天過期會話歸檔到冷存儲只保留摘要。用戶主動刪除的會話立即清除。4.4 性能與穩(wěn)定性問題套件化之后底座成了單點。底座掛了五個產(chǎn)品全掛。所以高可用是硬要求。關鍵措施有三個。第一無狀態(tài)化底座的服務實例不保存狀態(tài)狀態(tài)全放 Redis 或數(shù)據(jù)庫這樣實例可以隨意擴縮容。第二熔斷降級某個模型供應商掛了自動切備用某個 Skill 超時率高自動熔斷。第三限流保護入口做全局限流防止突發(fā)流量打垮底座。# 熔斷器簡化實現(xiàn) class CircuitBreaker: def __init__(self, failure_threshold5, recovery_time60): self.failures 0 self.threshold failure_threshold self.recovery_time recovery_time self.opened_at None def call(self, func, *args, **kwargs): if self.is_open(): raise CircuitOpen(熔斷中請稍后重試) try: result func(*args, **kwargs) self.failures 0 return result except Exception as e: self.failures 1 if self.failures self.threshold: self.opened_at now() raise注意熔斷閾值不要設得太敏感。Agent 調用本身就有一定失敗率模型超時、Skill 抖動閾值太低會導致頻繁熔斷反而影響可用性。我的經(jīng)驗是連續(xù) 5 次失敗才熔斷恢復時間 60 秒起步。5. 套件化的邊界與擴展什么時候該拆什么時候該合寫到這兒我想聊聊套件化的邊界問題。因為“一個底座統(tǒng)管五個產(chǎn)品”聽起來很美好但不是所有團隊都適合。我見過強行套件化最后失敗的案例也見過該合沒合、維護成本爆炸的案例。判斷標準其實就一條產(chǎn)品之間的共享收益是否大于耦合成本。5.1 適合套件化的三個信號信號一產(chǎn)品間共享大量 Skill。如果五個產(chǎn)品里有 60% 以上的 Skill 是重疊的套件化收益巨大。反之如果每個產(chǎn)品的 Skill 都是獨有的共享底座的價值就只剩模型接入和會話管理收益有限。信號二有統(tǒng)一的租戶和權限體系。企業(yè)客戶買的是“一套 WorkBuddy”而不是“五個獨立工具”。如果產(chǎn)品各自有獨立的賬號體系客戶要管理五套權限體驗很差。套件化能統(tǒng)一身份這是企業(yè)版的剛需。信號三團隊有能力維護底座。底座是一個長期投入的基礎設施需要專門的團隊維護。如果團隊規(guī)模小五個產(chǎn)品都靠同一批人開發(fā)套件化反而增加協(xié)調成本。這種情況下先做“共享庫”而不是“共享底座”更務實。5.2 底座不該管的三件事套件化最容易犯的錯是底座管太多。有三件事底座不該管第一產(chǎn)品的業(yè)務邏輯。底座提供 Skill 和編排原語但“這個產(chǎn)品的 Agent 該怎么回復用戶”是產(chǎn)品的事。底座一旦開始關心業(yè)務語義就會變成改不動的巨石。第二產(chǎn)品的 UI 和交互。底座只提供 API不提供界面。界面是產(chǎn)品差異化的核心底座不該碰。第三產(chǎn)品的專屬數(shù)據(jù)。底座管會話和記憶但產(chǎn)品自己的業(yè)務數(shù)據(jù)比如代碼產(chǎn)品的代碼庫索引應該產(chǎn)品自己管。底座只提供存儲抽象不提供具體存儲。5.3 擴展新產(chǎn)品的標準流程套件化的最大價值是降低新增產(chǎn)品的成本。我總結了一個標準流程新增一個產(chǎn)品大概分四步定義產(chǎn)品畫像這個產(chǎn)品面向什么場景、用什么模型、需要哪些 Skill。配置 Skill 組合從 Skill 注冊中心挑選需要的 Skill聲明 namespace。編寫系統(tǒng)提示詞這是產(chǎn)品差異化的核心決定 Agent 的行為風格。接入 OpenAPI用底座的 OpenAPI 實現(xiàn)產(chǎn)品后端前端自己開發(fā)。這四步里系統(tǒng)提示詞是最花時間的。我見過有團隊以為套件化之后新產(chǎn)品一周就能上線結果提示詞調了兩周。提示詞不是寫一次就完要反復測試、迭代。建議給每個產(chǎn)品建一個提示詞測試集每次改動都跑一遍回歸。5.4 一個真實的擴展案例假設要新增一個“科研文獻助手”產(chǎn)品熱詞里有workbuddy 科研。按套件化流程產(chǎn)品畫像面向科研人員需要文獻檢索、摘要生成、引用格式化能力。Skill 組合復用底座的“通用搜索”Skill新增“文獻庫檢索”“引用格式化”兩個專屬 Skill。系統(tǒng)提示詞強調學術嚴謹性要求引用必須標注來源不確定的內容要明確說明。OpenAPI 接入用底座的 chat 接口前端做一個文獻管理界面。整個過程底座代碼零改動只新增了兩個 Skill 和一套提示詞。這就是套件化的威力——新增產(chǎn)品從“造輪子”變成“拼積木”。6. 我在這套體系里踩過的坑和總結的經(jīng)驗最后這部分我想拋開架構聊點更實在的東西。套件化這件事技術方案可以抄但經(jīng)驗抄不來。我把自己踩過的坑列出來希望能幫你少走彎路。第一個坑過早抽象。項目剛開始就想著“要統(tǒng)管五個產(chǎn)品”把底座抽象做得極其寬泛結果每個產(chǎn)品接入時都要寫一堆適配代碼。正確做法是先讓兩個產(chǎn)品跑通再抽象。兩個產(chǎn)品的共性才是真共性五個產(chǎn)品的共性往往是想象出來的。第二個坑Skill 沒有版本管理。早期覺得 Skill 改了就改了結果一個產(chǎn)品依賴舊行為另一個依賴新行為互相打架。后來加了版本字段產(chǎn)品鎖定版本問題才解決。Skill 一旦發(fā)布就不能改行為只能發(fā)新版本。第三個坑忽略可觀測性。上線初期沒做 Trace出問題只能靠猜。后來補了全鏈路 Trace才發(fā)現(xiàn)很多問題出在上下文組裝而不是模型本身?？捎^測性不是上線后補的是設計時就要留的。第四個坑配額沒做預扣。并發(fā)請求同時通過配額檢查實際消耗超預算。改成預扣 結算后解決。這個坑很隱蔽因為單請求測試永遠發(fā)現(xiàn)不了。第五個坑會話沒做租戶隔離。測試時用同一個租戶沒發(fā)現(xiàn)問題。上線后多租戶發(fā)現(xiàn)結構化記憶串了。所有涉及數(shù)據(jù)的地方都要先問一句“租戶隔離了嗎”。這套體系跑下來我最大的體會是套件化的難點不在技術而在邊界。技術方案網(wǎng)上都能搜到但“什么該共享、什么該獨立”這個判斷只能靠對業(yè)務的深刻理解。底座做得太厚產(chǎn)品失去靈活性做得太薄共享價值不足。這個平衡點每個團隊都不一樣只能自己摸索。如果讓我給正在考慮套件化的團隊一個建議那就是先從共享模型接入和 Skill 注冊中心開始這兩塊收益最明確、風險最低。會話管理和身份體系可以第二步做。至于產(chǎn)品專屬邏輯永遠不要往底座里塞。守住這條線底座就能活得久。