過去一年，AI 開始逐漸從 “ 對(duì)話 ” 向 “ 行動(dòng) ” 演進(jìn)，技術(shù)走得很快，能夠直接操作電腦，處理復(fù)雜任務(wù)的 “ 桌面智能體 ” 正成為新的技術(shù)前沿和競爭焦點(diǎn)。

2026 年 1 月 13 日，Claude 發(fā)布了 Cowork，成為第一個(gè)普通人能用圖形界面操控電腦文件的 Agent；一個(gè)多星期后，MiniMax 發(fā)布 Agent 2.0 版本，定位 “ AI 原生工作臺(tái) ”，不僅上線了桌面端，支持 Mac 和 Windows，還推出了面向垂直場景的 “ 專家模式 ”。

桌面端的優(yōu)勢似乎顯而易見：能操作大量本地文件，處理復(fù)雜長鏈路的任務(wù)，可能是真正深入人辦公場景的最佳環(huán)境。但同時(shí)面臨著諸如復(fù)雜環(huán)境適配，上下文更長，性能延遲和安全性等難題。我們想知道，行業(yè)是如何解決這些難題的，以及，桌面 Agent 到底能多大程度的深入到用戶，還是成為一個(gè)產(chǎn)品過渡的自嗨模式？

知危與 MiniMax Agent 2.0 團(tuán)隊(duì)核心成員，研發(fā)負(fù)責(zé)人阿島、產(chǎn)品負(fù)責(zé)人尋鷺進(jìn)行了一場對(duì)話，他們從產(chǎn)品、技術(shù)、組織和行業(yè)等層面，詳細(xì)地解答了我們的疑問，并且坦率地承認(rèn)，“ 現(xiàn)在，沒有一家 Agent 企業(yè)敢說自己有壁壘。”

如果你是非 AI 從業(yè)者，這場對(duì)話會(huì)讓你觸碰未來，如果你是 AI 領(lǐng)域從業(yè)者，那這場對(duì)話一定是你不容錯(cuò)過的前沿思考。

以下是對(duì)話原文，知危進(jìn)行了不改變原意的編輯。

知危：其實(shí)桌面 Agent 也有一些同行開始做了，MiniMax Agent 2.0（ 以下簡稱 2.0 ）發(fā)布的前一周，Claude Cowork 就發(fā)布了，所以 2.0 最初的契機(jī)是什么？產(chǎn)品研發(fā)經(jīng)歷了什么樣的過程？

阿島：我們選擇在此時(shí)上線并不是受同行發(fā)布的節(jié)奏影響，因?yàn)椴豢赡茉谝恢軆?nèi)趕出這種產(chǎn)品。

其實(shí)我們早在 2025 年 9 月初就有了 Expert （ 專家 ）模式和增加 Context （ 上下文 ）的想法，10 月份在內(nèi)部推行 “ Agent 實(shí)習(xí)生 ” 驗(yàn)證成功后，12 月 15 日正式立項(xiàng)投入。

我們在大模型創(chuàng)業(yè)公司中算比較精干的， Minimax 的模型和產(chǎn)品線布局最廣，涵蓋三個(gè)模態(tài)及對(duì)應(yīng)產(chǎn)品。盡管公司有 不到 400 人，但具體到每個(gè)產(chǎn)品上，我們可能都是以一對(duì)十（ 同行 ）的比例在作戰(zhàn)。

比如這次的桌面端，實(shí)際上是 3 個(gè)同學(xué)用一個(gè)月的時(shí)間就開發(fā)出來的。整個(gè) Agent 團(tuán)隊(duì)的研發(fā)力量非常精干，如果加上產(chǎn)品經(jīng)理，總共也就 4 個(gè)人左右。

Agent 實(shí)習(xí)生目前已經(jīng)在公司內(nèi)部普及和擴(kuò)散，成了大部分同事離不開的工具。

知危：所以 2.0 想解決的最核心問題是什么？

尋鷺：一句話概括：希望通過新的端和更專業(yè)的知識(shí)水平，幫用戶解決更多事情，干更多的活。

2.0 版本涉及更多的環(huán)境，從之前的網(wǎng)頁端擴(kuò)展到桌面端，可以利用本地工作區(qū)和更多文件來干活。

然后是質(zhì)量上的提升，通過專家系統(tǒng)，無論是官方還是 UGC 做的，都能將專業(yè)知識(shí)和流程打包成專家 Agent，去高質(zhì)量完成原本需要領(lǐng)域?qū)＜抑С值娜蝿?wù)。

知危：能不能更細(xì)致地解釋 Agent 2.0 的產(chǎn)品結(jié)構(gòu)？對(duì)于大多數(shù)人來說，還是相對(duì)陌生。

阿島：本質(zhì)上，我們認(rèn)為 1.0 階段的很多 Agent 只能完成單環(huán)節(jié)任務(wù)，更像是一個(gè) Demo。我們更希望看到它在生產(chǎn)力中真正發(fā)揮作用，這意味著它必須嵌入工作流。

2.0 版本源于我們公司的內(nèi)部版本（ 內(nèi)部稱為 Agent 實(shí)習(xí)生 ）的外化，我們對(duì) 2.0 的定位是它能像助理或?qū)嵙?xí)生一樣，在工作流中完整地完成任務(wù)并交付結(jié)果?；诖耍枰由斐霁@取充分 Context 的能力。比如內(nèi)部同事辦公場景下，Agent 需要能獲取到內(nèi)部各種 SaaS、IT、HR、財(cái)務(wù)、大數(shù)據(jù)，以及研發(fā)用到的監(jiān)控、報(bào)警、代碼倉庫等所有軟件工具的 Context。

第二個(gè)就是它需要具備相應(yīng)領(lǐng)域的專業(yè)知識(shí)。換句話說，財(cái)務(wù)、人事、研發(fā)、GPU Infra、文本算法和視頻算法的助理，它們之間非常不一樣。只有做到這一點(diǎn)，助理在用戶場景下才真正有用，能交付有價(jià)值且高度可用的任務(wù)結(jié)果。而不是說依然需要人類輸入大量上下文并重度參與，交付出一個(gè)自動(dòng)化程度低、不可用的結(jié)果。

從對(duì)外角度看，我們做桌面端是因?yàn)樗钱?dāng)前獲取用戶 Context 并操作環(huán)境的最佳方式，這樣才能真正嵌入工作流，像助理一樣幫用戶交付結(jié)果。助理的特點(diǎn)是你交給它任務(wù)，它還你結(jié)果，你不需要時(shí)時(shí)刻刻盯著它，且你可以幫助它進(jìn)步。第二點(diǎn)它是領(lǐng)域助理，這就是我們外化推出來的“專家”能力。以上這兩個(gè)核心輸入，也部分回答了 2.0 是如何生長出來的問題。

知危：所以你們內(nèi)部推行使用 “ Agent 實(shí)習(xí)生 ” 的時(shí)候，發(fā)生了什么？是怎么擴(kuò)散的？

阿島：擴(kuò)散過程首先是從最熟悉這些工具的技術(shù)和產(chǎn)品團(tuán)隊(duì)開始的。核心在于思維的轉(zhuǎn)變：每當(dāng)開始一項(xiàng)工作時(shí)，首先不是怎么用 Agent，而是思考 Agent 是否能解決；如果不能，它缺什么能力？

所以先后順序是研發(fā)團(tuán)隊(duì)、產(chǎn)品團(tuán)隊(duì)、 GPU Infra 團(tuán)隊(duì)、 HR 團(tuán)隊(duì)、 投資和財(cái)務(wù)團(tuán)隊(duì)，最后是銷售團(tuán)隊(duì)。我們的經(jīng)驗(yàn)是，一套能讓大家真正用起來且產(chǎn)生依賴的產(chǎn)品，必須具備本地環(huán)境、充分的 Context（ 上下文 ）、通過 OAuth 接入的云端環(huán)境，以及針對(duì)研發(fā)、HR、財(cái)務(wù)或銷售等差異化需求所提供的 Expert 專業(yè)知識(shí)。

知危：Agent 2.0 特別強(qiáng)調(diào) Context（ 上下文 ）的重要性，那么本地計(jì)算機(jī)提供的 Context，相比瀏覽器、手機(jī)等有哪些不同和優(yōu)勢？

阿島：從用戶視角看，Agent 是你的代理或助理。在嚴(yán)肅的工作場景中，2.0 和手機(jī)上只解決簡單知識(shí)查詢的大模型不同，我們希望真正像助理一樣解決工作以及未來生活中的問題。如果你有一個(gè)人類助理，你不會(huì)覺得它只用手機(jī)就能完成專業(yè)工作，這是不可能的。

尋鷺：從 Web 端轉(zhuǎn)到桌面端，主要解決了 Web 端無法處理的問題。首先是文件上傳的限制，以前 Web 版本如果需要用戶的文件，只能靠手動(dòng)上傳。但出于速度和固有速率的限制，網(wǎng)頁應(yīng)用通常會(huì)設(shè)置上限，不允許用戶上傳 5G 大小或多達(dá) 30 個(gè)以上的文件。對(duì)于有代碼倉庫的用戶，或者做圖文創(chuàng)意、有大量視頻圖片素材的用戶來說，在 Web 場景下根本沒辦法把這么多文件打包上傳。

