對話MiniMax Agent團隊：“沒有Agent企業敢說自己有壁壘”

過去一年，AI 開始逐漸從 “ 對話 ” 向 “ 行動 ” 演進，技術走得很快，能夠直接操作電腦，處理復雜任務的 “ 桌面智能體 ” 正成為新的技術前沿和競爭焦點。

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

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

知危與 MiniMax Agent 2.0 團隊核心成員，研發負責人阿島、產品負責人尋鷺進行了一場對話，他們從產品、技術、組織和行業等層面，詳細地解答了我們的疑問，并且坦率地承認，“ 現在，沒有一家 Agent 企業敢說自己有壁壘。”

如果你是非 AI 從業者，這場對話會讓你觸碰未來，如果你是 AI 領域從業者，那這場對話一定是你不容錯過的前沿思考。

以下是對話原文，知危進行了不改變原意的編輯。

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

阿島：我們選擇在此時上線并不是受同行發布的節奏影響，因為不可能在一周內趕出這種產品。

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

我們在大模型創業公司中算比較精干的， Minimax 的模型和產品線布局最廣，涵蓋三個模態及對應產品。盡管公司有 不到 400 人，但具體到每個產品上，我們可能都是以一對十（ 同行 ）的比例在作戰。

比如這次的桌面端，實際上是 3 個同學用一個月的時間就開發出來的。整個 Agent 團隊的研發力量非常精干，如果加上產品經理，總共也就 4 個人左右。

Agent 實習生目前已經在公司內部普及和擴散，成了大部分同事離不開的工具。

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

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

2.0 版本涉及更多的環境，從之前的網頁端擴展到桌面端，可以利用本地工作區和更多文件來干活。

然后是質量上的提升，通過專家系統，無論是官方還是 UGC 做的，都能將專業知識和流程打包成專家 Agent，去高質量完成原本需要領域專家支持的任務。

知危：能不能更細致地解釋 Agent 2.0 的產品結構？對于大多數人來說，還是相對陌生。

阿島：本質上，我們認為 1.0 階段的很多 Agent 只能完成單環節任務，更像是一個 Demo。我們更希望看到它在生產力中真正發揮作用，這意味著它必須嵌入工作流。

2.0 版本源于我們公司的內部版本（ 內部稱為 Agent 實習生 ）的外化，我們對 2.0 的定位是它能像助理或實習生一樣，在工作流中完整地完成任務并交付結果。基于此，它需要延伸出獲取充分 Context 的能力。比如內部同事辦公場景下，Agent 需要能獲取到內部各種 SaaS、IT、HR、財務、大數據，以及研發用到的監控、報警、代碼倉庫等所有軟件工具的 Context。

第二個就是它需要具備相應領域的專業知識。換句話說，財務、人事、研發、GPU Infra、文本算法和視頻算法的助理，它們之間非常不一樣。只有做到這一點，助理在用戶場景下才真正有用，能交付有價值且高度可用的任務結果。而不是說依然需要人類輸入大量上下文并重度參與，交付出一個自動化程度低、不可用的結果。

從對外角度看，我們做桌面端是因為它是當前獲取用戶 Context 并操作環境的最佳方式，這樣才能真正嵌入工作流，像助理一樣幫用戶交付結果。助理的特點是你交給它任務，它還你結果，你不需要時時刻刻盯著它，且你可以幫助它進步。第二點它是領域助理，這就是我們外化推出來的“專家”能力。以上這兩個核心輸入，也部分回答了 2.0 是如何生長出來的問題。

知危：所以你們內部推行使用 “ Agent 實習生 ” 的時候，發生了什么？是怎么擴散的？

阿島：擴散過程首先是從最熟悉這些工具的技術和產品團隊開始的。核心在于思維的轉變：每當開始一項工作時，首先不是怎么用 Agent，而是思考 Agent 是否能解決；如果不能，它缺什么能力？

所以先后順序是研發團隊、產品團隊、 GPU Infra 團隊、 HR 團隊、 投資和財務團隊，最后是銷售團隊。我們的經驗是，一套能讓大家真正用起來且產生依賴的產品，必須具備本地環境、充分的 Context（ 上下文 ）、通過 OAuth 接入的云端環境，以及針對研發、HR、財務或銷售等差異化需求所提供的 Expert 專業知識。

