XianyuAutoAgent's four prompt files, its cookie login, and its latest-tagged image

Four prompt files decide every sentence the bot sends

Getting to a first run is four documented steps:

1. 克隆仓库
git clone https://github.com/shaxiu/XianyuAutoAgent.git
cd XianyuAutoAgent

2. 安装依赖
pip install -r requirements.txt

3. 配置环境变量
创建一个 `.env` 文件，包含以下内容，也可直接重命名 `.env.example` ：
#必配配置
API_KEY=apikey通过模型平台获取
COOKIES_STR=填写网页端获取的cookie
MODEL_BASE_URL=模型地址
MODEL_NAME=模型名称
#可选配置
TOGGLE_KEYWORDS=接管模式切换关键词，默认为句号（输入句号切换为人工接管，再次输入则切换AI接管）
SIMULATE_HUMAN_TYPING=True/False #模拟人工回复延迟

The behaviour of the whole agent then sits in the `prompts` directory, and there are exactly four files: `classify_prompt.txt` for intent classification, `price_prompt.txt` for the price expert, `tech_prompt.txt` for the tech expert, and `default_prompt.txt` for the default reply. Nothing else in the tree is meant to be edited for tone or policy. You create them by stripping `_example` from the template names, otherwise the program falls back to reading the four templates as they ship. The Dockerfile automates that rename, copying `classify_prompt_example.txt` to `classify_prompt.txt` and the same for price, tech and default, so the image ships with the template text, while docker-compose.yml mounts the host's `./prompts` directory over `/app/prompts`.

The cookie string copied from a browser console is the entire login

Authentication is a pasted value. `COOKIES_STR` is filled with cookies taken from the Xianyu web client, and the documented route is manual: open the F12 developer console in the browser, choose Network, click Fetch/XHR, click one request, and read the cookies. There is no account login, no password field, and no OAuth step in this project. Two consequences follow for whoever deploys it. First, the credential is a live session token copied out of a signed-in browser, so the same rules apply as for any session cookie: whoever holds the file holds the account session. Second, in the Docker path that file is mounted into the container from the host, so a cookie that exists only inside a container filesystem would be lost on every rebuild. The compose file makes this explicit by binding `./.env:/app/.env` alongside the data and prompts directories.

A single full stop toggles the shop between the bot and a person

Human takeover is one keyword. `TOGGLE_KEYWORDS` holds the takeover switching keyword and defaults to the Chinese full stop, with the shipped example setting it to `。`. Typing that character switches the conversation to manual takeover, typing it again switches back to AI takeover. This is the manual override for the whole system: a single punctuation mark that is also ordinary punctuation in chat. The consequence is that the switch is a keyword typed into the running conversation rather than a mode you set in a dashboard, so whoever is watching the shop has to notice the conversation state before a customer sees an unanswered message. `SIMULATE_HUMAN_TYPING` is the related polish switch, set to `False` in the example file, and it decides whether replies are staggered to imitate a person typing.

Intent classification routes each message to one of three experts

The dialogue engine has two layers and both are named in the feature table. Context awareness is implemented with conversation history storage, described as lightweight conversation memory management that feeds the complete dialogue history into the LLM as context. Expert routing is implemented with an LLM prompt plus rule based routing: prompt engineering does intent recognition, and the result dispatches dynamically to an expert agent, with support for switching between bargaining, technical and customer service scenarios. So the classify prompt is not decoration. It is the switchboard that decides whether a message goes to the price expert, the tech expert, or the default reply. What the routing does not have is a stated fallback rule for a message whose intent the classifier cannot place, and no confidence threshold is documented, so misclassification shows up as a wrong expert answering rather than as an error.

Tiered price drops are implemented and market comparison is not

The business feature matrix separates shipped work from planned work, and the bargaining column shows the gap. The 议价系统 row has a tiered price reduction strategy marked as implemented, and market price comparison marked as still in planning. The practical consequence is narrow and real: the bot can negotiate with its tiered price reduction strategy and `price_prompt.txt`, but it has no data telling it what the item sells for elsewhere. So a buyer who quotes a competing price gets an answer derived from the discount ladder alone, and the reply will be as good or as bad as the prompt you wrote. The same pattern holds in the core engine row, where LLM auto reply and context management are done while sentiment analysis enhancement is listed as planned, meaning there is no implemented read of a buyer's emotional state feeding the routing decision.

Web search is wired into tech support while the RAG knowledge base is not

The technical support row pairs one implemented capability with one planned one: web search integration is done, and RAG knowledge base enhancement is still in planning. That combination changes what the tech expert can promise. With web search it can look something up while answering, but it has no store-owned corpus to quote from, no product manual loaded, and no vector index over your own listings. So the answers it gives on technical questions come from a live search plus the model's own knowledge plus `tech_prompt.txt`, and there is no configured path for you to make it answer only from your own documentation. The README does point at a Feishu based walkthrough document for newcomers, which is where the step by step version of this setup lives, but that guide is a separate document outside the repository and nothing in the tree keeps the two in sync.

Basic logging is the whole operations story, with no web console

The operations and monitoring row is the shortest one in the matrix. What exists is basic logging. What is planned is DingTalk integration and a web management interface. Read together with the screenshots the README shows, one of which is captioned as the backend log, the current state is a text log and nothing more. The consequence for an operator is that there is no browser view of which conversations are live, no place to read what the bot said yesterday, and no way to change a prompt from a page. Everything that would make this supervisable lives in the planned column. The only interface named as existing is the takeover keyword typed into a live chat, so supervision means watching the shop the way you would watch any other inbox.

A :latest image with restart: always, and no releases to hold on to

The repository ships no GitHub releases, and the default branch was last pushed on 2026-06-10. What it does ship is a Docker path that trades version pinning for availability. `docker-compose.yml` defines one service named `XianyuAutoAgent` running `image: shaxiu/xianyuautoagent:latest` with `restart: always`, on a bridge network called `xianyu-network`, with `TZ=Asia/Shanghai` in the environment. A `:latest` tag with `restart: always` means the container comes back on its own but the code underneath it is whatever the registry served that day, so a restart after an upstream change can bring behaviour you never reviewed. The Dockerfile is a two stage build on `python:3.10-alpine` that keeps a virtualenv from the builder stage, creates `data` and `prompts`, copies the four modules and `utils/`, and starts the same way the local path does:

python main.py

The dependency set behind that is five pinned packages: `openai==1.65.5`, `websockets==13.1`, `loguru==0.7.3`, `python-dotenv==1.0.1` and `requests==2.32.3`. The `openai` pin is the reason any OpenAI-compatible base URL works, which is how the shipped default reaches `https://dashscope.aliyuncs.com/compatible-mode/v1` with `MODEL_NAME=qwen-max`. The project's own notice is the part to weigh: the team may stop updating or delete the project at any time.

Editorial conclusion

This project fits a seller who already has a Xianyu web session, accepts that the bot speaks through four editable prompts, and wants Docker Compose to restart it forever. It does not fit anyone who needs market pricing, a retrieval knowledge base, sentiment analysis, or a browser view of live conversations, since the README lists all four as still planned. Before deploying, read the own notice in the README: the team may stop updating or delete the project at any time, there are no GitHub releases, and the last push was 2026-06-10, so the image tag you run is not a version you can hold.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. shaxiu/XianyuAutoAgent on GitHub