AIAgent發(fā)展趨勢(shì)及架構(gòu)演進(jìn)AI原生應(yīng)用開發(fā)實(shí)戰(zhàn)營(yíng)成都站3.AI原生應(yīng)用架構(gòu)的實(shí)踐編程范式的演進(jìn)AIAI應(yīng)用中間件AI原生應(yīng)用開發(fā)全景圖開發(fā)框架可觀測(cè)性Golang低代碼開發(fā)框架可觀測(cè)性Golang低代碼生成通義靈碼Cursor生成AgentScopeAgentScope數(shù)據(jù)采集AIAIAgent性能分析性能分析大腦A2A感知大腦A2AAIAgent成本分析AI記憶魔搭/百煉/記憶魔搭/百煉/FC部署運(yùn)維平臺(tái)Agent部署運(yùn)維平臺(tái)Agent運(yùn)行時(shí)桌面/客戶端MCPServer運(yùn)行時(shí)Serverless運(yùn)行時(shí)Serverless運(yùn)行時(shí)投毒攻擊AI模型AI模型消息隊(duì)列KV緩存任AI基礎(chǔ)設(shè)施GPU/TPU/GPU/TPU/NPUCloud&VirtualizationAgent開發(fā)范式:三個(gè)關(guān)鍵問題?Agenticorworkflow?Agenticorworkflow真實(shí)的場(chǎng)景往往并非二選一混合模式?適用場(chǎng)景：任務(wù)步驟清晰、執(zhí)行路徑固定?真實(shí)的場(chǎng)景往往并非二選一混合模式?適用場(chǎng)景：任務(wù)步驟清晰、執(zhí)行路徑固定?典型應(yīng)用：數(shù)據(jù)ETL、報(bào)表生成、批量處理?優(yōu)勢(shì)：確定性、性能高、易測(cè)試?限制：靈活性不足，難應(yīng)對(duì)意料之外的情況Agentic模式(GPUbased)?Agentic模式(GPUbased)?適用場(chǎng)景：任務(wù)復(fù)雜、決策動(dòng)態(tài)、需多步推理?典型應(yīng)用：DeepResearch、CodingAgent、Manus?優(yōu)勢(shì)：高度靈活、具備自治能力、處理復(fù)雜任務(wù)?風(fēng)險(xiǎn)：準(zhǔn)確性、可測(cè)試性?Agent處理復(fù)雜邏輯，workflow協(xié)調(diào)子任務(wù)執(zhí)行?兼顧穩(wěn)定性與靈活性，平衡可控與自主?更適合企業(yè)級(jí)應(yīng)用與生產(chǎn)環(huán)境部署?主要考量因素：準(zhǔn)確性，成本單Agentor多Agent單Agent單Agent模式多Agent多Agent模式?適用場(chǎng)景：任務(wù)簡(jiǎn)單單一、目標(biāo)明確、響應(yīng)快速場(chǎng)景??適用場(chǎng)景：任務(wù)簡(jiǎn)單單一、目標(biāo)明確、響應(yīng)快速場(chǎng)景?適用場(chǎng)景：任務(wù)復(fù)雜、子任務(wù)明確、并行處理需求高、需強(qiáng)容錯(cuò)能力優(yōu)勢(shì)?處理復(fù)雜多步驟任務(wù)?并行執(zhí)行提高效率優(yōu)勢(shì)?處理復(fù)雜多步驟任務(wù)?并行執(zhí)行提高效率?提升目標(biāo)完成度和準(zhǔn)確性局限?復(fù)雜任務(wù)處理能力有限?模型的上下文窗口限制?擴(kuò)展性受限局限?架構(gòu)與協(xié)作復(fù)雜?資源與成本上升?調(diào)試難度加大?開發(fā)與維護(hù)簡(jiǎn)單?成本較低（單次LLM調(diào)用）如無(wú)必要，勿增實(shí)體?精心設(shè)計(jì)單次交互的指令或問題，即“問出正確的問題”ContextContextEngineering?為AI模型提供完成任務(wù)所需的全部背景信息、數(shù)據(jù)和知識(shí)，構(gòu)建一個(gè)有深度、有記憶的環(huán)境Structured/the-rise-of-context-engineering/事件驅(qū)動(dòng)事件驅(qū)動(dòng)MCPRegistry&Prompt安全管理移動(dòng)端移動(dòng)端Web端智能終端車機(jī)終端其他生態(tài)終端AIAgentSpringAIAlibaba/SpringAIAlibaba/綠網(wǎng)/敏感信息過濾Tools/MCPServerAgentAPI管理流量防護(hù)認(rèn)證鑒權(quán)策略/插件策略/插件向量數(shù)據(jù)庫(kù)/向量數(shù)據(jù)庫(kù)/Cache/Database模型生成結(jié)果評(píng)估全棧統(tǒng)一監(jiān)控AI應(yīng)用觀測(cè)&評(píng)估體系模型生成結(jié)果評(píng)估全棧統(tǒng)一監(jiān)控AI應(yīng)用觀測(cè)&評(píng)估體系全鏈路追蹤診斷SpringAIAlibaba是一款以SpringAI為基礎(chǔ)，深度集成百煉平臺(tái)，支持ChatBot、工作流、多智能體應(yīng)用開發(fā)模式的AI框架。2.通過AI生態(tài)集成，解決企業(yè)智能體落地過程中關(guān)心的痛點(diǎn)問題。與百煉企業(yè)知識(shí)庫(kù)、ARMSAI可觀測(cè)、3.探索具備自主規(guī)劃能力的通用智能體產(chǎn)品與平臺(tái)。Jmanus智能體平臺(tái)推動(dòng)自主規(guī)劃能力應(yīng)用于更多垂直為企業(yè)級(jí)場(chǎng)景打造專屬私有化MCP注冊(cè)中心MCPRegistry&ToolsManagementServerSchema/ServerSchema/PromptAIAgentAIAgentAI開發(fā)插件集AI安全防護(hù)多模型適配代理插件多APIKey管理可觀測(cè)AI開發(fā)插件集AI安全防護(hù)多模型適配代理插件多APIKey管理可觀測(cè)AI統(tǒng)計(jì)插件插件開發(fā)工具插件編程AI助手支持MCP★AIAgentClaudeClaudeDesktopGoogleBing場(chǎng)景痛點(diǎn)：多輪次、長(zhǎng)耗時(shí)場(chǎng)景痛點(diǎn)：多輪次、長(zhǎng)耗時(shí)AI會(huì)話中的狀態(tài)管理噩夢(mèng)RocketMQ提出了一種革命性的輕量化模型——“會(huì)話即主題”（Session-as-a-Topic其核心思想是為每一個(gè)會(huì)話（Session）或問題（Question）創(chuàng)建場(chǎng)景痛點(diǎn)方案特性方案特性?百萬(wàn)級(jí)隊(duì)列支持?百萬(wàn)級(jí)隊(duì)列支持：RocketMQ支持在單個(gè)集群中創(chuàng)建和管理百萬(wàn)級(jí)Lite-Topic。這意味著為海量并發(fā)會(huì)話或任務(wù)創(chuàng)建獨(dú)立Topic成為可能，且性能?輕量化資源管理：RocketMQ隊(duì)列的創(chuàng)建和銷毀極其輕量和自動(dòng)化。系統(tǒng)可實(shí)現(xiàn)按需自動(dòng)創(chuàng)建Lite-Topic，并在無(wú)連接后自動(dòng)回收，徹底避免了資源蔓延和手動(dòng)干預(yù)，解決了資源管理的后顧之憂。?大消息體支持：對(duì)于AIGC場(chǎng)景，消息體可能包含大量上下文的Prompt、高清圖片或長(zhǎng)篇文檔的AI回復(fù)。RocketMQ支持?jǐn)?shù)十MB甚至更大的消息體，完美滿足了這些數(shù)據(jù)傳輸需求。?順序消息保障：在單個(gè)會(huì)話隊(duì)列中，用戶往往采用LLM的流式輸出模式降低問答延遲，RocketMQ支持順序消息，能確保了推理結(jié)果流式輸出到客戶端的順序性，這是保障會(huì)話體驗(yàn)連貫性的基石。?強(qiáng)大的可觀測(cè)能力：系統(tǒng)支持OpenTelemetry標(biāo)準(zhǔn)的Metrics和Tracing，可以監(jiān)控消息收發(fā)量、消息堆積情況，還可以查詢每條消息收發(fā)的軌跡詳情，這對(duì)于調(diào)試和優(yōu)化復(fù)雜的多Agent交互至關(guān)重要。模型推理問題模型輸出的內(nèi)容是否準(zhǔn)確，是否合規(guī)？數(shù)據(jù)質(zhì)量問題回答效果不好模型推理問題模型輸出的內(nèi)容是否準(zhǔn)確，是否合規(guī)？數(shù)據(jù)質(zhì)量問題回答效果不好，如何進(jìn)一步提升數(shù)據(jù)的質(zhì)量和準(zhǔn)確性？成本問題用起來(lái)用的好用的省用起來(lái)用的好用的省基于OpenTelemetry的AI應(yīng)用可觀測(cè)性AIAgentAPIAIAgentAPI移動(dòng)端鏈路上下文鏈路上下文鏈路上下文鏈路上下文智能終端基礎(chǔ)設(shè)施(GPU基礎(chǔ)設(shè)施(GPU)鏈路上下文模型調(diào)用全鏈路診斷基于OpenTelemetry模型調(diào)用全鏈路診斷基于OpenTelemetryTrace實(shí)現(xiàn)用戶終端、網(wǎng)關(guān)、模型應(yīng)用、模型服務(wù)、外部依賴工具等全鏈路追蹤。模型生成結(jié)果評(píng)估構(gòu)建統(tǒng)一日志分析平臺(tái)，對(duì)模型調(diào)用日志進(jìn)行二次評(píng)估分析，實(shí)現(xiàn)質(zhì)量、安全、意圖提取等語(yǔ)義檢測(cè)。AI全棧統(tǒng)一監(jiān)控基于Prometheus構(gòu)建AI全棧監(jiān)控大盤，包源異動(dòng)分析等。AI應(yīng)用可觀測(cè)性的關(guān)鍵指標(biāo)LLM應(yīng)用黃金三指標(biāo)(TED)LLM應(yīng)用黃金三指標(biāo)(TED)?TTFT(Timetofirsttoken)?TPOT(Timeperoutputtoken)：Decode階段AIAgentModel/MCP服務(wù)網(wǎng)關(guān)鏈路上下文鏈路上下文鏈路上下文鏈路上下文基礎(chǔ)設(shè)施(GPU)基礎(chǔ)設(shè)施(GPU)?KVCache緩存命中率PythonAgentAI應(yīng)用可觀測(cè)性：全鏈路追蹤基于可觀測(cè)數(shù)據(jù)的評(píng)估：AI應(yīng)用的“回歸測(cè)試”??適用于達(dá)到穩(wěn)態(tài)之后?成本低，效率高?可擴(kuò)展性較好?成本較高?在Agent開發(fā)前期比較重要?指令不清晰?指令不清晰?任務(wù)過于復(fù)雜?執(zhí)行是否有重復(fù)?最終達(dá)到了目標(biāo)?執(zhí)行路徑是否簡(jiǎn)潔?工具調(diào)用正確性?工具參數(shù)錯(cuò)誤?工具調(diào)用效率?工具是否合適?召回語(yǔ)料相關(guān)性?召回語(yǔ)料多樣性?召回語(yǔ)料重復(fù)性模型輸入和輸出AIAgent評(píng)估要素Planning?持續(xù)追蹤線上數(shù)據(jù)Planning線上部署反饋和優(yōu)化?利用線上數(shù)據(jù)優(yōu)化Agent流程線上部署反饋和優(yōu)化ToolInstrumentationInstrumentation源于開源GoCompileInstrumentationInstrumentation源于開源GenAISemanticConvention社區(qū)貢獻(xiàn)與回饋LoongSuite可觀測(cè)采集套件開源存儲(chǔ)Agent開源存儲(chǔ)成本分析AIAgentLoongSuite成本分析Agent質(zhì)量分析云服務(wù)LoongSuiteJavaAgent云服務(wù)Node.js/iOS/AndroidAgent(敬請(qǐng)期待)未來(lái)規(guī)劃SpringAIAlibabaSpringAIAlibabaSpringAIAlibaba調(diào)試、評(píng)估效率?實(shí)現(xiàn)端到端可觀測(cè)性?采集，存儲(chǔ)，展示，到評(píng)估全周期覆蓋歡迎釘釘掃碼加入社區(qū)交流群構(gòu)筑AI領(lǐng)域的數(shù)據(jù)ETLEventBridge多源RAG能力發(fā)布阿里云產(chǎn)品經(jīng)理什么是AI？人工智能（AI）誕生于20世紀(jì)50年代，自90年代以來(lái)隨著數(shù)據(jù)量的爆發(fā)式增長(zhǎng)以及算力的不斷提升，AI被廣泛應(yīng)用于各行業(yè)，為社會(huì)帶來(lái)巨大機(jī)遇。AI提升了企業(yè)的決策效率和精準(zhǔn)度，驅(qū)動(dòng)創(chuàng)新，優(yōu)化運(yùn)營(yíng)，并助力組織變革和構(gòu)建競(jìng)爭(zhēng)優(yōu)勢(shì)。麥肯錫調(diào)研顯示，2022年全球有50%的公司部署了AI，投資超過總預(yù)算的4%。生成式AI（GenAI）的崛起進(jìn)一步推動(dòng)了企業(yè)轉(zhuǎn)型，其在流程優(yōu)化、個(gè)性化服務(wù)等方面的應(yīng)用超越了傳統(tǒng)AI。人工智能的發(fā)展歷程，即感知人工智能（PerceptionAI）->生成式人工智能（GenerativeAI）->智能體人工智能（AgenticAI）->具身人工智能（PhysicalAI），代表了人工智能從基本數(shù)據(jù)解讀到復(fù)雜的現(xiàn)實(shí)世界交互的演進(jìn)。AgenticAIPhysicalAIAgenticAIPhysicalAIAI時(shí)代的數(shù)據(jù)挑戰(zhàn)與機(jī)遇-GenAI演進(jìn)最初的起點(diǎn)從現(xiàn)在的視角看，可能過于“簡(jiǎn)陋”，不過當(dāng)時(shí)大語(yǔ)言模型剛出來(lái)的時(shí)候，一些基于AILLM能力之上包裝的一些現(xiàn)象級(jí)的應(yīng)用產(chǎn)品，都是使用這么直白的架構(gòu)，比如文本總結(jié)、AI算命、AI情感等，在這個(gè)架構(gòu)下能起到比較大作用的是Prompt的調(diào)優(yōu)。AI時(shí)代的數(shù)據(jù)挑戰(zhàn)與機(jī)遇-GenAI演進(jìn)增強(qiáng)上下文上下文增強(qiáng)主要是解決模型在處理特定問題時(shí)候的信息補(bǔ)充，在上下文增強(qiáng)上，比較常用的技術(shù)是RAG，RAG提供了面向模型輸入Prompt做動(dòng)態(tài)信息增強(qiáng)的能力。主要用途包括：1.問題域特有信息；比如分析用戶在某個(gè)平臺(tái)購(gòu)買喜好時(shí)，需要給到一些用戶在該平臺(tái)購(gòu)買的數(shù)據(jù)；AI時(shí)代的數(shù)據(jù)挑戰(zhàn)與機(jī)遇-GenAI演進(jìn)Agent模式Agent是在特定環(huán)境下的plan+tools，特定環(huán)境限制的是Agent的創(chuàng)建是面向一定的場(chǎng)景和問題域plan說明Agent有思考和規(guī)劃能力，且有根據(jù)反饋?zhàn)鲅h(huán)迭代的能力，Tools是指具備和外部交互能力的。tools的范圍是圍繞在當(dāng)前定義的場(chǎng)景和問題域下用于解決該類場(chǎng)景問題所需要的對(duì)外的行為的集合；AI時(shí)代的數(shù)據(jù)挑戰(zhàn)與機(jī)遇-數(shù)據(jù)種類AI時(shí)代的數(shù)據(jù)挑戰(zhàn)與機(jī)遇-主流數(shù)據(jù)采集AI時(shí)代的數(shù)據(jù)挑戰(zhàn)與機(jī)遇–GenAI+數(shù)據(jù)？擴(kuò)展難一個(gè)簡(jiǎn)單的數(shù)據(jù)集成總是愉快而且輕松的，但是隨著結(jié)構(gòu)化數(shù)據(jù)和半結(jié)構(gòu)化數(shù)據(jù)的加入，如何擴(kuò)展便成了最大運(yùn)維難一個(gè)簡(jiǎn)單的數(shù)據(jù)任務(wù)運(yùn)維總是愉快而且輕松的，但是當(dāng)業(yè)務(wù)逐漸擴(kuò)展，很快便會(huì)出現(xiàn)無(wú)休止的修復(fù)和更新。穩(wěn)定性差模型上下文是否準(zhǔn)確一定程度上決定了AIAgent是否可上生產(chǎn)，數(shù)據(jù)鏈路的問題型是最關(guān)鍵的一環(huán)。Event&Bridge-Event是什么？簡(jiǎn)單來(lái)說，事件就是狀態(tài)的顯著變化，針對(duì)當(dāng)用戶采取特定行動(dòng)時(shí)觸發(fā)或指一切能夠輸入計(jì)算機(jī)中，且能被處理的符號(hào)。以4S店售賣汽車為例：?當(dāng)客戶購(gòu)買汽車并且其狀態(tài)從ForSale變?yōu)镾old是一個(gè)事件。?成功交易后，從帳戶中扣除金額是一個(gè)事件。?單擊預(yù)訂試駕后，從將預(yù)約信息添加到指定用戶就是一個(gè)事件。?用戶資料和預(yù)約單本身也可以成為一個(gè)事件。轉(zhuǎn)換（Transform轉(zhuǎn)換（Transform）源（Source）過濾（Filter）事件模式結(jié)構(gòu)化/事件模式結(jié)構(gòu)化/半結(jié)構(gòu)化數(shù)據(jù)數(shù)據(jù)庫(kù)可觀測(cè)API/云產(chǎn)品通知&其他…指定值匹配指定值匹配前綴匹配數(shù)據(jù)庫(kù)義轉(zhuǎn)換代碼包含匹配包含匹配可觀測(cè)可觀測(cè)APIAPI多模式匹配多模式匹配結(jié)構(gòu)化/半結(jié)構(gòu)化數(shù)據(jù)對(duì)象存儲(chǔ)調(diào)用外部API完成數(shù)據(jù)轉(zhuǎn)換Event&Bridge-EventBridge是什么？事件總線模型經(jīng)典EDA（事件驅(qū)動(dòng)）場(chǎng)景的N：M模型，提供多事件路由，事件匹配，事件轉(zhuǎn)換等核心能力，幫助您快速搭建事件驅(qū)動(dòng)架構(gòu)。事件總線事件規(guī)則事件總線事件源對(duì)象存儲(chǔ)容器服務(wù)事件總線事件規(guī)則事件總線事件源對(duì)象存儲(chǔ)容器服務(wù)事件流模型標(biāo)準(zhǔn)Streaming（1:1）流式處理場(chǎng)景，無(wú)總線概念。使用于端到端的數(shù)據(jù)轉(zhuǎn)儲(chǔ)，數(shù)據(jù)同步及數(shù)據(jù)處理等，幫助您輕松構(gòu)建云上數(shù)據(jù)管道服務(wù)。事件源事件源事件流結(jié)構(gòu)化數(shù)據(jù)半結(jié)構(gòu)化數(shù)據(jù)半結(jié)構(gòu)化數(shù)據(jù)非結(jié)構(gòu)化數(shù)據(jù)非結(jié)構(gòu)化數(shù)據(jù)支持讀取多種非結(jié)構(gòu)化數(shù)據(jù)結(jié)構(gòu)讀取，如TEXT，JSON、XML、YAML、CSV等。兼容主流Loader數(shù)據(jù)處理方式，包括單文檔加載，分塊加載等。結(jié)構(gòu)化數(shù)據(jù)支持讀取多種結(jié)構(gòu)化數(shù)據(jù)源拉取，如Kafka，RokcetMQ、SLS、MQTT、數(shù)據(jù)庫(kù)等。為客戶提供豐富的數(shù)據(jù)源支持。多源RAG-向量數(shù)據(jù)庫(kù)入庫(kù)多種向量數(shù)據(jù)支持支持專用向量數(shù)據(jù)庫(kù)和傳統(tǒng)數(shù)據(jù)庫(kù)向量插件等，涵蓋市面主流向量數(shù)據(jù)庫(kù)能力，支持一鍵白屏化入庫(kù)。實(shí)時(shí)推理/異步推理能力概述實(shí)時(shí)推理/異步推理-結(jié)構(gòu)化輸出結(jié)構(gòu)化輸出性能。大型語(yǔ)言模型(LLM)的結(jié)構(gòu)化輸出是指讓模型生成特定格式的數(shù)據(jù)，而不是自然語(yǔ)言文本。通常，LLMs默認(rèn)的輸出是非結(jié)構(gòu)化的，例如散文、段落或?qū)υ?。然而，在很多?shù)據(jù)處理場(chǎng)景中，我們需要模型能按照預(yù)定義的格式（如JSON、XML、YAML、CSV甚至是特定的代碼結(jié)構(gòu)）來(lái)輸出信息。EventBridge支持產(chǎn)品化結(jié)構(gòu)輸出，優(yōu)先使用模型JsonSchema能力，當(dāng)模型原生不支持JsonScheam入?yún)r(shí)，通過產(chǎn)品化提示詞注入解決LLM鏈路結(jié)構(gòu)化輸出的問題。{}實(shí)時(shí)推理/異步推理數(shù)據(jù)應(yīng)用層使用，通過調(diào)用模型推理能力，增強(qiáng)數(shù)據(jù)Transform能力，完成傳統(tǒng)數(shù)據(jù)清洗無(wú)法實(shí)現(xiàn)的場(chǎng)景訓(xùn)練預(yù)數(shù)據(jù)處理SFT服務(wù)于模型訓(xùn)練場(chǎng)景，為模型訓(xùn)練提供預(yù)處理能力，滿足數(shù)據(jù)集整理訴求增強(qiáng)檢索數(shù)據(jù)入庫(kù)RAG通過將不同的數(shù)據(jù)入庫(kù)向量數(shù)據(jù)庫(kù)，并召喚符合的上下文信息喂給模型；場(chǎng)景描述事件源在數(shù)據(jù)集用于模型訓(xùn)練前，使用一定方法對(duì)數(shù)據(jù)進(jìn)行處理，以便把數(shù)據(jù)變換成適用于機(jī)器學(xué)習(xí)模型訓(xùn)練的格式或形式。事件源處理類型：數(shù)據(jù)錯(cuò)誤，數(shù)據(jù)重復(fù)，數(shù)據(jù)缺失，數(shù)據(jù)集不均衡。Transform實(shí)現(xiàn)效果Transform事件源（OSS）ChunkingChunkingEmbeddingEmbedding場(chǎng)景描述需要處理單一渠道的結(jié)構(gòu)化和非結(jié)構(gòu)化數(shù)據(jù)，可通過配置事件源和目標(biāo)服務(wù)來(lái)完成對(duì)RAG鏈路的多源數(shù)據(jù)接入。事件源（OSS,Kakfa..）ChunkingChunkingEmbeddingEmbedding場(chǎng)景描述需要處理來(lái)自不同渠道的結(jié)構(gòu)化和非結(jié)構(gòu)化數(shù)據(jù)，可通過配置事件源和目標(biāo)服務(wù)來(lái)完成對(duì)RAG鏈路的多源數(shù)據(jù)接入。場(chǎng)景：數(shù)據(jù)清洗與標(biāo)準(zhǔn)化(DataCleansing&Standardization)場(chǎng)景描述事件源Transform(百煉)需要處理來(lái)自不同渠道的用戶地址信息，這些地址格式不一、存在錯(cuò)別字。希望能在數(shù)據(jù)入倉(cāng)前，自動(dòng)將它們標(biāo)準(zhǔn)化為統(tǒng)一的省-市-區(qū)-事件源Transform(百煉)實(shí)現(xiàn)效果Agent輸入：["北京市海淀區(qū)中關(guān)村大街1號(hào)"]Agent輸出：Province:"北京",City:"北京",District:"海淀區(qū)",Street:"中關(guān)村大街1號(hào)",ZipCode:"100080"結(jié)構(gòu)化輸出結(jié)構(gòu)化輸出場(chǎng)景描述事件源Transform(百煉)需要分析用戶評(píng)論的情感傾向，以評(píng)估市場(chǎng)活動(dòng)的效果。希望能在ETL流程中，自動(dòng)為每一條用戶評(píng)論打上“正面”、“負(fù)面”或“事件源Transform(百煉)實(shí)現(xiàn)效果Agent輸入：["這款新手機(jī)的拍照功能太驚艷了！"]Agent輸出：Sentiment:"正面",Confidence:0.98結(jié)構(gòu)化輸出結(jié)構(gòu)化輸出場(chǎng)景描述事件源Transform(百煉)確保所有進(jìn)入分析系統(tǒng)的數(shù)據(jù)都符合GDPR/CCPA規(guī)范，不能包含用戶的個(gè)人身份信息（PII）。希望在ETL過程中自動(dòng)識(shí)別并脫敏處理文本中的姓名事件源Transform(百煉)實(shí)現(xiàn)效果Agent輸入：["客戶張三反饋了一個(gè)問題..."]Agent輸出：["客戶***（138****5678）反饋了一個(gè)問題..."]結(jié)構(gòu)化輸出結(jié)構(gòu)化輸出EventBridge客戶交流群2?EventEventBridge客戶交流群2?從技術(shù)角度而言，生成式AI代理是—種軟件抽象化，它通過觀察環(huán)境、推理最佳行動(dòng)方案并使用可用工具執(zhí)行操作，自主地追求既定目標(biāo)。它在執(zhí)行每個(gè)步驟時(shí)可以獨(dú)立于直接人工指令而運(yùn)行，并且可以主動(dòng)確定后續(xù)操作以實(shí)現(xiàn)最終目標(biāo)。這得益于生成式AI模型，這些模型可為代理提供推理和決策制定能力。任務(wù)分析任務(wù)分解Agent任務(wù)分發(fā)/監(jiān)控計(jì)劃執(zhí)行/toolcall下一步動(dòng)作計(jì)劃為Java開發(fā)者打造的、追求高成功率的面向生產(chǎn)Agent框架JavaJava生態(tài)集成?嘉賓內(nèi)容僅代表其個(gè)人觀點(diǎn)?為Java開發(fā)者打造的、追求高成功率的面向生產(chǎn)Agent框架JavaJava生態(tài)集成嘉賓內(nèi)容僅代表其個(gè)人觀點(diǎn)嘉賓內(nèi)容僅代表其個(gè)人觀點(diǎn)為Java開發(fā)者打造的、追求高成功率的面向生產(chǎn)Agent框架JavaJava生態(tài)集成點(diǎn)點(diǎn)?/alibaba/spring-ai-alibaba?spring-ai-alibaba-jmanus項(xiàng)目?駕馭不確定性：MCP時(shí)代AI應(yīng)用的上下文工程探索吳姚迪阿里云智能云原生應(yīng)用平臺(tái)C-01MCP的爆發(fā)式增長(zhǎng)MCP是什么>MCP是模型上下文協(xié)議（ModelContextProtocol）的簡(jiǎn)稱，是一個(gè)開源協(xié)議，由Anthropic（Claude開發(fā)公司）開發(fā)，旨在讓大型語(yǔ)言模型（LLM）能夠以標(biāo)準(zhǔn)化的方式連接到外部數(shù)據(jù)源和工具。>它就像AI應(yīng)用的通用接口，幫助開發(fā)者構(gòu)建更靈活、更具上下文感知能力的AI應(yīng)用，而無(wú)需為每個(gè)AI模型和外部系統(tǒng)組合進(jìn)行定制集成。>MCP被設(shè)計(jì)為一個(gè)通用接口，類似于USB-C端口，允許LLM應(yīng)用以一致的方式連接到各種數(shù)據(jù)源和工具，如文件、數(shù)據(jù)庫(kù)、API等。和FunctionCalling有什么關(guān)系>MCP是通用協(xié)議層的標(biāo)準(zhǔn)，類似于“AI領(lǐng)域的USB-C接口”，定義了LLM與外部工具/數(shù)據(jù)源的通信格式，但不綁定任何特定模型或廠商，將復(fù)雜的函數(shù)調(diào)用抽象為客戶端-服務(wù)器架構(gòu)。>FunctionCalling是大模型廠商提供的專有能力，由大模型廠商定義，不同大模型廠商之間在接口定義和開發(fā)文檔上存在差異；模型生成（選擇）調(diào)用函數(shù)及函數(shù)入?yún)ⅲ瑥亩|發(fā)外部函數(shù)，依賴模型自身的上下文理解和結(jié)構(gòu)化輸出能力。>模型上下文協(xié)議（ModelContextProtocol）提供了更多的拓展，如鑒權(quán)、安全邊界、資源描述、prompt等，從工具層面，與LLM的核心交互還是找工具和解析工具參數(shù)。MCP的工具選擇實(shí)現(xiàn)-DeepChatMCP的工具選擇實(shí)現(xiàn)–Cline1深入工具選擇優(yōu)化–Cline1流式實(shí)時(shí)解析的優(yōu)勢(shì)>可能遇到的問題：1.>可能遇到的問題：1.使用了不存在的工具3.工具調(diào)用響應(yīng)時(shí)間很久（最后可能還直接回答了）>對(duì)輸出內(nèi)容實(shí)時(shí)解析>使用XML格式的特征>第一行輸出完成即可知道工具名稱是否正確保留模型思考輸出重試與強(qiáng)調(diào)>Cline會(huì)立即打斷LLM的輸出LLM重試>Function重試與強(qiáng)調(diào)>Cline會(huì)立即打斷LLM的輸出LLM重試>LLM在輸出工具調(diào)用參數(shù)前，可能會(huì)進(jìn)行一些分析判斷——但是在黑盒模式下看>基于這些輸出可以DEBUG為什么LLM沒有按預(yù)期使用工具或給出預(yù)期的參數(shù)2前置參數(shù)解析與校驗(yàn)參數(shù)合法性了>有時(shí)候甚至選對(duì)了工具和參數(shù)，但是參數(shù)比較復(fù)雜(嵌套對(duì)象、SQL等帶字符轉(zhuǎn)義的內(nèi)容)，解析失敗，放棄Function2前置參數(shù)解析與校驗(yàn)參數(shù)合法性了建議需要更極致用戶體驗(yàn)時(shí)嘗試甚至不需要整個(gè)參數(shù)>許多場(chǎng)景把工具和參數(shù)的描述寫清晰寫規(guī)范，就能把成功率提升到一個(gè)可用的水平即可對(duì)>許多場(chǎng)景把工具和參數(shù)的描述寫清晰寫規(guī)范，就能把成功率提升到一個(gè)可用的水平高德MCPServer>對(duì)接高德MCPServer，可以獲得其12個(gè)工具的調(diào)用能力>但問題是有大量工具實(shí)際生產(chǎn)很難用到，且他們的描述可能會(huì)干擾其他工具的使用MCPRegistry>TheMCPRegistryserviceprovidesacentralizedrepositoryforMCPserverentries.ItallowsdiscoveryandmanagementofvariousMCPimplementationswiththeirassociatedmetadata,configurations,andcapabilities.>從官方的定義中可以抽象出兩個(gè)核心定義：>一個(gè)集中式管控的MCP服務(wù)倉(cāng)庫(kù)。>可以動(dòng)態(tài)發(fā)現(xiàn)和管理MCP服務(wù)倉(cāng)庫(kù)中的各種MCP服務(wù)。Nacos3.0MCPRegistry除了兼容官方定義的MCP元數(shù)據(jù)格式、和API外，MSENacos3.0同時(shí)提供KMS提供MCP服務(wù)敏感數(shù)據(jù)加密的能力，同時(shí)結(jié)router也可以實(shí)現(xiàn)智能路由檢索的能力，解決多MCP服務(wù)場(chǎng)景token消耗>通過自由組裝進(jìn)行MCPServer構(gòu)建AI網(wǎng)關(guān)Higress內(nèi)核Higress內(nèi)核構(gòu)建>許多功能在貢獻(xiàn)的基礎(chǔ)上進(jìn)行企業(yè)級(jí)特性>同時(shí)也會(huì)將一些好用的特性反哺給開源社區(qū)，例如圖中所示的MCPServer自由組裝C-02進(jìn)階至上下文工程的演化和應(yīng)對(duì)策略的轉(zhuǎn)變，是對(duì)現(xiàn)實(shí)中算法和工程挑戰(zhàn)的一種集體回應(yīng)，尤其是垂直和領(lǐng)域智能體?！?025年6月，Karpathy及業(yè)內(nèi)開始強(qiáng)調(diào)“上下文工程”相對(duì)于傳統(tǒng)“提示詞工程”（PromptEngineering）的范式轉(zhuǎn)變，提出ContextEngineering覆蓋了更全面和系統(tǒng)的提示設(shè)計(jì)與上下文管理。◆2025年7月初，多篇文章和技術(shù)分享明確將PromptEngineering升級(jí)為ContextEngineering，提出其不僅關(guān)注單次提示設(shè)計(jì)，而是關(guān)注為AI模型提供完整且動(dòng)態(tài)管理的上保留Context緩沖區(qū)maxAllowedSizemaxAllowedSize=Math.max(contextWindow-16_000,contextWindow*0.7)>固定的token數(shù)量緩沖區(qū)，如8k、16k>或按模型總的上下文長(zhǎng)度的30%作為緩沖區(qū)>避免下一次請(qǐng)求直接沖破模型上下文限制，導(dǎo)致請(qǐng)求失敗>許多模型在Context達(dá)到一定長(zhǎng)度時(shí)會(huì)出現(xiàn)比較明顯的性能、效果下降>模型架構(gòu)的差異導(dǎo)致它們處理長(zhǎng)上下文的能力各不相同，一般來(lái)說新架構(gòu)的模型表現(xiàn)會(huì)好一些>所以50%-80%都是可以使用的，具體取決于模型哪些內(nèi)容在多輪會(huì)話中不需要代入？RAG召回結(jié)果動(dòng)態(tài)MCPServer信息多輪回話場(chǎng)景中，history__messages(歷史對(duì)話)不應(yīng)視為固定值，而是將其作為需要精心構(gòu)建維護(hù)的可變值>用戶通常更聚焦于初始任務(wù)與最近的對(duì)話內(nèi)容，對(duì)中間部分關(guān)注很少——完美符合模型的“U型”性能曲線>對(duì)于資料引用，在模型做出回答后在客戶端緩存即可，持續(xù)參考價(jià)值一般不大示例：僅作用一次的RetrievedDocuments>減少Token消耗：通過移除不再需要的檢索信息，顯著降低了每次API調(diào)用的Token數(shù)量，從而節(jié)省成本>提高模型專注度：防止舊的、可能不相關(guān)的檢索信息干擾模型對(duì)當(dāng)前問題的理解和回答>避免上下文窗口超限：在長(zhǎng)對(duì)話中，可以有效防止上下文超出模型的最大Token限制>結(jié)構(gòu)清晰：使用XML標(biāo)簽使得上下文的結(jié)構(gòu)更加清晰，易于程序處理和調(diào)試動(dòng)態(tài)會(huì)話精簡(jiǎn)–留頭存尾研究表明，許多大型語(yǔ)言模型在處理長(zhǎng)上下文時(shí)，對(duì)于輸入序列的開頭和結(jié)尾部分的信息利用率更高，而中間部分的信息則容易被“遺忘”或忽略。這種現(xiàn)象被稱為“中間遺忘”（LostintheMiddle）。因此，保留對(duì)話的開頭（初始指令）和結(jié)尾（最近的交互并策略性地移除中間部分的對(duì)話歷史，是一種非常有效的上下文管理策略。這種方法不僅可以有效控制上下文長(zhǎng)度，防止超出模型的最大限制，還能在很大程度上保留對(duì)話的關(guān)鍵信息，從而維持較高的模型性能。動(dòng)態(tài)會(huì)話精簡(jiǎn)–利用LLM摘要總結(jié)簡(jiǎn)單直接的方式，讓LLM做上下文摘要從而進(jìn)行壓縮1.充分利用LLM的泛化性、注意力2.可通過prompt定制壓縮傾向3.效果隨模型性能提升而提升1.耗時(shí)較大2.Token消耗動(dòng)態(tài)會(huì)話精簡(jiǎn)–Context壓縮技術(shù)（1）Laban等人的最新研究揭示了LLMs處理信息的一個(gè)根本性特點(diǎn)：當(dāng)指令被拆分到多輪對(duì)話中傳遞時(shí)，相比一次性獲得完整上下文，其平均性能會(huì)下降39%。盡管論文中的模擬使用了簡(jiǎn)化版的真實(shí)對(duì)話場(chǎng)景，但其發(fā)現(xiàn)意義深遠(yuǎn)：如果模型連干凈、順序的信息處理都吃力，那么在真正混亂、來(lái)回切換的創(chuàng)意或調(diào)試對(duì)話中只會(huì)更加吃力。LLMs被優(yōu)化以適應(yīng)我們稱之為“順風(fēng)路”的場(chǎng)景——從全面輸入到目標(biāo)輸出之間有一條清晰的路徑。這就是為什么“校正方向”感覺像是在逆流而上。你