知危：Agent 2.0 特別強調 Context（ 上下文 ）的重要性，那么本地計算機提供的 Context，相比瀏覽器、手機等有哪些不同和優勢？

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

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

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

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

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

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

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

阿島：云端沙盒除了有被風控攔截問題，從更專業的角度看，它本質是面向通用場景的。舉個簡單的假設，比如專業的視頻剪輯團隊，肯定配有非常好的機器、超大內存和高性能 GPU，或者是 Mac Ultra 系列這種擁有大統一內存和 APU 的設備。只有這樣，在跑 FFmpeg 這種視頻處理任務時，才能達到很好的性能。

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

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

最后必須強調：今天 Agent 進步的最大瓶頸之一是 Agent Infra（ 可以簡單理解為智能體的基礎設施 ）。

知危：為什么這么說？

阿島：比如剛才說到了關于風控攔截或身份驗證的方面，這叫 Agent Auth。即 Agent 作為你的個人助理，如何能真正代表你的身份？在云端沙盒上，它無法真正代表你，因為它不是你個人的機器，沒有你的 IP 指紋、User Agent 等信息，產生的操作更容易引發安全性討論。

但在你的本機，它就是你的個人電腦，代表你的個人身份。在這里操作瀏覽器或處理事務，身份對標非常明確，不會存在這方面的問題。

我們橫向對比了所有獲取網頁信息的 Agent，無論是像 Browser Use 這樣專業的、Manus 這樣通用的，還是 ChatGPT、Claude Code 等。最終結果是，在 Cloudflare 這種網絡安全服務商的反爬、反垃圾機制面前，成功率普遍不高。即便人類接管去點驗證碼插件，也很有可能因為被識別出不是真實的桌面環境而無法通過。這就是目前 Agent Infra 面臨的現實挑戰。

我個人的觀點是，未來人類行為和基礎設施都會面向 AI 重新組織，屆時會有更不一樣的形態和更好的方式來驗證 Agent 的代理身份。但就目前而言，桌面端形態在這些方面是難以替代的。

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

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

而真正的 “ 通用 ” 應該是能夠深入并覆蓋各種專業場景。正是為了實現這種高階的通用性，我們才必須開發 “ 專家 ” 能力和桌面端。因為只有深入到每個人的具體專業環境、調用高性能硬件并理解其特定的工作流，Agent 才能在各種垂直領域都把活兒干好。

換句話說，我們的目標是通過深度專業化的能力，最終達成真正意義上的、全場景的通用。

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

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

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

知危：Agent 2.0 的產品形態比較新穎，您希望如何提升用戶認知并帶動用戶增長？

阿島：Agent 2.0 這種產品絕不是互聯網時代的買量產品，它首先不會完全受限于手機端，其次它深耕于生產力場景，而非娛樂或搜索這類淺層的通用場景。

增長的關鍵首先在于產品要達到極佳的效果并真正解決問題，其次要運營起相應的口碑和社群，建立良好的品牌，并基于實際的使用案例進行傳播。

因此，我們的增長路徑會更接近 Cursor 或 Lovable 等海外產品的成長模式。

尋鷺：用戶可能并不是因為知道 MiniMax 是一個通用產品才被吸引，而是因為在某個帖子中看到它做營銷、社媒監控或特定領域的工作非常好用才過來的。

針對垂直領域和專精 Agent，我們在獲取用戶和提升滲透率上面臨挑戰。因此，Expert 模式的下一個目標是產出更多 PGC 和 PUGC 內容，同時想辦法激勵更多 UGC 專家涌現。在這個過程中，我們希望用戶是因為有一個明確的問題或特定領域的訴求來使用 MiniMax Agent，而不是拿到一個看似無所不能、卻讓人不知道該拿它來做什么的通用產品。

Cursor 和 Lovable 增長策略的核心點在于：首先拋開常規手段，最關鍵的是能抓取并定義一個極具潛力的新場景。這種對場景的創新定義能力，決定了其后續做 PUGC 增長時能夠具備極高的初始勢能，并在起步階段就達成非常強悍的結果反饋。

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

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

