RTX 4060本地部署Mini-Agent实战：轻量架构与显存优化

1. 项目概述：为什么一个“Mini-Agent”值得在RTX 4060上折腾三个月

我第一次在本地跑通一个能真正调用天气API、读取本地Excel、再自动生成周报PDF的Agent时，显卡温度刚冲到72℃，风扇声像台老式电扇在全力续命——而它正运行在我那台二手RTX 4060笔记本上，没连服务器，没走云API，全程离线。这不是Demo，是我在给一家做工业设备维保的客户落地的真实轻量级运维助手。标题里那个“Mini-Agent”，不是指功能缩水，而是指架构精简、资源可控、部署可审计、行为可追溯——它不追求通用人工智能的幻觉输出，只解决“今天工单超了3单，该提醒张工换滤芯”这种具体问题。

核心关键词全在这里：Mini-Agent（非LLM全家桶，是带明确技能边界的轻量执行体）、消费级显卡（RTX 3060/4060/4070为主力，显存8–12GB，功耗≤150W）、本地部署（模型、工具链、状态存储全在本机，无外网回传、无第三方日志）、Agent（具备规划-工具调用-反思闭环，非单纯Prompt工程）、Ollama（当前最适配消费级硬件的本地模型运行时，但绝非唯一解）。

这项目不是教你怎么“用Ollama跑Qwen3”，而是解决一串真实卡点：

• 模型加载后显存占用飙到95%，推理卡顿，根本没法接实时工具调用；
• 工具函数注册后Agent总在“思考下一步”环节死循环，查日志发现是JSON Schema校验失败，但错误提示被Ollama吞掉了；
• 本地部署后想加个“自动归档历史对话到SQLite”的功能，结果发现Ollama原生不支持插件式扩展，得自己写中间层；
• 最要命的是：客户要求所有设备数据不出内网，但Ollama默认监听0.0.0.0:11434，一个配置漏改就等于敞开了防火墙。

所以这篇日记不讲概念，不画架构图，只记录我踩过的坑、测出的阈值、手写的补丁、以及为什么某些“教程推荐方案”在消费级显卡上就是行不通。比如你搜“dify本地部署教程”，90%会教你Docker一键拉起，但没人告诉你Docker Desktop在Windows上默认只分配2GB内存给WSL2，而一个7B模型+RAG向量库+Chrome无头浏览器，光启动就要3.8GB——这直接导致你的Agent在调用网页抓取工具时，进程被OOM Killer静默杀死。

适合谁看？三类人：

• 正在用RTX 4060/4070跑本地AI的开发者，需要知道显存怎么抠着用、模型怎么剪枝、工具链怎么绕过Ollama限制；
• 企业IT或交付工程师，要给客户签“数据不出域”承诺，得清楚每个端口、每个文件、每条日志的实际落点；
• Agent框架学习者，厌倦了LangChain文档里“假设你已部署好LLM”的跳步式教学，想从nvidia-smi命令开始，亲手把Agent焊死在本地硬件上。

下面所有内容，都来自我在这台笔记本上敲下的27个Git commit、重装11次Ollama、手撕3个Python包装器的真实过程。没有“理论上可行”，只有“实测在4060上跑满72小时未崩”。

2. 架构设计与技术选型：为什么放弃Dify、LangChain，坚持手写Mini-Agent内核

2.1 核心矛盾：消费级显卡的“三座大山”

在RTX 4060（8GB显存）上部署Agent，本质是在和三个物理限制搏斗：

第一座山：显存带宽瓶颈
4060的显存带宽是272 GB/s，而A100是2TB/s。这意味着同样一个7B模型的KV Cache，在4060上加载延迟高3.7倍。很多教程说“Qwen2-7B跑得动”，但没说清楚——它跑得动是指“能加载”，还是“能以>5 token/s速度流式输出”？我实测：用Ollama默认num_ctx=2048加载Qwen2-7B，显存占用7.1GB，但首次响应要等4.3秒；把num_ctx砍到1024，显存降到5.8GB，首响压到1.8秒，代价是长文本理解能力归零。这不是参数调优，是物理定律。

第二座山：PCIe通道数限制
消费级主板（如B650）通常只提供16条PCIe 4.0通道。当你同时跑：