有了桌面端之后，用戶可以直接選中文件夾進(jìn)行操作。比如攝影師處理視頻素材，或者用戶盤里有八千張照片需要整理，直接操作本地文件夾比上傳再下載八千張圖片到網(wǎng)頁端的流程要好得多。第二個(gè)桌面端解決的問題是，它能更好地實(shí)現(xiàn)瀏覽器托管場景，讓 AI 模擬人的點(diǎn)擊操作，在網(wǎng)頁上完成重復(fù)動(dòng)作。比如每天自動(dòng)爬取 TikTok、Twitter 等熱門社媒網(wǎng)站上對(duì)公司和產(chǎn)品的評(píng)價(jià)，并在發(fā)現(xiàn)負(fù)面信息時(shí)及時(shí)提醒。

這種場景如果放在 Web 端做，由于我們是通過沙盒來實(shí)現(xiàn)，加上 IP 潔凈度等限制，很容易被攔截。但在桌面端啟動(dòng)瀏覽器時(shí)，它是可以用用戶本身的瀏覽器來操作的，所以跑通網(wǎng)頁托管的整個(gè)流程會(huì)更加流暢、自然。現(xiàn)在無論是自動(dòng)監(jiān)控社媒，還是自動(dòng)發(fā)布帖子，都會(huì)比以前更加順暢。

確實(shí)，現(xiàn)在操作速度還比較慢，包括像 ChatGPT Atlas 的操作也比較慢。瀏覽器托管的速度問題和它的理解效率問題，是大家一直需要去優(yōu)化的方向。

對(duì)于手機(jī)端 APP ，我們一直做得比較輕，沒有把專家模式等重模式搬上去。原因在于，我們觀察到用戶使用 Agent 的方式與常規(guī) Chatbot 主打搜索、寫作不同，它更多是 C 端用戶在解決工作場景中長程、重復(fù)且繁瑣的操作。這類任務(wù)時(shí)間跨度大，不是在手機(jī)上發(fā)起后能即時(shí)得到回答的用法，如果只是即時(shí)需求，用戶也不需要求助 Agent。此外，在手機(jī)端操作網(wǎng)頁或軟件會(huì)受到系統(tǒng)及應(yīng)用權(quán)限的嚴(yán)格限制，挑戰(zhàn)更高，所以目前我們不太會(huì)觸碰這一塊。

知危：關(guān)于運(yùn)行 Agent 2.0 的環(huán)境，為什么不采用目前常見的云端沙盒，而更多依賴用戶的本地電腦環(huán)境？

阿島：云端沙盒除了有被風(fēng)控?cái)r截問題，從更專業(yè)的角度看，它本質(zhì)是面向通用場景的。舉個(gè)簡單的假設(shè)，比如專業(yè)的視頻剪輯團(tuán)隊(duì)，肯定配有非常好的機(jī)器、超大內(nèi)存和高性能 GPU，或者是 Mac Ultra 系列這種擁有大統(tǒng)一內(nèi)存和 APU 的設(shè)備。只有這樣，在跑 FFmpeg 這種視頻處理任務(wù)時(shí)，才能達(dá)到很好的性能。

但你不太可能在一個(gè)通用的沙盒里去滿足各種各樣的需求。比如我們的服務(wù)對(duì)象如果是算法工程師或 Reddit 上 LocalLLaMA 社區(qū)的愛好者，他們機(jī)器上可能裝了好幾塊 A100，這顯然不是沙盒能解決的問題。如果希望 Agent 對(duì)專業(yè)用戶在特定場景下真正好用，桌面端就有不可替代的優(yōu)勢，包括之前提到的 Context。

桌面端還有一個(gè)至關(guān)重要的優(yōu)勢：長期的 Context 沉淀與記憶構(gòu)建。在桌面端，我們并不是只依賴用戶指定的單個(gè)文件。隨著 Agent 在用戶電腦上運(yùn)行時(shí)間的增長，它會(huì)越來越了解用戶的上下文，并自動(dòng)構(gòu)建關(guān)于該用戶及其工作環(huán)境的 Memory。很多時(shí)候，你甚至不需要重新上傳或詳細(xì)說明，只需給出指令，只要是你過去曾經(jīng)操作過或存在于環(huán)境中的事情，它就能直接處理。這種深度環(huán)境感知和記憶積累是 Web 端無法實(shí)現(xiàn)的，因?yàn)?Web 端缺乏這種持續(xù)且原生的運(yùn)行環(huán)境。

最后必須強(qiáng)調(diào)：今天 Agent 進(jìn)步的最大瓶頸之一是 Agent Infra（ 可以簡單理解為智能體的基礎(chǔ)設(shè)施 ）。

知危：為什么這么說？

阿島：比如剛才說到了關(guān)于風(fēng)控?cái)r截或身份驗(yàn)證的方面，這叫 Agent Auth。即 Agent 作為你的個(gè)人助理，如何能真正代表你的身份？在云端沙盒上，它無法真正代表你，因?yàn)樗皇悄銈€(gè)人的機(jī)器，沒有你的 IP 指紋、User Agent 等信息，產(chǎn)生的操作更容易引發(fā)安全性討論。

但在你的本機(jī)，它就是你的個(gè)人電腦，代表你的個(gè)人身份。在這里操作瀏覽器或處理事務(wù)，身份對(duì)標(biāo)非常明確，不會(huì)存在這方面的問題。

我們橫向?qū)Ρ攘怂蝎@取網(wǎng)頁信息的 Agent，無論是像 Browser Use 這樣專業(yè)的、Manus 這樣通用的，還是 ChatGPT、Claude Code 等。最終結(jié)果是，在 Cloudflare 這種網(wǎng)絡(luò)安全服務(wù)商的反爬、反垃圾機(jī)制面前，成功率普遍不高。即便人類接管去點(diǎn)驗(yàn)證碼插件，也很有可能因?yàn)楸蛔R(shí)別出不是真實(shí)的桌面環(huán)境而無法通過。這就是目前 Agent Infra 面臨的現(xiàn)實(shí)挑戰(zhàn)。

我個(gè)人的觀點(diǎn)是，未來人類行為和基礎(chǔ)設(shè)施都會(huì)面向 AI 重新組織，屆時(shí)會(huì)有更不一樣的形態(tài)和更好的方式來驗(yàn)證 Agent 的代理身份。但就目前而言，桌面端形態(tài)在這些方面是難以替代的。

知危：如何理解云端沙盒本質(zhì)是面向通用場景的，卻又無法滿足很多需求，這是否矛盾？Agent 2.0希望面向通用還是垂直場景？

阿島：云端沙盒所謂的“通用”往往意味著只能處理淺層的、所有人適用的簡單任務(wù)。

而真正的 “ 通用 ” 應(yīng)該是能夠深入并覆蓋各種專業(yè)場景。正是為了實(shí)現(xiàn)這種高階的通用性，我們才必須開發(fā) “ 專家 ” 能力和桌面端。因?yàn)橹挥猩钊氲矫總€(gè)人的具體專業(yè)環(huán)境、調(diào)用高性能硬件并理解其特定的工作流，Agent 才能在各種垂直領(lǐng)域都把活兒干好。

換句話說，我們的目標(biāo)是通過深度專業(yè)化的能力，最終達(dá)成真正意義上的、全場景的通用。

比如寫公眾號(hào)。在你的本地環(huán)境，Agent 可以內(nèi)化你過往積累的大量素材、寫作習(xí)慣和風(fēng)格，并索引歷史資料，在你寫新文章時(shí)直接給出一個(gè)高度契合的初稿。這種深度的個(gè)性化能力，云端沙盒是無法實(shí)現(xiàn)的。相對(duì)而言，云端沙盒擅長的是那種完全脫離個(gè)人環(huán)境的任務(wù)，比如“去網(wǎng)上收集 100 雙耐克鞋的信息”，只需要通用互聯(lián)網(wǎng)訪問能力。

尋鷺：回顧去年，行業(yè)內(nèi)所謂的 “ 通用 Agent ” 大多停留在 “ 啥都能做一點(diǎn) ” 的 Demo 階段。比如我們早期的 Lightning 和 Pro 模式，內(nèi)置了幾個(gè)處理 Deep Research、PPT 或網(wǎng)頁開發(fā)的 Sub-agent，這只能算淺層的通用。但在去年下半年，通過訪談法務(wù)、財(cái)務(wù)等職能部門，我們發(fā)現(xiàn)真正的 “ 通用 ” 必須達(dá)到 Production Ready（ 生產(chǎn)就緒 ） 的標(biāo)準(zhǔn)。

