早在 2024 年 11 月，Anthropic 的 Model Context Protocol （MCP）發佈，通過這個協議，大模型就能比較容易地呼叫工具。OpenAI 在 2025 年 3 月曾公開表示要在自家產品裡支援 MCP。當時，業內都認為工具呼叫這個難題很快就會藉著MCP得到解決，通向Agent元年之路暢通無阻。因此 2025 年的夏天，MCP 生態確實爆發了。GitHub 上湧現了數以萬計的 MCP Servers，從操作 Kubernetes 叢集到訂購披薩，似乎一切皆可 Agent 化。然而一年多時間過去了，想像中Agent爆發的場景並沒有發生，它們迷路了。當企業試圖將成百上千個內部工具掛載到自家Agent模型上時，它們開始變得遲鈍、健忘，無法完成任務。全自動執行工具呼叫，很多時候變成了一場昂貴的報錯循環。在2025年的4月，我在和Konjie老師溝通的過程中，形成了一個共識，即MCP確實是一個殘缺的協議，因為它沒有規定大語言模型和MCP的互動模式。也就是說，MCP只承諾提供統一的工具介面，但並沒有規定大模型應該如何發現、選擇、組合這些工具。當時，kongjie老師認為，這個工作應該是Agent整合商或者Agent平台的活兒。但在這之後，除了LangChain一直在最佳化之外，大家的進步都很慢。直到 2025 年 12 月，隨著 Anthropic 低調但極其重要地發佈了 高級工具呼叫（Advanced Tool Use）套件。終於自己動手補齊了這個「殘缺」的協議。這也許會帶來Agent開發的新一輪重要變化。01只有介面，沒有規則要理解為什麼 Agent 會迷路，我們必須重新審視Agent和工具間到底有什麼互動模式。在 MCP 協議下，當一個 Agent 試圖解決問題時，它必須經歷四個連續的互動步驟：感知、決策、組裝、執行。在2025年的工程實踐中，這四個步驟每一步都佈滿了地雷。步驟一：感知階段在這個階段中，Agent 做的是打開工具箱，查看自己有那些能力可用。在舊的MCP模式中，這是一個靜態全量的過程。為了讓 Agent 隨時可用，開發者被迫把成百上千個工具的完整定義（Schema），包括名稱、描述、參數結構一股腦塞進 System Prompt。這導致了上下文的公地悲劇。大量的工具說明書擠佔了模型的上下文。根據Anthropic的計算，大概50 個工具的定義就會吃掉約 20,000 Tokens。結果Agent 的注意力全放在記住工具名上了，其他的執行、推理嚴重受損。這一切，都是因為缺乏按需發現機制。模型只能遍歷所有工具進行搜尋。步驟二：決策階段在這個階段，Agent 根據使用者指令，在工具列表中挑選最合適的那一個。而此時，當工具從 10 個增加到 1000 個時，列表裡必然充滿了功能高度相似的選項。MCP 並沒有提供區分這些細微差別的機制，模型只能依靠工具定義中微弱的語義差異去猜測。這導致了決策癱瘓。面對海量選項，模型的注意力機制被稀釋，而且很容易選錯。選錯工具是連鎖反應的開始。一旦第一步選錯，後面的參陣列裝和執行全是無用功。造成這一問題的原因，也是缺乏動態收縮機制。步驟三：組裝階段這一步，當Agent 選中了工具後，會開始根據 Schema 填寫入參（Arguments）。這是被大多數人忽視，但報錯率最高的一步。MCP 的工具定義中，Schema 往往只定義了顯性語法（例如：參數 date 是字串），但沒有傳遞隱性規則（例如：這個日期必須是 YYYY-MM-DD 格式，且不能早於 2020 年）。 更沒有教你具體這個工具怎麼用。這導致了就算工具選對了，也得猜謎式試錯。Agent 只能靠直覺填參。然後經歷報錯 → 換個格式重試 → 再報錯的地獄循環，在這一過程中，大量的 Token 被浪費在其中，而不是推進任務。這一切都是因為MCP缺乏最佳實踐的顯式指引。模型不僅需要知道參數是什麼類型，還需要知道參數長什麼樣，怎麼用。步驟四：執行階段在這一階段中，Agent 發起呼叫，等待結果，讀取結果，決定下一步。在傳統的 MCP 模式中，這是一個線性阻塞（Linear Blocking）的過程。 如果任務需要“翻閱 100 頁日誌找到報錯行”，Agent 就必須進行 100 次“呼叫-等待-讀取-思考”的循環。這導致了推理瓶頸與資訊污染。首先它巨慢，每一次微小的操作都要經過一次完整的 LLM 推理和網路往返，耗時極長。而且它還會很髒，工具返回的中間結果（例如 100 頁的原始日誌）會被全量塞回上下文。這些垃圾資料不僅浪費 Token，還會干擾模型對最終結論的判斷。這就是MCP缺乏邏輯編排與資料清洗的能力。這導致它工具就算用上了，效率也很低，還會進一步增加天量的上下文。這四個步驟的崩壞，構成了一個完美的失敗閉環。而 Anthropic 的新工具，就是針對這四個步驟的精準爆破。02Anthropic 用三板斧，重建工具呼叫的秩序Anthropic最新發佈的這套被統稱為 Advanced Tool Use 的功能，精確地對應了上述四個痛點，在混亂的 MCP 荒原上重建秩序。下面我們就來看看，他們是怎麼一一鬆動這些“屎山問題”的。1. 修復感知與決策：Tool Search Tool針對「感知階段的上下文超載」和「決策階段的癱瘓」，Anthropic 給出的解法是 Tool Search（工具搜尋），它可以幫助MCP，不要把所有工具定義一股腦塞進上下文；而是先搜尋，再只載入少量候選工具的定義。這把缺失的「工具發現與按需載入」做成了平台級能力。Tool Search 的工作流程可以分為七步。那它和過去有什麼不同呢？Tool Search就這三招：先收縮工具空間，再做精確選擇，同時隱藏工具描述。不過，這個工具依然有Anthropic只做系統層的限制，它「只負責找工具，不負責保證一定找對」。它的每次搜尋只返回 3–5 個最相關工具。如果工具描述寫得差、關鍵詞不匹配、同義詞覆蓋不足，就可能搜不到你期待的工具。所以文件還給出了工具庫最佳化的建議。比如工具名/描述要清晰、描述裡放使用者會用的關鍵詞、系統提示裡提示工具類別等。但只要定義精準，使用者靠它一下就可以省下上萬的token，進而把上下文空間還給計畫、狀態和約束，而不是被工具說明書吃掉。2. 修復組裝：Tool Use Examples解決了找不到合適工具的問題，緊接就要解決怎麼用工具的問題。針對模型不知道怎麼填參的痛點，Anthropic 引入了 Tool Use Examples（工具使用示例） 標準。通過增加幾個範例，模型可以更好的呼叫其 Few-Shot Learner（少樣本學習者）的能力，更好的學會如何使用這些工具參數。舉個例子，比如我要連結個出票工具。Anthropic 的內部資料顯示，僅僅是加上這些示例，模型在處理複雜參陣列裝時的精準率就從 72% 飆升到了 90%。更重要的是，它終結了那個報錯-道歉-重試死循環，讓組裝這個工具使用步驟更精準。3. 修復執行：Programmatic Tool Calling (PTC)最後 Anthropic 通過加入 PTC (Programmatic Tool Calling)解決「執行階段慢與髒」的問題。回顧第一章，傳統的 Agent 調一次工具，就需要看一眼返回結果，再調一次工具。這不僅慢，而且把中間看到的幾千行垃圾日誌全塞進了上下文，導致後續推理難以為繼。PTC 則允許模型編寫程式碼來重新編排執行流程。 模型自己不再去翻頁、過濾、尋找，而是寫一段指令碼交給 Python 直譯器去循環、過濾、聚合、平行。而模型只在關鍵時刻（比如換工具時）介入，它只接受結構化的指令碼輸出作為上下文，而不是把全部中間資料灌給模型。這一改變讓過去幾十次網路往返被壓縮成了一次秒級的程式碼執行。而且中間過程產生的數以萬計的垃圾上下文在程式碼層就被消化了，永遠不會污染模型的推理上下文。Anthropic 的這套組合拳，本質上是在原本殘缺的 MCP 介面層之上，強行建構了一個「互動層」。Tool Search 確保了模型能看見（Perception）正確的東西；Examples 確保了模型能組裝（Formulation）正確的指令；PTC 確保了模型能執行（Execution）高效的操作。至此，讓 Agent 迷路的四個路口，都被立上了紅綠燈。03這股浪潮，不只是Anthropic 參與在 Anthropic 發佈這套方案的同時，行業內的其他玩家也開始在MCP發佈一年後，發現了「工具呼叫缺乏互動規則」是阻礙 Agent 規模化的最大絆腳石。於是在2025 年末這個節點上，我們可以看到各家給出了一些殊途同歸的解法。GitHub Copilot：用“虛擬聚類”對抗數量級GitHub Copilot 面臨的是最複雜的 IDE 場景，擁有成百上千個開發工具。 在 12 月的更新中，他們提出了「Smarter with Fewer Tools」策略。他們沒有像 Anthropic 那樣完全依賴搜尋，而是設計了一套「虛擬工具集（Virtual Tool Clusters）」。這套工具集將默認上下文中的工具壓縮到僅 13 個核心工具，而將其餘數百個工具被折疊進「虛擬類別」（如 Edit, Terminal, Git）。這樣，模型不再直接選工具，而是先選工作目的，比如修改程式碼，系統就會展開 Edit 類目下的具體工具。這種分層決策的機制，本質上也是一種對工具空間的動態收縮。Spring AI：中介軟體層的“介面卡模式”就在 GitHub 更新的同一周，2025 年 12 月 11 日，Java 生態的領軍者 Spring AI 發佈了 Christian Tzolov 撰寫的重磅更新。與 Anthropic 和 GitHub 不同，Spring AI 沒有自己的大模型。如果模型（比如 Llama 3 或舊版 GPT-5）本身不支援原生的 tool_search，該怎麼辦？那就不要等待模型進化，在框架層解決它。Spring AI 推出了 Advisors API，這實際上是一種中介軟體層的「介面卡模式」。它允許開發者在應用層外掛一個向量資料庫（Vector Store）。當使用者提問時，Spring 框架會先攔截請求，在向量庫裡進行 RAG 檢索，找到最相關的幾個工具，然後再動態地將這些工具的定義“掛載”到 Prompt 裡，最後才發給 OpenAI 或 Llama。這一舉措意義重大。它意味著按需載入的能力被解耦了。即使是那些智商較低或架構較老的模型，也能通過 Spring 框架這個外骨骼，獲得處理海量工具的能力。Warp：用“子智能體”分而治之終端工具 Warp 則更加激進，同樣在2025年11月，他們推出了 MCP Search Subagent。他們認為主模型（如 Claude 3.5 Sonnet）太貴了，不應該用來幹翻說明書這種雜活。於是他們設計了一個專門的輕量級 Subagent，專門負責去 MCP 伺服器裡海選工具，選好了再喂給主模型。這種主從架構不僅解決了上下文問題，還進一步降低了 Agent 的運行成本。04這是比Skills，對Agent影響更大的事進入 2026 年初，Skills無疑成了 AI 圈最喧囂的詞彙。大家喜歡它，因為把一堆脆弱的工具鏈打包成穩定的能力塊，像人一樣積累、復用、升級。你甚至可以想像一個 Skill Store，在那裡能力被商品化，Agent 被規模化。一個新的，屬於Agent的App Store。但 Skills 其實是「上層建築」。它的前提，是下面那套基礎設施得先成立：工具多了不崩、流程長了不漂、結果大了不炸。而 Anthropic 這次做的，恰好是那個「更底層、也更隱藏」的轉向點。它一起回答了 MCP 最初留下的空白：MCP 負責統一介面，而現在平台開始規定「怎麼互動」，工具市場才可能真的進入可治理、可營運、可擴張的階段。所以這是 Agent 圈水底的大事兒。如果說 MCP 1.0 是打通了 AI 與世界的物理連接，那麼加上這套互動標準後的 MCP 2.0，確立了 AI 與世界的溝通語法。 (騰訊科技)