• Agent主进程（占1条x16）
• Chrome无头浏览器（GPU加速渲染，再占1条x16）
• SQLite WAL日志写入（虽走PCIe，但SSD控制器争抢带宽）
  实际可用带宽只剩理论值的60%。这解释了为什么很多“Agent+网页抓取”项目在服务器上丝滑，在笔记本上频繁超时——不是代码问题，是PCIe总线被挤爆了。

第三座山：功耗墙与散热墙
4060笔记本版TDP常锁在90–115W。一旦GPU利用率持续>85%，温度超过75℃，就会触发降频。而Agent的工具调用周期（Plan→Act→Observe）天然存在脉冲式负载：规划阶段CPU吃紧，工具执行阶段GPU飙升。Ollama默认不感知系统温度，它只管算，直到风扇啸叫、屏幕闪烁。

这三座山，直接否定了所有“开箱即用”的Agent平台。

2.2 为什么Dify被排除在方案之外

Dify确实强大，但它为云环境设计：

• 其Web UI依赖PostgreSQL+Redis+MinIO三件套，光数据库连接池就占1.2GB内存；
• 它的“工具编排”本质是HTTP API转发，每次调用都要序列化/反序列化JSON，对4060的PCIe带宽是额外负担；
• 最致命的是：Dify的RAG模块默认启用bge-m3嵌入模型（1.2GB），而Ollama不支持在同一进程内混用不同精度模型——你无法让Qwen2-7B（int4量化）和bge-m3（fp16）共存于同一显存空间。

我试过强行部署：Dify容器启动后，nvidia-smi显示GPU显存占用100%，但nvidia-persistenced日志报错CUDA_ERROR_OUT_OF_MEMORY。原因很讽刺：Dify的前端Vue组件在浏览器里渲染图表时，也偷偷调用了WebGL，和Ollama抢显存。

2.3 LangChain的“过度工程”陷阱

LangChain的抽象层在服务器上是优势，在4060上是枷锁：

• ConversationalRetrievalChain默认启用stuff文档合并策略，会把整个知识库拼成超长Prompt，直接触发Ollama的num_ctx溢出；
• 其Tool类强制要求args_schema为Pydantic BaseModel，而很多本地工具（如pandas.read_excel）的参数是动态的，硬套Schema会导致ValidationError，且错误堆栈深达12层，根本定位不到源头；
• 更隐蔽的问题：LangChain的CallbackHandler会高频写入日志到磁盘，而4060笔记本多用NVMe SSD，其随机写IOPS在持续负载下会从50万跌到8万——这导致Agent的“思考日志”写入延迟高达300ms，拖慢整个执行周期。

2.4 我的Mini-Agent内核设计原则

基于以上，我定义了四条铁律：

1. 显存即生命线：所有模型必须int4量化，KV Cache显式管理，禁用任何隐式缓存；
2. 工具即进程：每个工具（天气查询、Excel读取、PDF生成）独立为子进程，用multiprocessing.Queue通信，避免全局状态污染；
3. 状态即文件：Agent的对话历史、工具调用记录、错误快照，全部落盘为SQLite单文件，禁用网络数据库；
4. 监控即刚需：每500ms采样一次nvidia-smi --query-gpu=temperature.gpu,utilization.gpu,memory.used，超阈值自动降载（如关闭Chrome GPU加速、切到CPU模式推理）。

最终架构极简：

[用户输入] ↓ [Mini-Agent主循环] —— 规划：用Qwen2-7B-int4生成JSON Plan ↓ [工具调度器] —— 解析Plan，fork子进程执行工具（隔离显存） ↓ [结果聚合器] —— 合并工具输出，喂给Qwen2反思（Refine） ↓ [SQLite写入器] —— 原子写入history.db（含时间戳、显存快照、耗时）

没有中间件，没有消息队列，没有服务发现——所有模块通过文件系统和进程间通信直连。

2.5 Ollama：为何选它，又为何必须魔改

Ollama成为基石，不是因为它完美，而是因为它是目前唯一满足“消费级显卡友好三要素”的运行时：

• 要素一：模型加载粒度可控
  Ollama的Modelfile允许你指定FROM模型、PARAMETER num_ctx 1024、ADAPTER（LoRA），甚至RUN预处理命令。这让我能把Qwen2-7B的num_ctx硬编码为1024，把num_gqa设为8（减少KV Cache），把rope.frequency_base调高到500000（提升长文本位置编码鲁棒性）——这些在HuggingFace Transformers里要改源码，在Ollama里一行PARAMETER搞定。

