1. 從單兵作戰(zhàn)到團(tuán)隊(duì)協(xié)同企業(yè)級(jí) Agent 平臺(tái)要解決的真問(wèn)題過(guò)去一年我接觸過(guò)不少團(tuán)隊(duì)在內(nèi)部推 AI 編程助手幾乎都走過(guò)同一條曲線前兩周大家興致勃勃每個(gè)人都在自己的編輯器里裝插件、配模型、寫提示詞效率確實(shí)有肉眼可見的提升一個(gè)月之后問(wèn)題開始集中爆發(fā)——張三調(diào)好的那套提示詞李四不知道王五踩過(guò)的坑趙六又踩一遍某個(gè)同事離職后他電腦里那套祖?zhèn)髋渲弥苯邮?lián)團(tuán)隊(duì)想統(tǒng)計(jì)一下 AI 到底幫我們省了多少時(shí)間發(fā)現(xiàn)根本無(wú)從統(tǒng)計(jì)。這就是超級(jí)個(gè)體和超級(jí)團(tuán)隊(duì)之間的那道坎。單個(gè)開發(fā)者用 AI 工具把效率拉滿這件事在 2024 年就已經(jīng)被驗(yàn)證得很充分了但把這種個(gè)體能力沉淀成組織能力讓一個(gè) 20 人、50 人甚至 200 人的研發(fā)團(tuán)隊(duì)都能穩(wěn)定復(fù)用同一套 Agent 能力這是完全不同量級(jí)的問(wèn)題。騰訊云 WorkBuddy Enterprise 這個(gè)產(chǎn)品本質(zhì)上就是沖著這道坎去的——它要回答的不是AI 能不能寫代碼而是一個(gè)企業(yè)怎么把 AI 編程能力變成可管理、可復(fù)用、可度量的基礎(chǔ)設(shè)施。我先把結(jié)論擺前面企業(yè)級(jí) Agent 平臺(tái)的核心價(jià)值不在模型本身而在能力封裝 權(quán)限治理 效果度量這三件事上。模型能力是公共資源誰(shuí)都能調(diào)用但把某個(gè)團(tuán)隊(duì)特有的代碼規(guī)范、某個(gè)業(yè)務(wù)線的領(lǐng)域知識(shí)、某套經(jīng)過(guò)驗(yàn)證的工作流封裝成 Agent并且讓它在正確的權(quán)限邊界內(nèi)被正確的人使用這才是企業(yè)真正需要投入建設(shè)的地方。WorkBuddy Enterprise 配合 CodeBuddy、SkillHub 這套組合走的就是這條路。這篇文章我會(huì)從幾個(gè)角度拆企業(yè)級(jí) Agent 平臺(tái)到底要解決哪些個(gè)體工具解決不了的問(wèn)題、WorkBuddy Enterprise 的能力邊界在哪里、SkillHub 這種技能市場(chǎng)機(jī)制為什么關(guān)鍵、以及如果你現(xiàn)在要在一個(gè)真實(shí)團(tuán)隊(duì)里落地這套東西應(yīng)該按什么順序推進(jìn)、哪些坑必須提前避開。適合正在做技術(shù)選型的團(tuán)隊(duì)負(fù)責(zé)人、平臺(tái)工程師也適合想搞清楚企業(yè)級(jí) Agent和個(gè)人版 AI 助手到底差在哪的開發(fā)者。2. 企業(yè)級(jí) Agent 平臺(tái)繞不開的三道硬門檻2.1 能力封裝把某個(gè)人會(huì)用的技巧變成組織資產(chǎn)個(gè)人用 AI 編程工具最核心的資產(chǎn)其實(shí)是那個(gè)人腦子里的手感——他知道什么任務(wù)該拆成幾步問(wèn)、知道項(xiàng)目里哪些文件不能動(dòng)、知道這個(gè)團(tuán)隊(duì)的命名習(xí)慣是什么。這些知識(shí)高度隱性換個(gè)人就失效。企業(yè)級(jí)平臺(tái)要做的第一件事就是把這層隱性知識(shí)顯性化、結(jié)構(gòu)化。具體來(lái)說(shuō)一個(gè)可復(fù)用的 Agent 至少需要封裝四類信息任務(wù)邊界這個(gè) Agent 負(fù)責(zé)什么、不負(fù)責(zé)什么。比如只做單元測(cè)試生成不改業(yè)務(wù)邏輯邊界不清的 Agent 在團(tuán)隊(duì)里是災(zāi)難。上下文注入規(guī)則需要讀取哪些文件、哪些目錄要排除、要不要帶上接口文檔。這決定了 Agent 的輸出質(zhì)量下限。工具調(diào)用權(quán)限能不能執(zhí)行命令、能不能訪問(wèn)數(shù)據(jù)庫(kù)、能不能提交代碼。這是安全底線。輸出規(guī)范代碼風(fēng)格、注釋要求、提交信息格式。這決定了產(chǎn)出能不能直接進(jìn)主干。我見過(guò)太多團(tuán)隊(duì)把 Agent 做成一個(gè)萬(wàn)能提示詞結(jié)果就是誰(shuí)用誰(shuí)失望。真正好用的企業(yè) Agent往往是窄而深的——它只干一件事但把這件事干到 90 分以上。WorkBuddy Enterprise 里通過(guò) SkillHub 分發(fā)技能包本質(zhì)上就是在鼓勵(lì)這種窄而深的封裝方式。2.2 權(quán)限治理Agent 能碰什么必須由組織說(shuō)了算這是個(gè)人工具和企業(yè)平臺(tái)最本質(zhì)的分野。個(gè)人開發(fā)者給自己的 AI 助手開多大權(quán)限是自己的事但企業(yè)里一個(gè)能讀代碼、能執(zhí)行命令、能訪問(wèn)內(nèi)部系統(tǒng)的 Agent它的權(quán)限邊界必須由組織統(tǒng)一管控。我梳理過(guò)企業(yè)落地 Agent 時(shí)最容易出問(wèn)題的幾個(gè)權(quán)限場(chǎng)景風(fēng)險(xiǎn)場(chǎng)景典型后果治理手段Agent 讀取了敏感配置密鑰、連接串泄露目錄級(jí)白名單 敏感文件模式識(shí)別Agent 執(zhí)行了危險(xiǎn)命令誤刪數(shù)據(jù)、誤改生產(chǎn)配置命令沙箱 高危操作二次確認(rèn)Agent 提交了不合規(guī)代碼繞過(guò)代碼審查強(qiáng)制走 PR 流程 提交前校驗(yàn)Agent 調(diào)用了外部服務(wù)數(shù)據(jù)外流出網(wǎng)策略 調(diào)用審計(jì)WorkBuddy Enterprise 這類平臺(tái)的價(jià)值就在于把這些治理手段做成平臺(tái)級(jí)默認(rèn)能力而不是讓每個(gè)團(tuán)隊(duì)自己造輪子。一個(gè)團(tuán)隊(duì)自己搭的 Agent 系統(tǒng)往往在權(quán)限這塊是先跑起來(lái)再說(shuō)等出事再補(bǔ)代價(jià)極高。2.3 效果度量沒(méi)有數(shù)據(jù)AI 投入就是一筆糊涂賬第三個(gè)門檻是度量。老板問(wèn)我們花這么多錢買 AI 工具到底值不值如果答不上來(lái)下一年的預(yù)算就懸了。企業(yè)級(jí)平臺(tái)需要能回答幾個(gè)具體問(wèn)題哪些 Agent 被用得最多、平均每個(gè)任務(wù)節(jié)省多少時(shí)間、AI 生成的代碼有多少被直接采納、有多少被回滾、哪些團(tuán)隊(duì)用得好哪些團(tuán)隊(duì)用得差。這些數(shù)據(jù)不是用來(lái)考核的而是用來(lái)指導(dǎo)優(yōu)化的——用得少的 Agent 要么是設(shè)計(jì)有問(wèn)題要么是沒(méi)推廣到位采納率低的 Agent 說(shuō)明輸出質(zhì)量不達(dá)標(biāo)需要重新調(diào)優(yōu)。CodeBuddy 這類工具在個(gè)人場(chǎng)景下用戶自己感知效率提升就夠了但到了企業(yè)場(chǎng)景可度量性本身就是產(chǎn)品能力的一部分。這也是為什么 WorkBuddy Enterprise 要單獨(dú)做成企業(yè)版而不是把個(gè)人版功能堆一堆就完事。3. WorkBuddy Enterprise 的能力拼圖它到底由哪些部件組成3.1 CodeBuddy 作為執(zhí)行內(nèi)核個(gè)體效率的起點(diǎn)要理解 WorkBuddy Enterprise得先理解 CodeBuddy。CodeBuddy 是面向開發(fā)者的 AI 編程助手承擔(dān)的是執(zhí)行層的角色——代碼補(bǔ)全、對(duì)話式改代碼、多文件重構(gòu)、命令執(zhí)行、SSH 遠(yuǎn)程操作這些具體動(dòng)作都是它在做。我在實(shí)際項(xiàng)目里用 CodeBuddy 處理過(guò)幾類典型任務(wù)感受比較深第一類是跨文件重構(gòu)。比如要把一個(gè)散落在十幾個(gè)文件里的常量統(tǒng)一抽到一個(gè)配置模塊手工做要半小時(shí)還容易漏用 CodeBuddy 描述清楚意圖后它能一次性給出所有改動(dòng)點(diǎn)我只需要 review。這類任務(wù)的關(guān)鍵是把約束說(shuō)清楚——哪些文件要改、哪些不能動(dòng)、命名規(guī)范是什么。第二類是陌生代碼庫(kù)的快速理解。接手一個(gè)沒(méi)文檔的老項(xiàng)目直接問(wèn) CodeBuddy這個(gè)模塊的調(diào)用鏈路是什么比人肉翻代碼快得多。但要注意它的回答需要交叉驗(yàn)證尤其是涉及運(yùn)行時(shí)行為的部分。第三類是測(cè)試用例生成。這塊 CodeBuddy 表現(xiàn)相當(dāng)穩(wěn)尤其是邊界條件覆蓋比人手寫更全面。但生成的測(cè)試需要人工確認(rèn)斷言邏輯不能無(wú)腦合并。CodeBuddy 在個(gè)人場(chǎng)景下已經(jīng)能打但它的能力是會(huì)話級(jí)的——你關(guān)掉窗口這次積累的上下文就沒(méi)了。企業(yè)級(jí)平臺(tái)要解決的就是把這個(gè)能力持久化、結(jié)構(gòu)化、可分發(fā)。3.2 SkillHub 作為能力分發(fā)中樞讓好用的 Agent 流動(dòng)起來(lái)SkillHub 是我認(rèn)為這套體系里最值得說(shuō)道的部分。它的定位是技能市場(chǎng) / 技能倉(cāng)庫(kù)——團(tuán)隊(duì)里任何人調(diào)好的 Agent 配置可以封裝成 Skill 發(fā)布到 SkillHub其他人一鍵安裝就能用。這個(gè)機(jī)制解決了一個(gè)非?，F(xiàn)實(shí)的問(wèn)題AI 能力的復(fù)用成本。在沒(méi)有 SkillHub 之前一個(gè)團(tuán)隊(duì)里會(huì)用 AI和不會(huì)用 AI的人差距可能有三五倍有了 SkillHub這個(gè)差距會(huì)被快速拉平因?yàn)樽詈玫哪翘子梅梢员凰腥藦?fù)用。一個(gè)設(shè)計(jì)良好的 Skill我建議包含這些要素明確的適用場(chǎng)景描述一句話說(shuō)清楚什么時(shí)候該用它比如當(dāng)你需要為新寫的 service 層方法補(bǔ)單元測(cè)試時(shí)。輸入輸出約定需要用戶提供什么、產(chǎn)出什么格式。依賴聲明需要哪些工具權(quán)限、需要訪問(wèn)哪些目錄。示例至少一個(gè)完整的輸入輸出示例讓人一看就懂。版本與維護(hù)者誰(shuí)負(fù)責(zé)維護(hù)、多久更新一次。SkillHub 的另一個(gè)價(jià)值是沉淀組織知識(shí)。一個(gè)團(tuán)隊(duì)踩過(guò)的坑、總結(jié)的最佳實(shí)踐通過(guò) Skill 的形式固化下來(lái)新人入職直接裝一套 Skill等于把老員工的經(jīng)驗(yàn)打包帶走了。這比寫文檔有效得多因?yàn)槲臋n沒(méi)人看Skill 是拿來(lái)就能用的。3.3 WorkBuddy Enterprise 作為治理與編排層把散件組裝成體系CodeBuddy 是執(zhí)行內(nèi)核SkillHub 是分發(fā)中樞WorkBuddy Enterprise 則是把它們組織起來(lái)的治理與編排層。它要管的事情包括身份與權(quán)限誰(shuí)能用哪些 Skill、能訪問(wèn)哪些資源。策略下發(fā)統(tǒng)一配置模型、統(tǒng)一安全策略、統(tǒng)一審計(jì)規(guī)則。用量與效果分析誰(shuí)在用、用得好不好、省了多少時(shí)間。團(tuán)隊(duì)協(xié)作Skill 的共享、評(píng)審、版本管理。這三層的關(guān)系我習(xí)慣用一個(gè)類比CodeBuddy 是發(fā)動(dòng)機(jī)SkillHub 是零件倉(cāng)庫(kù)WorkBuddy Enterprise 是整車廠 交通管理系統(tǒng)。發(fā)動(dòng)機(jī)再好沒(méi)有整車廠組裝、沒(méi)有交通規(guī)則約束也上不了路。理解了這三層結(jié)構(gòu)就能明白為什么企業(yè)不能只買個(gè)人版工具湊合——個(gè)人版解決的是發(fā)動(dòng)機(jī)問(wèn)題企業(yè)真正缺的是整車廠和交通系統(tǒng)。4. 落地路徑一個(gè)真實(shí)團(tuán)隊(duì)該怎么分階段推進(jìn)4.1 第一階段先讓核心開發(fā)者跑通別急著全員鋪開我見過(guò)最典型的失敗案例是一上來(lái)就全員開通、全員培訓(xùn)結(jié)果三個(gè)月后活躍度掉到個(gè)位數(shù)。原因很簡(jiǎn)單沒(méi)有經(jīng)過(guò)驗(yàn)證的最佳實(shí)踐鋪得越廣浪費(fèi)越大。正確的做法是先選 3 到 5 個(gè)愿意折騰的核心開發(fā)者讓他們?cè)谡鎸?shí)項(xiàng)目里用 CodeBuddy把好用的用法沉淀成 Skill。這個(gè)階段的目標(biāo)不是覆蓋率而是產(chǎn)出第一批可復(fù)用的 Skill。這個(gè)階段我建議重點(diǎn)觀察幾件事哪些任務(wù)類型 AI 表現(xiàn)好、哪些表現(xiàn)差形成團(tuán)隊(duì)自己的能力地圖。哪些提示詞 / 配置反復(fù)被用到這些就是 Skill 的候選。出現(xiàn)了哪些安全問(wèn)題需要哪些治理規(guī)則。這個(gè)階段通常需要 2 到 4 周不要壓縮?；A(chǔ)沒(méi)打好后面全是返工。4.2 第二階段用 SkillHub 把驗(yàn)證過(guò)的能力分發(fā)出去第一批 Skill 打磨好之后通過(guò) SkillHub 發(fā)布然后逐步擴(kuò)大使用范圍。這個(gè)階段的關(guān)鍵是降低使用門檻——Skill 的描述要清楚、安裝要簡(jiǎn)單、出問(wèn)題要有人管。我在這個(gè)階段踩過(guò)的一個(gè)坑是Skill 發(fā)布后沒(méi)人用。排查下來(lái)發(fā)現(xiàn)不是 Skill 不好而是沒(méi)人知道它存在。后來(lái)我們做了兩件事一是在團(tuán)隊(duì)周會(huì)上專門花 10 分鐘演示新 Skill二是在 SkillHub 里給每個(gè) Skill 配一個(gè)什么時(shí)候用的標(biāo)簽。這兩招下去使用率明顯上來(lái)了。另一個(gè)經(jīng)驗(yàn)是建立 Skill 的反饋閉環(huán)。用的人遇到問(wèn)題要能快速反饋給維護(hù)者維護(hù)者根據(jù)反饋迭代 Skill。沒(méi)有這個(gè)閉環(huán)Skill 會(huì)迅速腐化最后變成沒(méi)人敢用的僵尸技能。4.3 第三階段接入 WorkBuddy Enterprise 做統(tǒng)一治理當(dāng)團(tuán)隊(duì)規(guī)模上來(lái)、Skill 數(shù)量變多之后就需要 WorkBuddy Enterprise 這樣的治理層介入了。這個(gè)階段要處理的問(wèn)題包括權(quán)限收斂之前為了跑通權(quán)限可能開得比較松現(xiàn)在要按最小必要原則收緊。策略統(tǒng)一模型配置、安全規(guī)則、審計(jì)要求統(tǒng)一到平臺(tái)層。效果度量建立一套指標(biāo)持續(xù)跟蹤 AI 投入的產(chǎn)出。這個(gè)階段最容易犯的錯(cuò)是治理過(guò)度。權(quán)限收得太緊開發(fā)者用起來(lái)處處受限活躍度反而下降。我的建議是漸進(jìn)式收緊——先監(jiān)控、再告警、最后才攔截給團(tuán)隊(duì)適應(yīng)的時(shí)間。4.4 一個(gè)容易被忽略的環(huán)節(jié)Agent 的退役機(jī)制大部分團(tuán)隊(duì)只想著怎么建 Agent不想著怎么退。結(jié)果是 SkillHub 里堆了幾百個(gè) Skill一半沒(méi)人維護(hù)、一半已經(jīng)過(guò)時(shí)新人進(jìn)來(lái)一臉懵。我建議從第一天就建立Skill 生命周期管理每個(gè) Skill 有明確的維護(hù)者、有最后更新時(shí)間、有使用量統(tǒng)計(jì)。超過(guò)一定時(shí)間沒(méi)人用、沒(méi)人維護(hù)的 Skill自動(dòng)標(biāo)記為待歸檔定期清理。這件事看起來(lái)小但決定了 SkillHub 長(zhǎng)期是資產(chǎn)還是負(fù)債。5. 實(shí)操中真正會(huì)卡住你的幾個(gè)細(xì)節(jié)5.1 上下文管理Agent 效果差八成是上下文沒(méi)喂對(duì)這是我在實(shí)際使用中體會(huì)最深的一點(diǎn)。同一個(gè) Agent喂對(duì)上下文和喂錯(cuò)上下文輸出質(zhì)量能差出一個(gè)數(shù)量級(jí)。常見的上下文問(wèn)題有幾類喂太多把整個(gè)倉(cāng)庫(kù)塞進(jìn)去模型注意力被稀釋關(guān)鍵信息反而被淹沒(méi)。喂太少只給一個(gè)函數(shù)模型不知道它在整個(gè)系統(tǒng)里的位置生成的代碼風(fēng)格對(duì)不上。喂錯(cuò)把過(guò)時(shí)的文檔、廢棄的接口定義帶進(jìn)去模型照著錯(cuò)的寫。我的經(jīng)驗(yàn)是分層喂上下文任務(wù)相關(guān)的核心文件全給周邊依賴給接口定義無(wú)關(guān)模塊只給目錄結(jié)構(gòu)。這個(gè)分層的規(guī)則最好固化到 Skill 里而不是每次靠人臨場(chǎng)判斷。5.2 提示詞的團(tuán)隊(duì)方言問(wèn)題每個(gè)團(tuán)隊(duì)都有自己的方言——命名習(xí)慣、目錄結(jié)構(gòu)、錯(cuò)誤處理風(fēng)格。個(gè)人用 AI 時(shí)這些方言靠人腦自動(dòng)翻譯企業(yè)級(jí) Agent 必須把這些方言顯式寫進(jìn) Skill。我建議每個(gè)團(tuán)隊(duì)維護(hù)一份AI 協(xié)作規(guī)范內(nèi)容包括命名約定、注釋要求、異常處理模式、日志規(guī)范、測(cè)試組織方式。這份規(guī)范不是給人看的文檔而是給 Agent 的約束條件要寫得足夠具體、足夠可執(zhí)行。舉個(gè)例子錯(cuò)誤處理要規(guī)范這種描述對(duì) Agent 毫無(wú)意義所有對(duì)外接口的錯(cuò)誤必須包裝成統(tǒng)一的 Result 類型不允許直接拋原始異常才是可執(zhí)行的約束。5.3 安全邊界哪些操作必須人工確認(rèn)Agent 能自動(dòng)執(zhí)行操作這是效率來(lái)源也是風(fēng)險(xiǎn)來(lái)源。我的原則是按影響范圍分級(jí)只讀操作讀文件、查文檔、分析代碼可以全自動(dòng)。本地寫操作改本地文件、生成測(cè)試可以自動(dòng)但要能一鍵回滾。遠(yuǎn)程寫操作提交代碼、推分支必須走 PR 流程人工 review。系統(tǒng)級(jí)操作執(zhí)行命令、訪問(wèn)數(shù)據(jù)庫(kù)、改配置必須二次確認(rèn)。這個(gè)分級(jí)不是拍腦袋定的而是根據(jù)出錯(cuò)后的恢復(fù)成本來(lái)的。恢復(fù)成本越高越要人工介入。WorkBuddy Enterprise 這類平臺(tái)的價(jià)值就是把這套分級(jí)做成平臺(tái)默認(rèn)策略而不是每個(gè)團(tuán)隊(duì)自己摸索。5.4 模型選型不是越強(qiáng)越好而是越合適越好企業(yè)里常見的誤區(qū)是無(wú)腦上最強(qiáng)模型。實(shí)際上不同任務(wù)對(duì)模型的要求差異很大任務(wù)類型對(duì)模型的要求選型傾向代碼補(bǔ)全低延遲、高吞吐輕量模型復(fù)雜重構(gòu)強(qiáng)推理、長(zhǎng)上下文旗艦?zāi)Ｐ臀臋n生成語(yǔ)言流暢、格式穩(wěn)定中等模型代碼審查強(qiáng)推理、領(lǐng)域知識(shí)旗艦?zāi)Ｐ桶押?jiǎn)單任務(wù)也丟給旗艦?zāi)Ｐ统杀緯?huì)失控把復(fù)雜任務(wù)丟給輕量模型質(zhì)量會(huì)崩。企業(yè)級(jí)平臺(tái)應(yīng)該支持按任務(wù)路由到不同模型這也是 WorkBuddy Enterprise 這類產(chǎn)品相比個(gè)人工具的一個(gè)明顯優(yōu)勢(shì)。6. 從工具到組織能力這套體系真正的長(zhǎng)期價(jià)值6.1 Agent 是載體組織知識(shí)才是資產(chǎn)用了大半年這套體系之后我最大的感受是Agent 本身不值錢Agent 背后沉淀的組織知識(shí)才值錢。一個(gè) Skill 之所以有價(jià)值不是因?yàn)樗昧硕嘞冗M(jìn)的模型而是因?yàn)樗庋b了這個(gè)團(tuán)隊(duì)在這個(gè)業(yè)務(wù)場(chǎng)景下經(jīng)過(guò)驗(yàn)證的最佳做法。模型會(huì)迭代、工具會(huì)更換但這些沉淀下來(lái)的知識(shí)是可以跨代際復(fù)用的。所以我在團(tuán)隊(duì)里推這套東西時(shí)反復(fù)強(qiáng)調(diào)一個(gè)觀點(diǎn)不要為了用 AI 而用 AI要為了沉淀知識(shí)而用 AI。每建一個(gè) Skill都要問(wèn)一句它封裝了什么別人不知道的東西。如果答案是沒(méi)有那這個(gè) Skill 就不該存在。6.2 度量體系要服務(wù)于優(yōu)化而不是考核前面提到效果度量這里再展開一點(diǎn)。度量數(shù)據(jù)最容易走偏的地方是變成考核工具——一旦和績(jī)效掛鉤大家就會(huì)開始刷數(shù)據(jù)度量就失真了。我的建議是度量數(shù)據(jù)只用于優(yōu)化不用于考核?？茨男?Skill 用得多就去研究為什么看哪些用得少就去了解是設(shè)計(jì)問(wèn)題還是推廣問(wèn)題。把度量當(dāng)成體檢報(bào)告而不是成績(jī)單。具體指標(biāo)我建議關(guān)注這幾個(gè)活躍度周活躍用戶數(shù)、人均使用次數(shù)。采納率AI 生成內(nèi)容被直接采用的比例?；貪L率AI 生成內(nèi)容被回滾的比例這個(gè)指標(biāo)比采納率更能反映質(zhì)量。節(jié)省時(shí)間通過(guò)任務(wù)前后耗時(shí)對(duì)比估算雖然粗糙但有參考價(jià)值。6.3 團(tuán)隊(duì)協(xié)作模式的改變從各寫各的到共建共享這套體系跑順之后團(tuán)隊(duì)協(xié)作模式會(huì)發(fā)生一個(gè)微妙但深刻的變化從各寫各的代碼變成共建共享的能力。以前一個(gè)開發(fā)者解決了一個(gè)難題經(jīng)驗(yàn)留在自己腦子里現(xiàn)在他會(huì)習(xí)慣性地想這個(gè)能不能做成 Skill 分享出去。這種轉(zhuǎn)變不會(huì)自動(dòng)發(fā)生需要機(jī)制引導(dǎo)——比如把 Skill 貢獻(xiàn)納入技術(shù)影響力評(píng)價(jià)、定期評(píng)選最有用 Skill、給 Skill 維護(hù)者一定的資源傾斜。我觀察下來(lái)一個(gè)團(tuán)隊(duì)從用 AI到共建 AI 能力通常需要 3 到 6 個(gè)月。這個(gè)過(guò)程中早期幾個(gè)標(biāo)桿 Skill 的示范效應(yīng)非常關(guān)鍵。只要有一兩個(gè) Skill 真正幫到了大家后面的事情就會(huì)自然發(fā)生。7. 一些踩過(guò)坑之后的實(shí)在建議寫到這里分享幾條我在實(shí)際推進(jìn)中總結(jié)的、文檔里不會(huì)寫的經(jīng)驗(yàn)。第一條不要追求全能 Agent。我見過(guò)太多團(tuán)隊(duì)想做一個(gè)什么都能干的超級(jí) Agent結(jié)果什么都干不好。正確的做法是做一堆專才 Agent每個(gè)只解決一個(gè)具體問(wèn)題但解決得足夠好。SkillHub 這種機(jī)制天然適合專才模式。第二條Skill 的文檔比 Skill 本身更重要。一個(gè) Skill 好不好用八成取決于它的說(shuō)明寫得清不清楚。我建議每個(gè) Skill 的說(shuō)明都包含什么時(shí)候用、怎么用、用了會(huì)怎樣、出問(wèn)題找誰(shuí)這四要素缺一不可。第三條給 Agent 留說(shuō)不的空間。好的 Agent 不是有求必應(yīng)而是在超出能力邊界時(shí)明確說(shuō)這個(gè)我做不了建議你這樣做。強(qiáng)行讓 Agent 處理它不擅長(zhǎng)的任務(wù)產(chǎn)出的是垃圾浪費(fèi)的是大家的時(shí)間。第四條定期做能力盤點(diǎn)。每隔一個(gè)季度把團(tuán)隊(duì)在用的 Skill 過(guò)一遍看看哪些還在用、哪些該更新、哪些該退役。這件事不做SkillHub 會(huì)迅速變成垃圾場(chǎng)。第五條安全規(guī)則要先緊后松不要先松后緊。一開始就把權(quán)限邊界劃清楚后面按需放開比一開始放開、出事再收緊要容易得多。后者不僅技術(shù)上麻煩還會(huì)打擊團(tuán)隊(duì)積極性。第六條別指望工具解決組織問(wèn)題。Agent 平臺(tái)能提升效率但解決不了團(tuán)隊(duì)不愿意分享流程本身就不合理這類組織問(wèn)題。工具是放大器好的組織會(huì)被放得更好壞的組織會(huì)被放得更壞。上工具之前先看看組織本身準(zhǔn)備好了沒(méi)有。這套體系我用了大半年最大的體會(huì)是企業(yè)級(jí) Agent 平臺(tái)的真正門檻從來(lái)不是技術(shù)而是組織愿不愿意把個(gè)體經(jīng)驗(yàn)變成公共資產(chǎn)。技術(shù)問(wèn)題都有解組織問(wèn)題才是真正的硬骨頭。WorkBuddy Enterprise 這類產(chǎn)品把技術(shù)側(cè)的活兒干得差不多了剩下的就看每個(gè)團(tuán)隊(duì)自己怎么走了。