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