引言

AI Agent其基礎架構可以簡單劃分為 Agent = LLM + 任務規劃（Plan） + 記憶（Memory） + 工具使用（Tools），現象級的AI Agent，例如deepresearch、manus、claude code等都在這個基礎框架上構建。

圖源 https://www.promptingguide.ai/research/llm-agents
任務規劃（Plan）是AI Agent中極其重要的關鍵步驟，任務規劃的質量直接影響最終回答的效果。好的任務規劃甚至能讓小模型的回答效果超越大模型。
在AI Agent的演進中，一個核心爭議始終存在：任務規劃應該完全交由大模型自主完成，還是需要人工規劃，AI只負責執行和分析？有人認為未來大模型將包辦一切規劃，那現在的Agent工程是否還有意義？
這個問題的答案，既關乎技術實現的複雜度，也直接影響業務場景的落地效果。
本文將以阿里雲RDS AI助手的實踐為例，結合當前熱門的AI Agent方案，探討這一問題的邊界與可能性。

一、大模型真的能自己拆任務嗎？我們的實測結果令人失望

Agentic AI，Gartner在2024年的<Top Strategic Technology Trends for 2025: Agentic AI>[1]中指出：
• 到 2028 年，33% 的企業軟件應用程序將包含Agentic AI，而 2024 年還不到 1%。
• 到 2028 年， 至少 15% 的日常工作決策將通過Agentic AI自主做出，在2024 年是0%。

圖源 https://www.gartner.com/doc/reprints?id=1-2J9CSAG9&ct=241104
Agentic AI中描述的AI自主完成複雜任務的拆解規劃，執行然後給出結果，讓人心神嚮往。
我們在 Agentic AI 領域算是先行者，於2025年4月在 GitHub 開源了阿里雲 RDS MCP[2]，其中提供的系統提示詞就強調了“任務拆解優先：必須先給出詳細的任務拆解步驟”。

alibabacloud-rds-openapi-mcp-server 提示詞
彼時，我們腦海中想象的是，工具 + 系統提示詞 + LLM = 無敵的數據庫專家。
然而現實跟我們預期相差甚遠，我們收到很多用户的使用反饋，那些嘗試通過這套模板解決各種問題的用户，普遍反饋遇到各種幻覺問題，偶爾有高光亮眼表現，大部分時候達不到預期。反而是少數有明確場景的用户（例如將 Agent 接入生產流程，通過自然語言創建實例等），通過自行編寫針對該場景的系統提示詞，就能很好地使用起來。
這些反饋給了我們很大的啓示，在測試的各種數據庫問題分析場景中，嘗試了各種提示詞工程，效果始終達不到預期，真所謂“一週出demo，半年用不好”。
在深刻反思後，我們終於看清了大模型的真實能力邊界，既然我們已經知道這類問題需要怎麼一步步去分析，又為何要苦苦求大模型搖骰子般給我們想要的答案？

二、企業要的是穩定，不是聰明：為什麼我們選擇人工規劃

企業在部署 AI Agent 時，最關注的不是“聰明程度”，而是“能否可靠工作”。其中的“可靠”就包括：
• 可解釋：不僅給出結論，還會給出推理過程及引用的相關數據，輔助用户對結論的準確性進行評估。
• 可重複：相同的場景，能夠重複使用，並且能夠得出相同的結論。
• 準確性：能夠有效對抗大模型幻覺，不會胡編亂造，給出準確可信的結論。
同時，企業部署AI Agent時往往是帶着明確的場景，有對應的企業知識庫、SOP等語料，有確定性的流程，這些特性也決定了人工規劃的可行性。簡而言之，企業Agent往往是為了將以前人來執行的重複流程，變成讓AI來執行，將人從重複性的工作中解放出來，提升企業效率。
企業對於可靠、重複流程AI化，這兩點述求決定了人工規劃，讓Agent按照設計好的步驟依次執行，是企業Agent的最佳選擇。
在數據庫運維場景是一個嚴肅的場景，任務規劃需要極強的確定性、可預測性和可解釋性。以阿里雲RDS AI助手為例，高頻問題場景（如CPU負載飆升、存儲空間不足），在這麼多年的運維中我們已經有一套成熟的SOP流程久經考驗，通過預設的診斷流程（人工規劃），系統會嚴格遵循“採集指標→定位根因→生成修復建議”的路徑，每一步都注入企業知識庫中的診斷規則。例如，當檢測到CPU負載異常時，系統會自動調用預定義的檢查清單，依次驗證連接數、慢SQL、索引缺失等問題，確保輸出結果的穩定性與可解釋性。
當提到SOP、工作流這些詞時，很容易讓人想到落後、固化、hard coding的規劃引擎。事實上，基於現在的大模型能力，我們完全可以通過提示詞工程來讓AI按照我們預設的步驟依次執行。
❌ def 獲取監控數據 --> def 獲取慢日誌 --> def 獲取錯誤信息 --> LLM “分析上面幾個步驟的返回結果”
✅Prompt：你是一個專業的數據庫診斷專家，負責數據庫異常診斷。你的工作流程是：1. 獲取監控數據；2. 獲取慢日誌；3. 獲取錯誤信息。你嚴格按照工作流程來進行工作，現在開始你的任務。
通過系統提示詞控制工作流程的好處在於你需要對流程進行更改時，只需要補充對應的工具和調整提示詞，不用花費大量時間去重新編排流程。
例如在RDS AI助手的慢SQL優化場景中，提示詞如下，通過這套結構化的系統提示詞進行任務規劃，在多次測試中都能夠讓AI按照我們預想的流程進行分析總結。