Anthropic這次確定了AI智能體產品形態2025年10月16日，Anthropic正式推出Claude Skills（簡稱Skills），這是一個專為Claude AI模型設計的可組合技能系統，旨在提升AI在專業工作流程中的實用性和可靠性。該功能標誌著Anthropic從通用對話AI向“代理式”（agentic）AI轉型的關鍵一步，允許使用者和開發者通過簡單資料夾結構“教導”Claude特定任務，避免了傳統提示工程的低效和不一致性。Skills目前面向Pro、Max、Team和Enterprise使用者開放，支援Claude.ai、Claude Code、API以及Claude Agent SDK等多平台無縫整合。具體使用體驗和邏輯上來看，Claude Skills有點像指令碼程序，基於特定規則實現某種功能服務。甚至，你可以直接將其理解為指令碼智能體技術，只不過借助Claude大模型，這種指令碼達到了通用、低程式碼實現。從某種層面上來講，是工具能力更強大更豐富版本的GPTs。而且是以便於傳播的檔案壓縮包的形態存在。預計未來Claude Skills會成為大模型們的一個統一服務形態，就像MCP協議一樣快速被全行業接受並支援。這一技術進一步展示了，Anthropic致力於借助各種工具來提高大模型精準率和降低算力消耗的技術路線。1. 具體原理：模組化載入與安全執行機制Claude Skills的核心是一個輕量級、可擴展的框架，其設計哲學強調“漸進式披露”（progressive disclosure）和“按需載入”，以最小化計算開銷並提升一致性。不同於傳統RAG（Retrieval-Augmented Generation）或提示鏈，Skills將知識封裝成自包含的“技能資料夾”，讓Claude像人類專家一樣“即時掌握”專長。結構與載入機制：每個Skill是一個資料夾，包含：SKILL.md：核心指令檔案，使用Markdown格式描述技能的用途、輸入/輸出規範和執行邏輯。Claude通過Bash工具（如cat SKILL.md）讀取此檔案，僅在任務相關時載入，避免上下文窗口膨脹。指令碼與資源：支援Python、Bash等可執行程式碼，以及輔助檔案（如範本、資料表）。例如，一個Excel技能資料夾可能包含生成公式的指令碼和示例資料集。中繼資料：技能名稱、描述和版本資訊，便於Claude自主決策是否呼叫（初始僅用數十個token掃描描述）。Claude在處理使用者查詢時，會先評估任務語義匹配度（如通過嵌入向量比較），然後動態載入匹配技能的全內容。這使得Skills“可組合”（composable）：多個技能可疊加，形成複雜工作流（如資料分析+可視化）。執行與安全保障：Skills依賴Anthropic的Code Execution Tool beta（一個沙箱化REPL環境），支援安全運行程式碼。程式碼執行隔離在容器中，防止惡意注入；Anthropic強調“僅信任來源”安裝，並提供審計指南。相比純token生成（如排序演算法），程式碼執行更快、更廉價（減少80%+ token消耗），並確保確定性輸出。建立與管理：使用者可通過Claude的“skill-creator”互動式聊天建構技能（非技術使用者友好），或用API的/v1/skills端點版本化管理。Anthropic提供GitHub倉庫（anthropic/skills）和Cookbook範本，加速開發。這一機制源於Anthropic的“憲法AI”原則，確保技能載入符合倫理邊界。總體而言，Skills將Claude從“通用聊天機器人”升級為“模組化代理”，其原理巧妙平衡了靈活性與效率，適用於長時任務（如30小時自主編碼）。2. 競對分析：針對OpenAI和Google的差異化定位Skills並非孤立創新，而是Anthropic在AI代理領域的精準反擊，聚焦企業級可靠性和安全性，與競品形成鮮明對比。當前市場，OpenAI的GPT-4o和Google的Gemini主導通用AI，但代理功能仍碎片化。vs. OpenAI：Skills直接挑戰OpenAI的AgentKit（2025年9月推出），後者依賴工具呼叫建構代理，但易受提示變異影響，導致輸出不穩。Skills的資料夾格式更易分享和版本控制，Anthropic強調“非基準導向，而是企業上下文最佳化”。 2 8OpenAI生態更成熟，但Skills在成本（程式碼執行節省token）和安全性上領先。vs. Google：Gemini的代理更偏基礎設施（如Vertex AI），適合雲整合，但缺乏Skills的“即插即用”簡易性。Anthropic的移動/桌面支援更強，針對中小企業。新興競對：xAI的Grok強調即時搜尋和幽默，但代理功能較弱；Meta的Llama代理依賴開源社區。Skills的封閉生態（市場+SDK）提供更可靠的企業入口。3. 能用來幹嘛：從日常辦公到代理自動化Skills將Claude轉化為“工作專家”，適用於重複性高、精度要求嚴的任務。Anthropic預置了Excel、PowerPoint、Word和PDF技能，使用者可自訂擴展。典型應用包括：文件與資料處理：生成帶公式的Excel報表、PowerPoint演示（e.g., 市場分析幻燈片）、可填PDF表單，或從Notion提取資料。品牌與合規工作流：自訂“品牌指南”技能，確保輸出符合公司風格；金融/醫療場景下，整合合規檢查指令碼。編碼與自動化：Claude Code中載入偵錯技能，自主運行30+小時編碼任務；建構代理鏈，如資料清洗+可視化。整合擴展：與Microsoft 365/Box無縫協作，Canva計畫用Skills定製設計代理。 012 早期反饋顯示，複雜任務從一天縮短至一小時。總體，Skills適合知識工作者和開發者，強調“一次建立，到處使用”。4. 對市場生態的改變：加速智能體時代，注入安全與模組化範式Skills的推出正值AI智能體從炒作轉向落地（2025年市場規模預計超500億美元），它將重塑生態格局。企業級轉型：推動AI從“輔助工具”到“核心代理”，減少提示工程依賴，提升ROI。Anthropic首席產品官Mike Krieger指出，企業已過“AI FOMO”階段，轉向可量化指標；Skills的確定性執行填補這一空白。生態開放與分享：通過marketplace和GitHub，Skills催生“技能經濟”——開發者可售賣/分享模組（如Datasette外掛），類似於App Store，但專注AI工作流。 45 這將刺激開源社區，降低進入門檻。安全與監管影響：Anthropic的沙箱+倫理設計強化AI在高規行業（如金融、醫療）的採用，緩解“黑箱”擔憂，推動標準制定。競爭動態：加劇與OpenAI的“代理戰”，可能迫使競品跟進模組化設計；同時，擴展Claude在中小企業滲透（當前企業使用者佔比30%+）。長期看，Skills或加速“AI技能市場”形成，價值鏈從模型訓練轉嚮應用層創新。 (AI頓悟湧現時)