在國內市場，由于 MiniMax Agent 上線相對較晚（ 去年 10 月上線，近期才正式增加交流與露面 ），目前我們仍處于對國內用戶行為的分析與拆解階段。

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

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

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

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

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

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

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

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

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

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

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

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

針對垂直與通用的爭議，我們堅持深耕通用框架。我們的核心目標不是停留在表面的“萬能”，而是通過構建一個更高階、更穩健的底層框架，能夠容納并理解用戶長期積累的復雜數據，而不僅僅是單次任務的片段信息，并且能夠無縫深入到各種本地、云端甚至復雜的企業生產環境。

知危：MiniMax團隊在研發Agent實習生的過程，其實是一個不錯的企業該如何走向Agent模式的樣本，但是似乎很少有企業能做到這么順暢？

阿島：傳統企業轉向 Agent 模式的最大障礙并非技術本身，而是人的思維與組織方式的重塑。這種轉變是一個動態進化的過程，正如 Minimax 團隊自身在過去一年也經歷了從不適應到 “ 離不開 ” 的認知升級。

這種進化的成功取決于兩個核心維度的交匯：一是人的接受度，即個體對 AI 等新事物的開放心態與駕馭能力；二是技術的成熟度，即模型與 Agent 性能的實質性飛躍。

即使在 MiniMax 這樣的技術驅動組織中，資深工程師初期也會因為固有的經驗路徑而對 Cursor 等 AI 工具產生抵觸與不信任。

因此，通用平臺的發展不能只停留在淺層功能，而應支持用戶在認知轉變后實現深度的協作進化。我們內部推行 “ AI First ” 和 “ Agent 友好 ” 的原則，要求無論是研發、財務還是產品，都要主動將 Context 和知識體系結構化，確保 Agent 能夠無縫獲取信息并發揮巨大的效率杠桿作用。這種 “ AI 原生 ” 的工作習慣，讓環境變得易于被 Agent 理解和調用，才是釋放 AI 潛力的關鍵前提。

我們會打造這樣一套產品和框架，去幫用戶往這個方向實現，但前提是用戶得有這個思維，得愿意這么做。這就像 Everett Rogers 提出的創新擴散理論里說的，從 Innovator（ 創新者 ）到 Early Adopter（ 早期采用者 ）有一個過程。

我們覺得現在還處于早期，大家的 Mindset（ 思維 ） 在進步，能力也在進步。它一定會有個臨界點，就是當能力進步到所有人無法忽視的時候。

拿我們團隊舉例，現在我根本不需要去建議任何一個同學用 Claude Code，大家已經深刻體會到它的威力了。但在最開始那個時間點，我得告訴大家，而且得把這件事弄得足夠簡單。

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

知危：會比較好奇，在 MiniMax，尤其是 Agent 產品的開發中，產品端和研發端是怎么合作的？

尋鷺：團隊間的合作機制，主要分為兩個層面。在產品與開發的合作中，Agent 團隊內部的職責邊界正在逐漸模糊。不同于傳統互聯網大廠由產品給出靜態 PRD 后交付給固定開發團隊進行交付、測試、上線的模式，目前的合作流程極大縮短了前置距離。產品人員也會直接參與 “ 搓 ” Expert、優化框架或產出 Vibe Coding Demo 等工作，這種協作方式更加靈活且緊湊。

以表單應用為例，很多時候是產品直接通過 Vibe 快速搭建出雛形，再由設計師接入調整樣式，隨后便直接上線。大家在 Agent 首頁看到的許多表單應用、運營位應用以及 PGC Expert，其實并非出自開發之手，而是產品利用Cursor和高效協同模式快速實現的。而且有想法的開發人員也會針對特定場景提出很有價值的應用方案。所以至少在我們的團隊里面，這個合作的模式正在消解傳統的權責邊界。

在分工上，大家依然保留著傳統職能，比如產品經理仍會承擔大量的競品調研、用戶研究以及 Query 分析等基礎工作。但在處理具體的某個產品化 Feature，或是面對一些比較緊急的需求時，分工形式就與傳統的互聯網大廠不太一樣。

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

