當一個代理不夠用時
一個代理同時兼顧研究、寫程式、寫作與審查，往往會抓不住主線——它的 上下文 (context) 被混雜的關注塞滿，它的 工具選擇 (tool selection) 也變得糊塗。多代理系統 (multi-agent systems) 把工作拆給數個專門化的代理，每個都有聚焦的角色、小巧的工具集，以及自己的上下文。一個常見的形態是一個*編排者 (orchestrator)（或稱管理者）代理，它分解目標、把子任務委派給工作者 (worker)* 代理——一個研究員、一個程式設計師、一個批評者——再把它們的結果組裝起來。
專門化有幫助，但協調有代價。代理之間必須乾淨地傳遞結果、避免重複勞動、化解分歧——而每多一個代理，就讓詞元、延遲，以及整件事出岔的方式倍增。當一個工作真的有彼此分明的子角色時，再動用多個代理；對於線性的任務，一個建得好、有好迴圈的單一代理更簡單，通常也更好。
編排框架：那些接線
你大可以手寫那個迴圈、工具派發、記憶儲存、重試，以及代理對代理的訊息傳遞。代理編排框架 (agent orchestration framework) 把這些當成可重用的零件給你，讓你寫的是代理的邏輯，而不是水電工程。框架通常提供：一個迴圈執行器、一個工具註冊表、記憶後端、代理之間的結構化交接，以及可觀測性——讓你事後能精確看到每個代理想了什麼、做了什麼的軌跡與日誌。
框架與 模型上下文協定 (Model Context Protocol) 彼此互補得很漂亮：MCP 把代理如何連到一個工具標準化，而編排框架把代理如何被運行與協調標準化。兩者合起來，讓你能用可互換的工具與可重用的代理模式來組裝一個系統，而不是一坨纏在一起的客製腳本。
把代理送上正式環境
demo 代理與正式環境代理天差地別。在正式環境裡，每個迴圈都是真金白銀與真實延遲，工具呼叫碰的是真實系統，而來自網路的不可信輸入是持續的攻擊面。第 4 篇的穩健性——有界的迴圈、錯誤復原 (error recovery)、有錨點的 反思 (reflection)——變成必備，而你還要用監控把整件事包起來，好讓你比使用者更早注意到失敗。
MLOps 生命周期循环：部署、监控、检测漂移、再训练、再部署。
- 設下硬性上限——最大步數、逾時、花費上限——好讓任何單次運行都不會失控暴衝。
- 把危險的工具關在 人類介入 (human-in-the-loop) 的關卡後面；只讓安全、可逆的行動無人監督地跑。
- 把所有工具與網頁輸出都當成不可信的資料，以防範提示注入。
- 記錄每一個思考、行動與觀察；在每次變更前後，都用真實任務來評估代理。
- 漸進式推出——先用影子運行 (shadow run) 與一小片流量——並密切盯著軌跡。
這一切要往哪裡去
你現在握有了整條弧線：一個 大型語言模型代理 (LLM agent) 是處在「觀察—思考—行動」迴圈裡的模型；工具使用 (tool use) 與 函式呼叫 (function calling) 給它雙手；ReAct、規劃與記憶給它方法；反思、復原與人類監督給它可靠性；而多代理編排把它放大。每一層都拿原始的 自主性 (autonomy) 去換控制，而工程的工作，就是決定一個給定任務到底各需要多少。
誠實的前沿：今天的代理令人驚艷卻脆弱——在短而界定清楚的任務上很強，目標越長、越開放就越搖晃。這門手藝不是追逐最大自主，而是把代理的觸及範圍對準任務的利害輕重，並建好那些迴圈、界限與人類檢查點，讓你敢把真正的工作託付給它。
为什么更长的智能体循环更脆弱：端到端成功率是每一步可靠性的乘积，因此随着步数 n 增加会迅速下降。