構建一個可運作的 AI 代理：實用詞彙表

AI 代理是一個程式，它接收一個目標，決定一系列動作，並使用工具執行這些動作直到目標達成或放棄。這與聊天機器人不同，聊天機器人只是回應訊息。代理會規劃、呼叫函式、檢查結果並調整。如果你只透過瀏覽器使用過 ChatGPT，構建你的第一個代理是模型從文字生成器轉變為更大系統中的一個組件的地方。

核心迴圈

每個代理，無論如何行銷，都執行相同迴圈的某個版本：觀察、思考、動作、重複。具體來說：

1. 代理接收一個任務（「找到下個月飛往里斯本的最便宜機票並草擬一份電子郵件摘要」）。
2. 它用任務加上可用工具的描述呼叫 LLM。
3. 模型返回最終答案或工具呼叫，例如 search_flights(destination="Lisbon", month="2025-06")。
4. 你的程式碼執行該函式，獲得真實結果，並將其輸入回模型的上下文。
5. 模型決定接下來做什麼：呼叫另一個工具、要求澄清，或完成。

這個模式通常被稱為 ReAct 迴圈（推理加動作），它是 LangChain 的代理執行器、LlamaIndex 代理和 OpenAI 的函式呼叫 API 等框架的骨幹。你可以用 Python 在不到 100 行程式碼中實現整個過程，只需一個 LLM API 和一個 while 迴圈——框架增加的是便利性，而非魔法。

工具是使其成為代理的關鍵

沒有工具的模型只能談話。給它函式，它就能動作。工具通常是普通的 Python 函式，搭配描述其名稱、參數和目的的模式，以便模型知道何時以及如何呼叫它們。例子：

def get_weather(city: str) -> str:
    """Return current weather for a given city."""
    resp = requests.get(f"https://api.weather.example/v1/{city}")
    return resp.json()["summary"]

使用 OpenAI 的函式呼叫，你傳遞一個 JSON 模式以及此函式，模型輸出結構化呼叫如 {"name": "get_weather", "arguments": {"city": "Lisbon"}} 而不是自由形式文本。你的程式碼解析它、執行真實函式，並將結果作為對話中的新訊息返回。重複直到模型有足夠資訊來回答。

記憶和狀態

單一 API 呼叫在其上下文視窗之外沒有記憶。代理需要明確的狀態：訊息的執行清單（對話歷史），通常還有一個單獨的存儲用於較長期的事實。對於短期任務，代表對話的 Python 字典清單就足夠了。對於需要跨會話記住事物的代理，你會使用向量資料庫（Chroma、Pinecone、Qdrant）來透過嵌入存儲和檢索相關的過去資訊。

不要在早期過度設計。許多「代理」專案失敗不是因為 LLM 較弱，而是因為狀態管理不夠周密：重複訊息、無限制的上下文成長，或遺失追蹤哪個工具呼叫屬於哪個結果。

最小可運作範例

這是使用 OpenAI API 的最簡陋代理的形狀，沒有框架：

messages = [{"role": "user", "content": "What's the weather in Lisbon?"}]

while True:
    response = client.chat.completions.create(
        model="gpt-4o",
        messages=messages,
        tools=[weather_tool_schema],
    )
    msg = response.choices[0].message
    if msg.tool_calls:
        for call in msg.tool_calls:
            result = get_weather(**json.loads(call.function.arguments))
            messages.append(msg)
            messages.append({
                "role": "tool",
                "tool_call_id": call.id,
                "content": result,
            })
    else:
        print(msg.content)
        break

這是一個真實、有效的代理。其他一切——規劃策略、多代理協調、檢索管線——都建立在這個迴圈之上。

容易出問題的地方

代理以可預測的方式失敗：當模型無法判斷成功時發生無限工具呼叫迴圈、幻想函式參數，以及從重新呼叫昂貴工具導致的成本失控。使用硬反覆上限（例如 10 步）防止迴圈，並在開發期間記錄每個工具呼叫。在執行任何涉及真實系統的操作之前驗證參數——可以發送電子郵件或執行 shell 指令的代理需要與面向使用者的程式碼相同的輸入淨化，因為 LLM 實際上是一個不信任的使用者生成該輸入。

接下來去哪裡

一旦迴圈運作，有趣的問題就開始了：在單代理和多代理設計之間選擇、決定授予多少自主權，以及當輸出不確定時可靠地測試代理。Korra Studio 的 AI 和 Python 課程若你想從這裡繼續構建，涵蓋檢索增強生成、提示設計和工具呼叫模式的更多深度。