這種協作的結果是大家打破了原有領域的思維定式。因為 Agent 類產品具有 “ 技術與產品高度合一 ” 的特性，研發不能只鉆研技術，產品也不能只考慮功能，雙方都會有端到端的視野和雙邊思維。但是也都有各自擅長的地方，畢竟每個人的精力和擅長領域終究有限。

知危：那么 Agent 團隊和模型團隊的協作關系是怎樣的？

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

因此，Agent 團隊會面向真實的內部用戶場景去構建自己的 Benchmark。比如我們構建的 Benchmark 往往針對當前市面上所有 Agent 都做不好的挑戰性任務（ 得分可能僅在三四十分左右 ）。這些任務并非憑空想象，而是從用戶的真實痛點中發掘出來的。所以我們構建的 Benchmark 更能代表真實世界的分布，從而指引其轉化為適合模型訓練的標準。

以我們最近開源的 VIBE Benchmark 為例，它專門用于評估模型在全棧開發（ 包括 Web、移動端、桌面端 ）上的表現。這一成果結合了產品視角的輸入與研發團隊的專業深度，因為研發團隊最懂服務端和 WEB/APP 開發的本質。

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

知危：桌面 Agent 是比較新穎的產品形態，又涉及用戶的私人數據輸入，用戶難免會有存儲安全和隱私安全方面的擔憂，MiniMax 如何解決這些安全隱患？

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

這也是為什么桌面端和網頁端的記錄沒有同步，因為兩者的工具和文件工作區是完全隔離的，這主要是出于安全和隱私的考慮。

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

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

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

目前，“ 移動到回收站 ” 功能已在最新版本支持，服務端也已下發風險提示邏輯，前端 UI 正在緊鑼密鼓地適配中。

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

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

首先是 AI Creator，對于不熟悉 Sub-agent、Instruction、Skills 或 MCP 配置的普通用戶，我們提供了一個 AI 驅動的創建工具。用戶只需提供非結構化的知識（ 如一段 SEO 專家的文本資料 ），AI 就能自動解析并完成復雜的后端配置。以 SEO 專家為例，AI Creator 可以自動將任務拆解并配置成三個協同工作的 Sub-agent，同時自動配齊對應的 Skill 和調度指令，明確它們之間如何協作。這種方式的優勢在于，它能迅速將用戶的專業經驗轉化為可執行的 Agent 架構，而不需要用戶具備任何技術背景。

AI Creator 的核心價值在于將復雜的 SOP 自動轉化為最優架構。用戶只需將已有的知識庫或 SOP 發給 AI，它就能在我們這套功能強大但配置相對復雜的專家框架中，自動匹配出最優的 Sub-agent 組合、Skill 定義和指令集。用戶無需手動編輯繁瑣的文檔或參數。

如果發現專家執行效果不佳，只需像聊天一樣告訴 AI：“ 它在某處處理得不好，幫我修改一下提取邏輯或解決方案。”

我們在制作 PGC 專家時也發現，最有效的調優方式并非手動改代碼，而是通過對話引導 AI 迭代。因此，我們將這套內部實戰經驗沉淀到了 AI Creator 框架中，讓普通用戶也能以自然語言交互的方式，打磨出生產級別的專家。

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

無論是 AI 自動生成的還是手動搬遷的專家，調優過程都極其簡便。用戶只需通過自然語言反饋，AI 就會輔助用戶完成指令和邏輯的迭代優化。

知危：接入本地計算機 Context，會帶來推理成本暴增嗎？

尋鷺：確實，大家可能會擔心 Agent 場景因為接入了用戶個人電腦的數據，輸入量變大，成本會比以前的產品高很多。

但其實測試下來還算好。就像有用戶問理解圖片和視頻會不會很費積分，其實這種理解類任務反而不太會，因為這類工具的消耗是比較容易控制的。

當然，如果是生成類任務，確實是另外一個量級，也跟任務復雜度直接掛鉤。

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

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

尋鷺：官方這邊也一直在持續優化消耗速率，目標是讓用戶的任務能在一個 ROI 比較高的區間內完成。比如下周我們要發布的一個功能就是做模式的 Routing。因為很多時候任務復雜度不高，Agent 完全可以自動調用“高效模式”快速搞定，不一定非要調用昂貴的 Pro 模式。

