隨意吐槽一下人工智慧代理的現況：
有些人不稱它們為代理，但具有確定性流程的「工作流程代理」無所不在，而且行之有效。任何人都可以建立簡單的工作流程代理，甚至可以從 Zapier 和 n8n 等無程式碼工具入手。建構複雜且可靠的工作流程代理則需要更多思考。針對常見且有價值的用例，並內建相關整合的複雜工作流程，既可以獨立作為一項業務，也可以作為未來擴展到其他工作流程或更自主工作的絕佳市場推廣方案。
更動態/自主的代理程式開始發揮作用，對研究（尤其是基於 Web 的）和編碼很有幫助。但一旦增加更多資料來源（例如 API），其可靠性就會降低。只讀代理程式感覺安全且易於測試，但讓自主代理程式執行操作（寫入）則令人擔憂。 （關於這一點，我有一個想法：如果像 CRM 這樣的工具允許用戶「fork」一個開發鏡像並運行自動化實驗，然後可以回滾或合併回主鏡像，那就太好了。）
動態智能體要高效運行，需要具備以下能力：(1) 制定並追蹤有效的計劃；(2) 正確執行任務；(3) 為每個步驟（包括計劃和每個任務）找到合適的上下文資訊。最後，它還需要 (4) 在執行過程中進行反思（無論是否需要人工幹預），以便適當調整計劃，並改進執行失敗或表現不佳的任務的方式。
任務規劃：LLM的推理能力 對於不需要私密情境的簡單任務清單（例如深度研究，只需進行一系列網路搜尋並進行總結），這種方法效果不錯。但如果要研究大量實體，深度研究的效果就不理想了，因為任務清單管理相對基礎。基於電子表格的AI工具更適合研究大量實體，因為任務管理實際上是將任務卸載到了電子表格中，而直接在提示之間傳遞冗長的任務列表在這裡行不通。編碼代理程式中的任務管理適用於簡單的問題、簡單的程式碼，或從零開始的情況。一旦涉及更複雜的現有項目，其可靠性就會降低——開發者可以透過記錄程式碼的工作原理和組織結構（.md檔案）來提高可靠性，這使得代理程式能夠建立更完善的任務清單。複雜的程式碼需要更多文檔，並最終動態地從這些文檔中提取相關的上下文資訊。許多人/企業對於處理專案的正確順序/方法/工具都有強烈的、未記錄的觀點，我們需要更多方法來預先記錄並隨時更新這些資訊。編碼和基於網路的研究代理之所以有效，另一個原因是它們都使用同一套工具，因此無需「學習」如何使用這些工具（下文將詳細介紹）。
任務執行：任務通常是 API 呼叫（需要身份驗證並了解如何使用 API 以及底層資料結構——例如 CRM 或具有自訂表/列的資料庫，資料結構可能獨一無二）、LLM 推理（例如，總結）、上述各項的組合，甚至包括工作流程代理*。研究代理其實就是循環中的網路搜尋和摘要。編碼代理程式是對程式碼庫的 CRUD 操作，也可能是網路搜尋學習 API。身份驗證和基本 API 存取似乎已經解決（MCP 符合要求），但我希望看到更多關於工具特定上下文的資訊（詢問用戶，但也需要在初始連接時進行分析，深入挖掘現有數據以了解工具的使用方式、數據結構以及我們使用該工具的場景/項目）。錯誤/反思/回饋需要轉化為有組織的學習成果，並在相關時作為情境回饋。相同的工具在不同的組織中可能用於不同的目的並以不同的方式使用，我們需要以某種方式捕獲/記錄這些信息，以便更好地執行任務。
想像一下你是一家公司的新進員工。你會在入職培訓期間學到很多東西（入職培訓越好，你上手後的工作效率就越高），然後是工作中的學習，這又可以細分為從組織經驗中學習（「我們就是這樣做的」）和從自身經驗中學習——前者在大公司中更為普遍。情境管理與之類似。上下文分為多個層次，例如元資料（使用者/公司）、專案/部門特定資訊、任務特定資訊、工具特定資訊等等。我們已經從簡單的系統提示發展到混合的紅黃綠（RAG）策略（向量、關鍵字、圖表），但除了擁有數據/上下文之外，我們還需要關於何時以及如何檢索上下文的指導，我們目前看到了一些早期版本——但還有很大的改進空間。這不僅僅是一個技術問題，也是一個業務問題——因為你基本上需要建立一個涵蓋所有預期場景的入職文件。隨著專案變得越來越複雜，我們需要更加周全地思考如何正確地篩選上下文，以便只在提示中包含相關信息，同時最大限度地減少無關的上下文。
反思：我們擁有能夠涵蓋 LLM/API 成本和觀察的智能體監控工具，但如何判定成功/失敗仍然是一個挑戰——在智能體編碼方面，其優勢之一在於能夠確定性地發現失敗（通過代碼測試）。對於許多其他智能體任務，我們仍在探索收集人類輸入以改善未來輸出的正確方法。據我所知，目前的反思機制是人機交互，反饋主要提供給人類開發者以改進智能體，但真正的突破在於如何將反思轉化為自我改進——即智能體能夠從任務列表生成和任務執行的失敗中汲取經驗，從而在下次做得更好。簡而言之，反思需要轉化為組織良好的上下文，以便在相關時將其提取到提示中。這將逐步發展為對智能體的各個部分進行微調，最終建構智能體強化學習環境——目前看來，這還處於起步階段。
*我之前提到過將任務交給工作流程代理，當你的代理不需要工作流程代理作為工具（而不是每次都去處理已知的任務列表）時，或者當你的系統足夠複雜，需要使用具有專門上下文和工具的專用代理才能更好地工作時，這種做法就變得有意義了。或者當你正在使用其他人建立的代理程式時（我開始注意到的一種模式是使用自然語言 API 端點來簡化代理程式之間的協作）。
如果我們擁有當今模型的質量，以及無限的內容視窗（質量不下降）、無限的計算能力、無限的存儲空間、瀏覽器訪問權限和支付方式，那麼一個LLM循環可能就足以完成很多工作。 上面這個毫無意義的觀點（沒有什麼是無限的）的重點是，代理編排主要在於透過建構結構和程式碼來管理限制，從而將工作從 LLM 中卸載出來。
生產環境中的代理程式形式多元：可以是內部工具，也可以是整合多種工具的獨立產品，還可以是核心工具的內建功能。它們可以是通用的，也可以是專用的。聊天代理、語音代理和後台代理似乎是觸發代理流程最常見的使用者介面。
還有什麼我沒考慮到的嗎？