掌握API建模：基本概念和實踐
這里的助手與我們這里探討的企業應用中的AI Agent有一定的區別：
AI Agent是一個以任務驅動的具備自主能力的智能體，不僅需要大模型這個核心“大腦”，也需要任務規劃、記憶與外部工具使用等能力。而我們?？吹降膫€人AI助手大部分是基于預設提示詞的大模型問答Bot，在不借助其他插件時，通常不具備工具使用能力。
當前在企業應用中以內容創作生成為主要能力的AI Agent從技術上至少有兩種：
1、單Agent的內容生成。簡單地將大模型的生成能力通過API集成到其他應用與業務流程中，替代或簡化原來由人工完成的部分工作。比如：
這種類型的AI助手簡單的借助Prompt工程即可實現（與C端個人助手并無本質區別）：
2、基于多Agent協作（可能還有人類）的內容生成。典型的為虛擬機器人軟件公司，由AI Agent擔任多個軟件開發崗位，通過相互協作完成某個軟件開發任務。
這種多Agent協作型的助手可以借助Multi-Agents框架來簡化開發與實現。比如MetaGPT，可以根據自然語言描述的開發任務，組建Agent團隊（PM、架構師、程序員、QA等），遵循SOP并最終輸出完整軟件開發的成果（文檔、代碼、API說明等）。
其他支持多Agent的開源框架包括微軟的AutoGen，xAgents等。
當前較為成熟的一種Agent類型。通俗地說，就是在企業應用中，通過“外掛”私有知識庫來擴充大模型的知識儲備，以提供基于自然語言的、對話式的企業私有知識訪問（對應到AI Agent的基本能力之一：持久化記憶），以解決通用大模型在面向企業應用時領域知識不足導致的幻覺問題。
知識助手通常借助于大模型的RAG（檢索增強生成）方案來實現，其本質上也是一種提示工程：借助于在大模型輸入時攜帶相關的私有知識上下文，讓大模型理解、總結、整理并回答用戶問題。只是這里的私有知識上下文需要借助嵌入模型（Embedding Model）、向量數據庫（Vector Store）、文檔加載分割（Document Loader&Splitter）等相關技術來獲得。
知識助手的技術實現基礎架構如下：
基于RAG方案的AI助手實現可以自行通過代碼直接實現，當然，為了簡化開發與管理過程，推薦使用的工具包括：
數據分析與商業智能(BI)在中大型企業的日常運營中的重要性毋庸置疑，無論是簡單的財務數據分析，還是復雜的客戶與運營數據洞察，都需要借助專業的工具。傳統BI工具使用門檻高、過度依賴技術部門、結果產出周期長的問題在AI時代可以借助大模型的能力得以緩解。
基于大模型的數據分析助手（Data Agent）是在企業應用中通過將自然語言轉換成數據分析的語言或代碼，比如對API的調用、對數據庫的訪問、甚至編寫數據分析代碼，來達到獲取數據、分析數據與可視化結果的目的。其實現基礎架構與原理如下：
無論是對本地的Excel數據文件分析，或者對數據庫中的關系型數據分析，又或者對互聯網的非結構化數據分析，當前大模型實現數據分析的技術途徑基本以這三種方式為主，自然語言轉API、轉SQL、以及代碼解釋器（轉代碼）。
這里推薦幾個除Langchain之外構建數據分析助手的工具與項目：
需要注意的是：數據分析助手嚴重依賴大模型對自然語言轉數據操作的能力（SQL或Python代碼等）。當然條件下，即使是針對這種場景專門優化的模型與提示工程，其失敗概率也很高（比如Text2SQL目前最高成功率在80%左右）。因此，在實際實施中需要根據場景、復雜性、可靠性要求做綜合評估。
企業應用中的AI助手很多時候需要與現有應用（CRM、OA系統）做集成與交互，以完成某個用戶任務或者驅動業務流程。比如：如果你需要AI幫你在協同辦公系統中提交一個付款申請，那么你需要調用辦公系統的接口；或者你需要借助互聯網獲得最新某上市公司的財務報告，你需要調用第三方平臺的公開接口。這就是AI Agent另一項重要能力：工具使用。
AI應用/工具助手就是能夠把自然語言轉換成對企業應用或者互聯網開放API調用的一種基礎Agent形式。當然，在復雜任務場景下的這種調用往往不是單一的。其基礎架構與原理：
應用助手的基本原理是比較簡單的，其復雜性主要體現在大模型對自然語言轉API的能力，在實際使用中，其主要體現以下兩個方面：
在實際測試中我們發現不同的大模型在這方面的能力是有較大的差異的，而且即使是最優秀的模型，也存在一定的不確定性，比如有時候無法判斷出正確的工具。
在構建企業基于大模型的應用助手時，有一些工程問題是需要考慮的，這些問題在做原型或者測試時容易被忽視：
構建應用助手的一些工具和項目推薦：
一種類似RPA（機器人流程自動化）的AI智能體。其主要能力是自動化Web網絡瀏覽、操作與探索的動作與過程，以簡化web瀏覽訪問與操作。對于個人來說，可以作為個人數字助理，簡單對話即可讓AI幫你完成Web瀏覽與操作，比如在線訂票。而對于企業來說，則可以作為企業的數字員工，來簡化企業日常工作中重復性較高、流程與規則固定、大批量的前端操作性事務。比如批量訂單處理、批量客戶聯絡、批量網站抓取等，提高效率，降低錯誤率。
傳統的RPA機器人也是用來完成此類工作的AI形式，由于這種AI機器人工作在軟件的最上層即操作層面，好處是流程直觀、簡單、也可以配置化，且對應用無侵入性；但其缺點是與前端應用耦合性大，每個任務需要根據前端應用界面做精心配置與調試，自適應能力較差。
在大模型出現以后，給這一類RPA智能也帶來了新的優化空間。利用大模型的理解與分析推理能力，可以讓AI更加智能的規劃與分解任務過程，然后借助瀏覽器完成執行；且在未來可以利用像GPT-4V這樣的視覺模型，更智能的理解界面元素與功能，實現完全自主的智能操作，具備更強的自適應能力。
實現一個自主Web操作的Agent的基礎原理與架構：
構建一個真實應用的Web Agent需要借助瀏覽器自身能力。由于外部應用無法直接接管瀏覽器實現操作，一般需要借助瀏覽器插件，比如Chrom擴展，借助瀏覽器API完成網站導航與自動化網頁操作，比如點擊界面元素，或者輸入表單。
我們前面介紹到的OpenAgents項目中的Web Agent是一個基于Chrom瀏覽器與擴展而實現的一個LLM Agent，可以參考用作參考。
當然由于大模型的輸出不確定性，當前的Web Agent仍然處于探索實驗階段，具有較大的失敗或誤操作可能，實際應用中需要根據情況反復測試與評估。
最后一種AI Agent嚴格來說是上面的幾種基礎Agent能力的組合。
理想中的AI Agent是在丟給他一個工具包與一些知識以后，借助于大模型的理解、推理能力，完全自主的規劃與分解任務，設計任務步驟，并智能的使用各種工具，檢索知識，輸出內容，完成任務。但是在企業應用中，由于企業知識、應用、業務需求的千差萬別，以及大模型自身的不確定性，如果這么做，那么結果很可能是“開盲盒”一樣的不可控。所以這也是越來越多的Agents項目要強調可控性的原因，即能夠對AI智能體的執行過程與細節進行更多的控制，來讓AI按照人類確認過的工作流程來完成任務。
比如之前我們介紹的HR簡歷自動化篩選的場景中，你可能需要更加細致的去定義整個自動化工作流程，包括：
在實際應用中，這樣基于LLM的工作流既可以是直接面向使用者的對話機器人來觸發；也可以是完全后臺觸發。
實現這樣的自動化工作流程AI智能體，除了借助Langchain/LlamaIndex這樣的LLM開發框架直接定制外，還可以參考或利用一些開源項目：
以上，我們對企業應用中的大模型AI Agent從技術原理層面區分的幾種類型做了簡單探討。實際上這里的每一種類型也都是一個可以深入的復雜話題，其中部分類型在之前的文章中也展開深入過，后續我們也會關注AI Agent技術趨勢與發展，并在未來做持續分享。
文章轉自微信公眾號@AI大模型應用實踐