大家好，我是艾倫。最近一直在當全端開發工程師，但開發前端遇到報錯的時候，總是要f12 看介面看各種報錯，然後再截圖給ClaudeCode。流程倒是不長，但就是很繁瑣。前段時間我還在想，Chrome 啥時候能出個能看網頁運行情況的MCP 啊。結果，就在前幾天，答案來了。Chrome 直接推出了一個叫做ChromeDevTools 的MCP。能夠直接在Chrome 瀏覽器中調試網頁，享受DevTools 的調試功能和效能分析能力。讓AI 終於能夠"開眼"寫程式碼了！知道這個MCP 的第一時間我就火速的打開ClaudeCode 進行安裝了。第一步，讓AI 學會登錄，像個真人一樣，能不能完成最基礎的操作。使用的方法很簡單，輸入前端的URL，然後輸入關鍵字"Chrome MCP"就可以將瀏覽器喚醒。然後再輸入我的要求，就可以看到瀏覽器在模擬我們的操作行為。點擊"登錄"按鈕，輸入使用者名稱和密碼，最後再點擊"登錄"。這不僅僅是自動化，這是「可視化」的自動化。它能重現Bug、測試複雜的使用者流程，這對於定位那些偶發性的、難以復現的Bug，價值無可估量。第二步，讓AI擁有“眼睛”，自己檢查工作。如果只是模擬操作，我覺得還不夠驚豔。真正的自動化，我覺得得讓它能自己檢查DevTools，自己檢查工作結果。http://localhost:3000/ 使用Chrome MCP 打開這個頁面，並輸入使用者名稱和密碼super_admin/123456，進入到我的頁面，在帳號設定中將手機號綁定/更換以及設定密碼這兩個填空欄全部刪除。最後核實這次修改是否按照預期進行。當我在最後加上了最後核實這次修改是否按照預期進行。 這句話時，Chrome MCP 會對介面進行一次截圖去檢視和記錄修改的結果。相當於他用自己的"眼睛"幫我們檢查了一遍，真正做到了我前面所說的"開眼"寫代碼。它不再是盲目執行指令的工具，而是一個能驗證結果、有閉環思維的夥伴。第三步，從前端開發到效能分析優化。Chrome MCP 在前端開發上的能力還遠不如此。我們還能讓它自動進行效能追蹤分析，診斷具體的效能瓶頸，例如過高的LCP（最大內容繪製）指標等。這個前端的終極難題，我現在把它拋給Chrome MCP。前端的頁面載入有點慢，Chrome MCP 去分析原因，讓它變快一些，再給我一個效能瓶頸的報告。Chrome MCP 發揮了它的優勢，我也直接一大個解放。再也不需要打開Chrome DevTools 效能介面去看渲染、指令碼執行、網路請求等耗時點了。現在Chrome MCP 自動幫我分析，找到了問題並直接上手改代碼。最後，一份詳盡的效能優化報告自動產生。我需要做的，僅僅是檢查一遍它的修改，然後提交。模擬器- 有"眼睛"的測試員- 性能優化專家。Chrome MCP 的出現，可以說徹底的改變了前端開發的方式，也可能徹底改變了前端開發者的命運。從繁瑣、重複的實現細節中解放出來，將更多精力投入更高維度的思考：系統架構的設計、業務邏輯的梳理、產品體驗的創新等。我們不再是那個需要時刻盯著儀表板的司機，而更像一個設定好目的地，並信任副駕駛能處理好路上一切狀況的領航員。讓機器做機器擅長的事，讓人回歸人擅長的創造。我想，這便是這場技術革命，帶給我們開發者最激動人心的未來。（阿倫AI工具庫）