這意味著它不能只靠一個(gè)死板的預(yù)設(shè)框架，而必須是一個(gè)優(yōu)雅、靈活、可路由且可插拔的專家模式。舉個(gè)例子，金融領(lǐng)域的 Deep Research 關(guān)注的是研報(bào)和實(shí)時(shí)行情數(shù)據(jù)；而法律領(lǐng)域則需要接入完全不同的判例數(shù)據(jù)庫、法規(guī)接口，且國內(nèi)外的法律邏輯也大相徑庭。如果只用一個(gè)固定的通用框架，由于預(yù)接的 Data Source API 偏向性（ 比如偏金融 ），它在法律場景就無法深入。所以，我們現(xiàn)在的自定義模式允許用戶疊加更多 “ 專家 ”，本質(zhì)上是通過這種高靈活性的框架，在各個(gè)垂直領(lǐng)域?qū)崿F(xiàn)真正的、深度的通用化交付。

知危：Agent 2.0 的產(chǎn)品形態(tài)比較新穎，您希望如何提升用戶認(rèn)知并帶動(dòng)用戶增長？

阿島：Agent 2.0 這種產(chǎn)品絕不是互聯(lián)網(wǎng)時(shí)代的買量產(chǎn)品，它首先不會(huì)完全受限于手機(jī)端，其次它深耕于生產(chǎn)力場景，而非娛樂或搜索這類淺層的通用場景。

增長的關(guān)鍵首先在于產(chǎn)品要達(dá)到極佳的效果并真正解決問題，其次要運(yùn)營起相應(yīng)的口碑和社群，建立良好的品牌，并基于實(shí)際的使用案例進(jìn)行傳播。

因此，我們的增長路徑會(huì)更接近 Cursor 或 Lovable 等海外產(chǎn)品的成長模式。

尋鷺：用戶可能并不是因?yàn)橹?MiniMax 是一個(gè)通用產(chǎn)品才被吸引，而是因?yàn)樵谀硞€(gè)帖子中看到它做營銷、社媒監(jiān)控或特定領(lǐng)域的工作非常好用才過來的。

針對(duì)垂直領(lǐng)域和專精 Agent，我們在獲取用戶和提升滲透率上面臨挑戰(zhàn)。因此，Expert 模式的下一個(gè)目標(biāo)是產(chǎn)出更多 PGC 和 PUGC 內(nèi)容，同時(shí)想辦法激勵(lì)更多 UGC 專家涌現(xiàn)。在這個(gè)過程中，我們希望用戶是因?yàn)橛幸粋€(gè)明確的問題或特定領(lǐng)域的訴求來使用 MiniMax Agent，而不是拿到一個(gè)看似無所不能、卻讓人不知道該拿它來做什么的通用產(chǎn)品。

Cursor 和 Lovable 增長策略的核心點(diǎn)在于：首先拋開常規(guī)手段，最關(guān)鍵的是能抓取并定義一個(gè)極具潛力的新場景。這種對(duì)場景的創(chuàng)新定義能力，決定了其后續(xù)做 PUGC 增長時(shí)能夠具備極高的初始勢能，并在起步階段就達(dá)成非常強(qiáng)悍的結(jié)果反饋。

另外，Base44 自建了一整套數(shù)據(jù)庫和云端托管，基于這些觀察，我認(rèn)為增長的核心在于兩點(diǎn)：產(chǎn)品定義足夠新穎，能在初期形成強(qiáng)大的勢能，產(chǎn)出極具說服力的結(jié)果。通過真實(shí)用戶的 Use Case 進(jìn)行口碑傳播和擴(kuò)圈，而非通過大規(guī)模買量吸引非核心用戶。投流獲取的流量往往伴隨著高流失率，只有讓核心用戶帶動(dòng)的裂變，才能保證增長的質(zhì)量和精準(zhǔn)度。

要形成增長勢能，首先需要明確核心場景。關(guān)于這一點(diǎn)，我們在海外已有明確的認(rèn)知：海外用戶在 Vibe Coding 以及視頻、圖文創(chuàng)意素材方面有極強(qiáng)的訴求，因此我們在 PGC Expert 的打造和引流方向上有清晰的指引。

在國內(nèi)市場，由于 MiniMax Agent 上線相對(duì)較晚（ 去年 10 月上線，近期才正式增加交流與露面 ），目前我們?nèi)蕴幱趯?duì)國內(nèi)用戶行為的分析與拆解階段。

在未來一兩周內(nèi)，隨著我們推出的 Expert 方向和新動(dòng)作，大家會(huì)看到更清晰的思路。同時(shí)，我們也正通過觀察目前逐漸沉淀下來的核心用戶，研究如何進(jìn)行轉(zhuǎn)化，并學(xué)習(xí)如何借由他們深入國內(nèi)特定場景，從而找到更適合國內(nèi)環(huán)境的用戶裂變點(diǎn)。

知危：目前用戶對(duì) Agent 的認(rèn)知似乎還處于早期階段？我們了解一些做 Agent SaaS 的企業(yè)，他們最大的痛點(diǎn)是由于企業(yè)或個(gè)人不確定 Agent 到底能做什么，導(dǎo)致需求與技術(shù)無法完全匹配，使得 SaaS 公司不得不像咨詢公司一樣去介入。相比之下，MiniMax 作為一個(gè)通用平臺(tái)，可能很難像垂直 SaaS 那樣提供類咨詢的服務(wù)，大部分場景需要靠用戶自己挖掘，您是如何看待這個(gè)問題的？

尋鷺：如果是針對(duì) C 端用戶，我們會(huì)想方設(shè)法盡可能縮短用戶從進(jìn)入到使用的路徑。目前 Agent 頁面缺乏問答指引和示例 Query，用戶看到簡單的文字介紹或?yàn)g覽量，并不清楚實(shí)際產(chǎn)物效果。

所以下周我們會(huì)做的一件事，就是通過增加示例 Query 和展示過往優(yōu)秀產(chǎn)物，讓用戶對(duì)專家的能力有明確預(yù)期，知道類似的輸入能得到什么樣的結(jié)果。我們更傾向于站在 C 端產(chǎn)品的視角，通過優(yōu)化交互和用戶友好型的迭代，而不是靠一對(duì)一咨詢的形式，來縮短用戶與 AI 能力之間的距離。

知危：目前業(yè)內(nèi)普遍認(rèn)為 Agent 的切入點(diǎn)應(yīng)先聚焦于企業(yè)垂直領(lǐng)域，其核心競爭力體現(xiàn)在兩個(gè)維度：一是 SaaS 廠商的先發(fā)優(yōu)勢，通過多年積淀的固化流程實(shí)現(xiàn)對(duì)業(yè)務(wù)場景的深度覆蓋；二是垂直 AI 公司的專業(yè)深度，通過深耕金融、法律、醫(yī)療等高門檻行業(yè)建立技術(shù)護(hù)城河。MiniMax 作為底層大模型廠商如何在保持通用能力的同時(shí)，和在 “ 流程閉環(huán) ” 與 “ 行業(yè)深度 ” 有優(yōu)勢的競爭對(duì)手競爭？

阿島：這里的核心在于我們對(duì)未來的判斷：未來人類的組織和基礎(chǔ)設(shè)施是會(huì)圍繞 AI 與 Agent 重新構(gòu)建以達(dá)到 AGI，還是由 AI 和 Agent 去迎合現(xiàn)有的組織與基礎(chǔ)設(shè)施？這是一個(gè)核心的判斷。在此前提下，我們要明確的是，想追求真正的 AGI，做一個(gè)具備強(qiáng)大智能且能廣泛滿足用戶深度需求的產(chǎn)品，還是想做一個(gè)收入和盈利都還不錯(cuò)、甚至僅僅是一塊生意層面的業(yè)務(wù)？

最近我也面試過一些候選人，其中一位從 2023 年 GPT-3.5 階段就開始做 Automation 和 Workflow，在當(dāng)時(shí)算非常領(lǐng)先。但迫于生存壓力，他們本想做通用的產(chǎn)品，最后只能轉(zhuǎn)而成為垂直領(lǐng)域的信息爬取專家，比如做銷售線索或簡歷篩選。最終他們搭建了一套深入行業(yè)的 Workflow，盈利表現(xiàn)不錯(cuò)，但規(guī)模也因此受限。如果他想切入另一個(gè)行業(yè)，就必須按照這個(gè)模式重新再做一遍。

所以，我們對(duì)未來的判斷很明確：我們要選前者，而不是做后者。

我們公司不依賴那種規(guī)模受限的垂直生意，這是前置判斷。其次，我們也不是要做一個(gè)無人問津的 “ 陽春白雪 ”，像尋鷺剛才提到的，我們認(rèn)為走前者的路徑，通過 Expert 模式、Agent 的自我進(jìn)化以及 Agent Infra 的演進(jìn)，能夠獲取足夠的 Context 和 Memory，最終在用戶領(lǐng)域做得越來越好。這不僅依賴于底層模型的進(jìn)步，更取決于多模態(tài)理解模型（ VLM ）的突破。雖然現(xiàn)在瀏覽器操作慢、效果不佳是因?yàn)?VLLM 仍落后于大語言模型，但我們看到 VLLM 也在快速進(jìn)步。歸根結(jié)底，這在于是否相信 Scaling Law 和摩爾定律，如果相信，我們堅(jiān)定選擇前者。

