現(xiàn)在 AI 智能體（AI Agent）的概念很火，似乎 Agent 是用 AI 解決問題的銀彈，有了 Agent 就可以解決很多問題。但也有很多人有不同意見，認(rèn)為 Agent 不過是噱頭，并沒有看到靠譜的應(yīng)用場景。
一個被提及很多的是吳恩達(dá)老師寫的多 Agent 翻譯的例子，簡單來說就是用三個 Agent：一個直譯 Agent、一個審查 Agent、一個意譯潤色 Agent，確實(shí)可以大幅提升翻譯質(zhì)量。
但并非一定要三個 Agent 才能提升翻譯質(zhì)量，我以前也提出過基于 Prompt 的翻譯方法，讓 LLM 在翻譯時，使用直譯 + 反思 + 意譯三個步驟輸出，也可以得到高質(zhì)量的翻譯結(jié)果。
本質(zhì)上，使用 LLM 來解決問題，思維鏈（COT， Chain of Thought）是一種有效提升生成質(zhì)量的方法，也就是說，之所以翻譯質(zhì)量能提升，不是因?yàn)橛辛?Agent，而是因?yàn)橛辛怂季S鏈。至于思維鏈的每個環(huán)節(jié)是用一個獨(dú)立的 Agent，還是輸出的一個步驟，并沒有太本質(zhì)的差別。
其實(shí)大部分 AI 應(yīng)用場景都類似：要用 AI 解決問題，核心不在于 Agent，而在于設(shè)計(jì)出一個適合 AI 的工作流。
那么怎么才能設(shè)計(jì)一個適合 AI 的工作流呢？我認(rèn)為有幾個因素需要考慮：
一、不要將 AI 的解決方案局限在人類現(xiàn)有的解決方案上
有時候我們過于將 AI 擬人化，會不自覺的用人類解決問題的方式來套用在 AI 上，有時候確實(shí)有效，但很多時候并不一定是最優(yōu)解。就像專業(yè)的翻譯員，他們并不需要直譯反思意譯三個步驟，他們可以一步到位，直接輸出高質(zhì)量的翻譯結(jié)果，所以最開始讓 AI 翻譯，Prompt 都是直接一步輸出翻譯結(jié)果，而不是分步驟輸出，結(jié)果翻譯出來的比較生硬。
而當(dāng)我們發(fā)現(xiàn)思維鏈?zhǔn)?LLM 的一種有效提升方法后，就可以設(shè)計(jì)出更適合 AI 的工作流，分成幾步來解決問題。
包括我看到一些 Agent 項(xiàng)目，嘗試模擬人類軟件開發(fā)的分工，使用項(xiàng)目經(jīng)理、產(chǎn)品經(jīng)理、架構(gòu)師、程序員、測試等等 Agent 角色去嘗試解決復(fù)雜的軟件項(xiàng)目，同樣也是一個過于擬人化而不一定適合 AI 解決問題的思路，所以也只能出現(xiàn)在論文中，而無法在實(shí)際項(xiàng)目中落地。相反像 GitHub Copilot 這樣輔助生成代碼的工具倒是真正適合當(dāng)前 AI 編程的工作流，能實(shí)實(shí)在在提升開發(fā)效率。
二、不必完全依賴 AI 做決策，而是讓 AI 輔助做決策或者做簡單的決策
去年有一個超級火爆的項(xiàng)目叫 AutoGPT，就是你輸入一個任務(wù)，GPT-4 會將任務(wù)分解，制定計(jì)劃，調(diào)用外部工具，比如 Google 搜索，甚至執(zhí)行代碼，最終完成任務(wù)。這也算是 AI Agent 的先驅(qū)項(xiàng)目之一，但現(xiàn)在已經(jīng)很少有人提及了，因?yàn)橐袁F(xiàn)在 AI 的智能程度，還不足以對開放性的任務(wù)做出靠譜的決策，最終除了幫 OpenAI 賣了大量的 Token 外，并沒有解決什么實(shí)際問題。
所以現(xiàn)在 AI 應(yīng)用的主流是把 AI 當(dāng) “副駕駛（Copilot）”，只是讓 AI 輔助人類完成任務(wù)，主要還是人在做決策。
另外就是自己設(shè)計(jì)工作流，讓 AI 在工作流中完成一部分工作，并不過于依賴 AI 做決策，或者只需要做簡單的決策。比如說商家借助 AI 處理差評的工作流：
AI 生成回復(fù)（可能需要人工審核）
這是一個典型的設(shè)計(jì)好流程的適合 AI 的工作流，AI 只需要做簡單的情感分析和回復(fù)生成，而不需要做復(fù)雜的決策，這樣的工作流可以很好的提升效率，并且結(jié)果也相對靠譜。
三、結(jié)合不同領(lǐng)域的 AI 模型或者工具，設(shè)計(jì)合適的工作流
去年起 AI 大熱，一個很重要的原因是 LLM 的出現(xiàn)，這些模型一方面確實(shí)能力強(qiáng)大，有一定的通用性，有簡單的推理能力，另一方面使用也簡單，無論是通過聊天機(jī)器人，還是通過 API 調(diào)用，都能很方便的使用。
即使像我這樣不是 AI 專業(yè)的人，也能很容易的使用這些模型。而在以前，AI 相對來說是個高門檻的領(lǐng)域，需要篩選數(shù)據(jù)、需要訓(xùn)練，還需要調(diào)參，對于非專業(yè)人士來說是很難使用的。
但這也導(dǎo)致一個問題，就是很多解決方案過于依賴 LLM，而不知道或者不會使用其他領(lǐng)域的 AI 模型，但當(dāng)你能夠根據(jù)任務(wù)，將不同領(lǐng)域的 AI 模型或者工具結(jié)合起來，設(shè)計(jì)出合適的工作流，就能夠得到更好的解決方案。
四、回歸問題本質(zhì)，AI 只是解決問題的工具
上面提的幾點(diǎn)都是容易犯的一些錯誤，之所以容易犯這些錯誤，恰恰是因?yàn)槲覀冇袝r候過于關(guān)注一些流行的概念或技術(shù)，而忽略了要解決的根本問題是什么，將 AI 變成了目的而不是手段。如果你有了解馬斯克的第一性原理思維，其強(qiáng)調(diào)的就是回歸事物最基本的條件，把其解構(gòu)成各種要素進(jìn)行分析，從而找到實(shí)現(xiàn)目標(biāo)最優(yōu)路徑的方法。
而運(yùn)用第一性原理通常有三個步驟：
定義清楚你要解決的根本問題
拆解問題
從頭開始創(chuàng)建解決方案
而這個思路也適用于我們?nèi)ソ柚?AI 解決問題，設(shè)計(jì)出適合 AI 的工作流。
舉兩個設(shè)計(jì)合適 AI 工作流解決問題的例子，一個例子是 PDF 轉(zhuǎn) Markdown。
做過 PDF 翻譯的都知道，要得到好的翻譯結(jié)果，將 PDF 的內(nèi)容整理成 Markdown，再讓大語言翻譯，效果是相當(dāng)好的。但這個不好做，因?yàn)?PDF 是用來打印的格式，并不是結(jié)構(gòu)化的數(shù)據(jù)，很難直接提取成 Markdown，再加上各種圖表、表格等，更是復(fù)雜。
最近看到一個項(xiàng)目叫 PDFGPT，它就做的很巧秒，本質(zhì)上是基于 GPT-4o 和 PyMuPDF 設(shè)計(jì)了一個工作流：
借助 GPT-4o 的視覺能力，解析標(biāo)注后的圖片，生成對應(yīng)的 Markdown
如果你純粹依賴 LLM，恐怕無法完成這樣的任務(wù)，一方面受限于上下文窗口的長度限制，一次無法處理多頁 PDF，另一方面對于圖片、圖表、表格等內(nèi)容無法嵌入 Markdown 中。如果結(jié)合 PyMuPDF 這樣的庫和一個簡單的工作流，就可以方便的實(shí)現(xiàn) PDF 轉(zhuǎn) Markdown，生成的結(jié)果也挺不錯。
另一個例子是漫畫的翻譯，有很多那種氣泡文字的漫畫，如果要翻譯成其他語言，就需要將氣泡文字提取出來，翻譯后再放回去。漫畫翻譯的難點(diǎn)在于：
翻譯后要對圖片進(jìn)行處理，抹掉原來的文字，將翻譯后的文字放回到原來的位置。
如果人工做會怎么做？可能是讀懂漫畫，翻譯，然后用 Photoshop 這個樣的工具抹掉原來的文字，再放上翻譯后的文字?？梢韵胂筮@樣的工作量還是不小的。
有一個開源項(xiàng)目 comic-translate，就做的很好，它也是設(shè)計(jì)了一個適合漫畫翻譯的工作流：
用一個專業(yè)模型做氣泡檢測，找出文字氣泡的位置
用 OCR 做氣泡內(nèi)文字的提取
用一個專業(yè)模型移除氣泡內(nèi)的文字
借助 GPT-4o 的視覺能力，根據(jù)漫畫內(nèi)容，翻譯氣泡內(nèi)的文字
用程序?qū)⒎g后的文字繪制到原來的氣泡位置
如果不考慮翻譯質(zhì)量的話，這幾乎是一個全自動的工作流，效率相當(dāng)高，成本也很低，最貴的部分是 GPT-4o 的 API，一頁也才 $0.02 左右。就算加上人工審核對翻譯結(jié)果和圖片生成結(jié)果的處理，也是能比以前的人工翻譯效率高很多。
從上面的例子可以看出，真正要用好 AI，讓 AI 發(fā)揮最大效能，核心是還是要基于你要解決的問題，重新設(shè)計(jì)一個適合 AI 的工作流，讓 AI 在工作流中完成它最擅長的工作，至于是不是 Agent，是不是 LLM，是不是 AI 幫你決策，都不是最重要的。
原文鏈接：https://baoyu.io/blog/ai/you-dont-need-agent-but-ai-suitable-workflow