Google剛剛發佈了一個新的智能體通訊協議A2A(Agent to Agent)，本文會從多個方面全面對比A2A、ANP、MCP。解決的問題ANP和A2A都是為瞭解決智能體之間的通訊問題，都看到了MCP在智能體通訊上的侷限性：MCP更加擅長於讓模型連接工具與資源。同時，ANP和A2A都認為自己是和MCP互補的。ANP與A2A則有很大的重合，之所以不是百分比重合，是因為看下來，A2A好像想解決的是企業內部的智能體協作，雖然官網沒有明確地說明這一點，但是我從他們的設計中能夠感受到這一點，特別是在Task的設計上。設計原則在設計原則上，ANP與A2A有很多相似之處：強調簡單，並且復用現有的協議。強調身份，智能體身份是ANP最核心的模組。解耦（不透明）：智能體不必共享思考過程、計畫或工具。這是ANP、A2A與MCP在設計細節上最大的區別。A2A應該也看到了MCP的複雜性，選擇使用Task來作為核心的概念，Task確實是比Tools、Resources更加抽象，更高level的概念。MCP的Tools和Resources也是非常適合MCP的概念，但是sampling、root的設計我認為需要斟酌一下。協議架構ANP與A2A在協議架構上都可以看做P2P架構。MCP是典型的C/S架構，不單單是連接上，也包括協議的概念、角色設定上。無疑P2P架構更適合智能體網路。傳輸層都支援HTTP，除此之外，MCP由於需要訪問本地資源，為了方便，還支援stdio。核心概念MCP的核心概念是Tools、Resources、Sampling、Root、Prompts。A2A的核心概念是Task、Artifact（工件）、Message、Part。ANP的核心概念是Interface：包括NaturalLanguageInterface（自然語言介面）、StructuredInterface（結構化介面）。ANP是將智能體互動方式的定義下放到了Interface中。比如，Interface可以是一個預訂酒店的API，這個API直接返回結果。也可以是類似A2A的Task，在Interface中定義Task的狀態。但是在協議層，我們沒有直接顯式的定義Task以及狀態。從不透明程度看：MCP是白盒，能夠查看對方內部的檔案、工具、資源等資訊A2A是灰盒，雖然不共享智能體的思考過程、計畫或工具，但是仍然定義了智能體之間的任務，以及任務的狀態等ANP是黑盒，兩個智能體完全不透明，只交付最終結果。同時保留靈活性。智能體身份這塊的差異非常的大。ANP協議本身會攜帶身份資訊、身份驗證資訊，目前主要是使用W3C的DID方案，一個智能體可以用自己的身份資訊，與其他所有的智能體進行互動，不必在其他智能體平台申請帳號。我們認為DID是最適合智能體的身份方案，特別是在網際網路場景下。當然也可擴展其他的身份認證方式。A2AA2A採用OpenAPI支援的認證方式，包括：HTTP 認證（如 Basic、Bearer）、API Key（可放在要求標頭、查詢參數或 Cookie）、Cookie 認證、OAuth 2.0 以及 OpenID Connect。A2A協議本身不攜帶身份資訊，只攜帶身份驗證資訊，身份驗證資訊在帶外獲得，即在A2A協議之外通過其他的手段獲得，比如通過Oauth。A2A的設計使其能夠充分利用企業現有的身份體系。但是，在智能體網際網路的場景中，如果要實現任意智能體之間的連接，A2A用起來會麻煩一些。MCPMCP使用Oauth做的身份驗證，也是一個中心化的方案，在連接工具和資源這個場景是適合的。智能體描述ANP與A2A比較類似，都是使用JSON。A2A的智能體描述文件命名為Agent Card，本質上是一個json文件。ANP的智能體描述則是基於JSON-LD和schema.org，這是語義網的技術，目的是提高兩個智能體對資訊理解的一致性。智能體發現MCP的發現規範還沒有看到，不過大機率用和ANP、A2A類似的發現機制。ANP和A2A都是基於RFC 8615做的，相當於在一個域名的.well-known目錄下增加一個中繼資料文件，A2A的檔案名稱是agent.json，ANP的檔案名稱是agent-descriptions。使用這個方案，都可以被搜尋引擎非常方便地抓取到。智能體資訊組織在智能體或者MCP server對外的資訊組織上，A2A和MCP都使用的是JSON-RPC，類似一種遠端呼叫技術。ANP在這裡比較獨特，ANP採用的是語義網的Linked-Data技術，目標是建構一個便於AI訪問和理解的AI原生資料網路。從這個角度看，ANP的技術路線更加靠近Web，我們認為未來的智能體網際網路是一個非常開放的網路，只有這樣才能夠讓資訊自由地流動，進而釋放AI的能力。開源licenseANP的license是MIT，Google-A2A的license是Apache 2.0。我仔細研究了一下，後面如果要推到大廠、參與標準化、走國際化路線，Apache 2.0 會是企業法律部門優先認可的協議。MIT 雖然簡單，但在你這種有專利潛在風險和商業化路徑的協議項目裡，容易被企業法律團隊卡住。開源許可上ANP會修改為Apache 2.0。趨勢雖然說A2A號稱與MCP是互補的，但是在閱讀文件的過程中，我隱約看到一個可能：工具Agent化，Agent工具化。現有的工具，是否可以進化成一個Agent？未來的Agent，是否也是一個工具？如果從這個角度看，MCP和A2A，包括ANP，應該會有一定的重疊。對行業智能體協議的影響MCP已經成為模型連接工具與資源的事實標準，A2A短期是難以撼動的。不過對於ANP是有很大的影響的。好的影響是，讓智能體通訊與協作被更多的人看到。之前MCP火的時候，我們去講ANP，很多人是不理解的。現在我們不用再強調智能體通訊協作的重要性了。壞的影響是，A2A和ANP有很大部分功能是重疊的，A2A背靠Google，影響力非常大，ANP主要靠開源社區，影響力無法比。這對ANP的發展是不利的。最後ANP最有價值的部分，其實是社區對未來智能體網際網路的設想，社區獨特的網際網路理念（連接即權力），以及DID+語義網的技術路線。 (長山的隨筆)