• 要素二：HTTP API足够轻量
  Ollama的/api/chat接口返回纯JSON，无WebSocket握手、无JWT鉴权、无请求ID追踪。我用curl -s http://localhost:11434/api/chat -d '{"model":"qwen2","messages":[{"role":"user","content":"..."}]}'，从发起到收到首字节平均耗时87ms（4060实测），比LangChain的ChatOllama封装快3.2倍——因为后者多了一层aiohttp异步调度。

• 要素三：社区量化模型丰富
  ollama run qwen2:7b-instruct-q4_K_M这种命名规范，意味着它已预量化（q4_K_M是4-bit量化，K分组，M中等质量），加载后显存占用仅4.3GB，留出3.7GB给工具进程。而自己用llama.cpp量化，光调试GGUF参数就耗掉我两天。

但Ollama必须魔改三点：

1. 禁用默认日志：ollama serve默认写~/.ollama/logs/server.log，高频写入拖慢SSD。我在systemd服务文件里加--log-level error，并重定向stdout/stderr到/dev/null；
2. 绑定本地地址：ollama serve --host 127.0.0.1:11434，杜绝0.0.0.0暴露风险；
3. 显存监控钩子：在/usr/bin/ollama二进制前加一层Shell包装器，每调用前执行nvidia-smi --query-gpu=memory.used --format=csv,noheader,nounits | awk '{if($1>7500) exit 1}'，超7.5GB显存直接拒绝请求，避免OOM。

这就是为什么标题强调“Mini-Agent开发日记”——它不是用现成框架搭积木，而是像机械师一样，拧开Ollama的外壳，给它的散热风扇加装温控开关。

3. 核心细节解析：从Ollama安装到Agent内核的17个关键实操点

3.1 Ollama安装：避开Windows子系统的“内存黑洞”

网上90%的“ollama下载太慢怎么办”教程，都在教你怎么换国内镜像源。但根本问题不在下载速度，而在Windows安装路径的陷阱。

Ollama官方Windows安装包（.exe）默认把模型存到C:\Users\<user>\.ollama\models\，而这个路径在WSL2中映射为/mnt/c/Users/<user>/.ollama/models/。问题来了：WSL2访问Windows文件系统，性能损耗高达400%。我实测：从/mnt/c/读取一个3.2GB的GGUF模型，平均IO延迟127ms；而从WSL2原生/home/xxx/.ollama/models/读取，延迟仅18ms。

正确做法（仅Windows）：

1. 下载Ollama Windows版，但不要运行安装程序；
2. 手动创建WSL2内的模型目录：mkdir -p /home/xxx/.ollama/models；
3. 修改Ollama配置：编辑C:\Users\<user>\.ollama\config.json，将"models"字段改为"/home/xxx/.ollama/models"；
4. 在PowerShell中以管理员身份运行：

   # 关闭WSL2 wsl --shutdown # 启动WSL2并挂载Windows盘为只读（防误写） wsl -u root -e sh -c "mount -t drvfs -o metadata,uid=1000,gid=1000,umask=22,fmask=11 /c /mnt/c" # 启动Ollama服务（指向WSL2路径） wsl -u xxx -e ollama serve --host 127.0.0.1:11434

这样，模型加载速度提升5.3倍，且避免了Windows Defender对/mnt/c/目录的实时扫描（它曾让我Ollama服务启动慢11秒）。

提示：Mac和Linux用户无需此操作，但要注意Mac的/usr/local权限问题。我见过太多人在Mac上sudo ollama run qwen2，结果模型被写入/usr/local/share/ollama/.ollama，导致普通用户无法读取——正确姿势是ollama run qwen2（不加sudo），Ollama会自动用当前用户权限创建~/.ollama。

3.2 模型选择：为什么Qwen2-7B-int4是4060的“甜点模型”

在RTX 4060上，模型不是越大越好，而是要找“显存占用-推理速度-任务精度”的帕累托最优解。我横向测试了7款主流7B模型（均用Ollama q4_K_M量化）：

*Excel解析准确率：测试100个含合并单元格、公式、中文表头的.xlsx文件，Agent能否正确提取“设备编号”“故障类型”“维修日期”三列；
*天气API调用成功率：连续100次调用https://api.weather.com/v3/wx/forecast/daily/5day，Agent能否正确构造URL、解析JSON、提取temperatureMax字段。

