議：破解智能體協(xié)作通信難題的鑰匙)
最近AI圈子討論最兇的除了模型參數(shù)和跑分就是智能體之間怎么“說話”的問題了。手機里的個人助手、電腦上的辦公助理、家里那個智能音箱單拎出來都能干活可一旦想讓它們接力完成一件事幾乎就是雞同鴨講。各個大廠都在做自己的智能體平臺互相之間卻沒有一套統(tǒng)一的溝通語言。這個節(jié)骨眼上某頭部科技平臺放出的PAPPerson Agent Protocol個人智能體協(xié)議資料被很多人視為破局的關(guān)鍵一步。我花了兩周時間把現(xiàn)有資料啃了一遍又用模擬項目實際跑了一版這篇就把協(xié)議的核心設(shè)計、消息流轉(zhuǎn)、權(quán)限模型和落地時容易踩的坑一次講透。不管是做智能體應(yīng)用、研究Agent間通信機制還是單純想搞清楚下一代個人助理長什么樣都值得往下看。1. PAP協(xié)議到底在解決什么問題個人智能體的“方言困境”1.1 智能體數(shù)量爆發(fā)之后最先崩的是“協(xié)作”兩三年前我們談AI助手說的多數(shù)還是單個聊天窗口?，F(xiàn)在不一樣了購物助手、日程助手、健康管理助手、代碼助手……每個人身邊都開始圍繞不同的場景聚集起一批智能體。它們的底層模型可能來自不同廠商數(shù)據(jù)存在不同服務(wù)端權(quán)限體系也完全不同。問題也隨之而來用戶需要在每個智能體里重復(fù)交代自己的偏好、習慣和身份信息。上個月跟購物助手說過“鞋碼43、偏愛深色系”這個月?lián)Q了辦公助手它又得重新問一遍。更麻煩的是跨智能體任務(wù)——讓助手A幫我整理差旅發(fā)票再讓助手B根據(jù)發(fā)票生成報銷單這兩個動作目前基本要靠人肉搬運數(shù)據(jù)。PAP要解決的正是這個層面的問題它定義了一套智能體與智能體之間、以及人與智能體之間的對話和協(xié)作規(guī)范。有點像給所有只會講方言的智能體統(tǒng)一了一份普通話手冊。協(xié)議不關(guān)心你的模型是哪個、跑在什么框架上只關(guān)心你怎么描述身份、怎么聲明能力、怎么傳遞會話狀態(tài)。1.2 現(xiàn)有交互方式為什么撐不起“多智能體協(xié)作”有人可能會問現(xiàn)在很多智能體不也能調(diào)用工具、能執(zhí)行任務(wù)嗎確實能但細看會發(fā)現(xiàn)都是“局域本地”的玩法。第一種是單個智能體內(nèi)部的工具調(diào)用Function Calling。這類方案把函數(shù)定義塞給模型模型按需觸發(fā)本質(zhì)上是在一個進程內(nèi)做函數(shù)路由跨設(shè)備、跨廠商根本不適用。第二種是各廠商自研的Agent通信接口。功能上該有的都有但字段語義、認證方式、錯誤碼完全各寫各的。A廠商的“目標”字段可能叫targetB廠商叫recipient對接一次光對齊字段就要花掉一周。第三種更常見干脆不開放接口所有協(xié)作都靠用戶手動復(fù)制粘貼結(jié)果。比如把聊天記錄里的會議紀要復(fù)制到待辦應(yīng)用里讓待辦助手自己再解析一遍。費時不說信息在傳遞過程中還會丟。PAP的核心思路是把智能體之間的通信抽象成一套穩(wěn)定的“信封內(nèi)容”結(jié)構(gòu)。信封負責身份、路由、會話、權(quán)限這些通用的東西內(nèi)容則是各家自己定義的任務(wù)載荷。這樣一來通用部分可以標準化特定能力又保留了個性化的空間。2. 協(xié)議的三根支柱身份、會話、能力發(fā)現(xiàn)2.1 個人數(shù)字身份不是賬號ID是授權(quán)過的“臨時身份”PAP里最先打動我的是它對人這個維度的建模?，F(xiàn)在市面上多數(shù)接口認證的都是“設(shè)備”或“賬號”PAP則引入了一個叫Person Identity的概念。它不是固定的用戶賬號而是用戶在某次授權(quán)范圍內(nèi)生成的一個臨時身份表示?？匆粋€簡化后的協(xié)議頭就明白了{ protocolVersion: 0.9.3, person: { personId: p_8f3a2c91, displayName: 匿名用戶, profile: { locale: zh-CN, timezone: Asia/Shanghai, preferences: { theme: dark, replyStyle: concise } }, credential: { type: bearer, token: eyJhbGciOi..., expiresAt: 2026-03-01T12:00:00Z } } }這里有幾個設(shè)計得很克制的地方personId不是明文手機號或郵箱而是一個匿名化之后仍能穩(wěn)定關(guān)聯(lián)的標識符防止平臺間互相串數(shù)據(jù)。profile是可選字段用戶不想給完全可以不給。credential是短期憑證過期即失效避免一個token滿天飛導(dǎo)致泄露后永久有效。我在模擬項目里實際感受是身份層這樣設(shè)計之后整個協(xié)議的安全基座穩(wěn)了很多。后面所有權(quán)限判斷都是基于這個臨時身份做的而不是基于底層賬號這讓跨平臺調(diào)用時的責任邊界清晰了不少。2.2 會話狀態(tài)傳“狀態(tài)”而不是傳“聊天記錄”智能體和智能體協(xié)作時最容易犯的錯是試圖把整個對話上下文丟給對方。像“用戶剛才說了要訂明天下午的火車票特別強調(diào)了靠窗……”這種原始文本傳給下游智能體之后對方還得自己理解一遍既浪費token又容易理解偏。PAP的做法是把上下文分成三層每層都有明確的生命周期上下文層級生命周期典型內(nèi)容傳遞范圍全局上下文跨會話長期存在用戶長期偏好、基礎(chǔ)身份信息僅在用戶授權(quán)時隨身份傳遞會話上下文單次協(xié)作任務(wù)全過程任務(wù)目標、已確認條件、待決策項跟隨sessionId在所有參與智能體間共享步驟上下文單個調(diào)用請求本次調(diào)用的輸入?yún)?shù)、臨時結(jié)果只存在于單次request/response中這個分層設(shè)計最大的好處是讓智能體之間傳遞的不再是“一句話”而是“一個狀態(tài)”。舉個例子主助手把任務(wù)交給發(fā)票識別助手時傳過去的不是用戶啰嗦了半天的那段語音轉(zhuǎn)文字而是一個結(jié)構(gòu)化的任務(wù)描述{ taskGoal: 提取2026年2月差旅發(fā)票中的金額與發(fā)票號, confirmedConditions: { timeRange: 2026-02-01~2026-02-28, includeType: [train, hotel] }, pendingDecisions: [], completedSteps: [pdf_download, files_num12] }下游智能體拿到這份狀態(tài)不需要猜用戶到底想干嘛直接在結(jié)構(gòu)上做增量就好。實測下來這種結(jié)構(gòu)化狀態(tài)比直接傳聊天記錄至少省掉一半的無效解析時間。2.3 能力發(fā)現(xiàn)每個Agent都有一份“菜單”PAP里每個智能體需要發(fā)布一份能力清單協(xié)議里叫Capability Manifest。這東西就像一個餐廳的菜單標明了每個菜是什么、什么價格、做多久、需不需要額外確認。{ agentId: agent_office_001, agentName: 辦公助手, capabilities: [ { action: invoice.ocr_extract, inputSchema: { type: object, properties: { fileUrls: {type: array, items: {type: string}} }, required: [fileUrls] }, outputSchema: { type: object, properties: { invoiceCount: {type: integer}, totalAmount: {type: number} } }, permissionLevel: user_consent, estimatedMs: 2000 } ] }能力清單的意義在于讓“我的智能體到底能干什么”這件事變得可查詢、可發(fā)現(xiàn)、可校驗。主智能體在跨平臺調(diào)用之前可以先去發(fā)現(xiàn)服務(wù)拉取目標智能體的Manifest比對一下對方是否支持自己需要的action避免了調(diào)用到一半才發(fā)現(xiàn)對面沒這個功能的尷尬。實際做模擬項目時我還在Manifest里加了兩個自定義字段rateLimit和offlineSupport。有這兩個字段之后路由邏輯可以提前避開那些當前負載很高、或者已經(jīng)進入離線維護狀態(tài)的智能體調(diào)度體驗一下子順了很多。3. 一次跨智能體調(diào)用是怎么跑通的消息格式與時序拆解3.1 消息信封為什么每個字段都不能省協(xié)議的消息結(jié)構(gòu)是典型的“信封載荷”設(shè)計。信封是通用的載荷是業(yè)務(wù)自定義的。一個典型的請求消息長這樣{ protocolVersion: 0.9.3, messageId: msg_1a2b3c4d, type: agent.request, sender: agent_main_001, receiver: agent_office_001, sessionId: sess_9f8e7d6c, timestamp: 2026-03-01T03:21:00Z, payload: { action: invoice.ocr_extract, input: { fileUrls: [https://example.com/invoices/202602.zip] }, scope: read:invoice } }幾個容易被忽略但特別重要的字段messageId每條消息的唯一ID作用是冪等。接收方如果重復(fù)收到同一個messageId直接丟棄或者返回上次的結(jié)果不會執(zhí)行兩遍。sender/receiver邏輯地址而不是物理地址解耦部署位置。sessionId串起整個多輪協(xié)作任務(wù)。scope聲明這次調(diào)用需要的最小權(quán)限范圍。3.2 完整調(diào)用鏈路從任務(wù)下發(fā)到結(jié)果回收我用自己的模擬項目跑通了整個鏈路大致分為六步步驟動作關(guān)鍵協(xié)議內(nèi)容1主智能體查詢辦公助手的能力清單請求能力發(fā)現(xiàn)服務(wù)匹配invoice.ocr_extract2主智能體創(chuàng)建協(xié)作會話生成sessionId初始化結(jié)構(gòu)化任務(wù)狀態(tài)3主智能體下發(fā)任務(wù)請求通過標準消息信封發(fā)送agent.request4辦公助手請求用戶確認返回consentRequiredtrue攜帶確認回調(diào)地址5用戶確認授權(quán)辦公助手訪問發(fā)票文件通過統(tǒng)一授權(quán)界面審批一次性授權(quán)6辦公助手執(zhí)行識別并回傳結(jié)果返回agent.response更新會話狀態(tài)我當時用Python寫了個簡化版的調(diào)度核心核心邏輯大概是這樣async def dispatch(request, registry): target registry.resolve(request[receiver]) action request[payload][action] if not target.capable(action): return build_error(request, CAPABILITY_NOT_FOUND) if request[payload].get(consentRequired): confirmed await request_consent( session_idrequest[sessionId], scoperequest[payload].get(scope), actionaction ) if not confirmed: return build_error(request, PERMISSION_DENIED) response await target.invoke(request) return response這段代碼雖然很粗糙但已經(jīng)覆蓋了協(xié)議里最核心的三個機制能力校驗、動態(tài)授權(quán)、任務(wù)分發(fā)。真實場景里還會多很多細節(jié)比如超時、重試、消息確認但骨架就是這樣。3.3 錯誤處理與重試不能一言不合就報錯協(xié)議里定義了一套規(guī)范的錯誤碼我抽了幾個最常見的整理成表格錯誤碼名稱含義推薦處理4001PERMISSION_DENIED缺少授權(quán)檢查scope是否足夠引導(dǎo)用戶授權(quán)4002CAPABILITY_NOT_FOUND目標智能體不支持該能力查詢目標Manifest并選擇替代方案4003CONTEXT_LIMIT_EXCEEDED會話上下文超限觸發(fā)上下文壓縮或開啟新一輪會話4091CONFLICT_DUPLICATE_MESSAGE重復(fù)消息忽略或返回上次結(jié)果5001INTERNAL_ERROR目標智能體內(nèi)部出錯按指數(shù)退避策略重試這里最容易踩的坑是重試。如果目標智能體已經(jīng)處理完但響應(yīng)包丟了盲目重發(fā)會造成重復(fù)執(zhí)行。所以我后來在模擬項目里加了一個基于messageId的去重表重發(fā)時帶上相同的messageId接收方識別后直接返回緩存的結(jié)果。這樣重試才真正安全。4. 權(quán)限與隱私設(shè)計容易被低估的協(xié)議半壁江山4.1 最小權(quán)限原則scope不是擺設(shè)PAP的權(quán)限模型是我認為整個協(xié)議里含金量最高的部分。它嚴格遵循最小權(quán)限原則主智能體在調(diào)用子智能體時必須在請求里明確聲明本次調(diào)用的scope比如read:invoice、write:calendar。這些scope會被授權(quán)服務(wù)做二次校驗。即使主智能體貼了一個比較大的scope授權(quán)服務(wù)也會把實際可執(zhí)行的操作限制在智能體本身已被授予的范圍之內(nèi)。也就是說主智能體不能通過調(diào)用來“放大”自己的權(quán)限scope只能縮小、不能放大。我用一個生活化的類比來理解這個機制你手里有一張門禁卡能開辦公區(qū)的所有門但你把臨時卡發(fā)給訪客時可以只給電梯層和會議室的權(quán)限。協(xié)議保證你在發(fā)臨時卡的時候沒法把“機房權(quán)限”一并塞給對方。4.2 敏感操作強制二次確認human-in-the-loop協(xié)議里專門為支付、發(fā)送消息、修改數(shù)據(jù)這類敏感操作設(shè)計了human-in-the-loop機制。關(guān)鍵字段是consentRequired一旦置true下游智能體不能直接執(zhí)行必須先返回一個確認請求給用戶設(shè)備。我一開始覺得這有點多此一舉直到模擬了“主智能體自動讓辦公助手把報銷單發(fā)給財務(wù)部門”的場景才意識到必要性。如果沒有二次確認用戶的一道口頭指令可能會順著智能體鏈條自動執(zhí)行下去中間任何一環(huán)理解偏差都可能導(dǎo)致敏感數(shù)據(jù)發(fā)錯地方。協(xié)議的妙處在于它不需要把用戶的密碼或者支付憑證傳給任何一個智能體。用戶確認動作發(fā)生在統(tǒng)一授權(quán)界面里確認之后平臺頒發(fā)的是一次性授權(quán)憑證授權(quán)范圍精確到單次操作。這樣即使下游智能體是惡意的也拿不到能反復(fù)使用的長期憑證。4.3 審計日志與可撤銷憑證給每筆調(diào)用留下痕跡每次跨智能體調(diào)用都會被記錄到一份除了用戶本人其他方無法篡改的授權(quán)日志里內(nèi)容包括誰調(diào)的誰、用了什么scope、在什么時間、執(zhí)行了什么action。用戶可以在授權(quán)中心隨時查看這些記錄就像銀行賬單一樣每一筆都清清楚楚。一旦發(fā)現(xiàn)可疑調(diào)用用戶可以直接撤銷某個智能體的全部授權(quán)。撤銷生效后該智能體在后續(xù)所有請求中都會直接收到4001已撤銷授權(quán)的提示。我自己的體驗是可撤銷憑證比密碼輪換高效得多——密碼輪換需要你找到所有使用場景逐一更換撤銷憑證只要在授權(quán)中心一鍵操作所有下游調(diào)用立刻失效。5. 落地過程中的三個大坑來自模擬項目的排錯記錄5.1 版本協(xié)商老智能體收到新字段直接翻臉協(xié)議剛出來的時候我默認所有智能體都跑同一個版本結(jié)果在模擬環(huán)境里接第一個“老設(shè)備”時就翻車了。對方實現(xiàn)的是0.8版協(xié)議不認識0.9.3版的contextCompaction字段收到消息后雖然沒報錯卻把新字段靜默丟掉了。這比直接報錯還麻煩——報錯你能知道哪里不對靜默丟棄導(dǎo)致的是數(shù)據(jù)錯位我以為對方收到了壓縮后的摘要實際上對方拿到的是截斷后的半截消息返回的結(jié)果自然牛頭不對馬嘴。后來我加了一套版本協(xié)商機制請求發(fā)出之前先發(fā)一條agent.discover消息探對方的協(xié)議版本和特性支持列表協(xié)商出一個雙方都支持的公共特性集再進行實際調(diào)用。整個過程有點像兩個人見面先確定“你用微信還是用短信”再開始談?wù)?。def negotiate_features(caller_supported: set, callee_supported: set): common caller_supported callee_supported if contextCompaction not in common: # 回退到原始上下文傳輸 use_context_compaction False return common5.2 上下文膨脹結(jié)構(gòu)化傳輸也會撐爆PAP不傳聊天原文傳的是結(jié)構(gòu)化狀態(tài)但這并不意味著不會膨脹。模擬到第20輪協(xié)作時會話上下文文件已經(jīng)接近4MB每次同步都明顯變慢。我的解決辦法是給每一個會話設(shè)置token預(yù)算超過85%時自動觸發(fā)壓縮策略。壓縮策略分兩步先把超過優(yōu)先級的細節(jié)片段折疊成摘要比如把“第3號發(fā)票金額128.5元、含稅、抵扣聯(lián)完好”壓成“詳情見附件緩存”如果還超就把最早完成的步驟上下文歸檔只保留任務(wù)目標、當前階段、以及最近兩輪的增量狀態(tài)。一個經(jīng)驗值可以分享會話上下文里真正核心的字段通常只占30%左右其余都是可以安全的歸檔或壓縮的內(nèi)容。我給會話設(shè)了128KB的軟上限實測在多數(shù)任務(wù)中都不會觸發(fā)壓縮但到了長鏈路任務(wù)里這套機制救了我好幾次。5.3 智能體循環(huán)調(diào)用兩個Agent互相等把任務(wù)活活拖死這是我模擬“主智能體嘗試調(diào)用辦公助手整理發(fā)票辦公助手反過來想請求主智能體提供歷史報銷記錄”時遇到的。兩個智能體互相發(fā)起請求各自都在等對方先返回形成典型的循環(huán)等待任務(wù)直接死鎖。排查鏈路比較痛苦日志顯示兩邊都在正常收發(fā)消息看起來毫無異常。后來我在每個消息上加了調(diào)用鏈IDtraceId和調(diào)用深度計數(shù)器打日志才發(fā)現(xiàn)調(diào)用棧已經(jīng)嵌套了五十多層從A到B再到A再到B無限套娃。最后的解法是三層防線單次任務(wù)設(shè)置最大調(diào)用深度超過10層直接拒絕繼續(xù)轉(zhuǎn)發(fā)調(diào)用鏈上如果檢測到traceId重復(fù)出現(xiàn)判定為循環(huán)立即終止并返回錯誤;每個調(diào)用請求附帶TTL超過時間自動失效防止任務(wù)掛死。這三層加完模擬環(huán)境才真正穩(wěn)定下來。后來我在思考為什么協(xié)議文檔里沒強調(diào)這些大概率是因為這類問題只有在真實異構(gòu)環(huán)境里才會暴露純設(shè)計階段很難預(yù)料。6. 這類協(xié)議的走向與我的幾點體會6.1 跟現(xiàn)有生態(tài)銜接的想象空間PAP這類協(xié)議真正有價值的地方在于它讓“設(shè)備廠商的助手”和“第三方開發(fā)者做的小智能體”處于同一套對話規(guī)則之下。短期內(nèi)最可能出現(xiàn)的場景是系統(tǒng)級助手通過協(xié)議去調(diào)用那些經(jīng)過認證的垂直領(lǐng)域智能體比如調(diào)用專業(yè)的法務(wù)助手、醫(yī)療咨詢助手。這并不是說要把所有助手合并成一個巨型應(yīng)用恰恰相反協(xié)議存在的意義是讓不同場景的智能體保持小而專同時通過標準化接口組合起來完成復(fù)雜任務(wù)。用戶不需要在十個App之間跳轉(zhuǎn)主助手會負責拆解任務(wù)、分派給合適的子助手、再匯總結(jié)果。6.2 標準化之爭協(xié)議多了等于沒有協(xié)議現(xiàn)在行業(yè)里的Agent通信協(xié)議已經(jīng)不是一兩個了各家都有自己的一套草案。PAP的挑戰(zhàn)在于它能不能成為大家愿意共同維護的標準。歷史上很多好協(xié)議最終沒能普及不是技術(shù)不行而是生態(tài)推進跟不上。我的判斷是決定這類協(xié)議命運的往往不是技術(shù)細節(jié)而是三件事第一有沒有足夠多的頭部玩家愿意開放自己的智能體接入第二授權(quán)與隱私模型能不能讓用戶真正感到可控第三開發(fā)者接入的成本夠不夠低——如果對接PAP比自研一套還麻煩那沒人會用。6.3 我做模擬項目期間的一點個人經(jīng)驗最后分享一個我自己體會很深的小技巧。不管以后哪種個人智能體協(xié)議勝出你如果現(xiàn)在就在做Agent相關(guān)開發(fā)都可以先把“消息冪等”和“能力發(fā)現(xiàn)”這兩件事做好。它們是最高頻的通用需求而且?guī)缀醪灰蕾嚲唧w協(xié)議版本。把這兩個抽象層先寫穩(wěn)后面無論接入哪家協(xié)議都只需要寫一個適配器不用改動核心業(yè)務(wù)邏輯。還有一點協(xié)議設(shè)計最忌貪多。PAP目前這套能讓人記住的核心概念本質(zhì)上也就三個身份、會話、能力。把這三點做扎實權(quán)限、審計、錯誤處理這些周邊的細節(jié)自然能順理成章地長出來。凡是那種想把所有智能體功能全都塞進協(xié)議里的規(guī)范大概率會死在復(fù)雜度上。我在模擬項目里壓測到兩百多次跨智能體調(diào)用之后最強烈的感受是個人智能體的未來不在單個模型有多強而在于多少個智能體能像一支配合默契的團隊一樣為了同一個用戶目標協(xié)作。PAP這類協(xié)議就是這支團隊的第一版溝通手冊。雖然現(xiàn)在它還遠不算完美但我相信方向是對的。 PAP個人智能體協(xié)議：破解智能體協(xié)作通信難題的鑰匙
最近AI圈子討論最兇的除了模型參數(shù)和跑分就是智能體之間怎么“說話”的問題了。手機里的個人助手、電腦上的辦公助理、家里那個智能音箱單拎出來都能干活可一旦想讓它們接力完成一件事幾乎就是雞同鴨講。各個大廠都在做自己的智能體平臺互相之間卻沒有一套統(tǒng)一的溝通語言。這個節(jié)骨眼上某頭部科技平臺放出的PAPPerson Agent Protocol個人智能體協(xié)議資料被很多人視為破局的關(guān)鍵一步。我花了兩周時間把現(xiàn)有資料啃了一遍又用模擬項目實際跑了一版這篇就把協(xié)議的核心設(shè)計、消息流轉(zhuǎn)、權(quán)限模型和落地時容易踩的坑一次講透。不管是做智能體應(yīng)用、研究Agent間通信機制還是單純想搞清楚下一代個人助理長什么樣都值得往下看。1. PAP協(xié)議到底在解決什么問題個人智能體的“方言困境”1.1 智能體數(shù)量爆發(fā)之后最先崩的是“協(xié)作”兩三年前我們談AI助手說的多數(shù)還是單個聊天窗口?，F(xiàn)在不一樣了購物助手、日程助手、健康管理助手、代碼助手……每個人身邊都開始圍繞不同的場景聚集起一批智能體。它們的底層模型可能來自不同廠商數(shù)據(jù)存在不同服務(wù)端權(quán)限體系也完全不同。問題也隨之而來用戶需要在每個智能體里重復(fù)交代自己的偏好、習慣和身份信息。上個月跟購物助手說過“鞋碼43、偏愛深色系”這個月?lián)Q了辦公助手它又得重新問一遍。更麻煩的是跨智能體任務(wù)——讓助手A幫我整理差旅發(fā)票再讓助手B根據(jù)發(fā)票生成報銷單這兩個動作目前基本要靠人肉搬運數(shù)據(jù)。PAP要解決的正是這個層面的問題它定義了一套智能體與智能體之間、以及人與智能體之間的對話和協(xié)作規(guī)范。有點像給所有只會講方言的智能體統(tǒng)一了一份普通話手冊。協(xié)議不關(guān)心你的模型是哪個、跑在什么框架上只關(guān)心你怎么描述身份、怎么聲明能力、怎么傳遞會話狀態(tài)。1.2 現(xiàn)有交互方式為什么撐不起“多智能體協(xié)作”有人可能會問現(xiàn)在很多智能體不也能調(diào)用工具、能執(zhí)行任務(wù)嗎確實能但細看會發(fā)現(xiàn)都是“局域本地”的玩法。第一種是單個智能體內(nèi)部的工具調(diào)用Function Calling。這類方案把函數(shù)定義塞給模型模型按需觸發(fā)本質(zhì)上是在一個進程內(nèi)做函數(shù)路由跨設(shè)備、跨廠商根本不適用。第二種是各廠商自研的Agent通信接口。功能上該有的都有但字段語義、認證方式、錯誤碼完全各寫各的。A廠商的“目標”字段可能叫targetB廠商叫recipient對接一次光對齊字段就要花掉一周。第三種更常見干脆不開放接口所有協(xié)作都靠用戶手動復(fù)制粘貼結(jié)果。比如把聊天記錄里的會議紀要復(fù)制到待辦應(yīng)用里讓待辦助手自己再解析一遍。費時不說信息在傳遞過程中還會丟。PAP的核心思路是把智能體之間的通信抽象成一套穩(wěn)定的“信封內(nèi)容”結(jié)構(gòu)。信封負責身份、路由、會話、權(quán)限這些通用的東西內(nèi)容則是各家自己定義的任務(wù)載荷。這樣一來通用部分可以標準化特定能力又保留了個性化的空間。2. 協(xié)議的三根支柱身份、會話、能力發(fā)現(xiàn)2.1 個人數(shù)字身份不是賬號ID是授權(quán)過的“臨時身份”PAP里最先打動我的是它對人這個維度的建模?，F(xiàn)在市面上多數(shù)接口認證的都是“設(shè)備”或“賬號”PAP則引入了一個叫Person Identity的概念。它不是固定的用戶賬號而是用戶在某次授權(quán)范圍內(nèi)生成的一個臨時身份表示?？匆粋€簡化后的協(xié)議頭就明白了{ protocolVersion: 0.9.3, person: { personId: p_8f3a2c91, displayName: 匿名用戶, profile: { locale: zh-CN, timezone: Asia/Shanghai, preferences: { theme: dark, replyStyle: concise } }, credential: { type: bearer, token: eyJhbGciOi..., expiresAt: 2026-03-01T12:00:00Z } } }這里有幾個設(shè)計得很克制的地方personId不是明文手機號或郵箱而是一個匿名化之后仍能穩(wěn)定關(guān)聯(lián)的標識符防止平臺間互相串數(shù)據(jù)。profile是可選字段用戶不想給完全可以不給。credential是短期憑證過期即失效避免一個token滿天飛導(dǎo)致泄露后永久有效。我在模擬項目里實際感受是身份層這樣設(shè)計之后整個協(xié)議的安全基座穩(wěn)了很多。后面所有權(quán)限判斷都是基于這個臨時身份做的而不是基于底層賬號這讓跨平臺調(diào)用時的責任邊界清晰了不少。2.2 會話狀態(tài)傳“狀態(tài)”而不是傳“聊天記錄”智能體和智能體協(xié)作時最容易犯的錯是試圖把整個對話上下文丟給對方。像“用戶剛才說了要訂明天下午的火車票特別強調(diào)了靠窗……”這種原始文本傳給下游智能體之后對方還得自己理解一遍既浪費token又容易理解偏。PAP的做法是把上下文分成三層每層都有明確的生命周期上下文層級生命周期典型內(nèi)容傳遞范圍全局上下文跨會話長期存在用戶長期偏好、基礎(chǔ)身份信息僅在用戶授權(quán)時隨身份傳遞會話上下文單次協(xié)作任務(wù)全過程任務(wù)目標、已確認條件、待決策項跟隨sessionId在所有參與智能體間共享步驟上下文單個調(diào)用請求本次調(diào)用的輸入?yún)?shù)、臨時結(jié)果只存在于單次request/response中這個分層設(shè)計最大的好處是讓智能體之間傳遞的不再是“一句話”而是“一個狀態(tài)”。舉個例子主助手把任務(wù)交給發(fā)票識別助手時傳過去的不是用戶啰嗦了半天的那段語音轉(zhuǎn)文字而是一個結(jié)構(gòu)化的任務(wù)描述{ taskGoal: 提取2026年2月差旅發(fā)票中的金額與發(fā)票號, confirmedConditions: { timeRange: 2026-02-01~2026-02-28, includeType: [train, hotel] }, pendingDecisions: [], completedSteps: [pdf_download, files_num12] }下游智能體拿到這份狀態(tài)不需要猜用戶到底想干嘛直接在結(jié)構(gòu)上做增量就好。實測下來這種結(jié)構(gòu)化狀態(tài)比直接傳聊天記錄至少省掉一半的無效解析時間。2.3 能力發(fā)現(xiàn)每個Agent都有一份“菜單”PAP里每個智能體需要發(fā)布一份能力清單協(xié)議里叫Capability Manifest。這東西就像一個餐廳的菜單標明了每個菜是什么、什么價格、做多久、需不需要額外確認。{ agentId: agent_office_001, agentName: 辦公助手, capabilities: [ { action: invoice.ocr_extract, inputSchema: { type: object, properties: { fileUrls: {type: array, items: {type: string}} }, required: [fileUrls] }, outputSchema: { type: object, properties: { invoiceCount: {type: integer}, totalAmount: {type: number} } }, permissionLevel: user_consent, estimatedMs: 2000 } ] }能力清單的意義在于讓“我的智能體到底能干什么”這件事變得可查詢、可發(fā)現(xiàn)、可校驗。主智能體在跨平臺調(diào)用之前可以先去發(fā)現(xiàn)服務(wù)拉取目標智能體的Manifest比對一下對方是否支持自己需要的action避免了調(diào)用到一半才發(fā)現(xiàn)對面沒這個功能的尷尬。實際做模擬項目時我還在Manifest里加了兩個自定義字段rateLimit和offlineSupport。有這兩個字段之后路由邏輯可以提前避開那些當前負載很高、或者已經(jīng)進入離線維護狀態(tài)的智能體調(diào)度體驗一下子順了很多。3. 一次跨智能體調(diào)用是怎么跑通的消息格式與時序拆解3.1 消息信封為什么每個字段都不能省協(xié)議的消息結(jié)構(gòu)是典型的“信封載荷”設(shè)計。信封是通用的載荷是業(yè)務(wù)自定義的。一個典型的請求消息長這樣{ protocolVersion: 0.9.3, messageId: msg_1a2b3c4d, type: agent.request, sender: agent_main_001, receiver: agent_office_001, sessionId: sess_9f8e7d6c, timestamp: 2026-03-01T03:21:00Z, payload: { action: invoice.ocr_extract, input: { fileUrls: [https://example.com/invoices/202602.zip] }, scope: read:invoice } }幾個容易被忽略但特別重要的字段messageId每條消息的唯一ID作用是冪等。接收方如果重復(fù)收到同一個messageId直接丟棄或者返回上次的結(jié)果不會執(zhí)行兩遍。sender/receiver邏輯地址而不是物理地址解耦部署位置。sessionId串起整個多輪協(xié)作任務(wù)。scope聲明這次調(diào)用需要的最小權(quán)限范圍。3.2 完整調(diào)用鏈路從任務(wù)下發(fā)到結(jié)果回收我用自己的模擬項目跑通了整個鏈路大致分為六步步驟動作關(guān)鍵協(xié)議內(nèi)容1主智能體查詢辦公助手的能力清單請求能力發(fā)現(xiàn)服務(wù)匹配invoice.ocr_extract2主智能體創(chuàng)建協(xié)作會話生成sessionId初始化結(jié)構(gòu)化任務(wù)狀態(tài)3主智能體下發(fā)任務(wù)請求通過標準消息信封發(fā)送agent.request4辦公助手請求用戶確認返回consentRequiredtrue攜帶確認回調(diào)地址5用戶確認授權(quán)辦公助手訪問發(fā)票文件通過統(tǒng)一授權(quán)界面審批一次性授權(quán)6辦公助手執(zhí)行識別并回傳結(jié)果返回agent.response更新會話狀態(tài)我當時用Python寫了個簡化版的調(diào)度核心核心邏輯大概是這樣async def dispatch(request, registry): target registry.resolve(request[receiver]) action request[payload][action] if not target.capable(action): return build_error(request, CAPABILITY_NOT_FOUND) if request[payload].get(consentRequired): confirmed await request_consent( session_idrequest[sessionId], scoperequest[payload].get(scope), actionaction ) if not confirmed: return build_error(request, PERMISSION_DENIED) response await target.invoke(request) return response這段代碼雖然很粗糙但已經(jīng)覆蓋了協(xié)議里最核心的三個機制能力校驗、動態(tài)授權(quán)、任務(wù)分發(fā)。真實場景里還會多很多細節(jié)比如超時、重試、消息確認但骨架就是這樣。3.3 錯誤處理與重試不能一言不合就報錯協(xié)議里定義了一套規(guī)范的錯誤碼我抽了幾個最常見的整理成表格錯誤碼名稱含義推薦處理4001PERMISSION_DENIED缺少授權(quán)檢查scope是否足夠引導(dǎo)用戶授權(quán)4002CAPABILITY_NOT_FOUND目標智能體不支持該能力查詢目標Manifest并選擇替代方案4003CONTEXT_LIMIT_EXCEEDED會話上下文超限觸發(fā)上下文壓縮或開啟新一輪會話4091CONFLICT_DUPLICATE_MESSAGE重復(fù)消息忽略或返回上次結(jié)果5001INTERNAL_ERROR目標智能體內(nèi)部出錯按指數(shù)退避策略重試這里最容易踩的坑是重試。如果目標智能體已經(jīng)處理完但響應(yīng)包丟了盲目重發(fā)會造成重復(fù)執(zhí)行。所以我后來在模擬項目里加了一個基于messageId的去重表重發(fā)時帶上相同的messageId接收方識別后直接返回緩存的結(jié)果。這樣重試才真正安全。4. 權(quán)限與隱私設(shè)計容易被低估的協(xié)議半壁江山4.1 最小權(quán)限原則scope不是擺設(shè)PAP的權(quán)限模型是我認為整個協(xié)議里含金量最高的部分。它嚴格遵循最小權(quán)限原則主智能體在調(diào)用子智能體時必須在請求里明確聲明本次調(diào)用的scope比如read:invoice、write:calendar。這些scope會被授權(quán)服務(wù)做二次校驗。即使主智能體貼了一個比較大的scope授權(quán)服務(wù)也會把實際可執(zhí)行的操作限制在智能體本身已被授予的范圍之內(nèi)。也就是說主智能體不能通過調(diào)用來“放大”自己的權(quán)限scope只能縮小、不能放大。我用一個生活化的類比來理解這個機制你手里有一張門禁卡能開辦公區(qū)的所有門但你把臨時卡發(fā)給訪客時可以只給電梯層和會議室的權(quán)限。協(xié)議保證你在發(fā)臨時卡的時候沒法把“機房權(quán)限”一并塞給對方。4.2 敏感操作強制二次確認human-in-the-loop協(xié)議里專門為支付、發(fā)送消息、修改數(shù)據(jù)這類敏感操作設(shè)計了human-in-the-loop機制。關(guān)鍵字段是consentRequired一旦置true下游智能體不能直接執(zhí)行必須先返回一個確認請求給用戶設(shè)備。我一開始覺得這有點多此一舉直到模擬了“主智能體自動讓辦公助手把報銷單發(fā)給財務(wù)部門”的場景才意識到必要性。如果沒有二次確認用戶的一道口頭指令可能會順著智能體鏈條自動執(zhí)行下去中間任何一環(huán)理解偏差都可能導(dǎo)致敏感數(shù)據(jù)發(fā)錯地方。協(xié)議的妙處在于它不需要把用戶的密碼或者支付憑證傳給任何一個智能體。用戶確認動作發(fā)生在統(tǒng)一授權(quán)界面里確認之后平臺頒發(fā)的是一次性授權(quán)憑證授權(quán)范圍精確到單次操作。這樣即使下游智能體是惡意的也拿不到能反復(fù)使用的長期憑證。4.3 審計日志與可撤銷憑證給每筆調(diào)用留下痕跡每次跨智能體調(diào)用都會被記錄到一份除了用戶本人其他方無法篡改的授權(quán)日志里內(nèi)容包括誰調(diào)的誰、用了什么scope、在什么時間、執(zhí)行了什么action。用戶可以在授權(quán)中心隨時查看這些記錄就像銀行賬單一樣每一筆都清清楚楚。一旦發(fā)現(xiàn)可疑調(diào)用用戶可以直接撤銷某個智能體的全部授權(quán)。撤銷生效后該智能體在后續(xù)所有請求中都會直接收到4001已撤銷授權(quán)的提示。我自己的體驗是可撤銷憑證比密碼輪換高效得多——密碼輪換需要你找到所有使用場景逐一更換撤銷憑證只要在授權(quán)中心一鍵操作所有下游調(diào)用立刻失效。5. 落地過程中的三個大坑來自模擬項目的排錯記錄5.1 版本協(xié)商老智能體收到新字段直接翻臉協(xié)議剛出來的時候我默認所有智能體都跑同一個版本結(jié)果在模擬環(huán)境里接第一個“老設(shè)備”時就翻車了。對方實現(xiàn)的是0.8版協(xié)議不認識0.9.3版的contextCompaction字段收到消息后雖然沒報錯卻把新字段靜默丟掉了。這比直接報錯還麻煩——報錯你能知道哪里不對靜默丟棄導(dǎo)致的是數(shù)據(jù)錯位我以為對方收到了壓縮后的摘要實際上對方拿到的是截斷后的半截消息返回的結(jié)果自然牛頭不對馬嘴。后來我加了一套版本協(xié)商機制請求發(fā)出之前先發(fā)一條agent.discover消息探對方的協(xié)議版本和特性支持列表協(xié)商出一個雙方都支持的公共特性集再進行實際調(diào)用。整個過程有點像兩個人見面先確定“你用微信還是用短信”再開始談?wù)?。def negotiate_features(caller_supported: set, callee_supported: set): common caller_supported callee_supported if contextCompaction not in common: # 回退到原始上下文傳輸 use_context_compaction False return common5.2 上下文膨脹結(jié)構(gòu)化傳輸也會撐爆PAP不傳聊天原文傳的是結(jié)構(gòu)化狀態(tài)但這并不意味著不會膨脹。模擬到第20輪協(xié)作時會話上下文文件已經(jīng)接近4MB每次同步都明顯變慢。我的解決辦法是給每一個會話設(shè)置token預(yù)算超過85%時自動觸發(fā)壓縮策略。壓縮策略分兩步先把超過優(yōu)先級的細節(jié)片段折疊成摘要比如把“第3號發(fā)票金額128.5元、含稅、抵扣聯(lián)完好”壓成“詳情見附件緩存”如果還超就把最早完成的步驟上下文歸檔只保留任務(wù)目標、當前階段、以及最近兩輪的增量狀態(tài)。一個經(jīng)驗值可以分享會話上下文里真正核心的字段通常只占30%左右其余都是可以安全的歸檔或壓縮的內(nèi)容。我給會話設(shè)了128KB的軟上限實測在多數(shù)任務(wù)中都不會觸發(fā)壓縮但到了長鏈路任務(wù)里這套機制救了我好幾次。5.3 智能體循環(huán)調(diào)用兩個Agent互相等把任務(wù)活活拖死這是我模擬“主智能體嘗試調(diào)用辦公助手整理發(fā)票辦公助手反過來想請求主智能體提供歷史報銷記錄”時遇到的。兩個智能體互相發(fā)起請求各自都在等對方先返回形成典型的循環(huán)等待任務(wù)直接死鎖。排查鏈路比較痛苦日志顯示兩邊都在正常收發(fā)消息看起來毫無異常。后來我在每個消息上加了調(diào)用鏈IDtraceId和調(diào)用深度計數(shù)器打日志才發(fā)現(xiàn)調(diào)用棧已經(jīng)嵌套了五十多層從A到B再到A再到B無限套娃。最后的解法是三層防線單次任務(wù)設(shè)置最大調(diào)用深度超過10層直接拒絕繼續(xù)轉(zhuǎn)發(fā)調(diào)用鏈上如果檢測到traceId重復(fù)出現(xiàn)判定為循環(huán)立即終止并返回錯誤;每個調(diào)用請求附帶TTL超過時間自動失效防止任務(wù)掛死。這三層加完模擬環(huán)境才真正穩(wěn)定下來。后來我在思考為什么協(xié)議文檔里沒強調(diào)這些大概率是因為這類問題只有在真實異構(gòu)環(huán)境里才會暴露純設(shè)計階段很難預(yù)料。6. 這類協(xié)議的走向與我的幾點體會6.1 跟現(xiàn)有生態(tài)銜接的想象空間PAP這類協(xié)議真正有價值的地方在于它讓“設(shè)備廠商的助手”和“第三方開發(fā)者做的小智能體”處于同一套對話規(guī)則之下。短期內(nèi)最可能出現(xiàn)的場景是系統(tǒng)級助手通過協(xié)議去調(diào)用那些經(jīng)過認證的垂直領(lǐng)域智能體比如調(diào)用專業(yè)的法務(wù)助手、醫(yī)療咨詢助手。這并不是說要把所有助手合并成一個巨型應(yīng)用恰恰相反協(xié)議存在的意義是讓不同場景的智能體保持小而專同時通過標準化接口組合起來完成復(fù)雜任務(wù)。用戶不需要在十個App之間跳轉(zhuǎn)主助手會負責拆解任務(wù)、分派給合適的子助手、再匯總結(jié)果。6.2 標準化之爭協(xié)議多了等于沒有協(xié)議現(xiàn)在行業(yè)里的Agent通信協(xié)議已經(jīng)不是一兩個了各家都有自己的一套草案。PAP的挑戰(zhàn)在于它能不能成為大家愿意共同維護的標準。歷史上很多好協(xié)議最終沒能普及不是技術(shù)不行而是生態(tài)推進跟不上。我的判斷是決定這類協(xié)議命運的往往不是技術(shù)細節(jié)而是三件事第一有沒有足夠多的頭部玩家愿意開放自己的智能體接入第二授權(quán)與隱私模型能不能讓用戶真正感到可控第三開發(fā)者接入的成本夠不夠低——如果對接PAP比自研一套還麻煩那沒人會用。6.3 我做模擬項目期間的一點個人經(jīng)驗最后分享一個我自己體會很深的小技巧。不管以后哪種個人智能體協(xié)議勝出你如果現(xiàn)在就在做Agent相關(guān)開發(fā)都可以先把“消息冪等”和“能力發(fā)現(xiàn)”這兩件事做好。它們是最高頻的通用需求而且?guī)缀醪灰蕾嚲唧w協(xié)議版本。把這兩個抽象層先寫穩(wěn)后面無論接入哪家協(xié)議都只需要寫一個適配器不用改動核心業(yè)務(wù)邏輯。還有一點協(xié)議設(shè)計最忌貪多。PAP目前這套能讓人記住的核心概念本質(zhì)上也就三個身份、會話、能力。把這三點做扎實權(quán)限、審計、錯誤處理這些周邊的細節(jié)自然能順理成章地長出來。凡是那種想把所有智能體功能全都塞進協(xié)議里的規(guī)范大概率會死在復(fù)雜度上。我在模擬項目里壓測到兩百多次跨智能體調(diào)用之后最強烈的感受是個人智能體的未來不在單個模型有多強而在于多少個智能體能像一支配合默契的團隊一樣為了同一個用戶目標協(xié)作。PAP這類協(xié)議就是這支團隊的第一版溝通手冊。雖然現(xiàn)在它還遠不算完美但我相信方向是對的。