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