Agentic AI可預測自主性的五大要素
本文探討了AI代理的五個要素：狹窄的上下文、簡單的工具、詳細的提示、適合用例的模型和集中管理。強調了Spring AI框架在簡化AI集成方面的作用，以及AI原生平臺在管理和擴展AI應用的重要性。
譯自：5 Factors for Predictable Autonomy With Agentic AI[1]
作者：Brian Friedman, Jonathan Eyler-Werve
這是“交付 Agentic AI”系列的第二部分。 閱讀第 1 部分[2]。
之前，我們探討了 AI 計劃失敗的原因，并描述了一個虛構的、在全國范圍內擁有連鎖店的汽車修理店，它即將開展其首個 agentic AI 項目。我們虛構的連鎖店希望加入已經從其 AI 工作中看到投資回報率 (ROI) 的 5% 企業的行列，因此它已決定創建一個代理，該代理將自動化一項商店經理每周要花費四個小時的任務。接下來，我們將深入研究以可預測的自主性運行的 AI 代理的五個要素。
通過汽車修理店連鎖店的例子，我們將探索一種解決方案，該解決方案每年每個商店可以節省超過 200 小時的管理時間，并且可以在 12 周或更短的時間內推出。我們將通過按時、按預算、按質量發布具有以下特點的解決方案來堅定地插上我們的投資回報率旗幟：
1. 狹窄的上下文
2. 簡單的工具
3. 詳細的提示
4. 適合用例的正確模型
5. 集中管理 AI 資產、連接和策略
狹窄的上下文
對于 agentic AI 來說，上下文就是一切。它定義了模型必須知道的所有為我們量身定制的內容，才能回答問題。例如，一些國際公司可能會選擇按照其服務的所有國家/地區的最高法律標準運營，以避免全面出現問題。詢問公司在特定國家/地區的代理應該做什么，不應僅依賴于普遍接受的地理知識；而應依賴于給定司法管轄區的公共和內部政策的組合。
在我們的汽車修理店連鎖店的場景中，上下文再狹窄不過了。我們對服務單感興趣。它們記錄了每一次送車、每一次取車、每一次執行的服務以及收集到的調查回復。還有大量的其他信息，例如零件編號和服務代碼，但鑒于我們當前的任務是將服務單中捕獲的調查數據轉換為可報告的數據源，因此其中很多信息都是無用的。
因此，我們希望描述盡可能少的字段供我們的 AI 代理篩選，因為我們希望精確地描述每個字段；在這種情況下，我們聘請 AI 代理不是為了他們的創造力。
簡單的工具
我們將在服務單系統中定義一個查詢，以獲取送車日期、取車日期、執行的特定服務和調查回復。我們將允許我們的 AI 代理通過視圖或存儲過程訪問該查詢，并且我們將通過稱為工具的 AI 編程結構公開它。
我們不會簡單地將模型釋放到我們的數據庫中，讓它“弄清楚我們需要什么”。我們將為它提供解決問題所需的確切數據形狀，并且我們將為它提供一種非常簡單的執行方式：要么獲取在兩個特定日期之間更改為“已關閉”的所有內容，要么獲取本周更改為“已關閉”的所有內容。
我們將使用 Spring AI[3] 和模型上下文協議 (MCP) 將我們的代理快速連接到我們的上下文中。Spring AI 將確保我們的代碼允許模型交互的靈活性，而 MCP 將確保在需要時調用我們的工具，并且當模型考慮我們用戶的提示時，我們的上下文會流入模型。Spring AI 的卓越之處在于，我上面描述的大部分內容都是使用人類語言而不是代碼實現的。
工具是開發人員提供的代碼塊，AI 可以使用它們。開發人員使用簡單的英語描述行為，然后 LLM 使用這些描述來了解如何使用該工具。這確實是一種卓越的范式轉變，開發人員 90% 的編碼工作都被幫助 LLM 正確使用代碼的文檔所取代，只剩下 10% 的剩余代碼需要實際編寫。
SpringAI 代碼塊
[4]
Spring AI 混合了自然語言和編程接口。（來源：Broadcom 旗下的 VMware）
我再怎么強調上面代碼片段所展示的概念對軟件開發來說有多么具有革命性都不為過。工具描述向其使用者（AI）描述了如何使用它以及如何理解其響應。早在 2023 年，我們就不得不編寫數十行（如果不是數百行）代碼來協調兩個不相關系統之間的交互。
僅僅不到兩年后的今天，我們就可以使用自然語言來指示 AI 如何為我們協調這些交互。我們所要做的就是提供在調用工具時在后臺調用的函數。但是，必須將所有這些函數調用拼接在一起才能產生有意義的結果，這就是代理及其系統提示成為粘合劑的地方。
詳細的提示
當實例化代理時（當托管代理的服務啟動時），模型首先想知道的是此代理的系統提示是什么。換句話說，該代理的任務和目的是什么？
在系統提示中，我們確切地告訴代理它的工作是什么。我們可以確切地告訴我們的代理它可以執行哪些任務，甚至在什么情況下可以執行。也許在營業時間內啟動的任務應該安排在非營業時間窗口進行處理。
這些事情可以非常快速地由普通人烘焙到提示中。無需編碼。系統提示是簡單的英語，就像我們審查過的工具描述一樣。以下代碼段來自用于配置我們的 Spring 應用程序的屬性文件：
系統提示
[5]
驅動受約束的客戶滿意度數據分析師代理行為的系統提示。（來源：Broadcom 旗下的 VMware）
想想這里消除了多少行代碼，這些代碼用于根據一天中的時間和一周中的哪一天來確定是安排進程還是立即運行它。這不僅僅是該邏輯的實現，而是它的封裝和集成，以便它可以與其他服務交互。只要存在用于確定當前日期的工具和用于安排任務的另一個工具，就可以通過在代理提示中描述來完全發明這種能力。
通過非常明確地告訴我們的代理應該做什么以及何時使用它擁有的工具，我們可以開始獲得我們期望從 AI 獲得的 可預測的自主性的回報。在這種情況下，回報的形式是每個商店每年超過 200 小時的經理工作時間。對于我們的第一槍來說，還不錯。
適合用例的正確模型
簡化的模型選擇決策樹
[6]
簡化的模型選擇決策樹（僅用于說明目的）。（來源：Broadcom 旗下的 VMware）
誠然，汽車修理店的例子并沒有為圍繞模型選擇的故事情節提供太多內容。每個企業首先也是最重要的問題應該是：我們是否愿意使用公共模型？考慮到我們必須將我們的狹窄上下文發送到這些模型；每次我們詢問有關服務單分組的問題時，我們都必須通過線路將數據發送到模型[7]進行評估。也許我們的汽車連鎖店不太關心當前數據集的內容，但隨著時間的推移，私有 AI 的重要性可能會增加。
這就是為什么我們將我們的模型交互包裝在像 Spring AI 這樣的框架中——更改模型提供商的業務決策不應需要對解決方案進行大規模更改。但是，如果沒有像 Spring AI 這樣的層介于開發人員和模型之間，就會發生這種情況。
如果我們要處理調度而不是調查數據，模型選擇將會有更多有趣的故事情節。調度需要推理，因此推理模型將比通用 LLM 有效得多。但是，當要求 LLM 使用在為該任務創建的視圖中清晰且容易獲得的字段以給定格式準備批處理文件時，不需要太多精明才能做出正確的決定。只要 MCP 在他們的技巧包中，任何主要的公共或私有參與者都可以輕松處理該用例。
第二天是最長的一天
早些時候，我提到了 Spring AI 以隔離開發人員[8]，使其免受與一個或多個模型交互的復雜性影響。與模型交互只是我們在運營化這項首次 agentic 工作時必須滿足的需求的冰山一角。正如 Tanzu 的 AI Native 報告詳細揭示的那樣（此處[9]提供），成功運營 AI 需要完成的工作不勝枚舉。我們需要能夠在許多方面應用策略：允許哪些模型以及允許哪些團隊？如何頒發令牌？如何處理配額和退款？如何輪換工具和 MCP 服務器的憑據？如何限制對 MCP 服務的訪問，使其僅限于部分使用者？我們如何管理部署并證明哪些版本的哪些模型可以安全使用？
我們需要完成所有這些以及更多的事情，并且我們需要以可重復的方式，為多個環境完成這些事情，然后才能看到生產的光芒。
能夠管理上述內容非常重要，因為隨著事物的演變，我們的系統將會是什么樣子。AI 代理在底層技術和部署架構方面與微服務具有很大的對稱性，但粒度更高。這些服務將更小，并且它們的任務將更加離散；微服務將被納米服務所取代。我們的客戶滿意度分析代理就是一個納米服務的例子。我們將保持該服務的規模較小，并專注于一件事，以便它以可預測的方式運行。
在我們的虛構汽車修理店的未來，將會有數百個（如果不是數千個）像這樣的納米服務，每個納米服務都具有一組狹窄的職責和工具。我們服務的粒度的權衡將是其數量的增加。AI 原生解決方案從想法到生產的速度將既令人震驚又讓人不知所措。如果我們想以可持續的方式大規模地做到這一點，我們將需要防護措施，而這正是 AInative 平臺所提供的。
如果沒有平臺來管理所有這些，第二天就會變成第二個月，然后變成第二年，然后你才有機會站穩腳跟。麻省理工學院的論文，批評企業 AI 部署，[10] 對此進行了量化。對于實際投入生產的 AI 工作，其中 67% 的工作使用供應商提供的 AI 資產管理解決方案。只有 22% 的成功系統是他們為管理 AI 集成問題而創建的。同樣，獨立研究[11] 發現，大多數受訪者 (82%) 認為 AI 平臺對于擴展 AI 來說很重要或必不可少。
圖表顯示，近一半的 IT 領導者表示 AI 應用程序平臺對于擴展 AI 至關重要
[12]
成功地設置自己以大規模交付 AI 應用程序
Agentic AI 是一件強大的事情，但陷阱很多。為了快速、安全地行動，同時交付價值，至關重要的是我們要減少要求 AI 為我們解決的問題空間。通過提供找到解決方案所需的 足夠多 的信息，并通過簡單的工具為我們的代理提供 足夠多 的能力，我們可以最大限度地減少幻覺毒害我們的響應的機會。
同樣，通過通過提示為每個代理制作職位描述，我們可以約束我們的代理的行為，限制他們可以訪問的工具，并提供對其工作績效的特定期望。
我們還了解到，并非所有模型都是平等創建的，并且用例應決定我們選擇的模型。但也許最關鍵的是，我們已經了解到，當我們使用 AI 原生平臺來管理這些問題而不是嘗試推出我們自己的 AI 集成平臺時，我們可以將成功部署的幾率提高一倍。
引用鏈接
[1] 5 Factors for Predictable Autonomy With Agentic AI:https://thenewstack.io/5-factors-for-predictable-autonomy-with-agentic-ai/[2]閱讀第 1 部分:https://thenewstack.io/how-to-build-agentic-ai-that-ships/[3]Spring AI:https://thenewstack.io/production-worthy-ai-with-spring-ai-1-0/[4]:https://cdn.thenewstack.io/media/2025/09/b4ab3435-springai_code.png[5]:https://cdn.thenewstack.io/media/2025/09/bfd8871f-system-prompt.png[6]:https://cdn.thenewstack.io/media/2025/09/1aa13866-simplified-model.png[7]數據發送到模型:https://thenewstack.io/5-useful-datasets-for-training-multimodal-ai-models/[8]Spring AI 以隔離開發人員:https://thenewstack.io/spring-cloud-gateway-the-swiss-army-knife-of-cloud-development/[9]此處:https://go-vmware.broadcom.com/from-cloud-native-to-ai-native[10]麻省理工學院的論文，批評企業 AI 部署，:https://www.npr.org/2025/08/23/nx-s1-5509946/bubbling-questions-about-the-limitations-of-ai[11]獨立研究:https://go-vmware.broadcom.com/from-cloud-native-to-ai-native[12]:https://cdn.thenewstack.io/media/2025/09/5a895ca6-ai-app-platform-importance.png
