1. 兩則新聞拼出的信號入口比模型更早變成戰(zhàn)場最近 Agent 圈子里有兩件事被很多人當(dāng)成獨(dú)立新聞看但把它們放在一塊兒琢磨會發(fā)現(xiàn)其實(shí)是同一件事的兩面一邊是 Amazon 對新 Agent 產(chǎn)品 Muse 的準(zhǔn)入限制另一邊是 Manus 公開強(qiáng)調(diào)要給 Agent 發(fā)身份證。一邊在擋一邊在發(fā)證核心圍繞的都是同一個(gè)問題——個(gè)人 Agent 時(shí)代到底誰能掌握用戶進(jìn)門的那道閘門我關(guān)注 Agent 開發(fā)有段時(shí)間了看到這兩條消息時(shí)第一反應(yīng)是入口爭奪戰(zhàn)已經(jīng)正式開打而且比大多數(shù)人預(yù)想的要早。過去一年大家聊 Agent焦點(diǎn)全在模型能力上誰的推理強(qiáng)、誰的上下文長、誰的 Agent benchmark 分?jǐn)?shù)高。但 Muse 和 Manus 這兩件事把注意力拉回到了一個(gè)更基礎(chǔ)的層面——當(dāng) Agent 真正成為個(gè)人助手用戶是通過哪個(gè)通道進(jìn)入 Agent 世界的這個(gè)通道被誰控制進(jìn)入之后Agent 以什么身份存在、怎么被識別、怎么被授權(quán)這才是入口戰(zhàn)的真相。模型能力會快速趨同真正的護(hù)城河在入口。1.1 為什么是入口而不是模型先開戰(zhàn)模型層當(dāng)然重要但模型是標(biāo)準(zhǔn)化的商品。OpenAI 有 GPT 系列Anthropic 有 ClaudeGoogle 有 Gemini開源那邊還有 Llama、Qwen 在追趕。能力差距在縮小而且任何一家模型廠商都不可能壟斷全部需求。入口則完全不同。入口是稀缺的、排他的、有鎖定效應(yīng)的。舉個(gè)現(xiàn)實(shí)中的類比傳統(tǒng)互聯(lián)網(wǎng)時(shí)代搜索引擎是入口誰占據(jù)搜索框誰就握住了流量分配權(quán)移動(dòng)互聯(lián)網(wǎng)時(shí)代應(yīng)用商店和超級 App 是入口誰占據(jù)桌面誰就握住了用戶時(shí)長。到了 Agent 時(shí)代入口變成了用戶在哪個(gè)平臺啟動(dòng) Agent、Agent 以什么權(quán)限訪問數(shù)據(jù)、Agent 的執(zhí)行結(jié)果沉淀在哪里。一旦用戶習(xí)慣了一個(gè)入口切換成本極高。因?yàn)槿肟诒澈蟛恢皇墙缑孢€有聊天記錄、賬號體系、授權(quán)關(guān)系、記憶數(shù)據(jù)、工具鏈配置。這些東西是逐年積累的換入口等于重新養(yǎng)一遍。所以大廠和創(chuàng)業(yè)公司現(xiàn)在拼的不是誰的 Agent 更聰明而是誰能讓用戶養(yǎng)成從這里進(jìn)門的習(xí)慣。1.2 入口的三層結(jié)構(gòu)設(shè)備層、應(yīng)用層、工作臺層要把這場戰(zhàn)爭講清楚得先拆一下 Agent 入口到底分幾層。我習(xí)慣把它分成三層每一層都有不同的玩家和打法。第一層是設(shè)備層。手機(jī)、PC、眼鏡、音箱誰控制了設(shè)備上的系統(tǒng)級入口誰就能在 Agent 醒來時(shí)第一時(shí)間被調(diào)用。這一層最典型的例子是操作系統(tǒng)內(nèi)置語音助手向 Agent 能力的演進(jìn)以及瀏覽器默認(rèn)集成 AI 功能。設(shè)備層的優(yōu)勢是天然擁有用戶注意力但它的問題是搶占成本極高不是每個(gè)團(tuán)隊(duì)都有資格下場。第二層是應(yīng)用層。獨(dú)立 App、瀏覽器插件、桌面客戶端用戶主動(dòng)安裝一個(gè) Agent 客戶端把聊天、任務(wù)、自動(dòng)化都放進(jìn)這個(gè)容器里。Muse 和 Manus 這類產(chǎn)品走的都是應(yīng)用層路線做的是你有一個(gè)專門干活的 Agent 助理。這一層拼的是產(chǎn)品體驗(yàn)、工具集成度和用戶信任。第三層是工作臺層。這也是過去半年熱詞里頻繁出現(xiàn)的harness和第三方工作臺所屬的層級。用戶未必直接面對一個(gè) Agent 產(chǎn)品而是通過一個(gè)編排環(huán)境比如 IDE、筆記工具、自動(dòng)化平臺讓 Agent 在里面掛載工具、執(zhí)行任務(wù)。這一層拼的是生態(tài)位——能不能成為 Agent 默認(rèn)的工作現(xiàn)場。三層入口之間有疊加也有競爭。設(shè)備層想通吃應(yīng)用層想站在設(shè)備層之上工作臺層想承接應(yīng)用層的輸出。而入口戰(zhàn)的第一波沖突恰恰發(fā)生在應(yīng)用層和平臺分發(fā)規(guī)則之間這就是 Amazon 與 Muse 那件事的戲劇性所在。1.3 Muse 與 Manus 各自代表的進(jìn)入姿勢把兩件事放在這層結(jié)構(gòu)里再去看會清晰很多。Muse 代表的是一種我要獨(dú)立進(jìn)門的姿勢。它想直接面向用戶提供 Agent 服務(wù)試圖在設(shè)備層和應(yīng)用層之間找到自己的位置——用戶因?yàn)樗捏w驗(yàn)和功能而主動(dòng)安裝、主動(dòng)使用。這種姿勢在所有平臺時(shí)代都會面臨同一個(gè)問題你要在王國的地盤上開門王國的守門人未必樂意。Manus 代表的則是另一種思路它干脆不談進(jìn)門談進(jìn)門之后的身份。它要給 Agent 發(fā)身份證實(shí)際上是試圖在應(yīng)用層之上建立一套身份標(biāo)準(zhǔn)不管用戶從哪個(gè)入口進(jìn)來Agent 都有一個(gè)統(tǒng)一的身份標(biāo)識可以被識別、被授權(quán)、被信任。這種姿勢更聰明的地方在于它繞開了誰擁有入口這個(gè)必死問題轉(zhuǎn)而爭奪誰定義進(jìn)入之后的世界。兩條路線沒有絕對優(yōu)劣但背后的信號是一致的個(gè)人 Agent 的入口不再只是一個(gè)技術(shù)交互界面而是變成一個(gè)權(quán)力結(jié)構(gòu)問題。誰能進(jìn)門、進(jìn)門之后主人是誰、客人以什么身份在場這些才是接下來一年真正會反復(fù)上演的戲碼。2. Amazon 的擋一次準(zhǔn)入門檻的實(shí)戰(zhàn)演示先聲明一點(diǎn)我無意猜測兩家公司之間的具體商業(yè)細(xì)節(jié)討論那件事更值得沉淀的是它把 Agent 行業(yè)里一個(gè)經(jīng)常被忽視的殘酷規(guī)則擺上了臺面再好的 Agent 產(chǎn)品也要過平臺分發(fā)這一關(guān)。擋這個(gè)動(dòng)作發(fā)生在哪一步不重要重要的是它揭示了一件事——Agent 產(chǎn)品從來不是寫好代碼、上線官網(wǎng)就完事了。它要獲得用戶就必然經(jīng)過某些通道應(yīng)用商店、系統(tǒng)權(quán)限、API 授權(quán)、廣告投放、支付體系。這些通道由大平臺把守而大平臺自身也在做 Agent于是裁判和運(yùn)動(dòng)員出現(xiàn)了一體化。這不是某個(gè)特定公司的原罪而是所有平臺生態(tài)的共性問題。任何一個(gè)掌握分發(fā)渠道的巨頭面對一個(gè)試圖在自己地盤上建立用戶關(guān)系的 Agent 產(chǎn)品都會有天然的防御動(dòng)機(jī)。2.1 擋的本質(zhì)是生態(tài)準(zhǔn)入規(guī)則把Amazon 擋住 Muse翻譯成技術(shù)行業(yè)聽得懂的話其實(shí)是一個(gè) Agent 產(chǎn)品在獲得生態(tài)準(zhǔn)入資格時(shí)遇到了阻礙。這個(gè)生態(tài)可以是硬件設(shè)備的生態(tài)可以是應(yīng)用商店的生態(tài)也可以是某個(gè)云服務(wù)體系的生態(tài)。生態(tài)準(zhǔn)入規(guī)則向來不是寫在公開文檔里的它由一系列松散的條件組成。比如應(yīng)用商店的審核條款是否認(rèn)定你的 Agent 功能合規(guī)系統(tǒng)級 API 是否向你的類型開放默認(rèn)搜索引擎或默認(rèn)助手的位置是否輪到你支付通道是否允許你的訂閱計(jì)劃接入。每一條單獨(dú)看都公平合理合在一起就構(gòu)成了一道篩選墻。我有一次做 Agent 產(chǎn)品上架的經(jīng)歷感受特別深。功能開發(fā)只花了四周提審、補(bǔ)材料、修改隱私說明、解釋數(shù)據(jù)用途前后花了三周。其中有一條審核意見是需要進(jìn)一步說明 AI 生成內(nèi)容的邊界而這條意見在兩輪審核里的解讀完全不一樣。平臺不是不讓你過是讓每個(gè)想進(jìn)來的產(chǎn)品都付出足夠多的成本讓多數(shù)人知難而退。2.2 審核之外還有三道隱形門很多人以為審核就是全部其實(shí)審核只是第一道。一個(gè) Agent 產(chǎn)品要在平臺上活下來后面還有三道隱形門。第一道是分發(fā)位置。即便通過了審核你的 App 排在第幾位、在什么分類下、有沒有推薦位直接決定了用戶能不能看見你。Agent 類產(chǎn)品很難靠自然搜索獲得流量因?yàn)橛脩暨€不太會主動(dòng)搜Agent這個(gè)詞更多人搜的是AI 助手而那個(gè)詞已經(jīng)被巨頭占滿。第二道是設(shè)備能力入口?，F(xiàn)在的 Agent 產(chǎn)品越來越依賴系統(tǒng)級能力——后臺常駐、推送權(quán)限、跨應(yīng)用數(shù)據(jù)讀取、屏幕理解。這些能力平臺只向特定類型的應(yīng)用開放新進(jìn)來的 Agent 產(chǎn)品的申請周期和通過率都很有隨機(jī)性。而老牌巨頭自己就是平臺天然擁有這些能力。第三道是商業(yè)閉環(huán)。Agent 訂閱制需要一個(gè)支付通道支付通道背后是抽成、結(jié)算周期、用戶數(shù)據(jù)的二次歸屬。這三樣加起來往往決定了一個(gè)第三方 Agent 產(chǎn)品能不能在平臺上做到盈利。很多產(chǎn)品不是死于沒人用而是死于每筆收入都要被規(guī)則抽走一大塊同時(shí)用戶關(guān)系還被平臺的用戶系統(tǒng)隔開。2.3 被擋之后開發(fā)者必須在第一天就假設(shè)會被擋我在這個(gè)行業(yè)里吃過類似的虧。早期做工具類產(chǎn)品默認(rèn)把寶押在了單一分發(fā)渠道上結(jié)果渠道一調(diào)整規(guī)則整個(gè)獲客鏈路直接斷掉。后來再看 Agent 賽道發(fā)現(xiàn)這個(gè)風(fēng)險(xiǎn)被放得更大了——因?yàn)?Agent 產(chǎn)品對系統(tǒng)權(quán)限和數(shù)據(jù)權(quán)限的依賴更深被平臺斷供的代價(jià)也就更重。所以我現(xiàn)在做任何 Agent 相關(guān)項(xiàng)目第一件事不是寫代碼而是畫一張分發(fā)與依賴清單這個(gè)產(chǎn)品必須經(jīng)過哪些分發(fā)渠道每一步依賴的平臺能力有沒有替代方案如果被拒、被下架、被限制 API 配額用戶還能不能找到我用戶的數(shù)據(jù)和 Agent 身份是存在我的服務(wù)器上還是被平臺托管這張清單的價(jià)值在于它逼著你在第一天就假設(shè)會被擋而不是在收到壞消息的那天才開始想辦法。對被擋這件事真正的解決方案不能是事后申訴而是事前分散。2.4 破局思路多通道分發(fā)、標(biāo)準(zhǔn)協(xié)議、自有身份那被擋之后怎么破按我踩坑的經(jīng)驗(yàn)三條路比較實(shí)在。第一條路是多通道分發(fā)。不做單一 App 依賴而是同時(shí)上 Web 端、瀏覽器插件、桌面端、自托管版本。Web 端尤其重要因?yàn)?Web 分發(fā)不經(jīng)過應(yīng)用商店用戶打開鏈接就能用只是需要解決移動(dòng)端能力受限的問題。很多 Agent 產(chǎn)品初期階段用 Web 端驗(yàn)證需求跑通之后再針對平臺渠道做適配這個(gè)順序可以避免第一天就被擋在門外。第二條路是擁抱開放協(xié)議和標(biāo)準(zhǔn)。這也是為什么 Agent 圈子里 skills 類標(biāo)準(zhǔn)越來越受重視因?yàn)闃?biāo)準(zhǔn)化的能力包意味著你的工具邏輯可以從一個(gè)平臺遷到另一個(gè)平臺。今天你在某個(gè)工作臺里寫好的 skill明天在其他環(huán)境里也可能跑得起來這種可移植性是對平臺鎖定最有效的對沖。第三條路是提前建立自有身份體系。用戶必須屬于你而不是屬于某個(gè)平臺。哪怕現(xiàn)在你的 Agent 跑在別人的工作臺里也要讓用戶建立獨(dú)立的賬號、獨(dú)立的偏好設(shè)置、獨(dú)立的記憶數(shù)據(jù)這樣入口切換時(shí)才不會把用戶連根拔走。Manus 的身份證動(dòng)作在這個(gè)視角下其實(shí)就是這條路的先手棋。3. Manus 的身份證Agent 身份層才是普及的暗線相比被擋的被動(dòng)防守Manus 做身份證的主動(dòng)進(jìn)攻更值得拆解。這件事初看像一句比喻但落在技術(shù)層面它指向的是 Agent 生態(tài)里一個(gè)長期被忽略、卻早晚卡脖子的基礎(chǔ)設(shè)施——身份層。什么叫 Agent 的身份證簡單說就是一個(gè) Agent 在數(shù)字世界里可以穩(wěn)定地被識別、被信任、被授權(quán)的標(biāo)識。它解決的不是這個(gè) Agent 叫什么名字而是這個(gè) Agent 是誰、它有沒有權(quán)限做這件事、它的行為是否可以被追溯。3.1 身份證的三個(gè)組成標(biāo)識、憑證、行為記錄我拆 Agent 身份層的時(shí)候習(xí)慣拆成三塊。標(biāo)識是第一塊。每個(gè) Agent 需要一個(gè)長期存在且跨平臺一致的 ID。這個(gè) ID 不能只是某個(gè)平臺內(nèi)部的用戶 ID因?yàn)?Agent 會穿梭于不同平臺、不同工作臺、不同 API 之間。一個(gè)跨平臺的標(biāo)準(zhǔn)化 ID是 Agent 被其他服務(wù)識別的前提。憑證是第二塊。Agent 代表用戶去操作外部服務(wù)時(shí)需要證明我被授權(quán)這么做。這塊目前的實(shí)現(xiàn)大多走的是 OAuth 類授權(quán)協(xié)議Agent 持有訪問令牌令牌背后是用戶的一次性授權(quán)決策。憑證設(shè)計(jì)的關(guān)鍵是最小權(quán)限 可撤銷——Agent 只拿完成當(dāng)前任務(wù)所需的最小權(quán)限用戶隨時(shí)可以收回。行為記錄是第三塊也是經(jīng)常被遺忘的那塊。身份證不只是用來進(jìn)出門的還要記錄你在這個(gè)空間里做過什么。Agent 執(zhí)行過的操作、調(diào)用過的工具、讀取過的數(shù)據(jù)都應(yīng)該沉淀成可審計(jì)的日志。這既是為了安全追責(zé)也是為了讓用戶對 Agent 建立信任——信任不是憑空來的是從一次次有據(jù)可查的執(zhí)行記錄里積累起來的。3.2 沒有身份證的 Agent 世界有多混亂反推一下如果 Agent 一直沒有身份層會發(fā)生什么首先是信任問題。你讓一個(gè) Agent 去操作你的郵箱、日歷、支付賬戶但你無法確認(rèn)這個(gè) Agent 是你授權(quán)的那個(gè) Agent而不是魚目混珠的別的程序?，F(xiàn)在很多 API 明文密鑰的濫用問題本質(zhì)上就是身份識別缺失導(dǎo)致。其次是可追溯性缺失。Agent 執(zhí)行鏈一旦出錯(cuò)——比如它給客戶發(fā)了一封錯(cuò)誤的郵件——你連是哪一步執(zhí)行、哪個(gè)子 Agent 干的、調(diào)用了哪個(gè)版本的配置都說不清楚。做過 Agent 編排的人都知道多 Agent 協(xié)作里的錯(cuò)誤排查是噩夢沒有身份和操作 ID你只能靠猜。再一個(gè)是可攜帶性斷裂。用戶在一個(gè)平臺積累的 Agent 配置、技能包、記憶庫換一個(gè)平臺之后全部作廢。因?yàn)槊總€(gè)平臺的 Agent 沒有統(tǒng)一身份平臺之間互不承認(rèn)。這就像你去一個(gè)城市辦的交通卡到另一個(gè)城市不能刷用戶的遷移成本被強(qiáng)行拉高。3.3 身份層怎么落地從賬號體系到授權(quán)協(xié)議身份層不是一句口號它落地的技術(shù)路徑是現(xiàn)成的關(guān)鍵看有沒有產(chǎn)品愿意把它系統(tǒng)化地做出來。最基礎(chǔ)的方案是中心化賬號體系。Agent 服務(wù)商為每個(gè)用戶生成的每個(gè) Agent 建一個(gè)數(shù)字身份身份數(shù)據(jù)和授權(quán)記錄都存在服務(wù)商側(cè)。優(yōu)點(diǎn)是實(shí)現(xiàn)簡單、體驗(yàn)一致缺點(diǎn)是你信不信這個(gè)服務(wù)商——它掌握了你 Agent 的全部授權(quán)記錄數(shù)據(jù)一旦泄露就是連鎖風(fēng)險(xiǎn)。進(jìn)階一點(diǎn)的方案是標(biāo)準(zhǔn)化授權(quán)協(xié)議。用 OAuth 2.0 那套思路把 Agent 的授權(quán)變成用戶 - Agent - 第三方服務(wù)三級鏈Agent 每次訪問第三方服務(wù)都攜帶特定的 scope 和 token用戶可以在統(tǒng)一面板里查看和管理所有授權(quán)。這套思路的成熟度很高很多開發(fā)者工具已經(jīng)在用了難的不是技術(shù)而是讓足夠多的服務(wù)商愿意接入這套體系。再往上走還有去中心化身份的方向。用分布式賬本或自托管憑證的方式讓 Agent 的身份不依賴任何單一服務(wù)商。這套方向在隱私保護(hù)上更好但落地門檻也更高短期內(nèi)更適合安全敏感型場景。不管走哪條路設(shè)計(jì)原則是一致的Agent 身份的擁有者必須是用戶本人而不是某個(gè)平臺授權(quán)必須是最小夠用級別操作記錄必須完整保留。這也是我判斷一個(gè) Agent 平臺是否值得長期投入的三個(gè)硬指標(biāo)。3.4 從發(fā)證到認(rèn)證身份是信任鏈的起點(diǎn)最后再把視線拉回 Manus 這個(gè)動(dòng)作本身。給 Agent 發(fā)身份證只是一個(gè)起點(diǎn)價(jià)值更大的是隨之而來的認(rèn)證環(huán)節(jié)——也就是說當(dāng)別的服務(wù)遇到一個(gè) Agent 時(shí)能通過某種方式快速驗(yàn)證這個(gè) Agent 的身份是否有效、權(quán)限是否在期內(nèi)、行為記錄是否可靠。一旦這個(gè)環(huán)節(jié)打通Agent 之間的互操作就有了基礎(chǔ)。Agent A 可以安全地向 Agent B 派發(fā)任務(wù)因?yàn)樗鼈冎缹Ψ降纳矸菔钦鎸?shí)可信的第三方服務(wù)可以放心地響應(yīng) Agent 的調(diào)用因?yàn)樗梢则?yàn)證 Agent 所持憑證的有效性。這其實(shí)和現(xiàn)實(shí)世界里的身份證邏輯一模一樣。身份證本身只是一張卡值錢的是政府信用和跨機(jī)構(gòu)認(rèn)證網(wǎng)絡(luò)。Manus 如果真能把這套認(rèn)證網(wǎng)絡(luò)搭起來它在 Agent 生態(tài)里的位置就遠(yuǎn)不止一個(gè)產(chǎn)品而是一個(gè)連接節(jié)點(diǎn)——它掌握著誰能以什么身份進(jìn)入什么場景的中樞能力。從這個(gè)角度回頭看 Amazon 的擋就更能理解入口戰(zhàn)的完整閉環(huán)了一邊是平臺用準(zhǔn)入機(jī)制卡住新玩家的門一邊是新玩家試圖用身份層繞開平臺、直接建立與用戶和其他服務(wù)的信任關(guān)系。門可以被擋但身份證是全球通行的。4. 開發(fā)者怎么選邊harness、skills 與記憶層的工程取舍前面講的都是戰(zhàn)略層面的東西落到開發(fā)者身上真正的困難其實(shí)是我應(yīng)該用什么技術(shù)棧去參與這場入口戰(zhàn)熱詞里頻繁出現(xiàn)的 harness、framework、skills、memory、token、Rust 這些概念到底怎么選怎么搭配這一章說點(diǎn)我自己的工程實(shí)踐。我的判斷是入口戰(zhàn)打到技術(shù)層面勝負(fù)手在于三點(diǎn)——用 harness 還是 framework 搭建執(zhí)行環(huán)境、用 skills 還是 plugins 承載能力、用什么樣的記憶和身份方案處理持久化。4.1 harness 與 framework兩種路線的真實(shí)差異很多剛?cè)腴T的朋友會把 harness 和 framework 混為一談我一開始也踩過這個(gè)坑。簡單區(qū)分一下framework 解決的是Agent 內(nèi)部的邏輯編排——怎么規(guī)劃任務(wù)、怎么調(diào)用工具、怎么讓多個(gè) Agent 協(xié)作harness 解決的是Agent 與外部環(huán)境的交互邊界——怎么安全地執(zhí)行命令、怎么管理沙箱、怎么處理長會話里的工具調(diào)用循環(huán)。打個(gè)比方framework 是編劇負(fù)責(zé)寫劇本harness 是劇場運(yùn)營負(fù)責(zé)管設(shè)備、停電預(yù)案、觀眾退場。你可以用一個(gè)框架做復(fù)雜的多 Agent 編排但如果執(zhí)行環(huán)境的安全邊界沒做好Agent 一通亂跑寫得再好的劇本也白搭。我自己的選擇邏輯比較簡單如果你做的是偏業(yè)務(wù)邏輯的 Agent——讀文檔、寫總結(jié)、跑自動(dòng)化流程——直接選一個(gè)成熟的框架把精力花在 prompt 設(shè)計(jì)和工具定義上如果你做的是偏基礎(chǔ)設(shè)施的 Agent——執(zhí)行命令行、操作文件系統(tǒng)、對接外部 API——那 harness 的安全性和穩(wěn)定性優(yōu)先級要高于一切。這兩年在工程圈里熱度上來的開源 harness 項(xiàng)目比如各類輕量 CLI 型 Agent Runner解決的核心問題就是讓 Agent 像一個(gè)人一樣安全地在終端環(huán)境里干活每一步執(zhí)行前要有審批每一個(gè)關(guān)鍵操作要留日志每一條指令都要有嚴(yán)格的權(quán)限邊界。這種思路做出來的 Agent天然適合接入正式生產(chǎn)環(huán)境。4.2 skills從插件到跨平臺能力包的演進(jìn)我再單獨(dú)聊聊 skills因?yàn)檫@是過去半年 Agent 開發(fā)生態(tài)里最值得關(guān)注的變化。老一代的 Agent 能力擴(kuò)展叫插件本質(zhì)上是一個(gè)平臺綁定的私有接口。你在 A 平臺上寫的插件到了 B 平臺全部重寫這既抬高了開發(fā)成本也強(qiáng)化了平臺鎖定。新一代的 skills 做了一件很聰明的事把能力定義和運(yùn)行環(huán)境解耦。一個(gè) skill 通常包含三樣?xùn)|西一份人類可讀的說明文檔SKILL.md描述這個(gè)能力能干什么、什么時(shí)候用、怎么用一組腳本或命令入口真正的執(zhí)行邏輯一份調(diào)用約定告訴 Agent 何時(shí)觸發(fā)、傳什么參數(shù)、期待什么輸出。我做 skills 的流程基本是這么跑的第一步把能力需求寫清楚。是把網(wǎng)頁保存成 Markdown還是批量重命名文件先定義輸入和輸出再描述邊界條件。第二步準(zhǔn)備可執(zhí)行腳本。Rust、Python、Node 都行關(guān)鍵是腳本要能獨(dú)立運(yùn)行、有清晰的參數(shù)接口、有完善的錯(cuò)誤處理。第三步寫 SKILL.md。這份文檔不是給人看的說明書是給 Agent 看的觸發(fā)手冊。它要包含能力的觸發(fā)條件、參數(shù)示例、使用禁忌、常見坑位——Agent 會根據(jù)這份文檔決定什么時(shí)候調(diào)用這個(gè) skill。第四步測試和迭代。每次讓 Agent 在真實(shí)任務(wù)里調(diào)用 skill把失敗案例回填到文檔里逐步提高 skill 的魯棒性。我團(tuán)隊(duì)里現(xiàn)在有三四十個(gè)維護(hù)狀態(tài)的 skills其中一個(gè)網(wǎng)頁轉(zhuǎn) Markdown 的 skill光失敗案例欄目就攢了十來個(gè)條目都是實(shí)際跑出來的不是拍腦袋想的。skills 對入口戰(zhàn)的意義在于它把能力與容器解耦了。你寫的 skill 在這個(gè)平臺能用換個(gè)平臺也能用那么你就擁有了一定程度的選擇自由。這也是我會建議所有 Agent 開發(fā)者盡早轉(zhuǎn)向 skills 語法的原因——你付出的開發(fā)成本沒有白費(fèi)能力資產(chǎn)是可遷移的。4.3 記憶與 Token 成本Agent 持久化的兩大基礎(chǔ)賬入口戰(zhàn)的另一個(gè)隱藏維度是記憶。用戶為什么不愿意切換 Agent 平臺最核心的原因是記憶——聊天記錄、偏好、項(xiàng)目上下文、歷史決策全在里面。沒有身份層和記憶層的可遷移能力入口鎖定是必然的。但記憶設(shè)計(jì)有個(gè)典型的坑很多人以為給 Agent 一個(gè) database 就能解決記憶其實(shí) token 成本才是真正的約束線。模型上下文都是有長度限制和成本代價(jià)的。你把所有歷史都往上下文里塞Agent 確實(shí)什么都記得但每次對話的 token 成本直線上升響應(yīng)速度也變慢最致命的是記憶噪聲會干擾 Agent 對當(dāng)前任務(wù)的理解。好的記憶設(shè)計(jì)應(yīng)該是分層的熱記憶當(dāng)前會話里正在用的信息放進(jìn)上下文溫記憶最近任務(wù)的要點(diǎn)壓縮成摘要或結(jié)構(gòu)化記錄按需注入冷記憶長期檔案比如用戶偏好、歷史項(xiàng)目總結(jié)只存不加載由 Agent 在需要時(shí)主動(dòng)檢索。這個(gè)三段式的設(shè)計(jì)我用了大半年實(shí)測下來 token 開銷能降低一半以上同時(shí) Agent 的回答質(zhì)量反而更穩(wěn)定因?yàn)樯舷挛睦餂]有那么多噪音了。熱詞里有AI agent token 是什么意思這個(gè)問題本質(zhì)上就是在問token 是 Agent 運(yùn)行的成本單位和上下文容量單位你的 Agent 設(shè)計(jì)方案決定了單位成本是多少。記憶分層是控制這個(gè)成本的第一杠桿skills 的按需觸發(fā)是第二杠桿——只加載當(dāng)下需要的工具不把整個(gè)工具庫塞進(jìn)上下文。4.4 場景化工程選擇自托管、Rust、第三方工作臺再聊幾個(gè)熱詞里出現(xiàn)的實(shí)戰(zhàn)選項(xiàng)對應(yīng)不同的開發(fā)場景。自托管方案適合隱私敏感型項(xiàng)目。數(shù)據(jù)不出自己的服務(wù)器Agent 身份、記憶、日志全在自己掌控下。代價(jià)是你要自己維護(hù)服務(wù)器、處理模型 API 的對接和配額、承擔(dān)運(yùn)維成本。如果你做的 Agent 要處理企業(yè)內(nèi)部數(shù)據(jù)自托管幾乎是必選項(xiàng)——因?yàn)閿?shù)據(jù)合規(guī)這條紅線沒人替你扛。Rust 相關(guān)的 Agent 框架最近熱度上升很快適合對性能和資源占用敏感的場景。比如你在一個(gè)受限的硬件環(huán)境里跑 Agent或者要做一個(gè)極輕量的 CLI AgentRust 的內(nèi)存效率和二進(jìn)制分發(fā)優(yōu)勢很明顯。我自己實(shí)際體驗(yàn)過幾個(gè)基于 Rust 的開源 Agent 框架感覺它們比較適合做Agent 即服務(wù)的底層模塊直接用 Rust 寫業(yè)務(wù) Agent 的團(tuán)隊(duì)還不太多但作為嵌入到現(xiàn)有系統(tǒng)中的輕量 agent runtime 是很合適的。第三方工作臺則是另一條低成本路線。你不自己搭環(huán)境直接把 Agent 塞進(jìn) Obsidian、桌面自動(dòng)化工具這一類工作臺里。熱詞里的hermes agent obsidian、agent anywhere基本指向這個(gè)方向。好處是上手快、界面現(xiàn)成、插件生態(tài)豐富壞處是你對 Agent 運(yùn)行環(huán)境的掌控力弱平臺一旦調(diào)整規(guī)則你要跟著改。這個(gè)路線更適合個(gè)人效率場景不適合做嚴(yán)肅的商業(yè)化產(chǎn)品。把這些路線過完之后我的核心建議其實(shí)很簡單不要押注單一技術(shù)棧而是把自己拆成可移植的能力層 穩(wěn)定的事件循環(huán) 獨(dú)立身份層無論外部入口和工具環(huán)境怎么變你都能快速適配。入口戰(zhàn)里被淘汰的永遠(yuǎn)是那些把自己焊死在單一依賴上的開發(fā)者。5. 給所有準(zhǔn)備入場的人三條立刻能落地的自保動(dòng)作講了這么多行業(yè)觀察和技術(shù)選型最后落回實(shí)操層面。如果你既不是大廠高管也不是投資人只是一個(gè)想做 Agent 產(chǎn)品、或者想用 Agent 提升生產(chǎn)力的普通人面對這場入口戰(zhàn)現(xiàn)在能做什么我根據(jù)自己的實(shí)際經(jīng)歷整理了三件馬上就能做的事。它們不復(fù)雜但能讓你在這場博弈里少踩不少坑。5.1 動(dòng)作一給 Agent 建一套可遷移的資產(chǎn)臺賬這個(gè)建議聽起來很樸素但絕大多數(shù)人沒做。很多用戶在用某個(gè) Agent 平臺時(shí)配置、提示詞、自定義指令、常用工具設(shè)置散落在各個(gè)地方哪天平臺改版或者你決定換工具所有積累直接歸零。我的做法是從第一天起就把 Agent 的配置資產(chǎn)文件化。所有提示詞、系統(tǒng)指令、常用參數(shù)寫成文本文件按項(xiàng)目分目錄存放在本地倉庫里配合版本管理工具做版本控制。一個(gè)可遷移 Agent 的最小資產(chǎn)包我一般建議包含這些內(nèi)容身份定義文件Agent 的角色設(shè)定、行為準(zhǔn)則、語氣風(fēng)格技能工具清單你依賴的 skills 的列表和對應(yīng)說明文檔常用流程模板比如周報(bào)生成流程、會議紀(jì)要整理流程的標(biāo)準(zhǔn)化步驟知識庫索引你平時(shí)喂給 Agent 的參考資料的目錄和摘要。這份臺賬的價(jià)值在于不管入口怎么換你都能帶著這套資產(chǎn)走。就像搬家前把家具列個(gè)清單到了新家照著清單重新布置就行不用從頭再置辦一遍。5.2 動(dòng)作二盡早測試 Agent 的安全邊界和權(quán)限模型入口戰(zhàn)里最容易受傷的是用戶因?yàn)槟阃懈督o Agent 的數(shù)據(jù)和權(quán)限正在成為各方爭奪的資源。別等出了問題才想起權(quán)限管理。具體操作上我建議給 Agent 的授權(quán)做最小化設(shè)計(jì)每一個(gè)新接進(jìn)來的服務(wù)或 API先給最低權(quán)限跑幾天確認(rèn)穩(wěn)定了再往上加。定期清理 Agent 的授權(quán)記錄把不再使用的令牌吊銷。給 Agent 的敏感操作增加二次確認(rèn)機(jī)制——比如發(fā)送郵件前需要我確認(rèn)刪除文件前需要我確認(rèn)。這個(gè)動(dòng)作看起來增加了操作步驟但它是一種成本極低的保險(xiǎn)。我見過太多人圖省事給了 Agent 完全的管理員權(quán)限結(jié)果一個(gè) prompt injection 事件就導(dǎo)致大量數(shù)據(jù)外泄。權(quán)限設(shè)計(jì)多一點(diǎn)麻煩數(shù)據(jù)泄露少一點(diǎn)風(fēng)險(xiǎn)這筆賬是劃算的。5.3 動(dòng)作三對入口專用的新鮮概念保持冷靜Agent 時(shí)代每天都有新概念冒出來有些確實(shí)有技術(shù)價(jià)值但有些只是營銷話術(shù)。我的原則是不管新概念講得多性感都先問三個(gè)問題——它解決的是不是身份層的真實(shí)需求它是不是一個(gè)可遷移的開放標(biāo)準(zhǔn)它是否把用戶權(quán)益放在第一位如果三個(gè)答案里有否定那這個(gè)概念大概率只是一次話語權(quán)爭奪。青年從業(yè)者容易被概念帶走花大量時(shí)間追逐所謂的最新趨勢結(jié)果能力和資產(chǎn)都沒有沉淀。真正能穿越周期的永遠(yuǎn)是那幾個(gè)樸素的東西你自己的技能資產(chǎn)包、你對身份和權(quán)限的掌控力、你對底層機(jī)制的理解力。我做了幾年 Agent 相關(guān)項(xiàng)目最大的體會是這場入口戰(zhàn)短時(shí)間內(nèi)不會有絕對贏家。平臺在攻創(chuàng)業(yè)公司在守用戶在被爭奪和說服之間搖擺。但有一點(diǎn)是確定的——在亂局里保持自己資產(chǎn)的獨(dú)立性和可遷移性的人永遠(yuǎn)有選擇權(quán)。你在哪個(gè)入口買的票決定了你進(jìn)哪個(gè)門但你手里握著什么資產(chǎn)、以什么身份存在決定了你進(jìn)沒進(jìn)門之后過得怎么樣。這句話不管是說給開發(fā)者、還是說給普通用戶都適用。