在AI技術飛速發展的今天，智能體（AI Agent）的概念備受關注，被一些人視為解決復雜問題的萬能鑰匙。然而，智能體并非萬能，其應用需要結合實際問題和工作流程設計。本文深入探討了智能體的實質和如何設計適合AI的工作流，以實現問題的有效解決。

現在 AI 智能體（AI Agent）的概念很火，似乎智能體是用 AI 解決問題的銀彈，有了智能體就可以解決很多問題。但也有很多人有不同意見，認為智能體不過是噱頭，并沒有看到靠譜的應用場景。

一個被提及很多的是吳恩達老師寫的多智能體翻譯的例子，簡單來說就是用三個智能體：一個直譯智能體、一個審查智能體、一個意譯潤色智能體，確實可以大幅提升翻譯質量。但并非一定要三個智能體才能提升翻譯質量，我以前也提出過基于 Prompt 的翻譯方法，讓 LLM 在翻譯時，使用直譯 + 反思 + 意譯三個步驟輸出，也可以得到高質量的翻譯結果。

本質上，使用大語言模型（LLM）來解決問題，思維鏈（COT, Chain of Thought）是一種有效提升生成質量的方法，也就是說，之所以翻譯質量能提升，不是因為有了智能體，而是因為有了思維鏈。至于思維鏈的每個環節是用一個獨立的智能體，還是輸出的一個步驟，并沒有太本質的差別。

其實大部分 AI 應用場景都類似：要用 AI 解決問題，核心不在于智能體，而在于設計出一個適合 AI 的工作流。

那么怎么才能設計一個適合 AI 的工作流呢？我認為有幾個因素需要考慮：

一、不要局限于人類現有方案

有時候我們過于將 AI 擬人化，會不自覺的用人類解決問題的方式來套用在 AI 上，有時候確實有效，但很多時候并不一定是最優解。就像專業的翻譯員，他們并不需要直譯反思意譯三個步驟，他們可以一步到位，直接輸出高質量的翻譯結果，所以最開始讓 AI 翻譯，Prompt 都是直接一步輸出翻譯結果，而不是分步驟輸出，結果翻譯出來的比較生硬。而當我們發現思維鏈是大語言模型的一種有效提升方法后，就可以設計出更適合 AI 的工作流，分成幾步來解決問題。

包括我看到一些智能體項目，嘗試模擬人類軟件開發的分工，使用項目經理、產品經理、架構師、程序員、測試等等智能體角色去嘗試解決復雜的軟件項目，同樣也是一個過于擬人化而不一定適合 AI 解決問題的思路，所以也只能出現在論文中，而無法在實際項目中落地。相反像 GitHub Copilot 這樣輔助生成代碼的工具倒是真正適合當前 AI 編程的工作流，能實實在在提升開發效率。

二、不必完全依賴 AI 做決策

去年有一個超級火爆的項目叫 AutoGPT，就是你輸入一個任務，GPT-4 會將任務分解，制定計劃，調用外部工具，比如 Google 搜索，甚至執行代碼，最終完成任務。這也算是 AI 智能體的先驅項目之一，但現在已經很少有人提及了，因為以現在 AI 的智能程度，還不足以對開放性的任務做出靠譜的決策，最終除了幫 OpenAI 賣了大量的 Token 外，并沒有解決什么實際問題。所以現在 AI 應用的主流是把 AI 當“副駕駛（Copilot）”，只是讓 AI 輔助人類完成任務，主要還是人在做決策。

另外就是自己設計工作流，讓 AI 在工作流中完成一部分工作，并不過于依賴 AI 做決策，或者只需要做簡單的決策。比如說商家借助 AI 處理差評的工作流：

• 程序抓取評論信息
• AI 分析每一條評論的情感，篩選出差評
• AI 生成回復（可能需要人工審核）

這是一個典型的設計好流程的適合 AI 的工作流，AI 只需要做簡單的情感分析和回復生成，而不需要做復雜的決策，這樣的工作流可以很好的提升效率，并且結果也相對靠譜。

三、可以結合多種 AI或工具

去年起 AI 大熱，一個很重要的原因是大語言模型的出現，這些模型一方面確實能力強大，有一定的通用性，有簡單的推理能力，另一方面使用也簡單，無論是通過聊天機器人，還是通過 API 調用，都能很方便的使用。即使像我這樣不是人工智能專業的人，也能很容易的使用這些模型。而在以前，人工智能相對來說是個高門檻的領域，需要篩選數據、需要訓練，還需要調參，對于非專業人士來說是很難使用的。