除此之外，我們一直在優化積分消耗。比如之前為保證最終效果，一些環節會讓 Agent 做大量的自動化測評，后來我們增加了 “ 用戶確認項 ”，用戶可以選擇是完全交給 Agent 去跑測試，還是由自己來做測試并把觀察到的點反饋給 Agent，從而更高效、更省積分地完成修改。

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

知危：您多次強調 Agent Infra 的重要性以及對當前 Agent 發展的限制，行業當前現狀到底是怎么樣的，距離理想狀態還有多遠？

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

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

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

在有身份認證的前提下，信息提供方式也會改變。現在的網頁是提供給人看的 HTML，未來也許會有專門提供給 Agent 的格式；或者隨著 VLM 的進步，HTML 依然存在，但會從面向 SEO 優化轉向面向 Agent 優化。比如為了讓 Agent 快速導航，HTML 的標簽需要變得更具語義化。

總結一句話，就是所有的基礎設施、軟件服務和人們的 Mindset，都將面向 AI 和 Agent 來重新定義和提供。我堅信這件事情一定會發生。

知危：專家的提示詞設計有兩點值得注意，一個是專家下還會設置 Sub-agent，這種雙層結構的好處是什么？

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

以制作視頻為例，如果用一個 Single Agent 掛載所有 Skills 來做，效果會很差：首先它的上下文會 “ 爆炸 ”，其次滿載了各種雜亂信息的上下文會分散它的注意力，工具集也會變得非常臃腫，很難把活兒干細。采用 Sub-agent 結構的好處就在于 “ 專注與共享 ”，比如你可以把導演、腳本分鏡、素材生成、后期剪輯分別交給不同的子 Agent。雖然它們各司其職，但因為共享同一個工作區，并且都能調用 Memory 工具，所以它們能擁有同樣的上下文記憶。這種模式既保證了信息的同步，又讓每個子 Agent 能夠專注于自己的專業環節，把事情做得更深、更好。

此外，因為每個 Sub-agent 擁有獨立的 Context Window，不容易觸發上下文壓縮總結。大家應該都知道，一旦觸發壓縮，模型就非常容易 “ 降智 ”。其次是Sub-agent 具備不可替代的 “ 并發能力 ”。比如你需要同時創作 3 個分鏡，或者同時調研 10 家上市公司。如果你只用一個 Single Agent 配一堆 Skills，它只能像排隊一樣一家一家做過去，既慢又做不深。

所以這兩點最關鍵：一是專注，通過上下文隔離讓任務做得更深、更好；二是能更好地處理并發。

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

當一個 Agent 在處理一件事（ 比如文檔處理 ）時，它可能會面臨不同的情況，一會兒是 Excel，一會兒又是 PDF 或 Word。這種時候你根據需要去動態加載對應的能力，一次只做一件事，就很合適用 Skills。

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

知危：另一點是，提示詞 Token 數限制是 5 萬，但一般在此規模上下文下，模型表現會受限不是嗎？

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

尋鷺：設定一個非常大的上限，也是為了兼容復雜的業務場景。例如在需要同時調度 10 個 Sub-agent 的情況下，Instruction 需要詳細規定各 Agent 的并行調用邏輯或執行順序。以 PGC Expert 中的“熱點追蹤”為例，即便經過壓縮，其指令量依然巨大，因為它涉及五六個 Sub-agent，執行中間需要并行對挖掘出的熱點話題再做一輪深度研究。但在大多數情況下，如果通過 AI Create 的方式生成指令，token 數通常會自然維持在 5000 左右。

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

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

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

幫助理財小白避免掉坑。

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

尋鷺：其實在公司內部，我們其實有一個在飛書里運行的 Agent 實習生，只要飛書開放 API 就能較好地接入。

對于外部用戶，并非所有企業的數據都在即時通訊工具里，云端可能更多起備份作用。

桌面端是我們拓展 Context 和環境的第一步，將 Web 端需要手動上傳的形式轉變為可以直接操作本地文件，這對于很多小型機構或個人來說已經是非常大的進步，因為他們的資料往往還是存在本地電腦里。

未來我們也希望能利用更多應用和云盤里的上下文環境，這也是我們后續追求的目標。

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

