做了半年AI Agent我把踩過(guò)的坑和最終跑通的方案寫(xiě)下來(lái)。如果你正打算從零搭建一個(gè)自己的智能體或者已經(jīng)在折騰卻總感覺(jué)差一口氣這篇內(nèi)容應(yīng)該能讓你少走不少?gòu)澛?。先說(shuō)清楚“Agent-Reach”是個(gè)什么東西。它的名字拆開(kāi)看就挺直白Agent是智能體Reach是觸達(dá)與覆蓋。實(shí)際做下來(lái)這套項(xiàng)目解決的核心問(wèn)題就是“怎么讓一個(gè)帶目標(biāo)的AI Agent真正把事情辦完”而不是聊到一半就斷掉或者答非所問(wèn)地把流程帶偏。它能做的具體事情包括根據(jù)用戶輸入自動(dòng)拆解任務(wù)、調(diào)用外部工具完成搜索或數(shù)據(jù)獲取、把多輪對(duì)話的狀態(tài)管理起來(lái)、最終輸出結(jié)構(gòu)化結(jié)果。適合三類人參考想入門智能體開(kāi)發(fā)的開(kāi)發(fā)者、正在做自動(dòng)化辦公流程的產(chǎn)品經(jīng)理以及打算在團(tuán)隊(duì)內(nèi)部落地AI工具的技術(shù)負(fù)責(zé)人。下面是我從需求拆解、架構(gòu)設(shè)計(jì)到最終落地全程的完整復(fù)盤(pán)。1. 為什么做Agent-Reach先想清楚要解決什么問(wèn)題1.1 項(xiàng)目定位與核心需求我一開(kāi)始做的那個(gè)Agent簡(jiǎn)直是災(zāi)難。給它一個(gè)簡(jiǎn)單任務(wù)比如“幫我查一下最近三天某產(chǎn)品的用戶反饋并整理成摘要”它會(huì)先泛泛地說(shuō)一堆“好的我來(lái)幫您搜索相關(guān)信息”然后就沒(méi)有然后了。要不就是搜到一半突然開(kāi)始聊它自己多聰明。這不是模型不行是我壓根沒(méi)想清楚要做一個(gè)什么樣的系統(tǒng)。Agent-Reach立項(xiàng)時(shí)我給自己定了三條硬性需求任務(wù)必須能自動(dòng)拆解。用戶給一個(gè)模糊目標(biāo)系統(tǒng)內(nèi)部要把它拆成可執(zhí)行的子任務(wù)而不是讓模型憑感覺(jué)自由發(fā)揮。工具調(diào)用必須可控。Agent不能想調(diào)什么就調(diào)什么工具的注冊(cè)、參數(shù)校驗(yàn)、結(jié)果回傳都要有明確邊界。狀態(tài)必須可追蹤。每一輪對(duì)話、每一次工具調(diào)用、用戶上下文的變化都要有記錄否則長(zhǎng)對(duì)話場(chǎng)景下必亂。這三條寫(xiě)下來(lái)之后“Agent-Reach”這個(gè)名字自然就出來(lái)了Agent承擔(dān)智能分析推理Reach強(qiáng)調(diào)對(duì)結(jié)果的最終觸達(dá)——每個(gè)任務(wù)都要能走到頭。1.2 方案選型為什么不用現(xiàn)成的LangChain/CrewAI立項(xiàng)的時(shí)候團(tuán)隊(duì)里有人提議直接用LangChain或者CrewAI我的看法是不完全反對(duì)但也不能無(wú)腦用?，F(xiàn)成的Agent框架確實(shí)省事它幫你把工具調(diào)用、記憶管理、任務(wù)編排都封裝好了。但問(wèn)題恰恰出在這層封裝上一旦出現(xiàn)詭異Bug你根本不知道是框架的問(wèn)題還是自己邏輯的問(wèn)題。我在測(cè)試階段遇到過(guò)工具參數(shù)連續(xù)傳錯(cuò)的情況最后發(fā)現(xiàn)是框架內(nèi)部的callback機(jī)制和自己代碼的沖突這類問(wèn)題排查成本極高。所以Agent-Reach的核心邏輯我全部手寫(xiě)框架只作為底層模型調(diào)用的適配層。這樣的好處是每一行邏輯都在自己掌控下出任何問(wèn)題都能順著代碼追下去。壞處是前期開(kāi)發(fā)量確實(shí)大但做工具的都知道可控性大于一切。具體選型如下核心語(yǔ)言Python 3.10LLM接入層OpenAI SDK的異步接口兼容本地部署的模型服務(wù)工具注冊(cè)機(jī)制Python裝飾器函數(shù)簽名自動(dòng)解析持久化存儲(chǔ)SQLite存會(huì)話狀態(tài)JSONL存完整交互日志1.3 整體架構(gòu)的演進(jìn)過(guò)程第一版我是按單Agent思路做的所有邏輯塞在一個(gè)“大腦”里。跑起來(lái)就發(fā)現(xiàn)問(wèn)題任務(wù)一復(fù)雜上下文窗口就不夠用而且職責(zé)混亂用戶問(wèn)題解析、工具調(diào)用決策、結(jié)果校驗(yàn)全混在一起。隨后第二版我引入了“規(guī)劃器執(zhí)行器”的雙層結(jié)構(gòu)。規(guī)劃器負(fù)責(zé)理解用戶目標(biāo)、產(chǎn)出子任務(wù)列表執(zhí)行器負(fù)責(zé)逐個(gè)完成子任務(wù)并回傳結(jié)果。這次跑通了很多場(chǎng)景但仍有一個(gè)痛點(diǎn)子任務(wù)之間如果有依賴關(guān)系執(zhí)行起來(lái)容易串行阻塞。最終版借鑒了過(guò)去做微服務(wù)時(shí)的路由思路把每個(gè)子任務(wù)當(dāng)作一個(gè)獨(dú)立的路由目標(biāo)。規(guī)劃器只產(chǎn)出任務(wù)描述和預(yù)期輸出格式不在過(guò)程中干預(yù)具體執(zhí)行。這版才算真正跑順了代碼結(jié)構(gòu)也清爽planner.py管思維編排executor.py管工具調(diào)用memory.py管狀態(tài)記憶。2. Agent-Reach的核心設(shè)計(jì)一個(gè)能跑通的Agent骨架2.1 工具注冊(cè)機(jī)制讓Agent學(xué)會(huì)“使用雙手”Agent本質(zhì)上是一個(gè)會(huì)思考的對(duì)話系統(tǒng)但只有思考沒(méi)有工具它就只能紙上談兵。Agent-Reach里的工具注冊(cè)我完全模擬了微服務(wù)里API網(wǎng)關(guān)的模式。# tools/registry.py from typing import Callable, Dict import inspect import json class ToolRegistry: def __init__(self): self._tools: Dict[str, Dict] {} def register(self, name: str, description: str): def decorator(func: Callable): signature inspect.signature(func) params [ { name: p.name, type: str(p.annotation), required: p.default is inspect.Parameter.empty } for p in signature.parameters.values() if p.name ! self ] self._tools[name] { function: func, description: description, parameters: params } return func return decorator def get_tool_schema(self): return [ { name: name, description: tool[description], parameters: tool[parameters] } for name, tool in self._tools.items() ] def execute(self, name: str, **kwargs): if name not in self._tools: raise ValueError(fTool {name} not found) return self._tools[name][function](**kwargs) registry ToolRegistry() registry.register( namesearch_web, description搜索公開(kāi)網(wǎng)頁(yè)內(nèi)容返回與查詢?cè)~相關(guān)的文本摘要 ) def search_web(query: str, top_k: int 5): # 實(shí)際場(chǎng)景中可替換為搜索API或爬蟲(chóng)實(shí)現(xiàn) results [] # ... 具體實(shí)現(xiàn)省略 return results registry.register( namecalculate, description執(zhí)行數(shù)學(xué)計(jì)算支持四則運(yùn)算和括號(hào) ) def calculate(expression: str): try: result eval(expression, {__builtins__: {}}, {}) except Exception as e: return fError: {str(e)} return str(result)這里有個(gè)關(guān)鍵點(diǎn)我用inspect.signature自動(dòng)函數(shù)簽名解析替代了手寫(xiě)參數(shù)說(shuō)明。過(guò)去在別的項(xiàng)目里需要為每個(gè)工具手寫(xiě)JSON Schema維護(hù)起來(lái)比工具本身還累?，F(xiàn)在寫(xiě)一個(gè)函數(shù)就自動(dòng)生成SchemaAgent調(diào)用工具時(shí)能拿到精確的參數(shù)名和類型。實(shí)測(cè)下來(lái)這套機(jī)制的精度和效率都很穩(wěn)定。2.2 規(guī)劃器設(shè)計(jì)任務(wù)拆解的邏輯規(guī)劃器解決的問(wèn)題是用戶說(shuō)了一句話怎么把它變成一系列可執(zhí)行步驟。這一步做不好后面全亂。我一開(kāi)始嘗試過(guò)讓模型直接輸出JSON格式的任務(wù)列表效果不穩(wěn)定因?yàn)槟Ｐ团紶枙?huì)漏掉任務(wù)或憑空創(chuàng)造不存在的任務(wù)。后面改成兩步走先將用戶輸入解析為“意圖約束條件”的結(jié)構(gòu)體再基于意圖匹配預(yù)置的任務(wù)模板模板中有明確依賴關(guān)系比如用戶說(shuō)“幫我調(diào)研一下最近三個(gè)月AI編程工具的排行最好找有數(shù)據(jù)來(lái)源的資料”。第一步解析出意圖是“調(diào)研排行”約束是“三個(gè)月內(nèi)”“需要數(shù)據(jù)來(lái)源”。第二步匹配到“調(diào)研型任務(wù)”模板模板里定義了搜索、篩選、歸納三個(gè)子任務(wù)且后兩個(gè)依賴前一個(gè)的結(jié)果。這比讓模型自由生成任務(wù)列表可靠得多。因?yàn)轭A(yù)置模板保證了任務(wù)結(jié)構(gòu)的完整性模型只負(fù)責(zé)往模板里填具體內(nèi)容而不是從零開(kāi)始想結(jié)構(gòu)。# planner.py 核心邏輯片段 from dataclasses import dataclass, field from typing import List dataclass class Task: task_id: str description: str dependencies: list field(default_factorylist) status: str pending result: str class Planner: def __init__(self, llm): self.llm llm def create_tasks(self, user_input: str) - List[Task]: # 第一層解析意圖和約束 parsed self._parse_intent(user_input) # 第二層從模板庫(kù)中匹配任務(wù)結(jié)構(gòu) template self._match_template(parsed[intent]) tasks [] for step_desc, deps in template.steps: task Task( task_iduuid4().hex, descriptionstep_desc.format(**parsed[constraints]), dependenciesdeps ) tasks.append(task) return tasks def _parse_intent(self, user_input: str): prompt f從用戶輸入中提取意圖和約束條件。 用戶輸入{user_input} 輸出JSON格式包含 intent 和 constraints 兩個(gè)字段。 # 調(diào)用LLM得到結(jié)構(gòu)化結(jié)果 # 如果JSON解析失敗退回基于規(guī)則的匹配這里面有個(gè)細(xì)節(jié)值得提退回策略。模型輸出不一定每次都合法如果解析失敗就直接報(bào)錯(cuò)用戶體驗(yàn)會(huì)很差。我的做法是LLM解析失敗時(shí)退回基于關(guān)鍵詞的意圖匹配。雖然不如前者聰明但至少能把流程走下去。這個(gè)兜底設(shè)計(jì)在真實(shí)場(chǎng)景中救了不知道多少次。2.3 執(zhí)行器與狀態(tài)追蹤Multi-Turn對(duì)話的根基Agent系統(tǒng)繞不開(kāi)的一個(gè)難題是多輪對(duì)話的狀態(tài)管理。用戶上一秒說(shuō)“查一下A產(chǎn)品的資料”下一秒說(shuō)“順便對(duì)比一下B”如果系統(tǒng)不知道“A產(chǎn)品”指什么第二個(gè)指令就會(huì)落空。Agent-Reach里我為執(zhí)行器配了一個(gè)結(jié)構(gòu)化的Memory對(duì)象負(fù)責(zé)維護(hù)三類信息當(dāng)前用戶目標(biāo)全局唯一的不會(huì)被中間操作覆蓋已完成任務(wù)列表每個(gè)任務(wù)有狀態(tài)和關(guān)鍵結(jié)果摘要用戶偏好快照比如用戶偏好中文輸出、需要詳細(xì)來(lái)源等# memory.py class SessionMemory: def __init__(self, session_id: str): self.session_id session_id self.goal None self.completed_tasks [] self.preferences {} self.context {} def set_goal(self, goal: str): self.goal goal def add_completed_task(self, task: Task): self.completed_tasks.append({ task_id: task.task_id, description: task.description, result_summary: task.result[:500] }) def to_system_prompt(self) - str: 將記憶內(nèi)容拼接到系統(tǒng)提示詞中給LLM提供上下文 prompt_parts [] if self.goal: prompt_parts.append(f當(dāng)前用戶目標(biāo){self.goal}) if self.completed_tasks: prompt_parts.append(已完成的任務(wù)) for t in self.completed_tasks: prompt_parts.append(f- {t[description]} {t[result_summary]}) return \n.join(prompt_parts)每個(gè)會(huì)話句柄會(huì)全程攜帶這個(gè)Memory每次調(diào)用執(zhí)行器前都把Memory的內(nèi)容注入系統(tǒng)Prompt。我實(shí)測(cè)過(guò)這個(gè)做法比單純把所有歷史消息塞給模型要省錢省token。書(shū)讀百遍其義自見(jiàn)但Token燒了就是燒了未必就能“其義自見(jiàn)”。3. 實(shí)操過(guò)程從零搭建Agent-Reach的完整記錄3.1 環(huán)境準(zhǔn)備與項(xiàng)目初始化先交代一下搭建環(huán)境我用的是一臺(tái)Linux服務(wù)器配置大概4核8G日常跑這個(gè)Agent系統(tǒng)沒(méi)任何壓力。如果你只是本地開(kāi)發(fā)測(cè)試Mac或Windows也能跑通只要能正常安裝Python依賴。項(xiàng)目初始化步驟# 1. 創(chuàng)建項(xiàng)目目錄 mkdir agent-reach cd agent-reach # 2. 建虛擬環(huán)境 python3.10 -m venv venv source venv/bin/activate # 3. 安裝核心依賴 pip install openai1.30.0 pip install pydantic2.7.0 pip install aiosqlite0.20.0 # 4. 目錄結(jié)構(gòu)規(guī)劃 mkdir -p agent_reach/{core,tools,memory,api} mkdir -p logs touch agent_reach/{__init__.py,main.py,config.py}依賴安裝有個(gè)需要注意的地方OpenAI SDK版本千萬(wàn)不能亂裝最新版。1.x版本API風(fēng)格變化大你要是照著老教程寫(xiě)代碼大概率會(huì)碰到Response對(duì)象不一樣的問(wèn)題。我鎖在1.30.0這個(gè)版本是因?yàn)槲覝y(cè)過(guò)它和自定義Agent循環(huán)的兼容性最穩(wěn)不追求新功能就別往上走了。3.2 核心循環(huán)邏輯Agent運(yùn)行時(shí)的調(diào)度中樞Agent-Reach的運(yùn)行循環(huán)是整個(gè)系統(tǒng)的心臟它的職責(zé)是讓規(guī)劃器、執(zhí)行器、記憶系統(tǒng)各司其職地配合起來(lái)。# agent_reach/core/agent_loop.py import asyncio class AgentReach: def __init__(self, planner, executor, memory_factory): self.planner planner self.executor executor self.memory_factory memory_factory async def run(self, user_input: str, session_id: str None): # 1. 獲取或創(chuàng)建會(huì)話記憶 memory self.memory_factory.get_or_create(session_id) # 2. 更新用戶目標(biāo) memory.set_goal(user_input) # 3. 規(guī)劃任務(wù) tasks self.planner.create_tasks(user_input) results [] for task in tasks: # 4. 檢查依賴是否已經(jīng)滿足 if not self._dependencies_satisfied(task, tasks): continue # 5. 執(zhí)行任務(wù)注入當(dāng)前記憶作為上下文 task_prompt self._build_task_prompt(task, memory) tool_results await self.executor.execute(task_prompt) # 6. 更新任務(wù)狀態(tài)與記憶 task.result tool_results task.status completed memory.add_completed_task(task) results.append(tool_results) # 7. 匯總最終答案 final_answer await self._summarize_results(results, memory) return final_answer這套主循環(huán)看著簡(jiǎn)單但調(diào)整了很多次才穩(wěn)定。核心要點(diǎn)是每個(gè)任務(wù)在執(zhí)行時(shí)都從Memory里取“當(dāng)前用戶目標(biāo)已完成任務(wù)列表”作為上下文這保證Agent干活時(shí)不會(huì)忘記最初的指令。用戶問(wèn)的是A執(zhí)行到子任務(wù)時(shí)被B帶偏這種情況我在早期版本遇到太多次了。_build_task_prompt方法里還有一層細(xì)節(jié)不是把全部上下文塞進(jìn)去而是只取前兩輪的關(guān)鍵信息并明確拼接當(dāng)前任務(wù)描述。太長(zhǎng)反而干擾模型判斷啥都給等于啥都沒(méi)看。3.3 工具實(shí)戰(zhàn)讓Agent接入搜索和計(jì)算為了讓Agent不是空殼子我實(shí)現(xiàn)了一個(gè)模擬搜索工具、一個(gè)真實(shí)可用的計(jì)算工具以及一個(gè)日期時(shí)間工具。這三個(gè)工具覆蓋面夠了能跑通常見(jiàn)的“查信息算數(shù)據(jù)看時(shí)間”組合場(chǎng)景。日期工具的實(shí)現(xiàn)細(xì)節(jié)值得一說(shuō)Agent經(jīng)常需要知道今天是幾號(hào)來(lái)回答“近三天”這類相對(duì)時(shí)間問(wèn)題。我通過(guò)工具返回精確日期比讓模型自己猜要靠譜得多。# tools/others.py import datetime registry.register( nameget_current_date, description獲取當(dāng)前日期和星期格式如2025-02-14 星期五 ) def get_current_date(): now datetime.datetime.now() weekdays [星期一, 星期二, 星期三, 星期四, 星期五, 星期六, 星期日] weekday weekdays[now.weekday()] return f{now.strftime(%Y-%m-%d)} {weekday}講一個(gè)我在實(shí)際測(cè)試中經(jīng)常用的場(chǎng)景大家能直觀感受這套系統(tǒng)的工作方式。用戶發(fā)來(lái)一句話“幫我查一下今天深圳的天氣然后計(jì)算攝氏26度等于多少華氏度?！盇gent的規(guī)劃器把這句話拆成兩個(gè)子任務(wù)查天氣、算換算。先執(zhí)行日期工具拿到當(dāng)日日期再用搜索工具查天氣關(guān)鍵詞同時(shí)用計(jì)算工具執(zhí)行算式。執(zhí)行完畢匯總模塊把“天氣數(shù)據(jù)”和“華氏度數(shù)值”拼成自然語(yǔ)言答案返回。這個(gè)場(chǎng)景雖然簡(jiǎn)單但完整走通了“目標(biāo)解析-任務(wù)拆解-工具調(diào)用-結(jié)果匯總”的鏈路用來(lái)做系統(tǒng)驗(yàn)收特別合適。3.4 會(huì)話接口怎么把Agent暴露出去光有一個(gè)核心循環(huán)還不夠得像Web服務(wù)一樣給外界暴露訪問(wèn)入口否則沒(méi)法在真實(shí)業(yè)務(wù)里用。我用FastAPI封裝了一個(gè)極簡(jiǎn)的HTTP接口# agent_reach/api/server.py from fastapi import FastAPI from pydantic import BaseModel import uuid app FastAPI(titleAgent-Reach API) agent_instance AgentReach(...) # 注入已初始化的實(shí)例 class ChatRequest(BaseModel): message: str session_id: str None class ChatResponse(BaseModel): reply: str session_id: str task_count: int app.post(/chat, response_modelChatResponse) async def chat(req: ChatRequest): session_id req.session_id or uuid.uuid4().hex reply await agent_instance.run(req.message, session_id) task_count len(agent_instance.memory_factory.get(session_id).completed_tasks) return ChatResponse(replyreply, session_idsession_id, task_counttask_count) app.get(/health) async def health(): return {status: ok}接入Web前后的差異很大。之前寫(xiě)死命令行直接調(diào)用很多邊界情況測(cè)不出來(lái)。接上HTTP接口后并發(fā)請(qǐng)求、重復(fù)session、超時(shí)這些真實(shí)業(yè)務(wù)里的問(wèn)題全暴露了對(duì)系統(tǒng)健壯性的提升非常明顯。4. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄4.1 工具調(diào)用失敗的三個(gè)高頻原因把Agent-Reach放到更多人手里跑之后反饋回來(lái)的問(wèn)題集中在工具調(diào)用環(huán)節(jié)這里列一下出現(xiàn)頻率最高的三類情況。第一類是參數(shù)格式錯(cuò)誤。模型輸出了字符串工具期望的是數(shù)字類型直接傳進(jìn)去必然報(bào)錯(cuò)。解決方案是在工具注冊(cè)時(shí)加一層“類型校正”邏輯用pydantic把傳入值按Schema定義做一次強(qiáng)制轉(zhuǎn)換轉(zhuǎn)換失敗才真正報(bào)錯(cuò)。第二類是超時(shí)無(wú)響應(yīng)。搜網(wǎng)工具偶爾卡在某次請(qǐng)求上幾秒沒(méi)返回會(huì)阻塞整個(gè)流程。解決思路是給每個(gè)工具調(diào)用加asyncio.timeout包裝超時(shí)就返回“工具超時(shí)請(qǐng)重試或換一種方式”不能讓一個(gè)工具卡死全流程。第三類是遞歸死循環(huán)。模型發(fā)現(xiàn)第一次工具返回的結(jié)果不滿足條件會(huì)嘗試再補(bǔ)一次搜索如果第二次結(jié)果仍不滿足它可能會(huì)繼續(xù)調(diào)第三次、第四次……我在早期版本沒(méi)加次數(shù)限制某次測(cè)試中模型連調(diào)了11次工具Token燒得心都在滴血。解決辦法是給執(zhí)行器加一個(gè)循環(huán)上限我設(shè)為最多5次超過(guò)上限就停止工具調(diào)用直接基于當(dāng)前已有信息生成回答。這個(gè)機(jī)制上線后再?zèng)]出現(xiàn)“無(wú)限循環(huán)燒Token”的慘案。4.2 Prompt設(shè)計(jì)的微妙之處語(yǔ)氣與格式的影響實(shí)踐下來(lái)發(fā)現(xiàn)同一個(gè)Agent能力上限的30%取決于代碼70%取決于你給它的系統(tǒng)Prompt。剛開(kāi)始我寫(xiě)的系統(tǒng)Prompt過(guò)于簡(jiǎn)化“你是一個(gè)智能助手請(qǐng)完成用戶的任務(wù)?！边@種話等于沒(méi)寫(xiě)。后續(xù)我在Prompt里加了三類關(guān)鍵信息角色定義跨領(lǐng)域研究助理在收到任務(wù)后先拆解再執(zhí)行邊界約束不能編造來(lái)源如果工具沒(méi)有返回?cái)?shù)據(jù)如實(shí)說(shuō)明未找到不得編造輸出偏好中文回答核心結(jié)論放開(kāi)頭細(xì)節(jié)放在后段引用工具結(jié)果時(shí)要標(biāo)明來(lái)源# agent_reach/core/prompts.py SYSTEM_PROMPT 你是Agent-Reach智能助理具備任務(wù)拆解和工具調(diào)用能力。 工作流程 1. 根據(jù)用戶目標(biāo)拆解為具體步驟。 2. 不要跳過(guò)中間步驟按依賴順序執(zhí)行。 3. 每個(gè)工具調(diào)用前判斷是否是完成當(dāng)前任務(wù)所必需的手段。 4. 無(wú)論結(jié)果如何最終都要整合信息給用戶一個(gè)明確的回復(fù)。 約束 - 必須基于工具返回的數(shù)據(jù)回答沒(méi)有數(shù)據(jù)時(shí)明確告知用戶不要編造。 - 回答使用中文在開(kāi)頭給出結(jié)論再補(bǔ)充細(xì)節(jié)。 - 工具調(diào)用失敗時(shí)不要反復(fù)重試同一個(gè)動(dòng)作最多更換策略后再試一次。這段Prompt上線后整體回答質(zhì)量肉眼可見(jiàn)地提升。尤其是“不要編造”和“反復(fù)重試”這兩條約束直接減少了模型幻覺(jué)和Token浪費(fèi)。后來(lái)我又根據(jù)反饋微調(diào)過(guò)幾個(gè)版本比如在“工具調(diào)用失敗時(shí)”那句后面加上了“更換策略后再試一次”的引導(dǎo)詞模型的表現(xiàn)更穩(wěn)定了。4.3 上下文膨脹與Token成本省錢技巧Agent系統(tǒng)部署久了最容易面臨的隱形問(wèn)題就是上下文膨脹。因?yàn)槟愕腗emory系統(tǒng)會(huì)往Prompt里拼接已完成任務(wù)摘要、用戶偏好、工具執(zhí)行記錄等時(shí)間一長(zhǎng)總量非?？捎^。實(shí)測(cè)數(shù)據(jù)一次完整調(diào)研型任務(wù)如果包含6個(gè)子任務(wù)完成時(shí)的對(duì)話總Token消耗大約在12K-20K之間其中Memory注入的部分約占總量的三到四成。這意味著你每跑一輪都要為“過(guò)去”付錢。省錢技巧有兩個(gè)。一個(gè)是摘要分層。不要直接拼接原始子任務(wù)結(jié)果而是用一個(gè)“摘要模型”把每個(gè)結(jié)果壓縮到100-200字再注入Prompt。三級(jí)壓縮后上下文總量能省四成左右而最終回答質(zhì)量和直接拼接原文幾乎無(wú)差。另一個(gè)技巧是“只保留對(duì)當(dāng)前目標(biāo)有關(guān)鍵價(jià)值的信息”。我給Memory增加了一個(gè)“相關(guān)性打分”的步驟每完成一個(gè)子任務(wù)后先讓規(guī)劃器評(píng)估該結(jié)果和最終目標(biāo)的相關(guān)度相關(guān)度低于閾值的直接存進(jìn)SQLite不注入本輪Prompt。這讓上下文總量進(jìn)一步縮減同時(shí)不失關(guān)鍵信息。4.4 實(shí)戰(zhàn)中的兩個(gè)小技巧第一個(gè)技巧給工具函數(shù)名取一個(gè)語(yǔ)義明確的名字。工具名其實(shí)會(huì)直接影響模型的理解search_web比execute_search_procedure_001效果好得多。模型看到清晰的名字調(diào)用起來(lái)才有信心。第二個(gè)技巧所有工具的說(shuō)明用中文不要用中英混搭。雖然模型英文能力強(qiáng)但這會(huì)讓它在生成工具參數(shù)時(shí)出現(xiàn)莫名其妙的語(yǔ)言切換。統(tǒng)一用中文描述成功率反而更高尤其當(dāng)參數(shù)說(shuō)明中包含“這個(gè)參數(shù)表示……”這類語(yǔ)義描述的時(shí)候中文表達(dá)更符合模型的任務(wù)上下文。這兩個(gè)技巧不是我拍的腦袋是在排查模型調(diào)用習(xí)慣后發(fā)現(xiàn)的。有一次我連續(xù)跑五個(gè)場(chǎng)景發(fā)現(xiàn)三個(gè)場(chǎng)景中模型都傾向于調(diào)用名稱包含get_且描述簡(jiǎn)潔的工具而不是那些描述冗長(zhǎng)的工具。想提升調(diào)用率就把工具說(shuō)明減到三行以內(nèi)只保留最核心的信息。Agent-Reach這套項(xiàng)目做下來(lái)我最大的感受是智能體開(kāi)發(fā)的難點(diǎn)不在于“讓模型變聰明”而在于“把模型的能力有條理地引導(dǎo)到目標(biāo)任務(wù)上”。規(guī)劃、執(zhí)行、記憶、工具四個(gè)環(huán)節(jié)環(huán)環(huán)相扣哪一環(huán)松了都跑不出穩(wěn)定結(jié)果。所以如果你也在做類似的Agent項(xiàng)目建議不要急著堆功能先把這四塊骨骼搭穩(wěn)。骨架撐住了皮肉是可以慢慢長(zhǎng)的。以后有機(jī)會(huì)我再把多Agent協(xié)作、人機(jī)審核介入這些擴(kuò)展點(diǎn)展開(kāi)聊聊。