第五章：AI提示詞配置

歡迎回來！

在第四章：意圖路由器中，我們了解了機器人如何通過IntentRouter確定由哪個專家代理（如PriceAgent或TechAgent）處理用戶消息。

但代理被選定后，如何知道該說什么？如何以友好賣家身份應對技術問題，或按照策略進行價格協商？

（專家代理分類的越細，就便于生成更準確的提示詞給LLM）

這正是AI提示詞配置的核心作用。

為什么AI代理需要"提示詞配置"？

想象你聘請演員出演話劇中的特定角色。你不會只說"去表演！"，而是提供劇本、角色性格說明、場景背景以及具體臺詞指導。

• 我們的AI代理如同演員，大語言模型（LLM）是底層能力，但需要清晰指引——“劇本"和"角色設定”——才能在閑魚對話場景中正確表現。

• 這些指引即提示詞。提示詞配置就是定義并加載這些指令的過程，使每個代理在處理特定類型用戶請求時，明確知曉行為準則和關鍵信息。

• 這正是我們告訴AI的方式：“當處理這類消息（如價格問題）時，記住你是賣家，商品細節是這樣，對話歷史是那樣，你的目標是禮貌協商。”

什么是AI提示詞配置？

AI提示詞配置指代一系列文本指令、規則和上下文信息的集合，由代理打包發送給大語言模型（LLM），用于引導回復生成。

• 在XianyuAutoAgent項目中，這些提示詞定義于純文本文件。

• 每個專家代理（如PriceAgent、TechAgent）甚至路由器的分類回退代理，都有專屬的提示詞文件。

• 用戶可通過簡單編輯這些文本文件，輕松定制AI在不同場景下的個性和行為。

核心概念：系統提示詞

現代LLM交互通常采用特定消息結構，其中"system"消息用于提供高層指令、設定角色或注入關鍵上下文。

在本項目中，提示詞文件內容即用于構建LLM調用的"system"消息。系統提示詞可視作代理的核心指令和角色專屬背景知識。

工作原理：提示詞實戰

回顧AI代理系統章節流程，觀察提示詞的作用位置：

當XianyuReplyBot根據意圖選擇代理后，該代理已在啟動時加載專屬系統提示詞。調用LLM前，代理會構建完整的消息結構，包含：

1. 系統提示詞（來自配置文件）
2. 商品詳情
3. 對話歷史
4. 最新用戶消息

這種結構化消息（尤其是系統提示詞）告知LLM如何解讀信息及預期回復類型。

提示詞文件位置

提示詞配置文件存儲于項目根目錄的prompts文件夾，包含：

• classify_prompt.txt：用于ClassifyAgent（意圖路由器的LLM回退分類），指令LLM輸出預定義意圖標識（tech/price/default）
• price_prompt.txt：指導PriceAgent價格協商策略，包含底價規則、議價風格等
• tech_prompt.txt：指引TechAgent技術答疑，要求精確引用商品參數，支持外部知識檢索
• default_prompt.txt：定義DefaultAgent通用回復風格，設定機器人作為友好賣家的基礎人設

定制AI行為

編輯這些文件即可輕松調整AI行為！以price_prompt.txt為例：

你是一個專業的二手商品賣家。你的目標是以合理的價格出售商品，同時保持友好的態度。
與客戶交流時，請遵循以下原則：
1. 始終禮貌和友好。
2. 如果客戶詢問價格或議價，參考【商品信息】和【你與客戶對話歷史】。
3. 如果客戶出價低于你的心理價位，可以適當拒絕或提出你的最低價。
4. 議價不是無限的，如果客戶多次大幅度議價，可以婉拒或引導回到原價。
5. 回復請簡短明了，不要透露任何個人聯系方式（微信、QQ等）。
▲當前議價輪次：{bargain_count}

這是PriceAgent的"劇本"，設定角色（“專業二手賣家”）、目標（“合理定價，保持友好”）及具體規則（“參考商品信息”、“拒絕低價”、“限制議價輪次”）。

• 占位符{bargain_count}將在發送前被替換為實際議價次數（見AI代理系統代碼）。

• 修改此文件即可調整議價策略，例如更嚴格的價格底線或更靈活的溝通風格。

classify_prompt.txt結構略有不同，專用于引導LLM輸出單字意圖標識：

你是一個意圖分類機器人。你需要根據客戶的最新消息和對話歷史，判斷客戶的意圖。
你的任務是只回復以下標簽中的一個，不要回復其他任何內容：
- tech (詢問商品技術參數、規格、性能對比等)
- price (詢問價格、議價、討論包郵等)
- default (其他所有意圖，例如打招呼、詢問是否在、無關問題等)請根據【商品信息】和【你與客戶對話歷史】，判斷用戶最新消息的意圖：

該提示詞明確LLM的角色（“意圖分類機器人”），并嚴格限制輸出為預定義標簽，確保IntentRouter能正確解析分類結果。

代碼中的提示詞加載機制