但這也導致一個問題，就是很多解決方案過于依賴大語言模型，而不知道或者不會使用其他領域的 AI 模型，但當你能夠根據任務，將不同領域的 AI 模型或者工具結合起來，設計出合適的工作流，就能夠得到更好的解決方案。

四、回歸問題本質，AI 只是錘子

上面提的幾點都是容易犯的一些錯誤，之所以容易犯這些錯誤，恰恰是因為我們有時候過于關注一些流行的概念或技術，而忽略了要解決的根本問題是什么，將 AI 變成了目的而不是手段。如果你有了解馬斯克的第一性原理思維，其強調的就是回歸事物最基本的條件，把其解構成各種要素進行分析，從而找到實現目標最優路徑的方法。

而運用第一性原理通常有三個步驟：

第 1 步：定義清楚你要解決的根本問題。

第 2 步：拆解問題。

第 3 步：從頭開始創建解決方案。

而這也個思路也適用于我們去借助 AI 解決問題，設計出適合 AI 的工作流。

舉兩個設計合適 AI 工作流解決問題的例子

一個例子是 PDF 轉 Markdown。

做過 PDF 翻譯的有經驗，要得到好的翻譯結果，將 PDF 的內容整理成 Markdown，再讓大語言翻譯，效果是相當好的。但這個不好做，因為 PDF 是用來打印的格式，并不是結構化的數據，很難直接提取成 Markdown，再加上各種圖表、表格等，更是復雜。

最近看到一個項目叫 PDFGPT，它就做的很巧秒，本質上是基于 GPT-4o 和 PyMuPDF 設計了一個工作流：

用一個 PDF 操作庫 PyMuPDF 檢測 PDF 中的圖片、圖表、表格等，提取成圖片并保存

每一頁 PDF 生成一張圖片，將圖片、圖表、表格等位置用紅框標記出來，并附上對應的圖片名稱

借助 GPT-4o 的視覺能力，解析標注后的圖片，生成對應的 Markdown

如果你純粹依賴大語言模型，恐怕無法完成這樣的任務，一方面受限于上下文窗口的長度限制，一次無法處理多頁 PDF，另一方面對于圖片、圖表、表格等內容無法嵌入 Markdown 中。如果結合 PyMuPDF 這樣的庫和一個簡單的工作流，就可以方便的實現 PDF 轉 Markdown，生成的結果也挺不錯。

另一個例子是漫畫的翻譯。

有很多那種氣泡文字的漫畫，如果要翻譯成其他語言，就需要將氣泡文字提取出來，翻譯后再放回去。漫畫翻譯的難點在于：

因為漫畫的氣泡文字位置不固定，有時候還會有重疊，不好提??；

翻譯的時候，如果只是把提取出來的文字按字面翻譯，但不知道當前畫面的內容，翻譯的結果可能會不通順；

翻譯后要對圖片進行處理，抹掉原來的文字，將翻譯后的文字放回到原來的位置。

如果人工做會怎么做？可能是讀懂漫畫，翻譯，然后用 Photoshop 這個樣的工具抹掉原來的文字，再放上翻譯后的文字?？梢韵胂筮@樣的工作量還是不小的。

有一個開源項目 comic-translate，就做的很好，它也是設計了一個適合漫畫翻譯的工作流：

用一個專業模型做氣泡檢測，找出文字氣泡的位置

用 OCR 做氣泡內文字的提取

用一個專業模型移除氣泡內的文字

借助 GPT-4o 的視覺能力，根據漫畫內容，翻譯氣泡內的文字

用程序將翻譯后的文字繪制到原來的氣泡位置

如果不考慮翻譯質量的話，這幾乎是一個全自動的工作流，效率相當高，成本也很低，最貴的部分是 GPT-4o 的 API，一頁也才 $0.02 左右。就算加上人工審核對翻譯結果和圖片生成結果的處理，也是能比以前的人工翻譯效率高很多。

從上面的例子可以看出，真正要用好 AI，讓 AI 發揮最大效能，核心是還是要基于你要解決的問題，重新設計一個適合 AI 的工作流，讓 AI 在工作流中完成它最擅長的工作，至于是不是智能體，是不是大語言模型，是不是 AI 幫你決策，都不是最重要的。