淺談 Agent 開發工具鏈演進歷程
作者:望宸
幾乎每個月,Agent 開發工具領域都會出現新的商業產品或開源項目,但 Agent 的應用架構相對穩定。
Agent 開發工具鏈日新月異
模型帶來了意識和自主性,但在輸出結果的確定性和一致性上降低了。無論是基礎大模型廠商,還是提供開發工具鏈和運行保障的廠家,本質都是希望提升輸出的可靠性,只是不同的團隊基因和行業判斷,提供了不同的實現路徑。以下我們按四個階段,通過串聯一些知名的開發工具,來回顧 Agent 開發工具鏈的演進歷程。
第一階段:基礎開發框架
2022 年底,ChatGPT 的發布,讓全球首次直觀感受到大語言模型的通用智能潛力,但彼時 LLM 仍是孤島智能,無法撬動廣大開發者的力量來加速行業發展。
隨后出現了首批 Agent 框架,如 LangChain、LlamaIndex,通過模塊化的抽象,例如模型通信、ChatClient、Prompt、格式化輸出、Embedding 等,來降低開發復雜度,快速構建 Chatbot、連接上下文、調用模型。
2024 年,Spring AI Aliabab 發布,提供高層次的 AI API 抽象與云原生基礎設施集成方案,幫助 Java 開發者快速構建 AI 應用。未來,其將作為 AgentScope 生態的一環,定位是做好 Spring 和 AgentScope 的連接,并計劃于今年 11 月底發布 AgentScope Java 版,對齊 AgentScope Python 能力。
隨著行業的快速發展,各類基礎開發框架也在持續演進,逐步支持或集成了檢索、檢索增強生成 RAG、Memory、工具、評估、可觀測、AI 網關等能力,并提供了單智能體、工作流、多智能體的開發范式,以及 DeepRearch、Jmanus 這些基于框架實現的深度研究智能體和通用智能體。
雖然在研究人員看來,開發框架做的事情沒有那么性感,但對于撬動廣大開發者快速融入 AI 開發生態,具有不可替代的作用。
第二階段:協作&工具
大模型雖然智能,但是缺少工具向物理世界進行延伸,它對物理世界既不可讀也不可寫。同時,第一階段的應用開發框架對非程序員群體并不友好,不利于團隊間協作和領域專家的參與。于是,2023 年-2024 年期間,Dify、n8n 等這些低代碼甚至零代碼的開發框架推向企業生產環境,通過 workflow、添加if/else 分支來定義任務的處理流程,甚至使用自然語言來生成一些簡單前端頁面,提升了領域專家和程序員間的協作效率。
工具層面,2023 年 6 月,OpenAI 正式推出 Function Calling。2024 年 11 月,Anthropic 發布 MCP 協議,實現跨模型工具互通。尤其是 MCP 的出現,大幅激活了開發者生態。
于是,兩者共同將 Agent 開發工具鏈推向了第二階段:工具&協作。
但是僅從降低構建應用的門檻,讓應用能通過工具調用外部應用或系統,并沒有很好的解決輸出的一致性和可靠性。于是,開發者工具鏈的演進進入了深水區。2024年,Andrej Karpathy 提出了上下文工程,引發業界共鳴,如何挑選上下文、組織上下文、在不同任務中動態調節上下文結構,才是提升輸出穩定性的關鍵,于是邁入了強化學習(以下簡稱 RL )的階段。
第三階段:強化學習
系統提示詞、知識庫、工具、記憶是上下文工程的重要構成,機制雖已成熟,但輸出仍然波動,依賴 RL 把上下文工程從靜態模板變成智能的動態策略。例如:
- RAG 檢索排序:RL 優化文檔重排策略,使上下文更貼近任務語義,減少無關噪音。
- 多輪對話記憶:RL 優化記憶的保留與遺忘策略,讓對話在長期交互中保持連貫性。
- 工具調用:RL 學習調用時機與參數構造,提高工具調用的有效率與正確率。
RL 是業內難點,既依賴算法技術,又需要具備足夠的領域 Know How,還會面臨通用性的挑戰。但其中不乏一些優先的實踐。
Jina.AI 近期被 Elastic 公司收購,其 CEO 肖涵博士曾在《搜索的未來,藏在一堆小模型里》一文中分享過 Jina.AI 研發的搜索底座模型,主要包括 Embeddings、Reranker 和 Reader:
- Embeddings 是為多語言和多模態數據設計的向量化模型,將文本或圖片轉化成定長向量。
- Reranker 是基于 query-documents 設計的精排模型,給定一個 query 和一堆文檔,直接輸入模型,然后根據 query 輸出文檔的相關性排序。
- Reader 主要目標是使用生成式小模型 (SLM) 實現單文檔上的智能,比如數據清理過濾提取等等。
以及,阿里云 API 網關基于 RL 提供了工具優選和語義檢索能力,提升批量 MCP 的調用質量、降低調用耗時。以工具精選為例,通過重排序與可選的查詢改寫,在請求發送至大語言模型前對工具列表進行預處理和篩選,提升大規模工具集場景下的響應速度與選擇精度,并降低 Token 成本。在 Salesforce 的開源數據集上,使用 50/100/200/300/400/500 個不同規模的工具集進行評測,結果表明:
- 準確性提升:經過查詢改寫(Query Rewrite)和工具精排(Reranker)后,工具及參數的選擇準確性最高可提升 6%。
- 響應速度提升:當工具集規模超過 50 個時,響應時間(RT)有顯著下降。在 500 個工具的測試場景下,響應速度最高可提升 7 倍。
- 成本降低:Token 消耗(費用)可降低 4~6 倍。
這些 RL 做得好的企業通常會把這部分實踐作為商業產品的競爭力和商業收費項,因此并不像框架、工具等能讓開發者快速收益。于是演進到第四階段,基礎模型廠商親自下場做上下文工程。
第四階段:模型中心化
2025 年 10 月,OpenAI AgentKit 和 Apps SDK,以及 Claude Skills 相繼發布,標志 Agent 工程進入模型中心化時代。
- OpenAI AgentKit 和 Apps SDK:提供官方級 Agent 開發工具鏈,直接在模型端托管 memory、tool registry、外部應用的調用邏輯,降低開發門檻。
- Claude Skills:允許模型自身加載和管理技能(skills),用戶只需提供輸入,模型在內部構建上下文與能力調用鏈。
尤其是 Claude Skills,Skills 構建能力,MCP 連接工具,甚至不需要 MCP,Skills 執行 py 腳本直接對接 API,再由大模型生成新的 Skills。把原本開發者負責的 Agent 上下工程,轉移到了框架側,包括構建、執行和運行。
從 Claude Skills 官方的示例看,是對輸出的一致性和確定性有直接幫助,尤其是協作類場景。把經驗和需求,可以是 xlsx/ppt/words/代碼… 最終以 skill.md 文件給到 Claude,作為上下文輸入。例如,搭建一個新系統,想復用現有系統的權限體系和視覺規范,那參照官方文檔,把現有系統權限設計的相關代碼、視覺規范,制作成 skill.MD 文件,就可以復用,不需要重新設計和反復調試了。
Agent 應用架構相對穩定
相比 Agent 開發工具鏈的日新月異,映射基礎設施的 Agent 應用架構,則相對穩定。
我們在《AI 原生應用架構白皮書》中分享過,AI 原生應用架構包含了模型、開發框架、提示詞、RAG、記憶、工具、AI 網關、運行時、可觀測、評估、安全等 11 個關鍵要素。以 AI 網關、運行時、可觀測、評估、安全為例。
- AI 網關: 負責模型、工具的聚合和智能調度,并提供訪問鑒權,和負載均衡、限流等流量治理等能力。無論開發者使用哪種工具鏈,最終都需要一個具備負載均衡、限流、身份認證與調用鏈追蹤的管控中樞。
- 運行時: 提供運行環境和算力支撐,負責任務調度、狀態管理、安全隔離、超時管理、并發追蹤等,讓 Agent 可靠、經濟運行。無論是私有化部署的 Agent,還是公有云上基于多模型的混合編排,最終都要回到 GPU 資源的分配、模型推理并發、容器化隔離與調度效率上。這些能力不會因為工具層的更新而頻繁重構。
- 可觀測: 由于 Agent 是由多個要素(模型、工具、RAG、記憶等)動態組成的復雜系統,缺乏統一的可觀測性將直接導致工程不可控。當前業界在這一層的共識較高:都需要提供端到端的日志采集和鏈路追蹤,對應用、網關、推理引擎提供請求吞吐量、錯誤率和資源使用情況,確保應用穩定、安全、高效運行。其結構演化都較為穩定。
- 安全: Agent 的安全性依舊遵循云計算架構的通用邏輯,包括身份鑒權、訪問控制、數據脫敏、越權防護等。尤其在多模型、多租戶運行環境中,安全策略的確定性比工具鏈的靈活性更重要。
工具鏈快速迭代和創新,提升輸出可靠性;網關、算力、可觀測、安全這些運行時模塊,則是確保應用能穩定、經濟、安全地運行。正是這種“上層快變、下層穩態”的結構,保證了 AI 應用生態既能高速創新,又不會陷入系統性混亂。
下周四北京,我們將在線下分享 AI 原生應用架構的關鍵要素和實踐,歡迎報名。
https://www.aliyun.com/activity/middleware/2025-beijing

浙公網安備 33010602011771號