Qwen2-7B胜出的关键，在于它的中文Tokenization效率。Qwen2用QwenTokenizer，对中文字符平均1字符=1.3 token；而Llama3用LlamaTokenizer，1中文字符=2.1 token。这意味着同样一段500字的中文工单描述，Qwen2生成Prompt仅需650 tokens，Llama3要1050 tokens——直接导致Llama3在num_ctx=1024时频繁截断，规划失真。

实操步骤：

1. 拉取模型：ollama pull qwen2:7b-instruct-q4_K_M（注意后缀，这是Ollama社区验证过的稳定量化版）；
2. 创建自定义Modelfile：

   FROM qwen2:7b-instruct-q4_K_M PARAMETER num_ctx 1024 PARAMETER num_gqa 8 PARAMETER temperature 0.3 PARAMETER repeat_penalty 1.1 SYSTEM """ 你是一个工业设备维保助手，只做三件事：1. 解析Excel工单；2. 查询天气决定是否外勤；3. 生成PDF周报。禁止闲聊、禁止虚构信息。 """

3. 构建：ollama create my-agent -f Modelfile；
4. 验证显存：ollama run my-agent "你好"后立即执行nvidia-smi，确认Memory-Usage稳定在4.3–4.5GB。

注意：别信“ollama下载慢怎么办”的玄学教程。Ollama模型下载慢，99%是因为DNS污染。在C:\Windows\System32\drivers\etc\hosts（Windows）或/etc/hosts（Mac/Linux）里加一行：185.199.108.133 cdn.ollama.ai，下载速度从12KB/s升到1.8MB/s。

3.3 Mini-Agent内核：137行Python实现的规划-执行闭环

我的Mini-Agent主循环，核心就137行（不含注释），它不依赖任何框架，只用Python标准库和requests。以下是关键片段解析：

规划阶段（Plan）：

def plan_step(user_input: str, history: List[Dict]) -> Dict: # 构造严格JSON格式的Prompt，禁用自由发挥 prompt = f"""<|im_start|>system 你是一个工业维保Agent，只能输出JSON，格式： {{ "thought": "分析用户需求，不超过20字", "tool": "可用工具名：excel_reader/weather_api/pdf_generator", "tool_input": {{...}} // 工具所需参数，必须符合JSON Schema }} <|im_end|> <|im_start|>user {user_input} <|im_end|> <|im_start|>assistant """ # 调用Ollama，超时设为8秒（显存紧张时推理可能卡住） resp = requests.post( "http://127.0.0.1:11434/api/chat", json={"model": "my-agent", "messages": [{"role": "user", "content": prompt}], "stream": False}, timeout=8 ) try: plan_json = json.loads(resp.json()["message"]["content"]) # 强制校验Schema，避免Agent胡说 if plan_json["tool"] not in ["excel_reader", "weather_api", "pdf_generator"]: raise ValueError("Invalid tool name") return plan_json except Exception as e: # 记录错误到SQLite，不抛异常（保证Agent不死） log_error(f"Plan failed: {str(e)} | Response: {resp.text}") return {"thought": "规划失败，切换人工模式", "tool": "none", "tool_input": {}}

关键点：

• <|im_start|>等特殊token必须显式写出，Ollama的Qwen2模型对token边界极其敏感，少一个<|im_end|>就可能输出乱码；
• timeout=8是血泪教训：4060在75℃时，Ollama推理偶尔卡死，不设超时会导致整个Agent线程阻塞；
• log_error函数会把错误连同当时的nvidia-smi快照一起写入SQLite，这是后续排查的黄金数据。

工具执行阶段（Act）：

def execute_tool(tool_name: str, tool_input: Dict) -> str: # 每个工具都是独立进程，避免显存泄漏 if tool_name == "excel_reader": proc = subprocess.Popen( [sys.executable, "tools/excel_reader.py"], stdin=subprocess.PIPE, stdout=subprocess.PIPE, stderr=subprocess.PIPE, text=True ) stdout, stderr = proc.communicate(json.dumps(tool_input)) return stdout if proc.returncode == 0 else f"ERROR: {stderr}" elif tool_name == "weather_api": # 关键：禁用SSL验证（内网环境证书可能不全），加超时 resp = requests.get( f"https://api.weather.com/v3/wx/forecast/daily/5day?geocode={tool_input['lat']},{tool_input['lon']}&format=json&apiKey=xxx", timeout=5, verify=False # 内网部署常见，不加此行会SSL错误 ) return resp.text elif tool_name == "pdf_generator": # PDF生成用weasyprint，它依赖GTK，但在Windows上需额外DLL # 我打包了gtk-4.0.dll到tools/目录，用os.add_dll_directory()注入 os.add_dll_directory(os.path.join(os.path.dirname(__file__), "tools")) from weasyprint import HTML html = f"<h1>周报</h1><p>{tool_input['content']}</p>" HTML(string=html).write_pdf("output/report.pdf") return "PDF生成成功，路径：output/report.pdf"

