XianyuAutoAgent：把閒魚客服交給 LLM 值守，先看清它的 Cookie 依賴與提示詞路由
智能闲鱼客服机器人系统：专为闲鱼平台打造的AI值守解决方案，实现闲鱼平台7×24小时自动化值守，支持多专家协同决策、智能议价和上下文感知对话。
秒懂
- 它是什麼？
- 這是一個以 Python 撰寫、GPL-3.0 授權的閒魚自動回覆機器人，靠網頁端 Cookie 接管訊息、用四份提示詞模板做意圖分類與專家分發。它的核心價值在提示詞工程，不在模型能力；風險則集中在帳號憑證與平台規則。
- 適合誰用？
- 如果你手上有閒魚店鋪、願意自己維護一份網頁端 Cookie、並且接受回覆品質完全取決於 prompts 目錄下那四份文字檔，這個專案值得跑一次 python main.py 看實際對話日誌再決定。反過來說，需要合規客服管道、需要多帳號集中管理、或不想承擔 Cookie 失效與帳號風險的人，不應該把它放進正式流程。
- 可以商用嗎？
- 可以，但有條件。GPL-3.0 是 copyleft 授權：如果你散布包含它的軟體，就必須以同一授權公開該軟體的原始碼。只在內部執行、不對外散布，則不會觸發這項義務。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 98 天前。
- 用什麼語言寫的？
- 主要是 Python（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它解決的是「沒人盯訊息」，不是「客服品質」
閒魚的二手交易場景有個現實：買家多半在夜間或零碎時間發問，賣家不可能一直守著對話框。XianyuAutoAgent 針對的正是這段空窗，README 把它描述為「7×24 小時自動化值守」。目標使用者是個人賣家或小規模店鋪，而不是有客服團隊的商家，因為它沒有工單、沒有坐席分配、也沒有跨帳號的後台。
從功能矩陣可以看出優先順序。已實作的是 LLM 自動回覆、上下文管理、階梯降價策略、網路搜尋整合與基礎日誌；情感分析、市場比價、RAG 知識庫、釘釘整合與 Web 管理介面都還標記為規劃中。也就是說，它目前是一條從訊息進來到 LLM 回覆出去的直線，外加一組提示詞切換，不是一套完整的客服系統。把它當成「值守工具」是準確的，當成「客服平台」就會失望。
Cookie 接管加四份提示詞，就是全部的架構
這個專案沒有官方 API 可用，所以它走的是網頁端身分模擬。README 要求填入 COOKIES_STR，並說明取得方式：在閒魚網頁端按 F12 打開控制台，切到 Network 的 Fetch/XHR，點任一請求查看 cookies。整條訊息鏈路因此建立在一個會被瀏覽器與平台逐步淘汰的憑證上。
對話處理分兩層。第一層是意圖分類，由 prompts/classify_prompt.txt 決定；第二層是專家分發，README 寫明是「LLM prompt + 規則路由」，命中議價、技術或一般客服場景後交給對應的 Agent。四個提示詞檔案各有分工：classify_prompt.txt 做意圖分類，price_prompt.txt 是價格專家，tech_prompt.txt 是技術專家，default_prompt.txt 是預設回覆。上下文方面，README 說是「輕量級對話記憶管理」，把完整對話歷史作為 LLM 上下文輸入。
這裡有個容易被忽略的取捨：完整歷史直接進上下文，意味著長對話會持續推高 token 消耗，而 README 沒有提到截斷或摘要策略。議價這類來回十幾輪的對話，成本曲線不會是平的。
部署路徑：五個環境變數與一次 pip install
安裝步驟在 README 裡寫得很直白。先 git clone https://github.com/shaxiu/XianyuAutoAgent.git 並進入目錄，接著 pip install -r requirements.txt，環境要求是 Python 3.8+。
設定的部分要建立 .env，或直接把 .env.example 改名。必填四項：API_KEY 由模型平台取得、COOKIES_STR 來自網頁端、MODEL_BASE_URL 是模型地址、MODEL_NAME 是模型名稱。選填兩項：TOGGLE_KEYWORDS 控制接管模式切換詞，預設是句號，輸入句號切為人工接管，再輸入一次切回 AI；SIMULATE_HUMAN_TYPING 設為 True 或 False 來模擬人工回覆延遲。
README 提到預設模型是通義千問，要換其他 API 得自己改 MODEL_BASE_URL 與 MODEL_NAME。還有一個容易踩的步驟：必須建立 prompts/*_prompt.txt，或者把模板名稱中的 _example 去掉，否則系統會讀取四個提示詞模板的內建內容。最後執行 python main.py 啟動。整個流程沒有容器化說明，也沒有 systemd 或進程守護範例，長時間值守要靠使用者自己補上。
提示詞就是業務邏輯，也是它最脆弱的地方
這個專案的差異化幾乎全在提示詞。議價不是靠一套定價演算法，而是靠 price_prompt.txt 描述「階梯降價策略」；技術支援不是靠知識庫，而是靠 tech_prompt.txt 加上網路搜尋整合。好處是修改成本極低，改文字檔就能調整行為，不需要碰程式。
代價是行為不確定。提示詞驅動的意圖分類在邊界案例上會漂移，同一個買家問「這個還能便宜嗎」和「最低多少」，可能被分到不同專家。README 沒有提供分類準確率的評估方式，也沒有回歸測試的說明。你只能靠執行後看日誌判斷，而日誌在功能矩陣裡只被列為「基礎」。
另一個現實限制是專案自己聲明的：README 寫「本項目僅供學習與交流」，並說鑑於項目的特殊性，開發團隊可能在任何時間停止更新或刪除專案。這是採用決策裡必須先讀進去的一句話，不是免責樣板。
什麼情況下它會直接失效
最明顯的失敗模式是 Cookie 過期或失效。COOKIES_STR 一旦被平台判定無效，整個值守就中斷，而且 README 沒有描述自動重取或失效告警機制。對於需要 7×24 的場景，這代表你得自己盯著進程與登入狀態。
其次是模型端。MODEL_BASE_URL 與 MODEL_NAME 指向的服務若回傳錯誤、限流或延遲升高，對話就會卡住或回覆品質下滑，而 README 沒有提到重試或降級策略。
第三是場景錯配。如果你的商品需要精確報價、庫存確認或售後流程，這些都不在已實作清單裡；階梯降價是提示詞層的行為，不是有上下限保護的規則引擎。若你賣的是高單價、需要人工確認的商品，讓 LLM 自行議價的風險高於省下的時間。
和自建腳本、SaaS 客服相比，差在哪裡
最直接的替代方案是照著 README 提到的上游專案 cv-cat/XianYuApis 自己寫一層。那個專案處理的是閒魚介面本身，XianyuAutoAgent 在其上加了提示詞路由、專家分發與 .env 設定流程。差別在於你要不要自己實作意圖分類與多專家切換。如果只需要固定話術回覆，自己寫可能更可控；如果要的是能分辨議價與技術問題的對話層，這個專案省下的正是那部分。
另一類替代是市面上的 SaaS 客服系統。它們通常有正式的 API 串接、坐席管理與報表，代價是月費與平台綁定，而且多半不支援閒魚這種以網頁端為主的管道。選擇的關鍵不在功能多寡，而在你願不願意把帳號憑證交給一個 GPL-3.0 的本地腳本。
授權方面，專案採用 GPL-3.0。這意味著如果你修改後對外散布，通常需要以相同授權釋出對應原始碼；單純自用執行則不涉及散布。這是一般性的授權說明，具體情況仍應諮詢法律專業人士。
維護成本落在提示詞與憑證兩處
README 沒有檢索到任何 release，也就是說沒有版本化的升級路徑，更新只能跟著 main 分支走。這讓「升級」變成一件需要自己判斷的事：拉下新程式碼後，你改過的 prompts 目錄檔案是否會被覆蓋，README 沒有交代。
日常維護的兩個固定支出很清楚。一是 Cookie 的重新取得，屬於手工作業，沒有自動化。二是提示詞調校，每當你發現某類問題被分錯專家，就得回頭改 classify_prompt.txt 或對應的專家提示詞。這兩件事都不難，但都不會自己消失。
值得注意的是，README 中列出的規劃項目包含釘釘整合與 Web 管理介面，若這些落地，維運負擔會下降；但在那之前，你面對的是一個需要人工照看的自動化工具。作者也在文件中留下聯絡信箱與交流群，說明目前社群是主要的支援管道，而非 issue 追蹤或正式文件站。
編輯結論
如果你手上有閒魚店鋪、願意自己維護一份網頁端 Cookie、並且接受回覆品質完全取決於 prompts 目錄下那四份文字檔，這個專案值得跑一次 python main.py 看實際對話日誌再決定。反過來說，需要合規客服管道、需要多帳號集中管理、或不想承擔 Cookie 失效與帳號風險的人，不應該把它放進正式流程。動手前先確認三件事：COOKIES_STR 能否穩定取得、TOGGLE_KEYWORDS 設定的接管詞是否與你日常訊息衝突、以及 MODEL_NAME 指向的模型是否支援你需要的上下文長度。作者在 README 中已寫明專案可能隨時停止更新或刪除，這個前提應該納入你的採用判斷。
社群筆記