硬氪獲悉，近期，深圳銀雲資訊技術有限公司（簡稱“深圳銀雲”）推出的全球首個開源MCP交易平台—XPack.AI正式上線。截止目前，深圳銀雲已完成Pre-A輪、A輪融資，獲數千萬元融資，投資方為紅杉資本和國宏嘉信。公司創立於2017年。創始人劉昊臻具備10年API行業經驗，是Linux Tars基金會成員，團隊亦在API領域積累豐富的技術和行業經驗，陸續推出Eolink、XRoute.AI等產品。其中，Eolink已是國內最大的API全生命周期治理平台，服務了100多萬開發者使用者，管理的API數量達20億個，業務涵蓋API研發管理、自動化測試、閘道器資料打通等領域。2024年，全球API交易市值約180億美金，到2030年可能接近500億美金，但在Anthropic發佈MCP協議，OpenAI、微軟、阿里雲、騰訊雲紛紛跟進搭建MCP平台、上線服務後，局面發生了根本性變化，市場至少比API大100倍。“AI時代應該會有一個平台，將所有第三方資料、工具、服務轉換為卡片並通過AI Agent分發給全球使用者。”Eolink、XPack.AI創始人劉昊臻說。正是看到MCP這種統一連接範式的前景，今年劉昊臻迅速帶領團隊開發新產品，推出MCP服務交易平台XPack.AI。據瞭解，這是全球首個開放原始碼的MCP交易平台，它既可以為開發者找到目標使用者，實現獲益、獲客的良性循環，也能為AI Agent找到服務資料，有效解決目前MCP生態不繁榮、缺少利益動力的痛點。目前任何MCP、SaaS軟體和API的開發者，通過開源版本的XPack.AI，10分鐘內就能從0到1部署一個MCP交易平台，並且將自己已有的API一件轉換為MCP並定價銷售。XPack目前也推出了線上版本，任何人都可以免費註冊帳號，在30秒內建立並且銷售自己的MCP，還可以為設定自己的域名，將其變成一個獨立的MCP交易站。後續XPack還會提供一鍵將任何網站轉換為MCP的服務，幫助內容創作者將內容轉換為MCP並接入全球AI。服務推廣方面，使用者在開源版或線上版建立MCP站點後，獨立站會在XPack官網、社交媒體及MCP發佈管道公開展示，提高站點曝光。開發者不需要自己投流，平台後續會做大量的SEO、通過KOL傳播、投流廣告，幫使用者推廣。並且，每個站點相對獨立，可設定自己的域名、品牌、logo，不會出現XPack.AI相關資訊。XPack.AI會重點關注三類供應商：其一是垂直領域的SaaS公司，可以將SaaS的功能通過MCP接入AI，或者將SaaS產品內脫敏的資料提供給AI Agent完成更複雜的任務；二是即時資料來源，可提供金融、天氣、物料、媒體等即時資訊，彌補大模型即時資料獲取能力的不足；三是垂直工具型API，比如能提供專業設計、多模態生成、資料分析等細分領域服務，填補大模型在相關領域的能力短板。面對同大廠競爭的問題，劉昊臻認為，XPack.AI屬於中立平台，全球各種語言、地區的MCP都可以入駐，而大廠出於自身品牌、定位及戰略考量，採用的資料來源有限，且MCP服務更多是其售賣AI Agent或大模型的附屬，“MCP提供者也不會只把服務放在一個市場，我們中立同時，又能做全球化連結。”劉昊臻介紹，今年，公司目標是對接100家以上AI agent產品，擁有超10萬個第三方MCP獨立站，吸引供應商1w+，接入50+主流Agent應用。除了已有的API轉MCP，之後還會推進網站、內容轉MCP，豐富平台的SKU，建立完整的MCP服務生態。 (硬氪)