如AI代理系統所示，XianyuReplyBot類在啟動時加載提示詞文件：

# 摘自 XianyuAgent.py 的簡化代碼片段
class XianyuReplyBot:def __init__(self):# ... 初始化客戶端 ...self._init_system_prompts() # 加載提示詞self._init_agents() # 使用提示詞初始化代理# ... 初始化路由器 ...def _init_system_prompts(self):"""從文件加載各代理提示詞"""prompt_dir = "prompts"try:with open(os.path.join(prompt_dir, "classify_prompt.txt"), "r", encoding="utf-8") as f:self.classify_prompt = f.read()with open(os.path.join(prompt_dir, "price_prompt.txt"), "r", encoding="utf-8") as f:self.price_prompt = f.read()with open(os.path.join(prompt_dir, "tech_prompt.txt"), "r", encoding="utf-8") as f:self.tech_prompt = f.read()with open(os.path.join(prompt_dir, "default_prompt.txt"), "r", encoding="utf-8") as f:self.default_prompt = f.read()logger.info("提示詞加載成功")except Exception as e:logger.error(f"提示詞加載失敗: {e}")raise # 加載失敗時終止def _init_agents(self):"""初始化各領域代理"""self.agents = {'classify': ClassifyAgent(self.client, self.classify_prompt, self._safe_filter),'price': PriceAgent(self.client, self.price_prompt, self._safe_filter),'tech': TechAgent(self.client, self.tech_prompt, self._safe_filter),'default': DefaultAgent(self.client, self.default_prompt, self._safe_filter),}

BaseAgent子類在生成回復時，通過_build_messages方法構建LLM輸入：

# 摘自 XianyuAgent.py 的簡化代碼片段
class BaseAgent:def __init__(self, client, system_prompt, safety_filter):self.client = clientself.system_prompt = system_prompt # 加載的提示詞文本self.safety_filter = safety_filterdef _build_messages(self, user_msg: str, item_desc: str, context: str) -> List[Dict]:"""構建LLM消息鏈"""system_content = f"【商品信息】{item_desc}\n【對話歷史】{context}\n{self.system_prompt}"return [{"role": "system", "content": system_content},{"role": "user", "content": user_msg}]

PriceAgent還會在系統消息中插入bargain_count，為LLM提供明確的議價階段信息。

結論

AI提示詞配置是XianyuAutoAgent項目中定義各代理行為規則、角色設定及應答策略的核心方法。

• 通過prompts目錄下的文本文件，用戶無需修改核心代碼即可定制AI的交互方式。

• 每個代理加載專屬提示詞并整合至LLM輸入，有效引導生成符合場景需求的回復。

理解提示詞配置機制后，您可自由調整AI賣家在閑魚平臺的交互策略。接下來我們將見證所有組件——對話記憶、通信層、AI代理系統、意圖路由器和提示詞配置——如何協同工作，詳見下一章主協調器。

---

第六章：主協調器

在前幾章中，我們已經構建了XianyuAutoAgent的核心組件：

• 第一章：對話記憶 - 學習機器人如何跟蹤聊天歷史和細節–sql
• 第二章：閑魚通信層 - 探索機器人如何連接閑魚平臺并收發消息–websocket
• 第三章：AI代理系統 - 了解機器人如何使用AI生成回復–LLM
• 第四章：意圖路由 - 解析用戶意圖的機制–正則匹配給專家代理-->提示詞txt
• 第五章：AI提示配置 - 通過文本文件定制AI行為

這些組件各自獨立，但如何協同工作？誰負責啟動引擎、管理消息流并確保系統平穩運行？

這正是主協調器的職責所在。

為什么需要"主協調器"？

想象一臺由齒輪、杠桿、引擎和線路組成的復雜機器。每個部件都有特定功能，但需要中央控制系統來協調運作。

我們的XianyuAutoAgent也是如此。主協調器需要：

1. 系統啟動
2. 建立連接閑魚平臺
3. 持續監聽消息
4. 路由消息到正確處理流程（存儲記憶、AI分析）
5. 連接管理（處理斷連、令牌過期）
6. 協調回復發送

主協調器如同空中交通管制員或交響樂指揮，雖不直接操作但確保系統有序運行。

主協調器的構成

核心職責包含：

• 系統啟動
• 通過WebSocket連接閑魚實時消息流
• 管理連接生命周期（重連、心跳、令牌刷新）
• 接收原始消息
• 傳遞消息給其他組件處理
• 協調回復發送

在項目中，main.py文件中的XianyuLive類即為主協調器實現。

運行機制：主循環

通過時序圖展示主協調器工作流程：

核心組件：XianyuLive類

系統啟動與主循環

# main.py 簡化代碼片段
if __name__ == '__main__':# 加載配置load_dotenv()# 初始化組件bot = XianyuReplyBot()xianyuLive = XianyuLive(cookies_str)# 啟動主循環asyncio.run(xianyuLive.main())

消息處理流程