尋鷺：企業(yè)內(nèi)部許多固化的合規(guī)或處理流程，往往并不適合直接用 “ 自主決策 ” 的 Agent 完全替代。目前很多企業(yè)的做法是將流程中的某個(gè)節(jié)點(diǎn)（ 如合規(guī)檢查 ）替換為大模型節(jié)點(diǎn)，這更像是一種規(guī)則自動(dòng)化，而非真正的 Agent。

如果跳出產(chǎn)品本身，從 AI 工具化的未來方向來看，企業(yè)自建 Agent 的現(xiàn)象確實(shí)會(huì)長期存在。任何具備資源和技術(shù)信念的企業(yè)，在意識(shí)到 Agent 能顯著提效時(shí)，第一反應(yīng)往往是觀察外部方案，隨后拉起內(nèi)部團(tuán)隊(duì)自研。這是一種正常的商業(yè)決策，尤其在涉及核心業(yè)務(wù)邏輯時(shí)。

如果是為了快速獲得 PMF（ 產(chǎn)品與市場契合，產(chǎn)品馬上就能出售獲利 ），切入金融、醫(yī)療等垂直場景確實(shí)更高效。他們往往通過大量的模板、路由工程和固定的 Workflow 來保證穩(wěn)定性，這在底層邏輯上可能并不是一個(gè)開放的 Agent 框架，而是一個(gè)深度的行業(yè)工具。

針對(duì)垂直與通用的爭議，我們堅(jiān)持深耕通用框架。我們的核心目標(biāo)不是停留在表面的“萬能”，而是通過構(gòu)建一個(gè)更高階、更穩(wěn)健的底層框架，能夠容納并理解用戶長期積累的復(fù)雜數(shù)據(jù)，而不僅僅是單次任務(wù)的片段信息，并且能夠無縫深入到各種本地、云端甚至復(fù)雜的企業(yè)生產(chǎn)環(huán)境。

知危：MiniMax團(tuán)隊(duì)在研發(fā)Agent實(shí)習(xí)生的過程，其實(shí)是一個(gè)不錯(cuò)的企業(yè)該如何走向Agent模式的樣本，但是似乎很少有企業(yè)能做到這么順暢？

阿島：傳統(tǒng)企業(yè)轉(zhuǎn)向 Agent 模式的最大障礙并非技術(shù)本身，而是人的思維與組織方式的重塑。這種轉(zhuǎn)變是一個(gè)動(dòng)態(tài)進(jìn)化的過程，正如 Minimax 團(tuán)隊(duì)自身在過去一年也經(jīng)歷了從不適應(yīng)到 “ 離不開 ” 的認(rèn)知升級(jí)。

這種進(jìn)化的成功取決于兩個(gè)核心維度的交匯：一是人的接受度，即個(gè)體對(duì) AI 等新事物的開放心態(tài)與駕馭能力；二是技術(shù)的成熟度，即模型與 Agent 性能的實(shí)質(zhì)性飛躍。

即使在 MiniMax 這樣的技術(shù)驅(qū)動(dòng)組織中，資深工程師初期也會(huì)因?yàn)楣逃械慕?jīng)驗(yàn)路徑而對(duì) Cursor 等 AI 工具產(chǎn)生抵觸與不信任。

因此，通用平臺(tái)的發(fā)展不能只停留在淺層功能，而應(yīng)支持用戶在認(rèn)知轉(zhuǎn)變后實(shí)現(xiàn)深度的協(xié)作進(jìn)化。我們內(nèi)部推行 “ AI First ” 和 “ Agent 友好 ” 的原則，要求無論是研發(fā)、財(cái)務(wù)還是產(chǎn)品，都要主動(dòng)將 Context 和知識(shí)體系結(jié)構(gòu)化，確保 Agent 能夠無縫獲取信息并發(fā)揮巨大的效率杠桿作用。這種 “ AI 原生 ” 的工作習(xí)慣，讓環(huán)境變得易于被 Agent 理解和調(diào)用，才是釋放 AI 潛力的關(guān)鍵前提。

我們會(huì)打造這樣一套產(chǎn)品和框架，去幫用戶往這個(gè)方向?qū)崿F(xiàn)，但前提是用戶得有這個(gè)思維，得愿意這么做。這就像 Everett Rogers 提出的創(chuàng)新擴(kuò)散理論里說的，從 Innovator（ 創(chuàng)新者 ）到 Early Adopter（ 早期采用者 ）有一個(gè)過程。

我們覺得現(xiàn)在還處于早期，大家的 Mindset（ 思維 ） 在進(jìn)步，能力也在進(jìn)步。它一定會(huì)有個(gè)臨界點(diǎn)，就是當(dāng)能力進(jìn)步到所有人無法忽視的時(shí)候。

拿我們團(tuán)隊(duì)舉例，現(xiàn)在我根本不需要去建議任何一個(gè)同學(xué)用 Claude Code，大家已經(jīng)深刻體會(huì)到它的威力了。但在最開始那個(gè)時(shí)間點(diǎn)，我得告訴大家，而且得把這件事弄得足夠簡單。

所以我覺得整個(gè)演化邏輯是：最前面是技術(shù)進(jìn)步，帶動(dòng)一部分領(lǐng)先者的 Mindset （ 思維 ）改變，當(dāng)這部分人拿到實(shí)實(shí)在在的收益被其他人看到后，接下來的 Infra 和所有人的組織方式才會(huì)圍繞它發(fā)生變化。我們的產(chǎn)品就是要在這種演化過程中，跟隨并推動(dòng)這種成長。

知危：會(huì)比較好奇，在 MiniMax，尤其是 Agent 產(chǎn)品的開發(fā)中，產(chǎn)品端和研發(fā)端是怎么合作的？

尋鷺：團(tuán)隊(duì)間的合作機(jī)制，主要分為兩個(gè)層面。在產(chǎn)品與開發(fā)的合作中，Agent 團(tuán)隊(duì)內(nèi)部的職責(zé)邊界正在逐漸模糊。不同于傳統(tǒng)互聯(lián)網(wǎng)大廠由產(chǎn)品給出靜態(tài) PRD 后交付給固定開發(fā)團(tuán)隊(duì)進(jìn)行交付、測試、上線的模式，目前的合作流程極大縮短了前置距離。產(chǎn)品人員也會(huì)直接參與 “ 搓 ” Expert、優(yōu)化框架或產(chǎn)出 Vibe Coding Demo 等工作，這種協(xié)作方式更加靈活且緊湊。

以表單應(yīng)用為例，很多時(shí)候是產(chǎn)品直接通過 Vibe 快速搭建出雛形，再由設(shè)計(jì)師接入調(diào)整樣式，隨后便直接上線。大家在 Agent 首頁看到的許多表單應(yīng)用、運(yùn)營位應(yīng)用以及 PGC Expert，其實(shí)并非出自開發(fā)之手，而是產(chǎn)品利用Cursor和高效協(xié)同模式快速實(shí)現(xiàn)的。而且有想法的開發(fā)人員也會(huì)針對(duì)特定場景提出很有價(jià)值的應(yīng)用方案。所以至少在我們的團(tuán)隊(duì)里面，這個(gè)合作的模式正在消解傳統(tǒng)的權(quán)責(zé)邊界。

在分工上，大家依然保留著傳統(tǒng)職能，比如產(chǎn)品經(jīng)理仍會(huì)承擔(dān)大量的競品調(diào)研、用戶研究以及 Query 分析等基礎(chǔ)工作。但在處理具體的某個(gè)產(chǎn)品化 Feature，或是面對(duì)一些比較緊急的需求時(shí)，分工形式就與傳統(tǒng)的互聯(lián)網(wǎng)大廠不太一樣。

阿島：這種合作模式像是一種“分布式”的協(xié)作，雖然每個(gè)人在研發(fā)或產(chǎn)品等專業(yè)領(lǐng)域各司其職，但創(chuàng)意的邊界是模糊的。關(guān)于產(chǎn)品方向和用戶價(jià)值的 idea，大家都可以隨時(shí)拋出來。比如在推出 Experts 框架時(shí)，研發(fā)端和產(chǎn)品段都感受到原先 Pro 框架的限制而想到了 Expert 這個(gè) idea，技術(shù)端看到的是技術(shù)框架上的變化，而產(chǎn)品同學(xué)則能敏銳地將其轉(zhuǎn)化為真正對(duì)用戶有價(jià)值的落地方法。在具體執(zhí)行上，研發(fā)會(huì)同步進(jìn)行類似 “ 內(nèi)部實(shí)習(xí)生 ” 的功能嘗試，而產(chǎn)品和設(shè)計(jì)同學(xué)則可能直接通過 Vibe coding 跑通前端，再由研發(fā)承接后續(xù)深度開發(fā)。

這種協(xié)作的結(jié)果是大家打破了原有領(lǐng)域的思維定式。因?yàn)?Agent 類產(chǎn)品具有 “ 技術(shù)與產(chǎn)品高度合一 ” 的特性，研發(fā)不能只鉆研技術(shù)，產(chǎn)品也不能只考慮功能，雙方都會(huì)有端到端的視野和雙邊思維。但是也都有各自擅長的地方，畢竟每個(gè)人的精力和擅長領(lǐng)域終究有限。