微軟正悄然醞釀一場作業系統革命！繼去年推出Copilot Plus PC和Windows AI功能後，這家科技巨頭近日宣佈將深度整合Model Context Protocol（MCP）協議，並推出全新Windows AI Foundry平台，目標直指打造“AI代理原生”的未來Windows系統。🚀 微軟的野心：讓Windows成為AI代理的“主戰場”“我們希望Windows進化成一個AI代理深度參與的系統，”微軟Windows部門負責人Pavan Davuluri在專訪中透露，“使用者將通過智能體與裝置持續互動，這將成為未來操作的核心模式。”這場變革的關鍵，正是被業界稱為“AI應用的USB-C介面”的MCP協議。Windows如何提供原生MCP支援 （圖源：微軟）這個由Anthropic提出的開源標準，如同USB-C統一了裝置介面，MCP將讓AI應用、服務與作業系統無縫連接。微軟的加入，意味著Windows將首次為AI智能體開放底層功能存取權。🔌 MCP是什麼？AI應用的“萬能介面”想像一下：▶️ 你的AI助手能直接呼叫Windows檔案系統，無需手動選擇資料夾▶️ 在Excel中通過自然語言查詢網頁資料，自動生成分析報表▶️ 跨應用協作：讓AI同時操作日曆、郵件和文件這正是MCP的魔力。微軟演示中，AI搜尋工具Perplexity通過MCP直接連接Windows檔案系統，使用者只需說“尋找我文件中所有度假相關檔案”，AI就能自動完成搜尋——就像給電腦裝上了“數字大腦”。🔒 安全挑戰：微軟的“三重防護網”開放介面也意味著風險。微軟安全副總裁David Weston坦言：“我們正把大語言模型視為‘不可信元件’。”為此，他們設計了三層防護：1.MCP登錄檔所有AI服務需通過安全認證才能接入系統2.動態權限管理每次AI呼叫功能時，使用者會收到類似“應用請求位置權限”的提示3.攻擊防禦機制防止令牌竊取、服務入侵和提示詞注入等新型攻擊“這有點像Windows Vista的UAC彈窗，但我們會找到安全與便利的平衡點，”Weston強調。微軟正與AMD、英特爾、輝達等晶片巨頭合作，確保從硬體到應用的全方位安全。🏭 Windows AI Foundry：開發者“智能工廠”伴隨MCP協議，微軟還推出了Windows AI Foundry平台，整合：✅ 本地化AI模型庫（Foundry Local）✅ 第三方模型市場（支援Ollama、NVIDIA NIM等）✅ 開發者工具鏈（Windows ML簡化部署流程）Windows AI Foundry 平台（圖源：微軟）開發者無需打包複雜執行階段環境，就能直接呼叫PC硬體的AI算力。這意味著未來我們可能看到：🎮 遊戲AI即時分析玩家習慣，自動調整難度💻 辦公軟體自動生成會議紀要+行動清單📊 設計軟體通過語音指令完成複雜操作🌍 作業系統的新戰場：從“人機互動”到“智能體協作”微軟的佈局預示著作業系統的新紀元：當AI代理能像人類一樣作業系統，PC將從“工具”進化為“合作夥伴”。這條路註定充滿挑戰——既要打破應用壁壘，又要防範安全風險，還要避免像UAC彈窗那樣幹擾使用者體驗。 (元透社)

