從 Chat 到 AgentSolon AI 帶你進入“行動派”大模型時代你要注意一個事實過去兩年我們習(xí)慣的大模型基本還停留在“聊天框”里。你問它答它給你一段漂亮的文字然后呢然后你自己去查資料、填表格、發(fā)郵件、調(diào)接口。所有“動手”的事仍然是你來做大模型更像一個很會說話的顧問。但顧問不會替你干活。我接觸 Solon AI 這個項目最初的觸動點就在這里。它想做的不是又一個聊天機器人而是把大模型從“提建議”往前推一步變成“直接執(zhí)行”。用官方一點的話說就是從 Chat 走向 Agent讓模型從“嘴上說說”變成“上手就做”。這篇文章我就以它為主線聊聊為什么 Agent 是大模型真正值得投入的方向以及我自己在搭建一個 Solon AI 智能體時的完整過程、踩過的坑和調(diào)參心得。不管你是后端開發(fā)、產(chǎn)品經(jīng)理還是剛接觸 AI 應(yīng)用的新手這篇內(nèi)容應(yīng)該都能給你一些能直接拿去用的東西。1. 先搞清楚Chat 和 Agent 到底差在哪1.1 Chat 模式的本質(zhì)會說話不等于能辦事要理解 Agent得先回頭看 Chat 模式的結(jié)構(gòu)。傳統(tǒng)的 Chat 應(yīng)用本質(zhì)上就是一個“輸入-輸出”的閉環(huán)你塞給模型一段提示詞它按照概率生成一段文本。這個過程干得漂亮的地方在于語言模型對自然語言的理解和生成能力確實強寫方案、翻譯、潤色、解釋代碼做得像模像樣。但這個模式有個天然的邊界——它不產(chǎn)生“副作用”。什么叫副作用在計算機術(shù)語里副作用是指函數(shù)執(zhí)行后對外部狀態(tài)造成的更改。你讓大模型寫一封郵件它給你一封很專業(yè)的郵件文本但這封郵件沒有出現(xiàn)在收件人的信箱里你讓它分析一份銷售數(shù)據(jù)它給你一段結(jié)論但結(jié)論不會自動出現(xiàn)在你的周報文檔里。模型本身只輸出 token不輸出動作。我見過不少團隊做一個“AI 助手”的時候就是把大模型接口包一層前面加個漂亮的對話框后面接個提示詞模板。用戶在對話框里問“幫我查一下上個月訂單金額”系統(tǒng)返回“根據(jù)你提供的信息上個月訂單金額是 380 萬”。聽起來沒問題但你注意用戶沒有提供上個月訂單金額是模型編了一個可能合理也可能完全離譜的數(shù)字。它沒有權(quán)限去查數(shù)據(jù)庫它只能猜。這就是 Chat 模式的第二個局限模型默認是在“接著話往下說”而不是在“解決一個真實問題”。它一旦被問到一個需要外部信息才能回答的問題要么編造要么要求你自己把數(shù)據(jù)貼進對話里。然后是上下文窗口的限制。每次對話能攜帶的信息量是有限的超過一定長度早期的內(nèi)容會被截斷或遺忘。你做一個需要多輪調(diào)查、逐步推進的任務(wù)Chat 模式很容易聊著聊著就丟了上下文。它沒有一個“目標清單”也不會主動去拆分任務(wù)。每一輪都像是失憶之后重新開始。所以我的結(jié)論是Chat 模式解決的是“語言表達”問題Agent 模式解決的是“任務(wù)完成”問題。這兩者有交集但邏輯完全不同。1.2 Agent 的核心能力感知、規(guī)劃、執(zhí)行、反思那 Agent 是怎么把“完成任務(wù)”這件事落地的我拆解下來它其實是在大模型的外圍加了一個“行動閉環(huán)”。模型還是那個模型但不再是單輪對話而是圍繞一個目標循環(huán)地做下面四件事感知理解用戶的目標同時讀取外部輸入比如用戶填的表單、系統(tǒng)傳過來的參數(shù)、當前環(huán)境里已有的數(shù)據(jù)。規(guī)劃把大目標拆成小步驟。比如“寫周報”可以拆成“收集本周提交的代碼記錄”“匯總項目進展”“生成結(jié)構(gòu)化文檔”“發(fā)送到協(xié)作群”四個子任務(wù)。執(zhí)行調(diào)用外部的工具或接口來完成每個子任務(wù)。工具可以是查數(shù)據(jù)庫的函數(shù)、發(fā)請求的 API、操作文件的腳本也可以是調(diào)用其他模型。反思拿到執(zhí)行結(jié)果后檢查是否正確、是否符合目標預(yù)期不行就再調(diào)整計劃重試。這個循環(huán)不一定是線性走一遍。很多時候要反復(fù)迭代特別是規(guī)劃錯了或者執(zhí)行失敗的時候Agent 需要從結(jié)果里拿到錯誤信息重新修正自己的下一步動作。用生活化的類比來說Chat 模式就是你雇了一個很厲害的咨詢顧問但你每次都要把問題背景從頭到尾講一遍聽完建議之后自己跑腿去辦Agent 模式是你雇了一個項目經(jīng)理你只告訴他“我要什么”他會自己安排人、調(diào)資源、做檢查、跟你匯報結(jié)果。這中間的差別不是模型變聰明了多少而是架構(gòu)上多了一條“手和腳”。1.3 為什么現(xiàn)在才是 Agent 的爆發(fā)期有人會問這種“帶工具的 AI”概念不是早就有了嗎確實很早就有通過腳本調(diào)用 API 實現(xiàn)自動化的工作流但那更多是硬編碼邏輯——固定的輸入、固定的步驟、固定的分支。Agent 和它的區(qū)別在于規(guī)劃這一步不是人肉完成的而是模型基于自然語言理解動態(tài)生成的。也就是說過去你要寫一個“自動整理周報并發(fā)送”的腳本你要明確告訴程序從哪里取數(shù)、按什么格式拼接、調(diào)用哪個接口發(fā)出去。一旦需求變了比如“順便統(tǒng)計一下團隊各成員的工作量”你得改代碼。但 Agent 只需要你換一句目標描述“整理周報同時按成員統(tǒng)計工作量”它會在規(guī)劃階段自己決定要不要多讀一份成員數(shù)據(jù)表、要不要在文檔里多加一個分組。加上這兩年大模型的工具調(diào)用能力越來越穩(wěn)模型知道“什么時候該調(diào)函數(shù)而不是自己硬編答案”Agent 才真正從玩具變成能用的工程方案。Solon AI 這類框架出現(xiàn)的意義就是把這套閉環(huán)打包成一套開發(fā)工具讓普通人不用從零搭 Agent 的基礎(chǔ)設(shè)施。2. Solon AI 的整體設(shè)計思路讓 Agent 變得可搭建2.1 定位一個輕量級的智能體運行時我第一次看 Solon AI 的代碼第一印象是“克制”。它沒有搞一套復(fù)雜得嚇人的編排引擎而是把 Agent 的開發(fā)抽象成幾個核心概念智能體、工具、策略、記憶。開發(fā)者要做的事情很聚焦——定義你的智能體具備哪些工具設(shè)置好它完成任務(wù)時的基本策略剩下的事情框架幫你管。這個設(shè)計思路我很認可。因為 Agent 開發(fā)最大的坑就是過早陷入復(fù)雜架構(gòu)。你一上來就考慮分布式任務(wù)調(diào)度、多智能體協(xié)作、知識庫向量檢索、復(fù)雜狀態(tài)機結(jié)果往往是項目才跑通第一個 Demo人已經(jīng)被配置和概念壓垮了。Solon AI 的做法相反先讓你用最少的代碼跑起來一個會調(diào)用工具的智能體有了真實感覺之后再按需加內(nèi)容。它的核心依賴很少不強制綁定某個大模型服務(wù)商你可以用國內(nèi)外的各類模型只要它支持函數(shù)調(diào)用或工具使用。甚至可以把不同模型混著用復(fù)雜規(guī)劃用強模型簡單抽取用輕量模型。這一點在企業(yè)內(nèi)部落地時特別實用因為成本是躲不開的問題。2.2 四個核心模塊拆解從輸入到行動的高速公路Solon AI 把一次智能體的運行過程分為感知層、決策層、執(zhí)行層和反思層我逐個說它們實際做什么。感知層負責(zé)把各種來源的輸入統(tǒng)一轉(zhuǎn)換成模型能理解的指令。用戶的自然語言、外部系統(tǒng)回調(diào)的 JSON、文件路徑、定時任務(wù)觸發(fā)的事件都匯聚到這里解析成“當前目標已有信息約束條件”。決策層是核心它承載著規(guī)劃能力。Solon AI 在這里跑的是“計劃-執(zhí)行-觀察”循環(huán)模型先輸出一份行動計劃然后逐個執(zhí)行每完成一步都把結(jié)果反饋給它它再決定下一步。你可以設(shè)定最大迭代次數(shù)防止它陷入無限循環(huán)。執(zhí)行層管的是工具調(diào)用。框架內(nèi)部有一個工具注冊表每個工具都是一個標準函數(shù)描述函數(shù)名、參數(shù)結(jié)構(gòu)、功能說明、返回值格式。模型在決策時會根據(jù)這些描述選擇調(diào)用哪個工具并生成對應(yīng)的參數(shù) JSON。Solon AI 負責(zé)把 JSON 轉(zhuǎn)成真實的函數(shù)調(diào)用并把返回結(jié)果再傳給模型。反思層容易被新手忽略但它恰恰是 Agent 效果提升的杠桿點。執(zhí)行完一個任務(wù)后反思機制會對比“當前狀態(tài)”和“目標狀態(tài)”之間的差距。比如任務(wù)目標是把文件上傳到對象存儲并返回 URL如果工具調(diào)用返回了文件不存在反思層會嘗試修正路徑或換一種方式讀取文件而不是直接把原始錯誤拋給用戶。四個模塊的關(guān)系看起來像一個流水線但實際上每一步都可能回溯。行動失敗不一定是終點而是一次反饋信號。理解了這一點你寫提示詞和設(shè)計工具函數(shù)時的思路都會不一樣——你不是在寫一個腳本而是在設(shè)計一個“有糾錯能力的自動化流程”。3. 實操記錄用 Solon AI 搭建一個自動周報 Agent3.1 環(huán)境準備與項目初始化我建議你動手之前先把目標場景定得非常具體。我這個 Demo 選的是“自動整理本周項目進展然后推送到團隊協(xié)作群”。這個場景麻雀雖小、五臟俱全——涉及數(shù)據(jù)讀取、文本生成、消息推送剛好能把 Agent 的感知、規(guī)劃、執(zhí)行、反思四個環(huán)節(jié)都串起來。先準備一個干凈的 Python 環(huán)境我用的是 3.10 版本。安裝 Solon AI 的依賴包同時需要準備好一個支持工具調(diào)用的大模型接口。這里我以最常見的一個配置為例pip install solon-ai然后創(chuàng)建一個工作目錄初始化配置文件。Solon AI 支持通過環(huán)境變量或者配置文件指定模型服務(wù)的地址和密鑰。我的配置大概長這樣model: provider: openai_compatible base_url: http://localhost:8000/v1 api_key: your-key model_name: your-model-name temperature: 0.3注意 temperature 我沒有用默認的 0.7而是設(shè)成了 0.3。原因后面在調(diào)參部分細說。先把模型服務(wù)配好做一次連通性測試確保 Solon AI 能正常調(diào)用模型。這一步看著簡單但很多人第一次卡住就是在這——模型服務(wù)地址寫錯、密鑰不對或者模型名匹配不上結(jié)果智能體還沒開始干活就報錯。3.2 定義工具給 Agent 配上手和腳下一步是關(guān)鍵定義 Agent 能用哪些工具。Solon AI 里注冊工具的方式很直接寫一個普通函數(shù)加一行注冊用的裝飾器即可。我定義了三個工具第一個是讀取本周提交記錄返回一個包含日期、模塊、提交說明、開發(fā)者的列表第二個是把一段文本格式化成帶 Markdown 標題的周報第三個是把渲染好的消息推送到協(xié)作群機器人接口。代碼大概長這樣from solon_ai import Tool Tool(獲取本周提交記錄) def get_commits() - list: # 實際場景中這里會查代碼托管平臺或內(nèi)部數(shù)據(jù)庫 return [ {date: 2025-06-09, module: 用戶中心, commit: 修復(fù)登錄態(tài)過期問題, author: A同學(xué)}, {date: 2025-06-10, module: 訂單系統(tǒng), commit: 新增批量導(dǎo)出功能, author: B同學(xué)}, ] Tool(格式化周報文本) def format_report(data: list) - str: lines [## 本周項目進展] for item in data: lines.append(f- {item[date]} {item[module]}: {item[commit]} ({item[author]})) return \n.join(lines) Tool(推送消息到協(xié)作群) def push_message(text: str) - bool: # 調(diào)用協(xié)作群機器人的 Webhook 接口 return True注冊工具時我會特別注意工具名和描述文案。Solon AI 依賴大模型來理解“什么時候該用哪個工具”所以描述要寫清楚這個工具是做什么的、參數(shù)是什么格式。我見過很多人工具函數(shù)寫得很好但描述隨便寫兩句模型根本不知道該什么時候調(diào)用它結(jié)果 Agent 就變成不會用工具的聊天機器人。工具描述是給模型看的不是給程序看的這一句話值得你謹記。3.3 創(chuàng)建智能體并運行任務(wù)工具定義好之后創(chuàng)建智能體非常簡潔from solon_ai import Agent agent Agent( name周報助手, tools[get_commits, format_report, push_message], system_prompt你是團隊的周報助手。你的任務(wù)是根據(jù)本周提交記錄生成周報并推送到協(xié)作群。 )注意 system_prompt 我寫得很短但把“目標”和“約束”放進去目標是根據(jù)提交記錄生成周報約束是最終要推送到協(xié)作群。Solon AI 的規(guī)劃邏輯會把這句話展開成具體的行動步驟。然后運行result agent.run(幫我把這周的進展整理成周報發(fā)到群里) print(result)第一次跑的時候模型給出的計劃是先調(diào)用 get_commits 獲取記錄再調(diào)用 format_report 格式化最后調(diào)用 push_message 推送。這個流程完全符合預(yù)期。但我在實際過程中發(fā)現(xiàn)模型偶爾會跳步——比如直接生成一個文本總結(jié)然后調(diào)用推送工具省略了格式化那一步。這不是 bug而是它認為文本已經(jīng)足夠好。這時候你就需要在 system_prompt 里補一句“必須先使用 format_report 工具格式化后再推送”給規(guī)劃加一條硬性約束。整體的執(zhí)行日志長這樣[決策] 目標拆解獲取數(shù)據(jù) → 格式化 → 推送 [執(zhí)行] 調(diào)用 get_commits [結(jié)果] 返回 2 條提交記錄 [決策] 調(diào)用 format_report [結(jié)果] 返回格式化后的 Markdown 文本 [決策] 調(diào)用 push_message [結(jié)果] 推送成功 [完成] 任務(wù)結(jié)束看到嗎Agent 做的事情本質(zhì)上還是那幾個工具調(diào)用但順序是模型自己決定的。換一個目標比如“只統(tǒng)計 B 同學(xué)這周的提交”它不一定需要 format_report可能直接過濾數(shù)據(jù)之后推給你。這就是規(guī)劃能力帶來的靈活性。3.4 參數(shù)調(diào)優(yōu)讓 Agent 更穩(wěn)的四個調(diào)節(jié)項跑通第一版之后就該調(diào)參數(shù)了。Solon AI 有幾個關(guān)鍵參數(shù)直接決定 Agent 是“靠譜”還是“發(fā)瘋”。temperature 控制隨機性。我之前設(shè) 0.3是要讓規(guī)劃步驟盡量穩(wěn)定不搞花活。如果調(diào)成 0.7模型偶爾會給出一些更有創(chuàng)意的執(zhí)行方案但代價是更容易選錯工具或生成無效的 JSON 參數(shù)。做 Agent大多數(shù)場景我都建議低溫畢竟你需要的是可靠執(zhí)行不是創(chuàng)意寫作。max_iterations 控制最大循環(huán)輪數(shù)。Agent 在反思環(huán)節(jié)被允許自我修正但這不意味著可以無限嘗試。如果某個工具一直報錯模型可能反復(fù)換方案重試白白消耗 token。我一般設(shè) 5-8 輪。如果超過這個數(shù)還沒完成說明工具定義或提示詞有問題應(yīng)該調(diào)代碼而不是讓模型硬試。工具描寫的詳細程度。同樣一個獲取天氣的工具寫“獲取天氣信息”和寫“根據(jù)城市名獲取當前天氣參數(shù) city 為城市名稱返回溫度、濕度、天氣狀況”模型調(diào)用它的準確率完全不一樣。工具描述是在給模型“指路”寫得越具體走錯路的概率越低。日志與回溯開關(guān)。開發(fā)時一定要開啟詳細日志看完一遍執(zhí)行過程再關(guān)掉。很多執(zhí)行異?？靠醋罱K輸出根本看不出來必須看中間的工具調(diào)用序列。4. 常見坑點與我的排查心得4.1 工具參數(shù)接錯模型的“幻覺 JSON”問題我在調(diào)試中遇到最多的一個問題是模型生成的工具調(diào)用參數(shù)和工具定義不一致。比如工具定義要求參數(shù)是 datetime 類型模型輸出了一個字符串“2025-06-09”看起來一樣但格式不對或者工具要求的是列表模型傳了一個對象進去。排查思路是第一步開啟 Solon AI 的詳細執(zhí)行日志找到模型生成的那段 JSON第二步對比工具定義里的參數(shù) Schema通常能一眼發(fā)現(xiàn)字段名不匹配。我發(fā)現(xiàn)比較穩(wěn)妥的解決辦法是在描述里直接寫清楚參數(shù)示例。比如工具: 推送消息 參數(shù): text(string) - 消息正文。示例周報已生成請查收。給模型看一個具體的 JSON 示例比寫一長串“text 參數(shù)是 string 類型”有用得多。這是從實踐中得來的經(jīng)驗——模型對示例的遵循度遠遠高于對抽象定義的遵循度。4.2 執(zhí)行鏈路長導(dǎo)致上下文被塞滿當 Agent 調(diào)用很多工具之后中間步驟的返回結(jié)果都會留在上下文里。如果某個工具的返回數(shù)據(jù)特別大比如查詢數(shù)據(jù)庫返回了幾百行記錄模型的注意力就會被大量無關(guān)信息占據(jù)規(guī)劃能力明顯下降。我的處理方式是在工具定義里限制返回字段數(shù)量或者讓工具先行做匯總。查詢“本周提交記錄”可以只返回統(tǒng)計數(shù)量而不是全部明細如果需要明細也要在描述里說明“返回最多 20 條超出部分請?zhí)崾居脩簟?。這既節(jié)省 token又保護上下文干凈。另一位開發(fā)者也遇到類似問題他的解決方式是給工具加一個“summary 模式”數(shù)據(jù)量大時只返回統(tǒng)計摘要細節(jié)在日志里單獨存需要再看時調(diào)用第二個工具。這個思路很不錯我后來直接借鑒了。4.3 反思機制的閾值別調(diào)得太瘋狂反思意味著 Agent 會自行決定“要不要重試一次”。反思機制如果太激進Agent 會在一個本來就正確的結(jié)果上反復(fù)檢查執(zhí)行速度慢、消耗大如果太保守遇到一次偶發(fā)失敗就直接放棄穩(wěn)定性又不夠。我的調(diào)法很務(wù)實僅在工具返回明確錯誤碼或異常信息時才重試并且同一操作最多允許重試兩次。如果第二次還失敗直接終止并把錯誤信息交給用戶。定時類或數(shù)據(jù)類任務(wù)要求準確性偶爾失敗重試可以但對外發(fā)送消息的任務(wù)你反而要更謹慎避免重復(fù)推送造成打擾。可以加一步防重檢查推送前先確認上一次推送是否成功。這類小細節(jié)最能影響 Agent 在真實業(yè)務(wù)里能不能留得住。4.4 成本回收與模型選型Agent 執(zhí)行一次任務(wù)的 token 消耗通常比單純 Chat 高很多。因為模型不僅要輸出最終結(jié)果還要輸出計劃、工具調(diào)用序列、觀察結(jié)果等。一個看似簡單的任務(wù)二十幾個工具調(diào)用、幾萬 token 完全正常。為了控制成本我自己做了個策略矩陣任務(wù)類型推薦模型策略簡單單工具任務(wù)輕量模型低溫迭代上限低多工具復(fù)雜任務(wù)強模型規(guī)劃輕量工具模型執(zhí)行需要大量建模分析強模型 批量離線處理避免在線頻繁循環(huán)高容錯內(nèi)部工具允許低置信度快速執(zhí)行、復(fù)核一次Solon AI 支持插拔模型提供者我實際是這么做的入口規(guī)劃用一個能力更強的模型而具體工具內(nèi)部偶爾會調(diào)用一個更快更便宜的模型來處理格式化、過濾這類子任務(wù)。這樣整體成本大約降了四成效果沒有明顯變化。想在生產(chǎn)環(huán)境長期跑這一步是必須考慮的。4.5 別讓 Agent 做“權(quán)限之外”的事最后提一個容易忽略的安全點。Agent 既然能調(diào)用工具就說明它具備真實操作的能力。如果你的工具里包含“刪除文件”“推送消息”“發(fā)送郵件”這類副作用操作一定要做好權(quán)限隔離。我的經(jīng)驗是兩層控制第一層工具本身要校驗調(diào)用來源和必要參數(shù)比如發(fā)送郵件的工具必須校驗收件人是否在白名單里第二層Agent 的執(zhí)行策略里設(shè)置“風(fēng)險操作確認模式”一旦行動計劃包含風(fēng)險操作Solon AI 先暫停并輸出待確認信息只有我手動確認后才會繼續(xù)執(zhí)行。這個機制不是限制 Agent 能力而是避免它在幻覺和異常狀態(tài)下做出不可逆的誤操作。我實際測試過如果不對工具做任何保護你讓 Agent“整理一下測試環(huán)境”它真有可能順手把測試數(shù)據(jù)庫里的表重建一遍——它只是執(zhí)行了模型規(guī)劃里的步驟并不知道刪除數(shù)據(jù)意味著什么。這個教訓(xùn)讓我后續(xù)在做任何 Agent 項目時都把工具級權(quán)限控制放在開發(fā)優(yōu)先級列表的最前面。5. 從 Demo 到生產(chǎn)Solon AI 還能往哪個方向走如果你已經(jīng)被上面的內(nèi)容吸引并且順利跑通了第一個 Agent Demo那我建議你別停在這里。Solon AI 從“會跑”到“好用”我總結(jié)出三個可以繼續(xù)深挖的方向。第一個方向是給 Agent 加持久化記憶。當前 Demo 里每次運行都是一次全新的任務(wù)它對上一次的偏好和結(jié)果完全沒有記憶。如果加上記憶模塊讓它記得“上次推送格式中標題用了三級標題”“用戶更喜歡簡潔的數(shù)據(jù)摘要”后續(xù)任務(wù)的完成質(zhì)量和個性化程度會明顯提升。Solon AI 支持接入向量庫做長期記憶把每次執(zhí)行的關(guān)鍵結(jié)果和用戶反饋存下來再用檢索的方式在下一次任務(wù)開始時注入上下文。這個改造不復(fù)雜但對體驗提升明顯。第二個方向是讓多個 Agent 協(xié)作。我最近在嘗試把一個 Agent 拆成三個一個負責(zé)需求理解一個負責(zé)數(shù)據(jù)檢索一個負責(zé)內(nèi)容生成和推送。這三個 Agent 共享同一個目標但各司其職通過 Solon AI 的 agent 間通信機制交換信息。這種方式的好處是單個 Agent 的規(guī)劃負擔(dān)變小出錯的概率降低而且每個 Agent 可以單獨調(diào)優(yōu)。壞處是整體鏈路更長調(diào)試成本變高如果不是任務(wù)本身足夠復(fù)雜沒必要硬拆。第三個方向是接入更豐富的工具生態(tài)。Solon AI 的注冊機制很開放你可以把內(nèi)部系統(tǒng)的 API、數(shù)據(jù)查詢接口、第三方服務(wù)全部封裝成工具。真正的 Agent 價值不在模型本身而在它有多少高質(zhì)量工具可用。給的工具有限的時候Agent 是無米之炊工具足夠多并且定義得好Agent 能做的事情就會遠超一個 Chat 對話框的想象空間。這篇文章寫到這里都是我在實際搭建和部署 Solon AI 過程中的真實記錄。我沒有刻意去吹某個功能多強大因為任何框架都有它的局限真正的價值還是在于你怎么去設(shè)計工具、調(diào)參數(shù)、控制風(fēng)險。正如我前文講的Agent 不是什么神秘魔法它是在大模型外面加一個“感知-規(guī)劃-執(zhí)行-反思”的行動閉環(huán)。你把這四個環(huán)節(jié)打磨好了大模型就會從只會說話的顧問變成真的上手辦事的項目經(jīng)理。希望這篇內(nèi)容能幫你少踩幾個坑更快做出自己想要的“行動派”應(yīng)用。