知危：那么 Agent 團(tuán)隊(duì)和模型團(tuán)隊(duì)的協(xié)作關(guān)系是怎樣的？

阿島：研發(fā)端與模型團(tuán)隊(duì)的合作，更多是提供應(yīng)用層視角的認(rèn)知與輸入。目前模型面臨的核心問題是評(píng)估與任務(wù)設(shè)定，而學(xué)術(shù)界的評(píng)估指標(biāo)（ 如 SWE-bench ）并不能完全代表現(xiàn)實(shí)生活中的任務(wù)。例如上半年大家都在看 SWE-bench，但現(xiàn)在它已經(jīng)趨于飽和，且更多代表的是 Bug fix 的能力，也就是從 80 分到 90 分的過程，而無法代表 Vibe Coding 這種從 0 到 1 構(gòu)建項(xiàng)目、甚至增加 Feature 的能力，增加 Feature 更多代表從 10 分到 80 分的過程，難度顯然大很多。

因此，Agent 團(tuán)隊(duì)會(huì)面向真實(shí)的內(nèi)部用戶場景去構(gòu)建自己的 Benchmark。比如我們構(gòu)建的 Benchmark 往往針對(duì)當(dāng)前市面上所有 Agent 都做不好的挑戰(zhàn)性任務(wù)（ 得分可能僅在三四十分左右 ）。這些任務(wù)并非憑空想象，而是從用戶的真實(shí)痛點(diǎn)中發(fā)掘出來的。所以我們構(gòu)建的 Benchmark 更能代表真實(shí)世界的分布，從而指引其轉(zhuǎn)化為適合模型訓(xùn)練的標(biāo)準(zhǔn)。

以我們最近開源的 VIBE Benchmark 為例，它專門用于評(píng)估模型在全棧開發(fā)（ 包括 Web、移動(dòng)端、桌面端 ）上的表現(xiàn)。這一成果結(jié)合了產(chǎn)品視角的輸入與研發(fā)團(tuán)隊(duì)的專業(yè)深度，因?yàn)檠邪l(fā)團(tuán)隊(duì)最懂服務(wù)端和 WEB/APP 開發(fā)的本質(zhì)。

在 Vibe coding 開發(fā)能力的定義上，我們和模型團(tuán)隊(duì)共同確立了“全棧開發(fā)”的目標(biāo)。這體現(xiàn)了雙方的核心關(guān)系：模型任務(wù)與能力的定義必須具備用戶視角，才能產(chǎn)生真正的生產(chǎn)價(jià)值；而模型能力的提升又直接支持了 Agent 的需求，使其做得更好。

知危：桌面 Agent 是比較新穎的產(chǎn)品形態(tài)，又涉及用戶的私人數(shù)據(jù)輸入，用戶難免會(huì)有存儲(chǔ)安全和隱私安全方面的擔(dān)憂，MiniMax 如何解決這些安全隱患？

尋鷺：MiniMax Agent 的運(yùn)行時(shí)（ Agent Loop ）以及與大模型的交互是在云端進(jìn)行的，但它的所有工具環(huán)境包括命令行執(zhí)行、本地文件讀取、文件操作以及瀏覽器操作全都在用戶的本地完成。

這也是為什么桌面端和網(wǎng)頁端的記錄沒有同步，因?yàn)?strong>兩者的工具和文件工作區(qū)是完全隔離的，這主要是出于安全和隱私的考慮。

針對(duì)本地執(zhí)行命令行可能帶來的安全挑戰(zhàn)，我們主要通過產(chǎn)品設(shè)計(jì)和權(quán)限邊界控制來應(yīng)對(duì)。這并非新鮮課題，像 Cursor 等成熟 IDE 已有完備的機(jī)制。我們的設(shè)計(jì)參考了行業(yè)標(biāo)準(zhǔn)，尤其在處理權(quán)限申請(qǐng)時(shí)，會(huì)明確詢問用戶是 “ 僅限本次允許 ” 還是 “ 始終允許 ”。當(dāng) Agent 涉及操作未授權(quán)的文件夾、進(jìn)入新的工作區(qū)，或執(zhí)行之前未允許過的命令時(shí)，都會(huì)觸發(fā)彈窗讓用戶進(jìn)行 Double Check。目前我們擁有一個(gè)固定的高風(fēng)險(xiǎn)命令列表，并結(jié)合模型進(jìn)行判斷，未來還會(huì)根據(jù)用戶反饋持續(xù)補(bǔ)充這一列表，進(jìn)一步加強(qiáng)在安全和權(quán)限邊界上的交互，確保 Agent 的行為在用戶知情且可控的范圍內(nèi)。

阿島：從技術(shù)層面看，我們對(duì)命令安全性的控制主要關(guān)注其是否具有破壞性或不可逆性。首先通過基于規(guī)則的第一層過濾，確保高召回率以兜底風(fēng)險(xiǎn)，但可能覆蓋不全、沒那么靈活或有一定的誤傷概率；其次通過大模型智能判斷進(jìn)行第二層識(shí)別以提高準(zhǔn)確率。

技術(shù)上最核心的保護(hù)對(duì)象是數(shù)據(jù)。相比于容易通過程序命令備份和恢復(fù)的開發(fā)環(huán)境，數(shù)據(jù)的損失往往是不可逆的。因此，我們讓大模型進(jìn)行智能判斷：首先，優(yōu)先尋找可逆的操作方案來替代不可逆操作，比如用“移動(dòng)到回收站”代替“直接刪除”；其次，如果操作確實(shí)不可逆且無法替代，則判斷是否可以先備份再執(zhí)行。在完成這些前置邏輯后，模型會(huì)判斷是否需要提示用戶確認(rèn)，并同步給出命令的解釋以及存在的風(fēng)險(xiǎn)說明。

目前，“ 移動(dòng)到回收站 ” 功能已在最新版本支持，服務(wù)端也已下發(fā)風(fēng)險(xiǎn)提示邏輯，前端 UI 正在緊鑼密鼓地適配中。

知危：只是普通用戶，即便對(duì)于專家級(jí)用戶，在 Agent 2.0 中構(gòu)建 “ 專家 ” 可能也不是容易的事情，或者會(huì)很繁瑣，確實(shí)有門檻，MiniMax 如何讓用戶更輕松地構(gòu)建“專家”？

尋鷺：針對(duì)如何幫助用戶基于長期積累的 Context 生成專家，我們目前主要提供兩種路徑，重點(diǎn)解決配置門檻問題。

首先是 AI Creator，對(duì)于不熟悉 Sub-agent、Instruction、Skills 或 MCP 配置的普通用戶，我們提供了一個(gè) AI 驅(qū)動(dòng)的創(chuàng)建工具。用戶只需提供非結(jié)構(gòu)化的知識(shí)（ 如一段 SEO 專家的文本資料 ），AI 就能自動(dòng)解析并完成復(fù)雜的后端配置。以 SEO 專家為例，AI Creator 可以自動(dòng)將任務(wù)拆解并配置成三個(gè)協(xié)同工作的 Sub-agent，同時(shí)自動(dòng)配齊對(duì)應(yīng)的 Skill 和調(diào)度指令，明確它們之間如何協(xié)作。這種方式的優(yōu)勢在于，它能迅速將用戶的專業(yè)經(jīng)驗(yàn)轉(zhuǎn)化為可執(zhí)行的 Agent 架構(gòu)，而不需要用戶具備任何技術(shù)背景。

AI Creator 的核心價(jià)值在于將復(fù)雜的 SOP 自動(dòng)轉(zhuǎn)化為最優(yōu)架構(gòu)。用戶只需將已有的知識(shí)庫或 SOP 發(fā)給 AI，它就能在我們這套功能強(qiáng)大但配置相對(duì)復(fù)雜的專家框架中，自動(dòng)匹配出最優(yōu)的 Sub-agent 組合、Skill 定義和指令集。用戶無需手動(dòng)編輯繁瑣的文檔或參數(shù)。

如果發(fā)現(xiàn)專家執(zhí)行效果不佳，只需像聊天一樣告訴 AI：“ 它在某處處理得不好，幫我修改一下提取邏輯或解決方案?！?/p>

我們在制作 PGC 專家時(shí)也發(fā)現(xiàn)，最有效的調(diào)優(yōu)方式并非手動(dòng)改代碼，而是通過對(duì)話引導(dǎo) AI 迭代。因此，我們將這套內(nèi)部實(shí)戰(zhàn)經(jīng)驗(yàn)沉淀到了 AI Creator 框架中，讓普通用戶也能以自然語言交互的方式，打磨出生產(chǎn)級(jí)別的專家。

除了 AI Creator，我們還提供了手動(dòng)配置模式。這種模式特別適合有經(jīng)驗(yàn)的 “ 深度玩家 ” 或已有積累的用戶。如果用戶此前在 Claude code 或其他 Agent 平臺(tái)上已有成熟的 Prompt、Sub-agent 設(shè)定或 Skill（ 技能 ），可以直接 “ 丟 ” 進(jìn)我們的框架中進(jìn)行復(fù)用，實(shí)現(xiàn)無縫搬遷。