五一快樂（最近很多朋友反應不能及時看到內容更新，只有關注並且⭐️才會第一時間收到更新）Anthropic 宣佈推出全新的功能：Claude 現在能夠與使用者的各種工具和應用進行無縫連接。這一功能名為 Integrations，通過該功能，Claude 能夠訪問並執行更多複雜任務，顯著提升其協作能力整合功能：無縫連接各種應用早在 2024 年 11 月，Anthropic 發佈了 模型上下文協議（Model Context Protocol，簡稱 MCP），這是一個開放標準，旨在將人工智慧應用與不同工具和資料來源進行連接。MCP已經火遍全網了，各大公司紛紛宣佈支援，但到目前為止，MCP 僅支援 Claude Desktop 通過本地伺服器工作，現在，隨著 Integrations 功能的推出，Claude 能夠通過 Web 和桌面應用與遠端 MCP 伺服器無縫協作這意味著，開發者可以建構和託管能夠增強 Claude 功能的伺服器，而使用者則可以通過整合任意數量的工具，進一步拓展 Claude 的能力通過這些整合，Claude 不僅能深刻理解你的工作內容，比如項目歷史、任務狀態以及組織知識，還能夠跨平台執行任務，成為一個更加智能的協作夥伴。在此基礎上，Claude 能夠幫助你在一個地方執行複雜的項目，提供專家級的協助目前，使用者可以選擇連接10個熱門服務，包括 Atlassian 的 Jira 和 Confluence、Zapier、Cloudflare、Intercom、Asana、Square、Sentry、PayPal、Linear 和 Plaid 等工具。未來，還將有更多來自 Stripe 和 GitLab 等公司的整合開發人員還可以使用官方文件或 Cloudflare 等提供內建 OAuth 身份驗證、傳輸處理和整合部署的解決方案，在短短 30 分鐘內建立自己的整合增強的研究能力：更深入的調研與報告除了整合功能外，Claude 的 研究能力（Research）也得到了極大的提升。通過這一新功能，Claude 能夠更深入地研究多個內外部資料來源，為使用者提供詳細且權威的報告。Claude 目前可以在 5 到 45 分鐘 內完成複雜的研究任務，而通常這些工作需要幾小時的人工調研在新的研究模式下，Claude 會將一個請求拆解成多個小部分進行深入研究，並在報告中明確標明來源，確保每一條資訊都有確鑿的出處，增強研究結果的可靠性。隨著 Integrations 功能的加入，Claude 不僅能夠訪問 web 搜尋和 Google Workspace，還可以通過連接任何應用來進一步拓展資料訪問能力。如何開始使用：適用於不同計畫目前，Integrations 和 高級研究 功能正在 Max、Team 和 Enterprise 計畫中測試，並將很快在 Pro 計畫中推出。同時，全球所有付費計畫的使用者現在都可以使用 Web 搜尋 功能。通過這些新功能，Claude 不僅成為了一個更強大的研究工具，還能在工作流中發揮更多作用，幫助使用者更高效地完成任務 (AI寒武紀)

