EAF 這個(gè)詞第一次聽到的人很容易把它當(dāng)成又一個(gè)“AI 中臺(tái)”式的新名詞。但真正在企業(yè)里把 Agent 落到生產(chǎn)環(huán)境的人會(huì)一眼看出它解決的痛點(diǎn)非常具體Agent 接入不再需要每個(gè)系統(tǒng)單獨(dú)定制散落在不同團(tuán)隊(duì)手里的工具能力被收進(jìn)一個(gè)統(tǒng)一目錄大家腦子里那些“只有某某人會(huì)配”的知識(shí)經(jīng)驗(yàn)變成可復(fù)制、可共享的資產(chǎn)。接入、能力、知識(shí)經(jīng)驗(yàn)這三個(gè)層面上的孤島恰恰是很多企業(yè)內(nèi)部 AI 項(xiàng)目從 Demo 走向生產(chǎn)的最大阻力。這篇文章我想從實(shí)際踩坑的角度聊聊 EAF 這類平臺(tái)的設(shè)計(jì)思路和落地方法。無論你是技術(shù)負(fù)責(zé)人、AI 應(yīng)用工程師還是在企業(yè)里負(fù)責(zé)“把 AI 用起來”的推進(jìn)者只要能搞清楚這三個(gè)孤島是怎么形成的以及 EAF 用什么樣的機(jī)制去打通它們基本就能判斷這類平臺(tái)適不適合自己所在的團(tuán)隊(duì)。1. 用大白話拆解企業(yè)里的 Agent 落地為什么這么難1.1 接入孤島每個(gè)系統(tǒng)都得單獨(dú)“談戀愛”先描述一個(gè)很常見的畫面。某公司內(nèi)部有 OA、ERP、CRM、BI還有一堆自研的業(yè)務(wù)系統(tǒng)每個(gè)系統(tǒng)都有一套 API。想做一個(gè)銷售日?qǐng)?bào) Agent就得分別對(duì)接 CRM 取客戶數(shù)據(jù)、對(duì)接 BI 取業(yè)績(jī)數(shù)據(jù)再自己拼裝。想再做一個(gè)客服工單分類 Agent又得去對(duì)接工單系統(tǒng)、知識(shí)庫系統(tǒng)。這些系統(tǒng)的鑒權(quán)方式、數(shù)據(jù)格式、限流策略、錯(cuò)誤返回邏輯全都不一樣Agent 每接一個(gè)新系統(tǒng)基本就是一次新開發(fā)。我見過有團(tuán)隊(duì)在三個(gè)月里接入了六個(gè)系統(tǒng)光“鑒權(quán)適配”就寫了三套從簡(jiǎn)單的服務(wù)賬號(hào)到 OAuth2.0 回調(diào)用法都不一樣。前期一兩個(gè) Agent 勉強(qiáng)能忍一旦數(shù)量上了 10整個(gè)集成就變成了泥潭。真正可怕的是這些對(duì)接代碼都散落在不同 Agent 工程里A 項(xiàng)目里調(diào) CRM 的代碼B 項(xiàng)目完全沒法復(fù)用因?yàn)閰?shù)結(jié)構(gòu)都被各自的業(yè)務(wù)邏輯污染了。接入孤島的實(shí)質(zhì)是“點(diǎn)對(duì)點(diǎn)連接”沒有中間層。EAF 要做的不是幫你把 CRM 和 BI 的 API 都重寫一遍而是在所有 Agent 和后端系統(tǒng)之間加一層標(biāo)準(zhǔn)化的接入層。Agent 只需要面向平臺(tái)做一次對(duì)接平臺(tái)再去適配底下那些千奇百怪的內(nèi)部系統(tǒng)。這個(gè)思路聽著樸素但絕大多數(shù)企業(yè)一開始根本沒想明白。1.2 能力孤島同樣的工具被反復(fù)接入權(quán)限卻沒人說得清企業(yè)里有一類特別隱蔽的浪費(fèi)同一個(gè)能力被不同團(tuán)隊(duì)反復(fù)接入。舉個(gè)例子知識(shí)庫檢索能力A 團(tuán)隊(duì)接了一遍B 團(tuán)隊(duì)又接了一遍C 團(tuán)隊(duì)再接一遍。表面上大家都在干活實(shí)際上每次接入都要重新讀文檔、重新調(diào)參數(shù)、重新處理那些奇怪的返回格式。如果三個(gè)團(tuán)隊(duì)各自的實(shí)現(xiàn)里參數(shù)還不一樣那就更熱鬧了這個(gè)檢索返回 5 條那個(gè)檢索返回 10 條下游接口的根本沒法統(tǒng)一處理。能力孤島比接入孤島更麻煩的地方在于權(quán)限。A 團(tuán)隊(duì)把數(shù)據(jù)庫查詢能力封裝成一個(gè)只讀接口做得挺規(guī)范B 團(tuán)隊(duì)為了圖省事直接把一個(gè)可寫連接串封裝進(jìn)了 Agent 配置里。等哪天出問題了審計(jì)日志拉出來一看根本說不清是哪個(gè)團(tuán)隊(duì)、哪個(gè) Agent、哪個(gè)人干的。權(quán)限邊界模糊帶來的風(fēng)險(xiǎn)是實(shí)打?qū)嵉牟恢皇枪芾頋嶑眴栴}。能力孤島的本質(zhì)是能力沒有被“目錄化、標(biāo)準(zhǔn)化、授權(quán)化”。EAF 的做法很直接把企業(yè)內(nèi)部所有能被 Agent 調(diào)用的工具、API、模型、知識(shí)庫統(tǒng)一注冊(cè)成“能力”每個(gè)能力都有清晰的參數(shù)定義、權(quán)限級(jí)別和負(fù)責(zé)人。Agent 不再自己直連數(shù)據(jù)庫或第三方服務(wù)而是通過統(tǒng)一的授權(quán)中心去調(diào)用。1.3 知識(shí)經(jīng)驗(yàn)孤島真正值錢的東西都在腦子里在企業(yè)里做 Agent 時(shí)間長了會(huì)發(fā)現(xiàn)一個(gè)規(guī)律模型能力大家都差不多真正拉開差距的是知識(shí)積累。你去問一個(gè)團(tuán)隊(duì)“你們這個(gè)客服 Agent 的 Prompt 是怎么寫的”大概率得到的回答是“在小王的電腦里”或者“在咱們之前的聊天記錄里”。工作流怎么設(shè)計(jì)、哪些環(huán)節(jié)容易出錯(cuò)、低置信度的時(shí)候怎么兜底這些經(jīng)驗(yàn)高度依賴個(gè)人完全沒有結(jié)構(gòu)化。更要命的是就算有人把經(jīng)驗(yàn)寫成了文檔那也是一份“死文檔”沒法跟 Agent 運(yùn)行時(shí)的行為綁定起來。文檔告訴你“遇到模糊分類要轉(zhuǎn)人工”但具體怎么做、轉(zhuǎn)給誰、用什么策略文檔里全都沒有。團(tuán)隊(duì)成員一旦離職經(jīng)驗(yàn)就跟著人走了新來的同事只能重新踩一遍坑。知識(shí)經(jīng)驗(yàn)孤島是企業(yè) Agent 能力持續(xù)增長的隱形天花板。EAF 對(duì)這塊的處理不是簡(jiǎn)單提供一個(gè)“知識(shí)庫上傳文檔”的功能而是把經(jīng)驗(yàn)做成可版本化、可復(fù)制、可共享的單元讓團(tuán)隊(duì)能力真正沉淀到平臺(tái)上而不是留在個(gè)人腦子里。這一點(diǎn)后面我會(huì)詳細(xì)展開。2. EAF 的核心設(shè)計(jì)把“孤島”變成“平臺(tái)”的三層架構(gòu)2.1 接入層一套協(xié)議讓 Agent 像 U 盤一樣即插即用EAF 的接入層解決的是我前面說的第一個(gè)孤島。它的核心思想是給 Agent 定義一套統(tǒng)一的“插口協(xié)議”所有 Agent 都通過這個(gè)協(xié)議注冊(cè)到平臺(tái)跟平臺(tái)通信而不直接跟企業(yè)內(nèi)部零散的系統(tǒng)通信。這套協(xié)議要覆蓋的信息挺多但每一項(xiàng)都有明確目的身份標(biāo)識(shí)每個(gè) Agent 有唯一 ID所有調(diào)用日志都能追溯到具體 Agent意圖聲明Agent 主動(dòng)聲明自己擅長處理哪些類型的任務(wù)方便上層做意圖路由輸入輸出 Schema說清楚請(qǐng)求和響應(yīng)長什么樣避免“參數(shù)全靠口頭溝通”鑒權(quán)方式Agent 用什么身份訪問平臺(tái)常見的是服務(wù)令牌或 OAuth2.0 客戶端模式運(yùn)行約束超時(shí)時(shí)間、并發(fā)上限、調(diào)用頻率限制打一個(gè)生活化的比方過去不同的外部設(shè)備要用不同的充電線桌面一堆線亂得不行后來統(tǒng)一成了同一個(gè)接口標(biāo)準(zhǔn)桌面清爽了插拔也方便了。Agent 接入層干的就是這件事它的價(jià)值不在于技術(shù)多炫而在于把“一套接口”變成企業(yè)內(nèi)部的潛規(guī)則新增 Agent 不用再讓周邊系統(tǒng)跟著改動(dòng)。我見過一個(gè)實(shí)際案例某團(tuán)隊(duì)接 EAF 之前上線一個(gè)新 Agent 要協(xié)調(diào)三四個(gè)系統(tǒng)負(fù)責(zé)人排期動(dòng)輒一兩周有了統(tǒng)一接入層之后新 Agent 上線只需要平臺(tái)管理員審核一份配置半天搞定。這就是接入層最大的價(jià)值。2.2 能力層能力目錄 授權(quán)邊界EAF 的第二個(gè)核心是能力目錄。企業(yè)內(nèi)部所有能被 Agent 調(diào)用的工具、API、模型、知識(shí)庫都統(tǒng)一注冊(cè)到目錄里。目錄不是一張沒人看的 Excel 表而是運(yùn)行時(shí)授權(quán)的真實(shí)依據(jù)。每條能力在目錄里都帶這些信息字段說明示例能力 ID全局唯一標(biāo)識(shí)sales_data_read名稱人類可讀的名稱銷售數(shù)據(jù)只讀查詢類型工具 / API / 模型 / 知識(shí)庫API功能描述說清楚這個(gè)能力是干什么的查詢銷售明細(xì)支持按日期和區(qū)域過濾調(diào)用方式HTTP / gRPC / 本地函數(shù)HTTP參數(shù)定義入?yún)⒑统鰠⒌慕Y(jié)構(gòu)化描述date_range, region, output: list權(quán)限級(jí)別只讀 / 讀寫 / 管理只讀負(fù)責(zé)人誰能審批授權(quán)和變更數(shù)據(jù)組某同學(xué)調(diào)用限制限流、配額、可用時(shí)段1000 次/小時(shí)為什么能力目錄這么重要因?yàn)樗鉀Q了兩件事。第一是“可發(fā)現(xiàn)性”很多企業(yè)內(nèi)部有幾百個(gè) API但大家根本不知道它們存在、能干什么目錄化之后開發(fā)者不用到處打聽。第二是“運(yùn)行時(shí)授權(quán)”Agent 請(qǐng)求調(diào)用某個(gè)能力的時(shí)候平臺(tái)網(wǎng)關(guān)會(huì)根據(jù)目錄里的授權(quán)規(guī)則做校驗(yàn)Agent 自己拿著數(shù)據(jù)庫連接串到處跑的情況被徹底杜絕。實(shí)際操作中我一直強(qiáng)調(diào)一條原則默認(rèn)拒絕顯式授權(quán)。新的能力注冊(cè)進(jìn)目錄之后默認(rèn)沒有任何 Agent 可以調(diào)用誰要用得單獨(dú)申請(qǐng)。這個(gè)原則看著死板但能避免大量越權(quán)事故。2.3 知識(shí)經(jīng)驗(yàn)層從“文檔庫”到“經(jīng)驗(yàn)包”EAF 的知識(shí)經(jīng)驗(yàn)層是我覺得最貼近真實(shí)痛點(diǎn)的一塊。它分成兩個(gè)維度一個(gè)是知識(shí)庫給 Agent 提供事實(shí)依據(jù)另一個(gè)是“經(jīng)驗(yàn)包”把一套可運(yùn)行的 Agent 配置打包成一個(gè)可復(fù)制的單元。先講知識(shí)庫。企業(yè)里很多知識(shí)庫項(xiàng)目做不起來就是因?yàn)榇蠹乙詾椤鞍盐臋n傳上去”就完事了。實(shí)際上PDF、Word、掃描件混在一起語義結(jié)構(gòu)七零八落Agent 檢索出來的內(nèi)容自己都看不明白。EAF 在知識(shí)庫層面做的事情是讓知識(shí)的組織方式跟 Agent 的調(diào)用方式對(duì)齊——做切分、做向量化、做檢索測(cè)試讓知識(shí)真正能幫 Agent 回答業(yè)務(wù)問題。再講經(jīng)驗(yàn)包這是 EAF 很有特色的設(shè)計(jì)。舉個(gè)例子某電商團(tuán)隊(duì)花了三周打磨一個(gè)“工單分類 Agent”里面包含了精心調(diào)過的 Prompt、工具能力組合、分類置信度閾值、低置信度時(shí)的轉(zhuǎn)人工策略、以及一整套用于驗(yàn)證效果的測(cè)試問法。EAF 可以把這一整套東西打成一個(gè)“經(jīng)驗(yàn)包”B 團(tuán)隊(duì)想用的話一鍵導(dǎo)入改改行業(yè)術(shù)語和字段映射半天就能上線。經(jīng)驗(yàn)包和“文檔分享”最大的區(qū)別在于文檔只是文字經(jīng)驗(yàn)包是“可運(yùn)行的配置 操作方法”。你拿到的不是一個(gè)“建議參考”而是一套已經(jīng)驗(yàn)證過的干活工具改一改就能跑起來。這個(gè)機(jī)制對(duì)打破團(tuán)隊(duì)之間的知識(shí)經(jīng)驗(yàn)孤島非常有效。3. 落地實(shí)操把 EAF 接進(jìn)企業(yè)時(shí)的關(guān)鍵步驟3.1 第一步盤點(diǎn)場(chǎng)景而不是急著選技術(shù)我見過太多人一上來就問“EAF 支不支持某某模型”“能不能跑某某框架”其實(shí)這都是后話。落地 EAF 的第一步是盤點(diǎn)業(yè)務(wù)場(chǎng)景搞清楚到底哪些工作值得用 Agent 來做。實(shí)操中我建議列一張場(chǎng)景盤點(diǎn)表把公司里重復(fù)性高、規(guī)則相對(duì)清晰、人力成本高的流程都列出來然后按幾個(gè)標(biāo)準(zhǔn)打分評(píng)估維度說明打分參考頻次每周出現(xiàn)多少次每周占用超過 5 人小時(shí)才算值得做邊界清晰度任務(wù)規(guī)則是否明確規(guī)則越明確Agent 越容易做對(duì)數(shù)據(jù)可訪問性系統(tǒng)里能否取到需要的數(shù)據(jù)數(shù)據(jù)都沒有就別談了結(jié)果可驗(yàn)證有沒有明確的對(duì)錯(cuò)標(biāo)準(zhǔn)對(duì)錯(cuò)模糊的場(chǎng)景先放一放比較適合第一批做的場(chǎng)景通常有日?qǐng)?bào)周報(bào)生成、客服工單分類、合同關(guān)鍵條款抽取、報(bào)銷單據(jù)初篩、周會(huì)紀(jì)要整理、數(shù)據(jù)報(bào)表問答。這些場(chǎng)景共同點(diǎn)是邊界清楚、數(shù)據(jù)能拿到、結(jié)果能驗(yàn)證。這里想多提醒一句不要一上來就搞一個(gè)“全知全能企業(yè)大助手”那種項(xiàng)目最后基本都會(huì)因?yàn)榉秶Э囟?。先選兩三個(gè)場(chǎng)景做成樣板間讓業(yè)務(wù)方看到真實(shí)效果再談橫向擴(kuò)展。3.2 第二步配置 Agent 接入注意幾個(gè)細(xì)節(jié)場(chǎng)景選好之后就開始在 EAF 上注冊(cè) Agent。這個(gè)過程雖然不復(fù)雜但有幾個(gè)細(xì)節(jié)容易翻車。我用一份簡(jiǎn)化的配置示例來說明agent: id: weekly-report-agent name: 周報(bào)生成助手 description: 匯總各團(tuán)隊(duì)周報(bào)數(shù)據(jù)并生成 Markdown 格式的周報(bào)文檔 intents: - generate_weekly_report - summarize_team_updates inputs: scope: string week: string outputs: content: markdown auth: type: service_token scope: report_readonly runtime: timeout_ms: 60000 max_concurrency: 5這份配置里description 是最容易被忽略但最要命的一項(xiàng)。后面做意圖路由的時(shí)候系統(tǒng)主要靠 description 來判斷這個(gè)請(qǐng)求該不該交給這個(gè) Agent寫得太籠統(tǒng)路由很容易翻車。建議把“能干什么、輸入什么、產(chǎn)出什么”寫清楚。intents 的命名建議跟業(yè)務(wù)動(dòng)作對(duì)應(yīng)比如 generate_weekly_report別用那種誰都看不懂的縮寫。scope 權(quán)限遵循最小化原則周報(bào)助手只需要讀權(quán)限就沒必要給它一個(gè)可寫范圍。超時(shí)和并發(fā)也別用默認(rèn)值一刀切。有的 Agent 要調(diào)用外部接口耗時(shí)天然長超時(shí)設(shè)短了會(huì)反復(fù)失敗有的 Agent 是純內(nèi)部查詢并發(fā)可以開高一點(diǎn)提高吞吐。3.3 第三步能力注冊(cè)與權(quán)限邊界能力注冊(cè)看似簡(jiǎn)單但有個(gè)關(guān)鍵點(diǎn)容易想不明白能力的“原子粒度”怎么把握。還是舉例子?！鞍l(fā)送郵件”和“發(fā)送郵件給指定列表的所有人”底層是同一個(gè)郵件 API但語義和風(fēng)險(xiǎn)完全不同。前者給單個(gè)人發(fā)后者可能一下觸及幾百個(gè)客戶。EAF 的做法是把它們注冊(cè)成兩個(gè)能力分別授權(quán)、分別審計(jì)。能力原子化的原則是“最小原子、獨(dú)立授權(quán)”別為了省事把一個(gè)完整接口整塊注冊(cè)上去。權(quán)限模型建議這么分平臺(tái)管理員管理能力目錄、用戶角色和全局配置Agent 開發(fā)者創(chuàng)建和調(diào)試 Agent、申請(qǐng)能力調(diào)用權(quán)限業(yè)務(wù)用戶通過工作臺(tái)使用 Agent、查看自己的調(diào)用記錄審計(jì)員查看全量調(diào)用日志、數(shù)據(jù)訪問記錄不參與日常運(yùn)維權(quán)限邊界能真正落地前提是“統(tǒng)一網(wǎng)關(guān)”。所有 Agent 調(diào)能力都必須經(jīng)過平臺(tái)網(wǎng)關(guān)禁止直連后端數(shù)據(jù)庫或第三方服務(wù)。如果沒有這個(gè)硬性約束權(quán)限模型就是紙面上的一張圖。統(tǒng)一網(wǎng)關(guān)還有一個(gè)額外好處所有調(diào)用都有審計(jì)日志出了問題可以快速定位是誰、在什么時(shí)候、用什么 Agent 調(diào)了什么能力。3.4 知識(shí)經(jīng)驗(yàn)庫維護(hù)先有“評(píng)估集”再談“優(yōu)化”知識(shí)庫建設(shè)是企業(yè) Agent 項(xiàng)目里最容易被低估的工作。很多團(tuán)隊(duì)把文檔傳上去就覺得完事了結(jié)果一測(cè)試Agent 回答得亂七八糟然后開始懷疑是模型不行。其實(shí)問題往往出在“沒有評(píng)估機(jī)制”。我給一個(gè)比較靠譜的落地路徑給每個(gè)知識(shí)型 Agent 配一套“評(píng)估集”。評(píng)估集就是一批典型業(yè)務(wù)問題每個(gè)問題有期望的答案要點(diǎn)Agent 回答之后按要點(diǎn)打分。操作流程可以分成五步梳理業(yè)務(wù)里高頻的問題大概 50 到 100 條給每個(gè)問題寫好“期望答案要點(diǎn)”和“評(píng)分標(biāo)準(zhǔn)”讓 Agent 實(shí)際回答這批問題逐個(gè)打分針對(duì)低分項(xiàng)調(diào)整知識(shí)庫切分方式、檢索參數(shù)、Prompt每次升級(jí) Agent 或換模型先跑一遍評(píng)估集對(duì)比分?jǐn)?shù)有沒有下降這套方法聽著笨但非常管用。有了評(píng)估集你就可以告訴業(yè)務(wù)方“這個(gè) Agent 目前答對(duì)率為 85%上次升級(jí)后提升了 6 個(gè)百分點(diǎn)”一切用數(shù)據(jù)說話。而沒有評(píng)估集的時(shí)候大家只能憑感覺說“好像行又好像不行”這樣項(xiàng)目很容易變成玄學(xué)。4. 常見故障排查實(shí)錄接入、能力、知識(shí)經(jīng)驗(yàn)三個(gè)維度4.1 Agent 接入后時(shí)好時(shí)壞這是接入層最容易遇到的問題癥狀很典型同一個(gè)問題有時(shí)候秒回有時(shí)候卡半天有時(shí)候直接報(bào)錯(cuò)。很多人第一反應(yīng)是“模型能力不行”但排查下來往往不是。我的排查順序一般是這樣看 Agent 日志確認(rèn)是不是請(qǐng)求超時(shí)看網(wǎng)關(guān)日志確認(rèn)是不是被限流了看上游系統(tǒng)調(diào)用記錄確認(rèn)是不是外部 API 響應(yīng)慢或者不穩(wěn)定超時(shí)重試是重災(zāi)區(qū)。查詢類的操作理論上可以重試但發(fā)送通知、創(chuàng)建訂單這類非冪等操作不能盲目重試否則用戶會(huì)收到好幾條消息或者系統(tǒng)里出現(xiàn)重復(fù)單據(jù)。正確的做法是給不同操作配置不同的重試策略而不是全局統(tǒng)一重試三次。4.2 知識(shí)庫檢索質(zhì)量差答非所問這個(gè)問題幾乎每個(gè)企業(yè)知識(shí)庫項(xiàng)目都會(huì)碰到。癥狀是 Agent 回答內(nèi)容跟問題不相關(guān)或者回答得模棱兩可。排查時(shí)先看幾件事原始文檔是不是已經(jīng)被切分成合理的塊檢索時(shí)返回的 topK 合不合適分?jǐn)?shù)閾值設(shè)置的是不是過高或過低如果一個(gè)大合同 PDF 不切分就丟進(jìn)向量庫檢索按“塊”召回的時(shí)候一塊內(nèi)容就有幾千字語義中心很分散檢索質(zhì)量自然差。常見的參數(shù)參考我整理了一張表參數(shù)建議初始值調(diào)整方向chunk_size512 tokens內(nèi)容太長可適當(dāng)調(diào)小chunk_overlap64 tokens段落之間語義銜接差就調(diào)大topK5答案不全就調(diào)大噪音多就調(diào)小score_threshold0.3 - 0.4誤召回多就調(diào)高漏召回多就調(diào)低還要特別提醒一點(diǎn)企業(yè)內(nèi)部文檔格式遠(yuǎn)比想象中復(fù)雜。PDF 有掃描版、Word 有各種亂排版、Excel 有合并單元格。上傳知識(shí)庫之前先做一輪格式清洗和結(jié)構(gòu)化處理效果會(huì)好很多。4.3 Agent 越權(quán)調(diào)用能力權(quán)限報(bào)錯(cuò)不明確權(quán)限問題一旦出現(xiàn)往往嚇人一跳。我遇到過的情況是某個(gè) Agent 居然能修改客戶狀態(tài)而業(yè)務(wù)方根本不知道誰給它開了這個(gè)權(quán)限。排查之后發(fā)現(xiàn)是早期某個(gè)開發(fā)者為了調(diào)試方便把一個(gè)大而全的權(quán)限直接綁給了 Agent后來忘了收回來。這類問題的排查思路先看能力目錄里這個(gè) Agent 被授權(quán)了哪些能力再核對(duì)授權(quán)審批記錄確認(rèn)是不是有人顯式授權(quán)過最后看審計(jì)日志里 Agent 實(shí)際調(diào)用過哪些能力防范的關(guān)鍵還是我之前說的那兩條默認(rèn)拒絕、統(tǒng)一網(wǎng)關(guān)。后端能力只能通過網(wǎng)關(guān)訪問不允許任何 Agent 直連數(shù)據(jù)庫或內(nèi)部服務(wù)。這樣即使有人不小心配置錯(cuò)了權(quán)限審計(jì)日志也能記錄下來不至于出了事完全沒法查。4.4 經(jīng)驗(yàn)包過期無人維護(hù)經(jīng)驗(yàn)包用了一段時(shí)間之后可能會(huì)因?yàn)闃I(yè)務(wù)規(guī)則調(diào)整、接口字段變動(dòng)而失效。最常見的問題是沒人更新。原因其實(shí)不復(fù)雜——沒指定負(fù)責(zé)人也沒有生命周期管理機(jī)制。我的建議是給每個(gè)經(jīng)驗(yàn)包一個(gè)明確的生命周期指定 Owner負(fù)責(zé)定期檢查兼容性記錄最近使用時(shí)間平臺(tái)定期清理長期未被引用的低活躍包每次業(yè)務(wù)規(guī)則變更跑一遍包內(nèi)綁定的評(píng)估集確認(rèn)效果另外經(jīng)驗(yàn)包分享機(jī)制最好跟團(tuán)隊(duì)激勵(lì)掛鉤。誰共享的高質(zhì)量經(jīng)驗(yàn)包被其他團(tuán)隊(duì)采納了該怎么認(rèn)定貢獻(xiàn)這需要從組織制度層面去設(shè)計(jì)單靠平臺(tái)功能推動(dòng)不起來。我把上面幾個(gè)高頻問題匯總成一張速查表方便你在群里被同事時(shí)快速定位問題現(xiàn)象快速排查方向常用解決路徑時(shí)好時(shí)壞網(wǎng)關(guān)限流、上游超時(shí)、重試策略檢查日志按冪等性調(diào)整重試答非所問知識(shí)庫分塊、檢索參數(shù)、文檔格式調(diào)整 chunk/topK/閾值清洗文檔越權(quán)或權(quán)限報(bào)錯(cuò)能力授權(quán)記錄、網(wǎng)關(guān)審計(jì)改為默認(rèn)拒絕清理多余授權(quán)經(jīng)驗(yàn)包失效Owner、版本、最近使用時(shí)間指定負(fù)責(zé)人定期回歸測(cè)試5. 寫在最后我的一些實(shí)際體會(huì)真正把 EAF 這類平臺(tái)用好的團(tuán)隊(duì)最后都會(huì)有一個(gè)共識(shí)這事的核心根本不是 AI 模型有多強(qiáng)而是企業(yè)內(nèi)部有沒有形成一套標(biāo)準(zhǔn)化的機(jī)制。接入層統(tǒng)一的是接口標(biāo)準(zhǔn)能力層統(tǒng)一的是授權(quán)和復(fù)用規(guī)則知識(shí)經(jīng)驗(yàn)層統(tǒng)一的是經(jīng)驗(yàn)的沉淀方式。三件事本質(zhì)上都是“把混亂變成有序”。我實(shí)操中的一個(gè)體會(huì)是知識(shí)經(jīng)驗(yàn)孤島比技術(shù)和能力的孤島更難打通因?yàn)樗恢皇羌夹g(shù)問題更是組織問題。平臺(tái)能提供經(jīng)驗(yàn)包的機(jī)制但真正讓大家愿意分享、持續(xù)維護(hù)的是背后的激勵(lì)和認(rèn)同。所以如果你在團(tuán)隊(duì)里推這類平臺(tái)別只盯著技術(shù)落地也要想一想怎么讓分享經(jīng)驗(yàn)的人得到應(yīng)有的認(rèn)可。最后再分享一個(gè)小建議從第一天就建設(shè)評(píng)估集。不管你的 Agent 是做分類、抽取還是問答都值得配一套測(cè)試問法和評(píng)分標(biāo)準(zhǔn)。有了這個(gè)東西后面換模型、調(diào) Prompt、改知識(shí)庫參數(shù)才有據(jù)可依而不是每次升級(jí)都憑感覺。別等到出了問題才想起來補(bǔ)到那時(shí)候歷史包袱已經(jīng)夠你收拾一陣子了。