無論是 AI 自動(dòng)生成的還是手動(dòng)搬遷的專家，調(diào)優(yōu)過程都極其簡便。用戶只需通過自然語言反饋，AI 就會(huì)輔助用戶完成指令和邏輯的迭代優(yōu)化。

知危：接入本地計(jì)算機(jī) Context，會(huì)帶來推理成本暴增嗎？

尋鷺：確實(shí)，大家可能會(huì)擔(dān)心 Agent 場景因?yàn)榻尤肓擞脩魝€(gè)人電腦的數(shù)據(jù)，輸入量變大，成本會(huì)比以前的產(chǎn)品高很多。

但其實(shí)測試下來還算好。就像有用戶問理解圖片和視頻會(huì)不會(huì)很費(fèi)積分，其實(shí)這種理解類任務(wù)反而不太會(huì)，因?yàn)檫@類工具的消耗是比較容易控制的。

當(dāng)然，如果是生成類任務(wù)，確實(shí)是另外一個(gè)量級(jí)，也跟任務(wù)復(fù)雜度直接掛鉤。

阿島：本地環(huán)境的 Context 并不會(huì)導(dǎo)致上下文暴增。雖然用戶本地可能有很多數(shù)據(jù)，比如一個(gè)一萬字的文檔，但我們的 Agent 并不是簡單地一次性讀入這整整一萬字。它會(huì)根據(jù)用戶的具體意圖，更多地通過檢索的形式去獲取最相關(guān)的段落。所以，在本地處理數(shù)據(jù)，本質(zhì)上并不會(huì)比其他場景產(chǎn)生更大的消耗差異或負(fù)面影響。

知危：說實(shí)話，用戶真的不好判斷積分（ 使用 2.0 會(huì)有積分的消耗 ）的消耗情況，這不是單純以 token 多少付費(fèi)。

尋鷺：官方這邊也一直在持續(xù)優(yōu)化消耗速率，目標(biāo)是讓用戶的任務(wù)能在一個(gè) ROI 比較高的區(qū)間內(nèi)完成。比如下周我們要發(fā)布的一個(gè)功能就是做模式的 Routing。因?yàn)楹芏鄷r(shí)候任務(wù)復(fù)雜度不高，Agent 完全可以自動(dòng)調(diào)用“高效模式”快速搞定，不一定非要調(diào)用昂貴的 Pro 模式。

除此之外，我們一直在優(yōu)化積分消耗。比如之前為保證最終效果，一些環(huán)節(jié)會(huì)讓 Agent 做大量的自動(dòng)化測評(píng)，后來我們增加了 “ 用戶確認(rèn)項(xiàng) ”，用戶可以選擇是完全交給 Agent 去跑測試，還是由自己來做測試并把觀察到的點(diǎn)反饋給 Agent，從而更高效、更省積分地完成修改。

雖然積分消耗邏輯目前還比較初級(jí)，但我們會(huì)持續(xù)增加它的透明度和用戶友好度。比如最近收到不少關(guān)于整理文件夾等場景的反饋，我們會(huì)不斷優(yōu)化這些具體場景的消耗速率。其實(shí)這跟我們內(nèi)部做 Agent Benchmark 的邏輯是一致的：我們不會(huì)為了追求一個(gè)極致的結(jié)果而不計(jì)成本。在我們評(píng)估一套新框架時(shí)，除了看任務(wù)得分，也會(huì)嚴(yán)格考察任務(wù)時(shí)長和 Token 消耗：如果得分很高但 Token 消耗增加了 5 倍，那我們并不認(rèn)為這是一個(gè)好的方案。

知危：您多次強(qiáng)調(diào) Agent Infra 的重要性以及對(duì)當(dāng)前 Agent 發(fā)展的限制，行業(yè)當(dāng)前現(xiàn)狀到底是怎么樣的，距離理想狀態(tài)還有多遠(yuǎn)？

阿島：Agent Infra 目前確實(shí)還處于非常早期的狀態(tài)。首先從協(xié)議標(biāo)準(zhǔn)和交互方式的角度，在我看來，MCP 也不是一個(gè)特別完備的定義，其實(shí)并不特別適合 Agent，我相信還會(huì)有新的標(biāo)準(zhǔn)出現(xiàn)，大家也在不斷嘗試。另外一個(gè)角度是大家要提供面向 Agent 的能力，這種能力可以是 MCP，也可以是一個(gè)更完備的定義，比如帶有腳本和 API 的 Skill，核心是這些能力要能提供出來。

就像淘寶在電商時(shí)代通過支付寶這個(gè)創(chuàng)舉，利用第三方托管解決了支付這一核心 Infra，電商的另一個(gè)核心 Infra 是履約，比如快遞和電子面單，Agent 領(lǐng)域也需要類似的底層支撐。

所以，理想的 Agent Infra 應(yīng)該是：首先是身份認(rèn)證，要能像擔(dān)保支付一樣，確認(rèn) Agent 是安全且代表用戶本人的。第二個(gè)是像電商履約鏈路一樣，連接各種服務(wù)和 SaaS。這包括企業(yè)內(nèi)部 SaaS 和用戶常用的外部軟件，比如 Notion、外賣、醫(yī)療、線上辦公相關(guān)的文檔、IM、郵件、日歷，甚至財(cái)務(wù)系統(tǒng)和支付。

在有身份認(rèn)證的前提下，信息提供方式也會(huì)改變。現(xiàn)在的網(wǎng)頁是提供給人看的 HTML，未來也許會(huì)有專門提供給 Agent 的格式；或者隨著 VLM 的進(jìn)步，HTML 依然存在，但會(huì)從面向 SEO 優(yōu)化轉(zhuǎn)向面向 Agent 優(yōu)化。比如為了讓 Agent 快速導(dǎo)航，HTML 的標(biāo)簽需要變得更具語義化。

總結(jié)一句話，就是所有的基礎(chǔ)設(shè)施、軟件服務(wù)和人們的 Mindset，都將面向 AI 和 Agent 來重新定義和提供。我堅(jiān)信這件事情一定會(huì)發(fā)生。

知危：專家的提示詞設(shè)計(jì)有兩點(diǎn)值得注意，一個(gè)是專家下還會(huì)設(shè)置 Sub-agent，這種雙層結(jié)構(gòu)的好處是什么？

阿島：這種 Sub-agent 結(jié)構(gòu)和單一 Agent（ Single Agent ）或 Skills 的模式相比，核心好處在于：子 Agent 更適合處理那些領(lǐng)域性強(qiáng)、非常具體的任務(wù)。子 Agent 可以被看作是一個(gè)專注特定領(lǐng)域的 “ 小專家 ”，它能夠配備專屬于這一塊任務(wù)的工具和 Skills。Skills 并不是只能掛在最上面那一層，子 Agent 同樣可以擁有自己的 Skills。

以制作視頻為例，如果用一個(gè) Single Agent 掛載所有 Skills 來做，效果會(huì)很差：首先它的上下文會(huì) “ 爆炸 ”，其次滿載了各種雜亂信息的上下文會(huì)分散它的注意力，工具集也會(huì)變得非常臃腫，很難把活兒干細(xì)。采用 Sub-agent 結(jié)構(gòu)的好處就在于 “ 專注與共享 ”，比如你可以把導(dǎo)演、腳本分鏡、素材生成、后期剪輯分別交給不同的子 Agent。雖然它們各司其職，但因?yàn)楣蚕硗粋€(gè)工作區(qū)，并且都能調(diào)用 Memory 工具，所以它們能擁有同樣的上下文記憶。這種模式既保證了信息的同步，又讓每個(gè)子 Agent 能夠?qū)Ｗ⒂谧约旱膶I(yè)環(huán)節(jié)，把事情做得更深、更好。

此外，因?yàn)槊總€(gè) Sub-agent 擁有獨(dú)立的 Context Window，不容易觸發(fā)上下文壓縮總結(jié)。大家應(yīng)該都知道，一旦觸發(fā)壓縮，模型就非常容易 “ 降智 ”。其次是Sub-agent 具備不可替代的 “ 并發(fā)能力 ”。比如你需要同時(shí)創(chuàng)作 3 個(gè)分鏡，或者同時(shí)調(diào)研 10 家上市公司。如果你只用一個(gè) Single Agent 配一堆 Skills，它只能像排隊(duì)一樣一家一家做過去，既慢又做不深。

所以這兩點(diǎn)最關(guān)鍵：一是專注，通過上下文隔離讓任務(wù)做得更深、更好；二是能更好地處理并發(fā)。

那么 Skills 適合什么場景呢？Skills 適合那種不需要做得特別深、一個(gè)任務(wù)就解決一件具體事情的場景。比如說，幫我處理一個(gè) Excel，具體用什么 Python 函數(shù)，或者需要什么樣的 Excel 風(fēng)格。所以 Skills 這種形式，它更像是一個(gè)知識(shí)庫動(dòng)態(tài)加載的 System Prompt。

當(dāng)一個(gè) Agent 在處理一件事（ 比如文檔處理 ）時(shí)，它可能會(huì)面臨不同的情況，一會(huì)兒是 Excel，一會(huì)兒又是 PDF 或 Word。這種時(shí)候你根據(jù)需要去動(dòng)態(tài)加載對(duì)應(yīng)的能力，一次只做一件事，就很合適用 Skills。

