數據分析一直是現代社會中的重要工具，它幫助我們洞察本質、發現規律并指導決策。然而，數據分析過程往往復雜且費時，因此我們期望存在一個智能助手助力用戶直接 “與數據對話 “。得益于大語言模型（LLM）的發展，虛擬助手和 Copilot 等智能 Agent 紛紛涌現，它們在自然語言理解和生成方面的表現令人嘆為觀止。但遺憾的是，在處理復雜數據結構（如 DataFrame, ndarray 等）和引入領域知識方面，現有的 Agent 框架仍然舉步維艱，而這恰恰是數據分析和專業領域中的核心需求。

為了突破這一瓶頸，微軟推出了 TaskWeaver—— 一款代碼優先的 Agent 框架。TaskWeaver 能夠將用戶的自然語言請求巧妙地轉化為可執行代碼，并支持豐富的數據結構、動態插件選擇以及專業領域適應的規劃過程。作為開源框架，TaskWeaver 充分發揮了大語言模型的潛力，通過可定制的示例和插件融入特定領域知識，讓用戶能夠輕松打造個性化虛擬助手。

• 論文：TaskWeaver: A Code-First Agent Framework
• 論文地址：https://export.arxiv.org/abs/2311.17541

TaskWeaver 項目已在 GitHub上開源，并于發布當日登上 GitHub 趨勢榜，目前已收獲 2.9k 個 star，在領英等社交平臺上也有一些實用案例（例如用 TaskWeaver 進行 SAP 數據分析）。

• 項目主頁：https://microsoft.github.io/TaskWeaver/
• 項目地址：https://github.com/microsoft/TaskWeaver

故事示例

追蹤銷售數據中的隱藏秘密

作為商業分析師的小雅，她的日常工作之一就是從近期的銷售數據中找出異常現象，從而指導公司調整銷售策略。所有銷售數據都安全地存儲在一個 SQL 數據庫中。她渴望通過與 AI 助手的自然語言交流來輕松提取和分析數據。更重要的是，在銷售領域，異常現象有其獨特性，因此她希望 AI 助手能采用定制的異常檢測算法來解決問題。圖 1 生動地展示了小雅與 AI 助手的聊天實錄。在收到小雅的求助信息后，AI 助手首先從數據庫中提取出相應數據，并匯報給小雅進行確認。隨后，該 AI 助手運用專屬異常檢測算法進行分析，并最終向小雅展示出一份直觀的可視化結果。

圖 1. 故事示例中的對話實錄

Agent 框架需要具備哪些技能？

通過上述小雅的故事，我們梳理了 Agent 框架應具備的幾大核心能力：

1. 插件支持：在上面的故事中，Agent 需要從數據庫中獲取數據，然后使用指定的異常檢測算法。為了完成這些任務，智能助手需要能夠定義和調用自定義插件，如 “query_database” 插件和 “anomaly_detection” 插件。

2. 豐富的數據結構支持：Agent 需要處理復雜的數據結構，如數組、矩陣、表格數據等，從而順利進行高級數據處理，如預測、聚類等。此外，這些數據應能在不同插件間無縫傳遞。然而，現有的大多數 Agent 框架會將數據分析的中間結果轉換為 Prompt 中的文本，或者先將它們保存為本地文件，然后需要時再讀取。然而，這些做法容易出錯和超過 Prompt 的字數限制。

3. 有狀態執行：Agent 往往需要與用戶進行多輪迭代交互，并根據用戶輸入，生成并執行代碼。因此，這些代碼的執行狀態應在整個會話期間保留，直到會話結束。

4. 先推理后行動（ReAct）：Agent 應該擁有 ReAct 的能力，即先觀察推理后再采取行動，這在一些存在有不確定性的場景中非常有必要。例如，在上述樣例中，由于數據庫中的數據模式（schema）通常比較多樣，因而 Agent 必須首先獲取數據模式信息并了解哪些列是合適的（且與用戶確認），然后才可以將相應的列名輸入到異常檢測算法中。

5. 生成任意代碼：有時候，預定義的插件無法滿足用戶的請求，Agent 應能夠生成代碼以應對用戶的臨時需求。在上述示例中，Agent 需要生成代碼來可視化檢測到的異常，而這個過程是不借助于任何插件來實現的。

6. 融入領域知識：Agent 應提供一種系統性的方案來融入特定領域的知識。這將幫助 LLM 進行更好的規劃和準確地調用工具，從而產生可靠的結果，尤其是在行業定制的場景中。

揭秘 TaskWeaver 的核心架構

圖 2 展示了 TaskWeaver 的總體架構，包括規劃器（Planner），代碼解釋器（Code Interpreter），以及記憶模塊（Memory）。