我們內部目前是通過 API 封裝來實現深度接入的。針對企業級場景，我們考慮以 ToB 模式應用，因為這需要企業管理員提供密鑰授權才能調用 API。對于像 Notion、Slack 這種 OAuth 或 MCP 授權已相對成熟的平臺，我們會盡快接入。我們的終極目標是接入用戶所有的 Context。這正是我提到的 Agent Infra 的構建過程：不僅是 Agent 應用層的努力，更是整個行業甚至線下服務（ 如麥當勞的點餐 MCP ）向 AI 進化的過程。我們將盡可能全、盡可能快地接入這些能力。

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

這需要所有組織達成共識，認同 Agent 的價值，并齊心協力開放工具、API 和權限接口。因此，Context 的獲取分為兩步：第一步是努力接入已有的 API 或 MCP 開放應用；而更難的第二步則是，當常用的 SaaS 接入完成后，進一步深入將不再僅僅是軟件或技術問題，而是涉及到組織架構與企業管理的深層挑戰。

核心在于該公司的基礎設施（ Infra ）是否對 Agent 友好，以及組織管理上是否樂于擁抱 “ 由 AI 替代人工節點 ” 的形式。

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

將這一套 Agent 經驗平移至大公司時，會面臨顯著的現實挑戰：首先是存量組織與流程的慣性，大公司往往已有成熟細致的人工團隊和固定流程，在資源充足的情況下，替代動力可能不如初創公司迫切；其次是系統碎片化與權限復雜度，大廠內部不同部門、組織間的平臺與工具往往高度割裂，難以統一接入，導致開發適配 Agent 的基礎設施周期漫長，且權限控制極其復雜，極大增加了面向 “ Agent 友好 ” 工具轉換的難度。

還有一個現實痛點：ROI（ 投入產出比 ），在大公司維度下，當人力資源相對充足時，管理層會權衡：投入大量研發資源去開發工具接口、梳理復雜的權限邊界以及界定責任歸屬，其最終帶來的效率提升是否值得？這種涉及權限體系重構和責任控制的決策，往往很難在短期內快速推進。

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

尋鷺：在去年沒有那么多團隊做 Agent 的時候，可能某些團隊還能說自己有一些壁壘，但到了今年，坦白說沒有任何一個團隊有壁壘。

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

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

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

本質上，在一個技術的快速上升期，除非技術停滯，否則沒有任何人能夠擁有壁壘。唯一的壁壘就是你有沒有組織優勢：有沒有相應的人才能保持足夠強的認知，有沒有相應的底層 Infra，以及整個團隊去執行和實現它的技術能力。這其實就是 Anthropic 和 Gemini 能追上來的原因。比如 Gemini，最根本原因的是創始人直接下場寫代碼，如果沒有這一點，其他努力都是白費心機。

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

尋鷺：我們會有多個主要努力的方向。第一個方向，是繼續完善桌面端設計、做 Experts，涉及 Knowledge 和 Memory 機制的構建，也會涉及思考如何通過 Computer Use 接入更多應用。

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

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

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

最后是提供更多的 PGC 和 PUGC 的 Expert，我們也會進一步鼓勵 UGC 的生態。我們終歸希望用戶來用的時候，不是面對一個好像能解決所有問題的通用 Agent，而是帶著自己明確要解決的問題。

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

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

確實，Agent 的下一個重要方向將是自舉（ Self-bootstrapping ）與自我進化。即 Agent 不僅能為用戶創造專家，還能根據反饋自我改進。

我們希望達到的下一步目標是：Agent 能夠主動觀察用戶的滿意度，并在發現表現不佳時，主動提議具體的修改點。這代表著 Agent 不再是一個 “ 死 ” 的配置，而是一個能與用戶不斷互動、在工作流中實時進化的實體。以代碼編寫為例，它能自動糾正那些繁瑣的格式錯誤，而不需要人類反復叮囑。

目前，我們公司內部處理用戶反饋和問題的流程已經由 Agent 自己完成并給出建議。所以，我們正在推進的下一步，就是讓 Agent 根據這些反饋自動優化自身。

雖然行業內目前僅有一部分人意識到這一點，但這將是 Agent 真正深度融入人類生產力的關鍵。

（ 訪談全文完 ）