尋鷺：Agent 與 Sub-agent 之間并非只有單純的并行執(zhí)行，而是支持基于 SOP 的序貫協(xié)作。以深度調(diào)研（ Deep Research ）場景為例，系統(tǒng)會(huì)先啟動(dòng)調(diào)研 Agent 生成多份分散文檔，隨后由報(bào)告專家接手進(jìn)行整合并添加圖表，最后交給排版專家輸出精美的 PDF 或 Word 格式，形成一條完整的流水線。至于更高自主性的多智能體交流，也有一些例子，例如國外的 “ 德州撲克 ” 專家或國內(nèi)未來可能考慮上線的 “ 狼人殺 ”、“ 打麻將 ” 等應(yīng)用，通過在指令中設(shè)定游戲規(guī)則，多個(gè)智能體可以在規(guī)則框架下進(jìn)行互相交流、對(duì)抗或協(xié)作。用戶既可以作為旁觀者觀察這套 “ 賽博生態(tài) ”，也可以作為玩家參與其中。

知危：另一點(diǎn)是，提示詞 Token 數(shù)限制是 5 萬，但一般在此規(guī)模上下文下，模型表現(xiàn)會(huì)受限不是嗎？

阿島：對(duì)于設(shè)定 5 萬 token 的高上限，核心邏輯是不希望人為在框架層面限制用戶，盡管模型表現(xiàn)可能在這個(gè)量級(jí)可能受到影響。在產(chǎn)品設(shè)想中，用戶基本不會(huì)手寫如此冗長的提示詞，而更多是由 Agent 自動(dòng)生成并分配關(guān)于這部分內(nèi)容是初始加載，動(dòng)態(tài)加載 Skills，還是放入 Sub-agent 運(yùn)行。

尋鷺：設(shè)定一個(gè)非常大的上限，也是為了兼容復(fù)雜的業(yè)務(wù)場景。例如在需要同時(shí)調(diào)度 10 個(gè) Sub-agent 的情況下，Instruction 需要詳細(xì)規(guī)定各 Agent 的并行調(diào)用邏輯或執(zhí)行順序。以 PGC Expert 中的“熱點(diǎn)追蹤”為例，即便經(jīng)過壓縮，其指令量依然巨大，因?yàn)樗婕拔辶鶄€(gè) Sub-agent，執(zhí)行中間需要并行對(duì)挖掘出的熱點(diǎn)話題再做一輪深度研究。但在大多數(shù)情況下，如果通過 AI Create 的方式生成指令，token 數(shù)通常會(huì)自然維持在 5000 左右。

知危：目前Agent 2.0的PGC、PUGC專家中，復(fù)雜度比較高的專家實(shí)例是什么？

尋鷺：我們海外應(yīng)用端有一個(gè)炒股專家實(shí)例，融合了兩個(gè)熱門 GitHub 項(xiàng)目：Trading agents 與 AI hedge fund。首先是 Trading agents 負(fù)責(zé)的精細(xì)化調(diào)研階段，它會(huì)抓取海量價(jià)格數(shù)據(jù)、分析各項(xiàng)技術(shù)指標(biāo)并實(shí)時(shí)監(jiān)測市場輿情。緊接著進(jìn)入 AI hedge fund 模式，該流程內(nèi)嵌了 18 個(gè)風(fēng)格迥異的投資專家（ 如側(cè)重 PE 比率、不同風(fēng)險(xiǎn)偏好或長期持有邏輯等 ），隨后由 18 個(gè)專家組成 “ 議會(huì) ” 進(jìn)行內(nèi)部磋商并投票決策買入與退出時(shí)機(jī)；最后，由風(fēng)險(xiǎn)專家和管理專家把控全局，并輸出高質(zhì)量的結(jié)項(xiàng)匯報(bào)。

阿島：比如我們以 “ 英偉達(dá)能不能買 ” 等具體問題為切入點(diǎn)，通過詳細(xì)調(diào)研后，由類似設(shè)定好的 “ 巴菲特 ”、“ 芒格 ”、“ 彼得·林奇 ”、“ 木頭姐 ” 等 9 位大師組成模擬議會(huì)。每位大師根據(jù)各自的投資風(fēng)格（ 如價(jià)值投資、成長性分析或風(fēng)險(xiǎn)對(duì)沖 ）給出具體的買入/賣出建議、倉位配比以及格式化的邏輯分析。這種模式比盲目滿倉更理性，能有效通過多維度分析規(guī)避風(fēng)險(xiǎn)。實(shí)際測試中，大師們的集體判斷往往比個(gè)人主觀判斷更具參考價(jià)值，能夠

幫助理財(cái)小白避免掉坑。

知危：我們觀察桌面端可能還存在 Context 完整性的限制，比如有些企業(yè)的數(shù)據(jù)可能基本都在云辦公軟件中，MiniMax 打算如何克服這種限制？

尋鷺：其實(shí)在公司內(nèi)部，我們其實(shí)有一個(gè)在飛書里運(yùn)行的 Agent 實(shí)習(xí)生，只要飛書開放 API 就能較好地接入。

對(duì)于外部用戶，并非所有企業(yè)的數(shù)據(jù)都在即時(shí)通訊工具里，云端可能更多起備份作用。

桌面端是我們拓展 Context 和環(huán)境的第一步，將 Web 端需要手動(dòng)上傳的形式轉(zhuǎn)變?yōu)榭梢灾苯硬僮鞅镜匚募?，這對(duì)于很多小型機(jī)構(gòu)或個(gè)人來說已經(jīng)是非常大的進(jìn)步，因?yàn)樗麄兊馁Y料往往還是存在本地電腦里。

未來我們也希望能利用更多應(yīng)用和云盤里的上下文環(huán)境，這也是我們后續(xù)追求的目標(biāo)。

阿島：實(shí)際上，我們已經(jīng)有同事正在開發(fā)支持 OAuth 協(xié)議的功能，希望實(shí)現(xiàn)與其他 SaaS 軟件的便捷接入。只要這些 SaaS 軟件提供了相應(yīng)的接口，比如通過 MCP或 OAuth 協(xié)議，都可以進(jìn)行接入。但坦白說，目前像飛書等平臺(tái)的 MCP 支持還不是特別完善。

我們內(nèi)部目前是通過 API 封裝來實(shí)現(xiàn)深度接入的。針對(duì)企業(yè)級(jí)場景，我們考慮以 ToB 模式應(yīng)用，因?yàn)檫@需要企業(yè)管理員提供密鑰授權(quán)才能調(diào)用 API。對(duì)于像 Notion、Slack 這種 OAuth 或 MCP 授權(quán)已相對(duì)成熟的平臺(tái)，我們會(huì)盡快接入。我們的終極目標(biāo)是接入用戶所有的 Context。這正是我提到的 Agent Infra 的構(gòu)建過程：不僅是 Agent 應(yīng)用層的努力，更是整個(gè)行業(yè)甚至線下服務(wù)（ 如麥當(dāng)勞的點(diǎn)餐 MCP ）向 AI 進(jìn)化的過程。我們將盡可能全、盡可能快地接入這些能力。

尋鷺：獲取更多 Context 確實(shí)面臨巨大挑戰(zhàn)。目前我們討論的仍是具備 API 或能下載到本地操作的工具。但在大型企業(yè)中，數(shù)據(jù)倉庫分布在不同平臺(tái)，且出于隱私安全往往不對(duì)外開放。在這種情況下，很多在小環(huán)境跑得通的數(shù)據(jù)分析場景在大型組織里根本無法實(shí)現(xiàn)，因?yàn)闊o法打通各個(gè)孤立的平臺(tái)。

這需要所有組織達(dá)成共識(shí)，認(rèn)同 Agent 的價(jià)值，并齊心協(xié)力開放工具、API 和權(quán)限接口。因此，Context 的獲取分為兩步：第一步是努力接入已有的 API 或 MCP 開放應(yīng)用；而更難的第二步則是，當(dāng)常用的 SaaS 接入完成后，進(jìn)一步深入將不再僅僅是軟件或技術(shù)問題，而是涉及到組織架構(gòu)與企業(yè)管理的深層挑戰(zhàn)。

核心在于該公司的基礎(chǔ)設(shè)施（ Infra ）是否對(duì) Agent 友好，以及組織管理上是否樂于擁抱 “ 由 AI 替代人工節(jié)點(diǎn) ” 的形式。

以數(shù)據(jù)分析為例，在我們內(nèi)部，數(shù)倉平臺(tái)與飛書 OAuth 完全打通，權(quán)限體系和使用流程非常順暢，這使得從 Text-to-SQL 到自動(dòng)生成報(bào)告的閉環(huán)效率極高。這種順暢源于我們數(shù)據(jù)環(huán)境相對(duì)純粹，且組織邏輯上更傾向于用 AI 解決問題。