規劃器就像是系統的大腦，它有兩個核心職責：1）制定計劃，即把用戶的需求拆分成子任務，將這些子任務逐個發送給代碼解釋器，并在整個計劃執行過程中根據需要自我調整計劃方案；2）回應用戶，它會將代碼解釋器的反饋結果轉換成用戶容易理解的答案并發送給用戶。

代碼解釋器主要由兩個組件組成：代碼生成器（Code Generator）會收到規劃器發送的子任務，結合現有可用的插件以及領域特有的任務示例，來生成相應的代碼塊；代碼執行器（Code Executor）則負責執行生成的代碼，并在整個會話過程中保持執行狀態。正因為此，復雜數據結構可以在內存中傳遞而無需通過 Prompt 或者文件系統。這就像在 Jupyter Notebook 中用 Python 編程，用戶在單元格中輸入代碼片段，程序的內部狀態會按順序執行保留下來并且可被后續過程被引用。在實現上，每個會話中，代碼執行器都會有一個獨立的 Python 進程來執行代碼，從而支持同時服務多用戶。

記憶模塊主要存儲了整個系統運行過程中的有用信息，如執行結果等，可以被不同的模塊寫入和讀取。短期記憶主要包括當前會話中用戶和 TaskWeaver 之間的通信記錄，以及各模塊之間的通信記錄。長期記憶則包括了用戶可預先定制的領域知識，以及在交互過程中總結出的一些經驗等等。

圖 2. TaskWeaver 整體架構示意圖

除了基本架構之外，TaskWeaver 還具有許多獨特的設計。例如，會話壓縮功能可以減小文本大小，從而允許更多的對話輪數；動態插件選擇功能能夠根據用戶請求自動挑選合適的插件，從而允許集成更多的定制插件。此外，TaskWeaver 還支持經驗保存功能，用戶在使用過程中通過輸入命令即可觸發該功能，它將總結用戶在當前會話中的經驗教訓，避免在下次會話中重復錯誤，實現真正的個性化。在安全性方面，TaskWeaver 也進行了精心設計，例如用戶可以指定一個 Python 模塊的白名單列表，如果生成的代碼中引用了白名單之外的模塊，將觸發錯誤，從而降低安全風險。

TaskWeaver 的具體流程

圖 3 向我們展示了 TaskWeaver 在完成前述樣例任務的部分流程。

首先，規劃器接收用戶的輸入，結合各模塊功能描述和規劃示例生成具體規劃。該規劃包含四個子任務，而其中第一個子任務是從數據庫中提取數據并描述數據模式。

然后，代碼生成器根據其能力描述和所有相關插件的定義生成一段代碼。這段代碼調用了 sql_pull_data 插件，將數據保存到 DataFrame 中，并提供數據模式的描述。

最后，生成的代碼會被發送到代碼執行器中執行，完成后的結果將被發送到規劃器中以更新規劃或者進行下一個子任務。圖中執行結果顯示 DataFrame 中有兩個列，即日期和數值。規劃器可以進一步與用戶確認這些列是否正確，或者直接進行下一步的 anomaly_detection 插件的調用。

圖 3. TaskWeaver 內部工作流

TaskWeaver 中如何注入領域知識？

在大模型應用中，整合特定領域知識的主要目的是提高 LLM 在行業定制中的泛化性能。TaskWeaver 提供了三種將領域知識注入模型的方法：

• 使用插件進行定制：用戶可以通過自定義插件的形式整合領域知識。插件可以有多種形式，如調用 API，從特定數據庫中抓取數據，或運行特定的機器學習算法或模型等。插件定制相對直觀，只需提供插件的基本信息（包括插件名稱、功能描述、輸入參數和返回值）以及 Python 實現。
  
• 使用示例進行定制：TaskWeaver 還為用戶提供了一個系統化的接口（以 YAML 格式）來配置示例，從而教導 LLM 如何響應用戶請求。具體而言，示例可以分為兩種類型，分別用于規劃器中的規劃制定和代碼生成器中的代碼編程。
  
• 進行經驗保存：TaskWeaver 支持用戶將當前會話過程總結并存儲為長期記憶。用戶可以將專業領域知識作為對話內容對 TaskWeaver 進行 “教學”，隨后保存對話為經驗。在后續的使用過程中就可以通過動態加載經驗，更好地完成專業領域問題。

如何使用  TaskWeaver？

TaskWeaver 的完整代碼目前已在 GitHub 上開源。目前支持三種方案進行使用，分別是命令行啟動，網頁服務，以及以 Python 庫的形式導入。在簡單安裝后，用戶只需要配置幾項關鍵參數，如 LLM API 地址、密鑰和模型名稱，即可輕松啟動 TaskWeaver 服務。

圖 4. 命令行啟動界面

圖 5. TaskWeaver 運行樣例

TaskWeaver 是一款全新的 Agent 框架方案，其設計符合數據分析和行業定制場景的需要。通過將用戶語言轉成程序語言，「與數據對話」將不再是夢想，而是現實。