关键点：

• subprocess.Popen而非os.system：前者可精确控制stdin/stdout，后者会继承父进程环境，可能污染显存；
• verify=False是内网部署必备，很多企业防火墙会拦截HTTPS证书链；
• os.add_dll_directory()解决Windows下GTK DLL找不到的问题，比装完整GTK环境省3.2GB空间。

反思阶段（Observe）：

def reflect_step(plan: Dict, tool_output: str) -> str: # 把规划+执行结果喂给模型，让它判断是否完成 prompt = f"""<|im_start|>system 你是一个反思引擎，根据规划和执行结果，判断任务是否完成。只输出JSON： {{ "status": "success" or "failed", "reason": "简短说明，如'天气API返回空数据'", "next_action": "继续执行下一个工具，或返回最终答案" }} <|im_end|> <|im_start|>user 规划：{json.dumps(plan)} 执行结果：{tool_output} <|im_end|> <|im_start|>assistant """ resp = requests.post("http://127.0.0.1:11434/api/chat", json={"model": "my-agent", "messages": [{"role": "user", "content": prompt}]}) return resp.json()["message"]["content"]

这个设计让Agent具备“自检”能力。比如天气API返回{"error": "invalid geocode"}，反思引擎会识别为failed，并触发重试逻辑，而不是把错误JSON当答案返回给用户。

3.4 显存监控与动态降载：让Agent在75℃高温下继续工作

这是让Mini-Agent在消费级显卡上“活下来”的核心技术。我写了gpu_monitor.py，每500ms执行：

import subprocess import json def get_gpu_stats(): # 用nvidia-smi获取原始数据 result = subprocess.run( ["nvidia-smi", "--query-gpu=temperature.gpu,utilization.gpu,memory.used", "--format=csv,noheader,nounits"], capture_output=True, text=True ) if result.returncode != 0: return {"temp": 0, "util": 0, "mem_used": 0} lines = result.stdout.strip().split("\n") temp, util, mem = lines[0].split(", ") return { "temp": int(temp.strip()), "util": int(util.strip().replace("%", "")), "mem_used": int(mem.strip().replace(" MiB", "")) } def dynamic_throttle(stats): # 温度>75℃ 或 显存>7.2GB，触发降载 if stats["temp"] > 75 or stats["mem_used"] > 7200: # 1. 关闭Chrome GPU加速（节省1.2GB显存） subprocess.run(["taskkill", "/f", "/im", "chrome.exe"]) # 2. 切换Ollama到CPU模式（临时） os.environ["OLLAMA_NUM_GPU"] = "0" # 3. 降低推理并发数 global MAX_CONCURRENT_TOOLS MAX_CONCURRENT_TOOLS = 1 log_info(f"降载触发：温度{stats['temp']}℃，显存{stats['mem_used']}MB")

然后在Agent主循环里插入：

while True: stats = get_gpu_stats() dynamic_throttle(stats) # ... 执行规划-执行-反思 ... time.sleep(0.5) # 每轮间隔0.5秒，避免监控本身吃资源

实测效果：在连续运行12小时后，GPU温度稳定在71–74℃，从未触发降频，而未加监控的版本在第3小时就因过热降频，响应延迟从1.2秒涨到4.7秒。

实操心得：别用pynvml库！它在Windows上会和Ollama的NVIDIA驱动冲突，导致nvidia-smi命令失效。坚持用原生命令行，虽然丑，但稳。

4. 实操全流程：从零开始部署一个可工作的Mini-Agent（含全部配置文件）

4.1 环境准备：Windows/Mac/Linux三平台统一清单

硬件要求（最低）：

• GPU：NVIDIA RTX 3060（12GB） / RTX 4060（8GB） / RTX 4070（12GB）
• CPU：Intel i5-1135G7 或 AMD Ryzen 5 5600H（4核8线程）
• 内存：16GB DDR4（建议32GB，避免SWAP）
• 存储：512GB NVMe SSD（模型+工具+日志约占用280GB）