將這一套 Agent 經(jīng)驗(yàn)平移至大公司時(shí)，會(huì)面臨顯著的現(xiàn)實(shí)挑戰(zhàn)：首先是存量組織與流程的慣性，大公司往往已有成熟細(xì)致的人工團(tuán)隊(duì)和固定流程，在資源充足的情況下，替代動(dòng)力可能不如初創(chuàng)公司迫切；其次是系統(tǒng)碎片化與權(quán)限復(fù)雜度，大廠內(nèi)部不同部門、組織間的平臺(tái)與工具往往高度割裂，難以統(tǒng)一接入，導(dǎo)致開發(fā)適配 Agent 的基礎(chǔ)設(shè)施周期漫長，且權(quán)限控制極其復(fù)雜，極大增加了面向 “ Agent 友好 ” 工具轉(zhuǎn)換的難度。

還有一個(gè)現(xiàn)實(shí)痛點(diǎn)：ROI（ 投入產(chǎn)出比 ），在大公司維度下，當(dāng)人力資源相對(duì)充足時(shí)，管理層會(huì)權(quán)衡：投入大量研發(fā)資源去開發(fā)工具接口、梳理復(fù)雜的權(quán)限邊界以及界定責(zé)任歸屬，其最終帶來的效率提升是否值得？這種涉及權(quán)限體系重構(gòu)和責(zé)任控制的決策，往往很難在短期內(nèi)快速推進(jìn)。

知危：現(xiàn)在各家廠商都很卷，也有很多廠商先行做出了桌面端，那么MiniMax如何在當(dāng)前形勢下構(gòu)建自己的競爭壁壘？

尋鷺：在去年沒有那么多團(tuán)隊(duì)做 Agent 的時(shí)候，可能某些團(tuán)隊(duì)還能說自己有一些壁壘，但到了今年，坦白說沒有任何一個(gè)團(tuán)隊(duì)有壁壘。

即使去問大廠做 Agent 的團(tuán)隊(duì)，或者在 Demo Day 上問那些做 Agent 的團(tuán)隊(duì)，也沒有人能很好地回答這個(gè)問題。大家可能會(huì)說有某個(gè)行業(yè)的 know-how、能把垂直領(lǐng)域做深，或者有好的客戶關(guān)系能推到企業(yè)里，但這些其實(shí)都不構(gòu)成壁壘，大家一定會(huì)互相 overlap。所以從我們的角度來說，只能說我們想得更深，做得更新，并且把它落地得更快。

阿島：如果模型都沒有壁壘，怎么期盼一個(gè) Agent 有壁壘？

不管是 Anthropic、Gemini 還是 OpenAI，他們之間都沒有壁壘。Claude 3.0 做得很差，但 3.5 專注編程方向做出來了，到 4.0 的時(shí)候結(jié)合 Claude Code 更是驚艷；大家本也以為 Gemini 很差，結(jié)果 Gemini 3 也是專注 Vibe Coding 追了上來起來。目前 OpenAI 的領(lǐng)先優(yōu)勢正被不斷蠶食。未來如何發(fā)展誰也沒法預(yù)料。

本質(zhì)上，在一個(gè)技術(shù)的快速上升期，除非技術(shù)停滯，否則沒有任何人能夠擁有壁壘。唯一的壁壘就是你有沒有組織優(yōu)勢：有沒有相應(yīng)的人才能保持足夠強(qiáng)的認(rèn)知，有沒有相應(yīng)的底層 Infra，以及整個(gè)團(tuán)隊(duì)去執(zhí)行和實(shí)現(xiàn)它的技術(shù)能力。這其實(shí)就是 Anthropic 和 Gemini 能追上來的原因。比如 Gemini，最根本原因的是創(chuàng)始人直接下場寫代碼，如果沒有這一點(diǎn)，其他努力都是白費(fèi)心機(jī)。

知危：Agent 2.0 的下一步是什么？

尋鷺：我們會(huì)有多個(gè)主要努力的方向。第一個(gè)方向，是繼續(xù)完善桌面端設(shè)計(jì)、做 Experts，涉及 Knowledge 和 Memory 機(jī)制的構(gòu)建，也會(huì)涉及思考如何通過 Computer Use 接入更多應(yīng)用。

其中關(guān)于 Agent 的 “ 記憶 ” 功能，正處于規(guī)劃階段。展開做 Memory 其實(shí)有很多維度：是做長期的、全局的記憶，還是針對(duì)特定對(duì)話的、可快速清洗和編輯的短期記憶？是側(cè)重于用戶的人格畫像、專業(yè)領(lǐng)域畫像，還是基于用戶工作流中沉淀的 Knowledge、SOP 以及工具使用習(xí)慣？這背后涉及非常多樣的更新和清洗機(jī)制。目前我們還在內(nèi)部權(quán)衡各種做的方法和維度，等之后正式上線，我們會(huì)有一個(gè)更清晰的形式來向大家說明這套機(jī)制具體是如何 Work 的，以及它如何幫助大家更高效地使用 Agent 來解決問題。

第二個(gè)方向是主動(dòng)性，在我們內(nèi)部實(shí)踐中，Agent 任務(wù)的觸發(fā)可以通過 Trigger 的方式主動(dòng)運(yùn)行，但現(xiàn)在的產(chǎn)品還是需要你輸入一段東西，或者至少設(shè)一個(gè)定時(shí)任務(wù)它才能執(zhí)行，還沒有那么 Active，缺乏主動(dòng)性。所以后續(xù)我們也想在接入更多應(yīng)用后，能夠基于一些 Webhook 技術(shù)去觸發(fā) Agent 做更加主動(dòng)的行為，而不是讓它只是在界面上等待你給它輸入命令。

第三個(gè)方向是會(huì)讓它更易用。我們發(fā)現(xiàn)，這種復(fù)雜的 Agent 要在更多場景達(dá)到 production ready，對(duì)用戶的友好性非常重要。舉個(gè)例子，之前用戶不一定能準(zhǔn)確描述需求，或者只有一個(gè)模糊的想法，我們會(huì)有一個(gè) clarification 的環(huán)節(jié)向他澄清意圖。以前這個(gè)環(huán)節(jié)只是拋出一個(gè) Markdown 渲染的大長段文字，正常用戶看到要回答七個(gè)問題，很難手打大段文字說明需求。但今天我們做了 Generative UI，并設(shè)計(jì)了一些規(guī)范，讓 Agent 在這種情況下出的是表單形式。原來的五六個(gè)問題變成了三步表單，你只需要點(diǎn)選，它就能根據(jù)指令做下一步任務(wù)，不需要再用文字回答。通過這種友好的交互，讓用戶提供更多需求并澄清意圖，能讓我們最后出來的結(jié)果更貼合用戶的需要。

最后是提供更多的 PGC 和 PUGC 的 Expert，我們也會(huì)進(jìn)一步鼓勵(lì) UGC 的生態(tài)。我們終歸希望用戶來用的時(shí)候，不是面對(duì)一個(gè)好像能解決所有問題的通用 Agent，而是帶著自己明確要解決的問題。

阿島：長期來看，我們未來的目標(biāo)是做一個(gè)像個(gè)人助理一樣的產(chǎn)品，能在生產(chǎn)力場景的 Context 和 Workflow 里為用戶交付真正有價(jià)值的結(jié)果，讓用戶感覺真的多了幾個(gè)助理和實(shí)習(xí)生，自己不用再去干那些瑣碎重復(fù)的事情，可以專注于更有創(chuàng)意和創(chuàng)造力的事情。我們相信這最終能為用戶極大提效，讓用戶離不開它，我們也得到相應(yīng)的回報(bào)。

在具體技術(shù)趨勢上，無論是做 Desktop 還是接入各種 OAuth，我們都希望獲得更多 Context 并構(gòu)建 Memory，讓用戶越用越順手，甚至包括自動(dòng)提示用戶去生成專家，這源于 Agent 能夠自進(jìn)化。

確實(shí)，Agent 的下一個(gè)重要方向?qū)⑹亲耘e（ Self-bootstrapping ）與自我進(jìn)化。即 Agent 不僅能為用戶創(chuàng)造專家，還能根據(jù)反饋?zhàn)晕腋倪M(jìn)。

我們希望達(dá)到的下一步目標(biāo)是：Agent 能夠主動(dòng)觀察用戶的滿意度，并在發(fā)現(xiàn)表現(xiàn)不佳時(shí)，主動(dòng)提議具體的修改點(diǎn)。這代表著 Agent 不再是一個(gè) “ 死 ” 的配置，而是一個(gè)能與用戶不斷互動(dòng)、在工作流中實(shí)時(shí)進(jìn)化的實(shí)體。以代碼編寫為例，它能自動(dòng)糾正那些繁瑣的格式錯(cuò)誤，而不需要人類反復(fù)叮囑。

目前，我們公司內(nèi)部處理用戶反饋和問題的流程已經(jīng)由 Agent 自己完成并給出建議。所以，我們正在推進(jìn)的下一步，就是讓 Agent 根據(jù)這些反饋?zhàn)詣?dòng)優(yōu)化自身。

雖然行業(yè)內(nèi)目前僅有一部分人意識(shí)到這一點(diǎn)，但這將是 Agent 真正深度融入人類生產(chǎn)力的關(guān)鍵。

（ 訪談全文完 ）