# Role: 數據庫SQL問題排查專家
你是一位精通SQL問題排查的數據庫專家，專注於為客户提供關於SQL問題排查、慢SQL調優的高效技術支持和解答。你的目標是通過清晰的問題拆解、精準的工具調用以及準確的時間計算，幫助客户快速解決問題。所有內容必須基於專業知識和獲取到的數據，不得杜撰。
### 示例分析
{{案例注入}}
## Rules
{{規則限定}}
## Skills
{{技能配置}}
## Workflows
### 目標
分析慢SQL和錯誤SQL的根本原因，並提供優化建議，幫助用户快速解決SQL相關問題。
### 分析步驟
#### 步驟 1: 獲取時間段信息
- 獲取對應的時間段,明確需要分析的具體時間段或者SQL內容....
#### 步驟 2: 提取慢SQL日誌
- 獲取指定時間段內的慢查詢日誌,根據日誌中的執行時間、掃描行數等指標，篩選出高耗時SQL語句,分析這些SQL的執行計劃，找出性能瓶頸（如全表掃描、索引失效等）。
#### 步驟 3: 獲取對應表結構
- 若存在慢SQL信息，則獲取對應SQL的表結構....
#### 步驟 4: 檢查錯誤日誌
- 獲取指定時間段內的錯誤日誌,分析日誌中的報錯信息，判斷是否存在語法錯誤、權限問題或其他異常。
#### 步驟 5: 獲取性能監控數據
- 使用 RDS 工具獲取實例的指定時間段內的監控數據....
#### 步驟 6: 監控指標分析
- 分析性能監控數據，識別異常時間點及其對應的性能指標波動.....
#### 步驟 7: 綜合分析與優化建議
- 根據性能監控、慢SQL日誌、錯誤日誌和性能監控數據的分析結果，綜合評估SQL問題的根本原因。提供針對性的優化建議，包括但不限於：添加或調整索引以提升查詢效率....
  
現在用户的提出SQL相關的分析與優化，你的目標是按照workflows的定義以及流程進行工作，給出你的優化建議。**首先對任務進行分解步驟並簡要描述各步驟**，然後再根據workflow進行工作。

這裏給大家推薦一個系統提示詞優化工具[3]，它能夠將你簡單的輸入變成各種結構化的系統提示詞，十分方便。
我們收集整理了RDS過去10多年運維形成的各類場景SOP，總結分析了過去一年的幾千工單並形成案例庫，構造50多種異常場景，對比自主規劃和人類規劃兩種agent的準確率，在多輪測試中，人工規劃的agent能夠在多種場景中精確分析到具體根因，而自主規劃的agent對於相同表象，不同根因的異常場景，反而無法做到精確劃分根因，經常將“果”做“因”，得出籠統結論。體現在準確率上，人工規劃的準確率達到85%以上，而自主規劃的 Agent 準確率僅在20%左右徘徊。

在深入分析後，我們發現自主規劃的泛化能力往往僅體現在面對不同垂直場景時能做出不同規劃，但無法做到在一個垂直場景內繼續細分。

人工規劃會面臨規則爆炸 ？

你可能會問：如果每個場景都要寫一套規則，會不會陷入“規則爆炸”？
我們的解法是——用案例庫代替規則庫。
想象醫生看病：先問診、開檢查單、看結果，再結合經驗判斷需要更多檢查還是確認病因。同理，我們可以：

1. 用 SOP 做第一輪信息採集和特徵提取；
2. 將採集到的特徵與歷史案例庫匹配；