软件清单（全部免费开源）：

关键配置文件（全部贴出，可直接复制）：

1.ollama.service（Linux systemd服务，放/etc/systemd/system/）：

[Unit] Description=Ollama Service After=network-online.target [Service] Type=simple User=yourusername WorkingDirectory=/home/yourusername ExecStart=/usr/bin/ollama serve --host 127.0.0.1:11434 Restart=always RestartSec=3 Environment="PATH=/usr/local/bin:/usr/bin:/bin" Environment="OLLAMA_NUM_GPU=1" Environment="OLLAMA_NO_CUDA=0" # 关键：重定向日志，避免SSD写爆 StandardOutput=null StandardError=null SyslogIdentifier=ollama [Install] WantedBy=default.target

启用命令：

sudo systemctl daemon-reload sudo systemctl enable ollama sudo systemctl start ollama

2.agent_config.json（Agent主程序配置）：

{ "ollama_host": "http://127.0.0.1:11434", "model_name": "my-agent", "max_history_length": 20, "gpu_monitor_interval_ms": 500, "throttle_temp_threshold": 75, "throttle_mem_threshold_mb": 7200, "tools": { "excel_reader": { "timeout_sec": 30, "max_file_size_mb": 50 }, "weather_api": { "base_url": "https://api.weather.com/v3/wx/forecast/daily/5day", "api_key": "your-api-key-here", "timeout_sec": 5 }, "pdf_generator": { "output_dir": "./output", "max_pages": 50 } } }

3.requirements.txt（Python依赖）：

requests==2.31.0 openpyxl==3.1.2 weasyprint==62.2 lxml==4.9.4

安装命令：pip install -r requirements.txt --no-cache-dir（--no-cache-dir防pip缓存占满SSD）

4.2 分步部署：15分钟完成从安装到第一个Agent响应

Step 1：安装Ollama（Windows）

• 下载OllamaSetup.exe，双击运行；
• 打开PowerShell（管理员），执行：

  # 创建WSL2模型目录 wsl -u root -e mkdir -p /home/yourname/.ollama/models # 修改配置 wsl -u yourname -e sh -c 'echo "{\"models\":\"/home/yourname/.ollama/models\"}" > ~/.ollama/config.json' # 启动服务 wsl -u yourname -e ollama serve --host 127.0.0.1:11434 &

Step 2：拉取并定制模型

• 在WSL2终端中：

  # 拉取基础模型 ollama pull qwen2:7b-instruct-q4_K_M # 创建Modelfile（内容见3.2节） echo 'FROM qwen2:7b-instruct-q4_K_M PARAMETER num_ctx 1024 PARAMETER num_gqa 8 SYSTEM """你是一个工业维保助手..."""' > Modelfile # 构建 ollama create my-agent -f Modelfile

Step 3：部署Agent代码

• 创建项目目录：mkdir mini-agent && cd mini-agent；
• 创建main.py（粘贴3.3节的137行核心代码）；
• 创建tools/目录，放入excel_reader.py（用openpyxl解析Excel）、weather_api.py（封装requests调用）、pdf_generator.py（用weasyprint）；
• 放入agent_config.json和requirements.txt；
• 安装依赖：pip install -r requirements.txt；

Step 4：首次运行与验证

• 启动Agent：python main.py；
• 在另一终端测试：

  curl -s http://127.0.0.1:11434/api/chat -d '{ "model": "my-agent", "messages": [{"role": "user", "content": "你好"}] }' | jq '.message.content'

  应看到"你好！我是工业设备维保助手，请告诉我需要处理什么任务。"；
• 测试工具链：上传一个test.xlsx到./input/，运行python main.py --input ./input/test.xlsx，检查./output/report.pdf是否生成。

Step 5：生产化加固

• Windows：用winsw将main.py包装为Windows服务，开机自启；
• Mac：用launchd创建plist文件；
• Linux：用systemd创建mini-agent.service（类似4.1节的ollama.service）；
• 全平台：在main.py开头加入：

  import os os.environ["PYTHONDONTWRITEBYTECODE"] = "1" # 禁用.pyc，省SSD空间 os.environ["PYTHONUNBUFFERED"] = "1" # 实时输出日志

4.3 性能调优实录：4060上的极限参数表

经过72小时压力测试（每分钟1次工单处理请求），我得出4060的黄金参数组合：