什麼是 AI Agent 系統#
- Agent 系統是一種能夠獨立完成任務的系統，與傳統軟體不同，它可以在用戶授權下高度獨立地執行工作流。
- Agent 系統的核心在於利用 LLM 進行工作流管理和決策，並能夠根據需要動態選擇工具與外部系統互動。
何時應該構建 AI Agent 系統#
- Agent 系統適用於那些傳統自動化方法難以處理的複雜、多步驟任務，例如需要複雜決策、難以維護規則或依賴非結構化數據的場景。
- 例如，在支付欺詐分析中，Agent 系統能夠像經驗豐富的調查員一樣評估上下文並識別可疑活動。
AI Agent 設計基礎#
- Agent 系統由三個核心組件構成：模型（LLM）、工具（外部 API）和指令（明確的行為指南）。
- 模型選擇應基於任務複雜性、延遲和成本的權衡。
- 工具應標準化定義，以便在代理系統之間靈活使用。
- 指令需要清晰明確，以減少歧義並提高決策質量。
編排模式#
- 單 Agent 系統：一個模型配備適當工具和指令，以循環方式執行工作流。
- 多 Agent 系統：將工作流分布在多個協調的 Agent 之間，分為 “管理型”（一個中心 Agent 協調多個專業 Agent）和 “去中心化型”（多個 Agent 平等地相互移交任務）。
防護欄#
- 防護欄是確保 Agent 系統安全運行的關鍵，用於管理數據隱私風險和聲譽風險。
- 防護欄可以包括相關性分類器、安全性分類器、PII 過濾器、內容審核和工具安全評估等。
- 防護欄的設置應基於實際風險，並隨著新漏洞的發現而不斷調整。
實施建議#
- 從單 Agent 系統開始，逐步擴展到多 Agent 系統。
- 使用靈活的提示模板來簡化維護和評估。
- 在 Agent 系統中實施人類干預機制，以應對高風險或失敗的情況。
Agent 提示詞實踐#
Persistence (持久性)#
告訴模型這是一個多輪人物，需要一直工作到問題解決，不是回答一句就完事
You are an agent - please keep going until the user’s query is completely resolved, before ending your turn and yielding back to the user. Only terminate your turn when you are sure that the problem is solved.
->
你是一个智能助手 - 请持续工作直到用户的问题完全解决，再结束你的回合。只有当你确定问题已解决才停止。
Tool-calling (工具調用)#
鼓勵模型在不確定時主動使用工具查詢，而不是瞎猜
If you are not sure about file content or codebase structure pertaining to the user’s request, use your tools to read files and gather the relevant information: do NOT guess or make up an answer.
->
如果你不确定文件内容或代码结构，请使用工具查询相关信息：绝对不要猜测或编造答案。
Planning (規劃)#
引導模型在每次調用工具前先規劃，調用後再反思。這能讓模型 “把思考過程說出來”，提高解決問題的能力 (推理模型不依賴)
You MUST plan extensively before each function call, and reflect extensively on the outcomes of the previous function calls. DO NOT do this entire process by making function calls only, as this can impair your ability to solve the problem and think insightfully.
->
你必须在每次函数调用前进行详细规划，并在调用后对结果进行深入反思。不要只依靠函数调用解决整个问题，
工具調用的正確姿勢#
- 強烈建議用 API 的 tools 字段：別再手動在提示詞裡塞工具描述了！官方測試表明，通過 API 傳遞工具定義，可以減少錯誤，讓模型表現更好（SWE-bench 提升 2%）
- 起個好名字，寫清楚用途：工具名稱和描述要清晰明了，參數也一樣，這能幫模型正確使用工具。
- 複雜工具用法放例子裡：如果工具比較複雜，最好在系統提示中專門開個 "# Example" 部分，保持描述簡潔。
推薦的指令編寫流程#
- 先給出整體要求：用 "指令" 或 "回覆規則" 標題列出基本要求
- 分點說明細節：針對具體行為用子標題詳細說明
- 明確步驟順序：如需按特定流程操作，用有序列表明確標出
- 調試與優化：
- 檢查指令間是否矛盾
- 提供清晰的例子演示你想要的結果
- 謹慎使用全大寫、感嘆號等強調手段，可能導致模型過度關注這些點
常見的坑和解決辦法#
- 必須 XX陷阱：比如強制要求 “每次回覆前必須調用工具”，可能導致模型亂調用。解決方法：補充說明 “信息不足時先詢問用戶”。
- 照搬示例問題：模型可能直接複製你給的例子。解決方法：明確說明 “參考但不限於這些例子，根據情況靈活調整 "。
- 話太多問題：有時模型會輸出太多解釋或不必要的格式。解決方法：在指令中明確要求簡潔和具體格式”。
上下文處理#
- 能力邊界：雖然基礎能力強，但在需要從海量信息中檢索很多信息，或者進行需要全局信息的複雜推理時，性能可能會下降。
- 最佳實踐：把指令同時放在上下文的開頭和結尾各重複一次
- 可以明確指示模型是只能用你提供的信息回答，還是可以結合自身知識庫
思維鏈#
引導模型像人一樣 “思考”，把複雜問題分解成小步驟解決簡單的思維鏈指令 （推理模型不依賴）：
...First, think carefully step by step about what documents are needed to answer the query. Then, print out the TITLE and ID of each document. Then, format the IDs into a list.
->
...首先，仔細逐步思考需要哪些文檔來回答查詢。然後，列出每個文檔的標題和ID。最後，將ID格式化為列表。
進階 CoT：如果發現模型思考過程有偏差，可以通過更具體的指令來規範它的思考策略。比如，指南裡給了一個例子，要求模型先做查詢分析 (Query Analysis)，再做上下文分析 (Context Analysis)，最後綜合 (Synthesis)。
推薦的 Prompt 結構模板#
# Role and Objective
# Instructions
## Sub-categories for more detailed instructions
# Reasoning Steps (e.g., Chain of Thought instructions)
# Output Format
# Examples
## Example 1
# Context (if any)
# Final instructions and prompt to think step by step (e.g., the CoT starter)
->
# 角色和目標
# 指令
## 更詳細指令的子類別
# 思考步驟（如思考鏈指令）
# 輸出格式
# 示例
## 示例1
# 上下文（如有）
# 最終指令和逐步思考提示
分隔符選擇#
- 首選 Markdown：標題、列表、代碼塊等，清晰直觀
- XML 也不錯：適合精確包裹內容，便於嵌套
- JSON 相對繁瑣：結構強但在提示詞中可能需要轉義
- 長文檔場景：XML (
<doc id=1 title=”...”>...</doc>) 和類表格 (ID: 1 | TITLE: ... | CONTENT: ...) 格式效果好，JSON 表現較差