3. 根據匹配結果，決定是繼續收集信息，還是直接給出診斷。
   這樣，規則不再是死板的 if-else，而是由真實工單沉澱出的案例庫。每處理一個新問題，Agent 就變得更“老道”一點。
   

   三、不走極端：我們如何用‘混合規劃’兼顧靈活與可靠

   技術架構的選型不是非黑即白，而是因地制宜。我們相信存在即合理，在合適的場景使用合適的技術才能發揮其最大價值。
   為什麼選“混合規劃” ？ -- 從用户場景做選型
   我們對過去一年的幾千個用户工單問題進行人工分析及總結歸納，最終發現在工單問題中，既有開放性的問題，例如：
   • rds mysql對於大數據量表（上億條數據）如何添加加索引？
   • 如何快速的備份一份數據放到線下的數據庫?
   • 數據庫有連接報錯的日誌，是有什麼問題嗎 ？
   • 實例怎麼變更成serverless模式 ？
   • ....
   這類問題的特點是範圍發散、難以枚舉，且對任務規劃的要求不高，基本上文檔檢索結合實例信息，就可以做到精確回答，這類問題在所有工單問題中佔比達到50%。
   剩下的50%工單問題，則比較聚焦，高頻出現的問題，例如：
   • CPU使用率問題：
   • 實例的CPU使用率很高，需要幫忙分析下是什麼原因導致的？
   • 實例在xx時間點CPU突然打滿，需要排查下是為什麼。
   • SQL使用或優化問題：
   • 實例這條慢SQL不明白為什麼執行慢，需要幫忙看下怎麼優化。
   • SQL執行報錯了，但是看語法不明白
   • 存儲空間問題：
   • 實例磁盤空間滿了，需要幫忙分析下使用分佈。
   • 磁盤空間突然上漲，需要幫忙分析下是哪裏增長了。
   • ...
   這些問題的特點是需要精確的規劃，多輪分析，才能做根因定位。例如CPU使用率問題，需要看監控數據，觀察是否有會話突增，獲取CPU最高點的Profiling進行熱點分析，查詢慢SQL和SQL審計觀察是否有和Profiling熱點匹配的關鍵SQL，對關鍵SQL做執行計劃分析，總結特徵進行案例診斷，並決定是否要繼續獲取更多數據（鎖表、buffer pool命中率等等）。通過上述CPU例子可以看出，這類深度診斷的場景具備很深厚的專業知識，若依賴大模型進行自主規劃，容易出現因果顛倒的情況，舉個簡單的例子，業務突增導致CPU快速打滿，而CPU打滿後原本很多正常SQL也會變成慢SQL，此時僅靠大模型的規劃分析，會經常捕捉不到會話突增這個關鍵信息，而是給出因為慢SQL導致CPU打滿。
   通過對用户工單問題的整體分析，我們最終採用多Agent混合架構，在不同場景中靈活切換規劃模式：
   
   RDS AI助手多Agent架構
   • 泛化場景：以大模型自主規劃為主，人類規則兜底。
   面對用户提出的開放性、邊界模糊的問題（例如“數據庫有連接報錯的日誌，是有什麼問題嗎 ？”），我們啓用“探索型Agent”。該Agent允許大模型在預設的安全邊界內進行自主任務拆解，比如動態決定是否需要查監控、看日誌、分析SQL等。同時對常見的幾類最常見的幻覺場景進行了提示詞引導及工程兜底：
   時間理解：數據庫問答場景中，會經常出現“最近一個小時的運行情況”這類相對時間的問題，每個模型都有其知識最後的終止時間，如果不強調獲取當前時間來理解相對時間，那麼很可能出現大模型基於離譜的過去時間來計算“最近一小時”。同時，會默認在用户問題前面注入“當前時間： xxx”，強調時間概念。
   
   時間注入示例
   工具調用：大模型經常會自行捏造不存在的工具導致對話異常，這種場景下，需要在對話上下文中提醒大模型，該工具不存在。
   
   工具異常處理示例
   真實數據：強調結論必須基於調用工具獲取真實數據（如禁止憑空編造慢SQL）。
   • 垂直場景：以人工SOP驅動為主，大模型負責執行與推理
   對於高頻、高確定性的運維場景（如“CPU使用率突增至95%”“實例存儲空間不足”“SQL執行花了10多秒”），我們採用“執行型Agent”。該Agent除了具備上述對抗幻覺的設計外，任務規劃是嚴格遵循標準化診斷流程（SOP），大模型的角色被限定為：
   • 按順序調用工具獲取數據；
   • 對結構化數據進行歸納與解釋；
   • 依據知識庫規則生成可操作建議。
   規劃路徑完全由人工預設，確保每一步可追溯、可復現、可審計。在此類場景中，我們不追求“創造性”，而追求“準確率”。
   分場景設計多 Agent 架構不僅能提升規劃能力，還能有效縮短上下文長度。原因在於我們的MCP Server中提供了超30種工具，光工具的上下文加起來就有9K，細分場景後，我們可以根據不同的場景只提供特定的工具列表，垂直類Agent的工具上下文從9K能夠縮短到~1K，TTFT和工具調用準確率顯著提升。
   規則切換：關鍵詞匹配為主，大模型意圖識別為輔
   在上面的架構中可以看到，怎麼把問題路由到對應的Agent直接決定了問題回答的準確率。在意圖識別上，除了在分類器的提示詞裏面加上few shot，讓用户能夠準確地描述問題更加重要。
   為了讓用户能夠準確的提出問題，同時能夠從功能的角度直觀看到RDS AI助手“能做什麼”，我們在歡迎頁進行場景引導，這種交互的改進，將用户原本需要自行清晰描述問題的操作，簡化為點擊兩次按鈕（選擇場景、選擇實例），既能提升操作體驗，又能讓後端根據問題模板進行關鍵詞路由，無需大模型介入。
   
   RDS AI助手預設對話模板
   關鍵詞問題分類代碼示例如下。
   import re

   定義關鍵詞與 agent 的映射關係

   RULES = {
    r"磁盤空間|硬盤剩餘|存儲分析": storage_agent,
    r"CPU使用率|cpu佔用|處理器負載": cpu_agent,
    r"慢SQL|慢查詢|SQL性能|執行慢": sql_agent,
    ...
   }
   def classify(query):
    query_lower = query.lower().strip()
    
    for pattern, agent in RULES.items():
        if re.search(pattern, query_lower):
            return agent
    
    # 若無匹配，則交給LLM進行分類
    return classier_by_llm(query)

   在 LLM 分類方面，我們發現：除了提供 few-shot 示例，若在提示詞中引導大模型先進行簡要分析再給出結論，其分類準確率會顯著高於直接輸出結論的方式。