開源大模型新王！Qwen3連發8種規格支援119種語言。阿里通義大模型新成員Qwen3系列模型終於亮相！智東西4月29日報導，今日凌晨4點，阿里雲正式開源Qwen3系列模型，包含2個MoE模型、6個稠密模型。發佈2小時，Qwen3模型在GitHub上的star數已超過16.9k。其中旗艦模型Qwen3-235B-A22B，在程式設計、數學、通用能力等基準評估中的表現優於DeepSeek-R1、OpenAI o1、OpenAI o3-mini、Grok-3和Gemini-2.5-Pro等業界知名模型。此次全新升級的Qwen3系列有以下5大關鍵特性：8種參數大小的稠密與MoE模型：0.6B、1.7B、4B、8B、14B、32B和Qwen3-235B-A22B（2350億總參數和220億啟動參數）、Qwen3-30B-A3B（300億總參數和30億啟動參數）；引入混合思考模式：使用者可切換“思考模式、“非思考模式”，自己控制思考程度；推理能力提升：在數學、程式碼生成和常識邏輯推理方面超越QwQ（在思考模式下）和Qwen2.5 instruct models（在非思考模式下）；支援MCP（模型上下文協議），Agent能力提升：可以在思考和非思考模式下實現大語言模型與外部資料來源和工具的整合，並完成複雜任務；支援119種語言和方言：具備多語言理解、推理、指令跟隨和生成能力。目前，Qwen3系列模型已在Hugging Face、ModelScope和Kaggle等平台上開源，均遵循Apache 2.0許可證。在部署方面，其部落格提到，建議開發者使用SGLang和vLLM等框架，並推薦本地部署的開發者使用Ollama、LMStudio、MLX、llama.cpp等工具。值得一提的是，Qwen3模型採用了不同的命名方案，後訓練模型不再使用“-Instruct”後綴，基礎模型的後綴是“-Base”。體驗地址：https://chat.qwen.ai/部落格地址：https://qwenlm.github.io/blog/qwen3/GitHub地址：https://github.com/QwenLM/Qwen3Hugging Face地址：https://huggingface.co/collections/Qwen/qwen3-67dd247413f0e2e4f653967f01.以小搏大！啟動參數僅1/10 實現性能反超6個稠密模型中，0.6B～4B參數規模的模型上下文長度為32K，8B～32B參數規模的模型上下文長度為128K。2個MoE模型的上下文長度均為128K。小型MoE模型Qwen3-30B-A3B，在啟動參數是QwQ-32B的1/10的情況下，實現了性能反超。且參數規模更小的Qwen3-4B模型，實現了與Qwen2.5-72B-Instruct的性能相當。其他基準測試評估結果顯示，Qwen3-1.7B/4B/8B/14B/32B-Base的性能分別與Qwen2.5-3B/7B/14B/32B/72B-Base相當。其部落格還特別提到，在STEM、程式設計和推理等領域，Qwen3稠密模型的性能甚至優於參數規模更大的Qwen2.5系列模型。▲Qwen3系列與Qwen2.5系列基準測試對比02. 引入混合思考模式支援119種語言、MCP協議Qwen3系列模型的關鍵特性包括引入混合思維模式、支援119種語言和方言、整合MCP協議以提升Agent能力。其中，混合思維模式指的是支援思考和非思考兩種模式。思考模式下，模型會逐步推理，花費時間給出最終答案，這適用於需要深入思考的複雜問題；非思考模式下，模型提供快速、幾乎瞬間的響應，適用於對響應速度敏感的問題。▲思考和非思考模式對比這使得使用者可以根據任務需求控制模型進行的“思考”程度。例如，對於更難的問題可以使用擴展推理來解決，而對於較簡單的問題則可以直接回答，無需延遲。此外，這兩種模式的整合還增強了模型實施穩定和高效思考預算控制的能力，這種設計使使用者能夠組態特定任務的預算，平衡實現成本效率和推理質量。在多語言方面，Qwen3模型支援119種語言和方言。此外，Qwen3系列模型在程式設計和Agent能力方面性能提升，整合了MCP協議。03. 預訓練資料集翻番 模型兼顧逐步推理、快速響應與Qwen2.5相比，Qwen3的預訓練資料集大小翻了兩倍。Qwen2.5在1800億個token上進行預訓練，Qwen3基於大約3600億個token進行預訓練。為了這一大型資料集，研發人員收集了網路資料、PDF文件資料等，然後使用Qwen2.5-VL從這些文件中提取文字，並使用Qwen2.5提高提取內容的質量。同時，為了增加數學和程式碼資料量，研發人員使用了Qwen2.5-Math和Qwen2.5-Coder來生成教科書、問答對和程式碼片段等合成資料。預訓練過程分為三個階段：在第一階段，模型在超過3000億個token上進行了預訓練，上下文長度為4K個token。這一階段為模型提供了基本語言技能和一般知識；在第二階段，其通過增加STEM、程式設計和推理任務等知識密集型資料的比例來改進資料集，並讓模型在額外的500億個token上進行預訓練；第三階段，研發人員使用高品質的長上下文資料將上下文長度擴展到32K個token，使得模型可以處理較長的輸入。在後訓練階段，為了開發既能逐步推理又能快速響應的混合模型，研發人員採取了四階段訓練流程：思維鏈（CoT）冷啟動、基於推理的強化學習、思維模式融合、通用強化學習。第一階段，其使用多樣化的長思維鏈資料微調模型，涵蓋各種任務和領域，如數學、程式設計、邏輯推理和STEM問題，這個過程旨在使模型具備基本的推理能力。第二階段專注於擴大強化學習的計算資源，利用基於規則的獎勵來增強模型的探索和利用能力。第三階段，通過在長思維鏈資料和常用指令微調資料組合上微調，將非思考能力整合到思考模型中。這些資料由第二階段增強的思考模型生成，確保推理能力和快速響應能力的無縫融合。第四階段，其將強化學習應用於超過20個通用領域任務，包括指令遵循、格式遵循和Agent能力等任務，以進一步增強模型的一般能力和糾正不良行為。04. 結語：Agent生態爆發前夜最佳化模型架構和訓練方法推進智能升級通過擴大預訓練和強化學習的規模，可以看到Qwen3系列模型以更小的參數規模實現了更高的智能水平，其整合的混合思考模式，使得開發者能更靈活控制模型預算。研發人員還提到，未來其將圍繞以下幾個維度繼續提升模型能力：最佳化模型架構和訓練方法，以實現擴展資料規模、增加模型大小、延長上下文長度、拓寬模態的目標，並通過環境反饋推進長期推理的強化學習。如今，AI產業正從關注模型訓練的時代過渡到一個以訓練Agent為中心的時代，未來大模型能力的實際應用價值將逐漸被放大，通義大模型系列也正以此為目標繼續推進升級。 (智東西)