async def handle_message(self, message_data, websocket):# 步驟1：消息確認# 步驟2：過濾非聊天消息# 步驟3：提取聊天信息# 步驟4：處理賣家控制命令# 步驟5：保存用戶消息# 步驟6：檢查人工模式# 步驟7：獲取商品信息# 步驟8：獲取對話上下文# 步驟9：AI生成回復# 步驟10：處理議價計數# 步驟11：保存機器人回復# 步驟12：發送回復

連接生命周期管理

• 心跳機制：定期發送心跳包檢測連接
• 令牌刷新：異步任務維護令牌有效性
• 異常處理：自動重連機制保證服務連續性

組件協同

主協調器通過持有各組件實例實現協同：

• XianyuApis處理平臺通信
• ChatContextManager管理記憶存儲
• XianyuReplyBot驅動AI生成

結論

主協調器作為系統核心，承擔連接管理、消息路由、組件協調等關鍵職責，通過XianyuLive類實現完整的自動化流程控制。

下一章：閑魚協議工具

---

第七章：閑魚協議工具

在第六章：主協調器中，我們了解了XianyuLive類如何協調整個機器人運作——連接閑魚平臺、監聽消息并協調數據流向記憶系統和AI系統。

• 然而，主協調器負責管理何時執行操作，而具體如何與閑魚平臺進行技術交互則需要專門的協議工具。

• 閑魚平臺與大多數在線平臺類似，在API和WebSocket通信中使用特定的技術"語言"。這些通信不僅需要特殊格式的消息體，還涉及唯一標識符和安全校驗碼等復雜機制。

為什么需要"協議工具"？

閑魚通信層（特別是XianyuLive和XianyuApis類）直接與服務器交互時面臨以下技術挑戰：

通過WebSocket發送消息時需構造包含以下元素的復雜數據結構：

• 消息唯一ID（uuid）
• 請求唯一ID（mid）
• 會話ID（cid）
• 接收方ID（toid）
• Base64等特殊編碼的消息內容
• 其他技術參數

HTTP API調用（如獲取商品詳情）需要：

• appKey、時間戳t、版本v、類型type等參數
• 安全簽名sign（采用臨時令牌token+時間戳+請求數據的特定算法生成）

接收的WebSocket消息可能采用Base64編碼和MessagePack二進制格式，需要專用解碼器處理

協議工具構成

這些工具函數主要位于utils/xianyu_utils.py文件，包含：

1. 唯一ID生成

# 來自utils/xianyu_utils.py
def generate_mid() -> str:"""生成符合閑魚要求的mid"""return f"{隨機數}{時間戳} 0"  # 示例：1231630000000 0def generate_uuid() -> str:"""生成設備特征uuid"""return f"-{時間戳}1"  # 示例：-16300000001

通過時間戳與隨機數組合生成符合平臺規范的標識符

2. 安全簽名生成

def generate_sign(t: str, token: str, data: str) -> str:"""MD5哈希簽名算法"""app_key = "34839810"  # 閑魚H5接口固定密鑰msg = f"{token}&{t}&{app_key}&{data}"return hashlib.md5(msg.encode()).hexdigest()

該簽名算法用于API請求合法性驗證

3. 消息解碼系統

在實際項目之中，錯誤的日志信息打印是非常重要的，一定要重視對報錯的處理

核心解碼函數實現：

class MessagePackDecoder:"""自定義MessagePack解析器"""def decode(self) -> Any:try:# 解析二進制數據結構return self._decode_value()  except Exception:return base64回退處理def decrypt(data: str) -> str:"""多層解碼處理器"""try:decoded_bytes = base64.b64decode(清理數據)# 優先嘗試MessagePack解析return MessagePackDecoder(decoded_bytes).decode()except MessagePackError:# 回退文本解碼return decoded_bytes.decode('utf-8')

支持從二進制到結構化數據的完整解析流程

4. Cookie解析器

def trans_cookies(cookies_str: str) -> Dict:"""Cookie字符串轉字典"""return {k:v for cookie in cookies_str.split("; ") for k,v in [cookie.split('=',1)]}

將.env文件中的cookie字符串轉換為requests可用的字典格式

系統架構關系

技術實現細節

MessagePack解碼器

包含20+種數據類型處理邏輯，支持：

• 定長/變長整數
• 浮點數解析
• 數組/映射結構
• 擴展數據類型處理

錯誤處理機制

采用三級回退策略：

1. 優先MessagePack解析
2. 嘗試UTF-8文本解碼
3. 最終十六進制轉儲+錯誤日志

模塊結構

結論

協議工具模塊作為閑魚通信的"技術密碼本"，承擔著：

• 唯一標識生成
• 安全認證簽名
• 復雜消息解碼
• 輸入數據標準化

通過封裝這些底層技術細節，使主協調器能夠專注于業務流程控制，實現通信層與業務邏輯的解耦。這是構建穩定可靠的閑魚自動化系統的關鍵技術保障