4. SQL問題分析：用户給定具體的SQL，希望分析為什麼SQL報錯、SQL執行結果不符合預期、諮詢SQL語法問題，或者詢問一個時間範圍內的SQL執行或SQL性能相關問題。
5. 存儲空間使用率診斷：用户希望查詢分析磁盤或者存儲空間的大小，使用分佈；希望瞭解磁盤空間滿導致無法對實例、數據庫執行操作的原因。
6. CPU使用率診斷：用户希望分析實例CPU使用率異常原因，包括CPU使用率為什麼突增...。

7. 諮詢問題：用户希望瞭解RDS具體的一項功能...

   示例

   Q：幫我分析下這個慢SQL。
   A：分析：用户想做SQL分析。
   分類：SQL問題分析
   Q：磁盤空間突然升高了，分析下什麼原因。
   A：分析：用户需要幫忙診斷存儲空間的分佈和增長情況。
   分類：存儲空間使用率診斷
   Q：CPU佔用滿了，看下什麼原因。
   A：分析：用户需要幫忙診斷CPU使用率情況。
   分類：CPU使用率診斷
   Q: 為什麼客户端IP跟我本地不一樣？
   A：分析：用户詢問RDS裏面關於客户端IP顯示問題。
   分類：諮詢問題
   Q: DTS 數據傳輸服務
   A：分析：用户詢問DTS，可能需要通過DTS遷移數據庫到RDS。
   分類：諮詢問題

   回答模板

   分析：(對問題進行簡短分析)...。
   分類：其他問題
   一步一步思考，給我問題的最終分類。分析過程不得超過50個字，然後給出最終分類。

   ## 四、總結
   AI Agent 的規劃能力不應再被簡單地理解為“全自主”或“人工”的非此即彼選擇，而應基於產品定位、目標用户和具體應用場景進行系統性權衡。
   在當前階段，若構建的是開放性問答類 Agent，適度交由大模型自主規劃不失為高效策略；但若對準確性、穩定性有較高要求，則完全依賴模型自主決策仍顯倉促。我們需對大模型的“智能”保持理性認知——在 Agent 的開發體系中，人類仍應作為最終的決策者與主導者，而 AI 更適合作為執行者與分析者。
   隨着工具調用、記憶機制和規劃能力的持續進化，AI Agent的自主性邊界會不斷擴展。但在可預見的未來，高價值、高風險的企業場景，仍需要人類專家設定路線。要打造一個真正穩定可靠的 Agent，紮實的工程化能力以及熟悉行業流程，缺一不可，至關重要。
   大模型的普及帶來了算法層面的“平權”，也讓垂直領域的行業知識愈發珍貴。**未來屬於那些既深諳特定行業邏輯，又懂得如何將大模型能力與實際場景深度融合、實現“Agent 化”的複合型人才。**
   RDS AI助手的實踐告訴我們：**真正的智能，不是讓AI取代人，而是讓人與AI各司其職。**
   當領域知識與大模型能力深度融合，Agent才能從“能聊”走向“能用”，從“玩具”變成“工具”。
   這，才是企業級AI落地的正道。
   **參考鏈接：**
   [1]https://www.gartner.com/doc/reprints?id=1-2J9CSAG9&ct=241104
   [2]https://github.com/aliyun/alibabacloud-rds-openapi-mcp-server/blob/main/README_CN.md