旧电脑本地部署Hermes Agent：配置、联调与维护

去年冬天我把一台闲置的旧笔记本重装了系统，本意只是做一台常年在线的小主机，结果一个月后它成了我家里最忙的一台机器：上面常驻着一个本地智能体运行时，也就是我给它起的代号“爱马仕（Hermes Agent）”。它不像网页对话框那样问一句答一句就结束，而是一个跑在自己机器上的进程——接收指令、拆解任务、调用工具、读写本地文件、执行命令、把结果回传，全程都在我的眼皮底下发生。这篇就聊透一件事：在一台普通的个人电脑上，从零开始把爱马仕（Hermes Agent）装起来、配好、跑通、并且能长期稳定地用下去。适合谁看？手上有一台闲置电脑或者主力机性能富余、对本地智能体、自动化任务编排有兴趣、但又不想一上来就折腾分布式部署的朋友。哪怕你只会复制粘贴命令，跟着走也能落地；如果你已经有运维底子，中间关于权限模型和参数取舍的几段应该更对你胃口。

1. 先想清楚：本地跑智能体运行时到底图什么

动手之前我一直觉得有必要先把“为什么”讲清楚，因为这一步没想明白，后面配置的时候很容易被各种参数绕晕，最后装完吃灰。我踩过这个坑，第一次装完只跑了两句对话就关了，觉得跟网页版没区别，直到第二次带着明确目的重装，才发现完全是两个东西。

1.1 三个真实诉求：隐私边界、成本可控、可定制

第一个诉求是文件不出机器。网页对话模式下，你让它帮忙整理一份表格，文件得先上传；而在本地运行时里，它读的是你磁盘上那个路径的文件，中间不经过任何外部存储。对于包含内部资料、个人记录、尚未公开的稿件这类内容，这条边界非常重要。我自己有一批工作笔记，放在本地让它做归类和摘要，整个过程数据只在本机内存和磁盘之间流转。

第二个诉求是成本可控。本地运行时本身开源免费，花钱的只有模型调用这一环，而且怎么花、花多少完全由你决定：可以接一个便宜的云端推理服务，可以限制单次会话的 token 上限，也可以本地跑小参数模型做草稿、云端模型做终稿。我给自己定的规矩是日常整理类任务走本地小模型，复杂推理才走云端，一个月下来账单低到可以忽略。

第三个诉求是可定制。这是本地运行时相对封闭产品最大的优势。工具是自己注册的，提示词是自己写的，工作目录、记忆文件、日志格式全都可以改。我给它写了三个自定义工具：一个查天气的、一个读 RSS 的、一个把长文切成结构化摘要的，加起来不到两百行代码，但它们让我每天早上的例行任务从“手动点六个网站”变成了“一条命令”。

提示：如果你只是偶尔问几个问题、不需要它碰你本地的文件、也不想折腾配置，那本地运行时的收益其实不大，网页对话更省事。别为了折腾而折腾。

1.2 硬件与系统底线的实测判断

硬件这块我给一个实测结论，避免你走弯路。纯做“调度层”——也就是它自己不跑模型，只负责规划、调工具、转发请求——那门槛极低，我实测在一台 4 核 8G 内存的老机器上跑得很稳，CPU 占用常态在个位数，内存峰值不到 1.2G。真正吃资源的是“本地模型”这部分，那是另一个量级的事。

我整理了一张对照表，按用途分档，你可以对号入座：

操作系统方面，我更推荐 Linux 或者 macOS，主要原因是路径分隔符、权限模型、进程管理这三件事在类 Unix 系统上更一致，容器化也更顺。Windows 上不是不能跑，但你得准备好面对路径转换、换行符、权限继承这几类问题，我帮朋友在 Windows 上装过一次，多花了大概四十分钟处理路径相关的报错。如果你坚持用 Windows，建议直接上 WSL2，把运行环境放到 Linux 子系统里，能省一半事。

1.3 和“直接开个网页对话”的本质区别

很多人装完之后的第一反应是“这不就是个聊天框吗”，然后就没有然后了。这两者的差别不在交互形式，而在执行闭环。网页对话的输出是文本，你得自己拿这段文本去执行；本地运行时的输出可以是“我已经把文件改好了”“命令已经跑完了，日志在某个路径”。

举个我每天都在用的例子：早上我让它读三个信息源，把重复内容合并，按主题聚成四条，写进一个 Markdown 文件，并且把昨天那个文件归档到按日期命名的子目录里。整个过程包含网络读取、去重判断、文件写入、目录重命名四类操作，这是一条完整的执行链。网页对话要完成同样的事，中间得你手动搬运至少四次。

理解了这一点，你就会明白后面配置里为什么“工具权限”和“工作目录”这两块那么重要——它们是执行闭环的物理边界，边界画不清楚，要么它干不了活，要么它能干出你不想看到的活。

2. 开工前的环境盘点与依赖准备

真正开始装之前，我建议花二十分钟做一次环境盘点。我见过太多人一上来就 clone 代码，结果卡在 Python 版本不对、pip 源超时、磁盘空间不足这类基础问题上，白耗一晚上。这一节就是把地基夯实。

2.1 系统版本、磁盘、内存的硬性门槛

先把三样东西确认了：解释器版本、可用磁盘、内核版本。运行时框架对解释器版本通常有下限要求，我这套配置用的是 Python 3.11，实测 3.10 也能跑，但个别依赖的语法糖在 3.9 上会报错，所以建议直接上 3.11 或以上。查一下当前版本：

python3 --version df -h uname -a

三个命令分别看解释器版本、磁盘余量、内核信息。磁盘这块别只看/的余量，还得看你要放数据的那块盘。我把工作目录放在一块单独的固态上，原因是运行时会产生大量小文件——会话记录、工具调用日志、文件快照——这些文件碎、写入频繁，放在机械盘或者系统盘上时间长了容易拖慢整体响应。

内存方面，即便只跑调度层，也建议留出 2G 以上空闲。原因不是它自己要用多少，而是上下文拼装这一环会瞬时占用不少内存：它要把历史会话、工具描述、当前任务、检索到的记忆片段拼成一次请求，内容多的时候峰值会明显抬升。我一开始给了 8G 的机器，跑长会话时偶尔会触发系统的内存回收，表现就是卡顿一两秒。

注意：别在剩余空间低于 10% 的盘上跑长期任务。日志文件是持续增长的，等你发现空间满了的时候，通常已经出现了写入失败但没报错的情况，排查起来很烦。

2.2 运行时选择：Python 虚拟环境还是容器

这是第一个需要做取舍的地方，两条路各有适用场景，没必要争谁更优。

虚拟环境方案的优点是轻、启动快、调试方便。你在项目目录下建一个 venv，所有依赖装进去，跟系统 Python 完全隔离。改代码后直接重启进程就行，日志实时打在终端里，出问题一眼能看到。缺点是它对系统本身的依赖是有暴露面的——尤其是一些需要编译的包，系统上缺了构建工具就会装不上。

容器方案的优点是环境完全自包含，换台机器只要镜像在，跑起来行为一致；而且权限隔离天然更好做，你可以精确控制它能访问哪个目录。缺点是首次构建镜像慢，挂载目录、用户 ID 映射这些东西需要额外配置，调试的时候进容器看现场也麻烦一点。

我的选择是：主力机用虚拟环境，长期在线的那台机器用容器。前者我要频繁改代码、看日志；后者我要求它稳定、隔离、重启后自动拉起，改代码的频率低。这个分法我觉得挺合理，你也可以照搬。

2.3 目录规划：把配置、数据、日志分开放

这一步很多人跳过，但我必须强调，因为它是后面所有麻烦的根源之一。如果你把配置文件、数据文件、日志全塞在源码目录里，那么升级的时候一覆盖，配置没了；清理日志的时候一手抖，数据没了。

我的目录结构长这样，你可以按自己的习惯调整名字，但分层这个思路建议保留：

建目录就一行：

mkdir -p ~/hermes/{app,conf,workspace,data,logs,backup}

分层之后有几个直接好处：升级只动app；备份只打包conf和data；清理空间只清logs；出问题时能快速定位是哪一层的问题。后面排查章节里我会多次用到这个结构，你先建好，省得来回找。

3. 从零安装：一条可复现的落地路径

准备工作做完，正式进安装环节。我把整个过程拆成三段：拉代码建环境、装依赖跑自检、初始化配置。这三段每一步都有明确的“完成标志”，看到标志再往下走，别一口气复制一大串命令然后对着报错发呆。

3.1 拉取源码与创建隔离环境

先进入到源码目录，创建虚拟环境并激活。这里有个细节值得说：先建环境再拉代码，还是先拉代码再建环境？我习惯先建目录、建环境，再拉代码，原因是虚拟环境和源码放在同一层级，目录结构更清楚，而且删代码重拉的时候环境还在，不用重装依赖。

cd ~/hermes/app python3 -m venv .venv source .venv/bin/activate python -V

最后那行python -V是确认激活生效，如果还是系统版本，说明激活失败或者被你 shell 的配置覆盖了。激活成功后命令行提示符前面通常会带(.venv)前缀。

然后拉代码。这里我把仓库地址写成占位形式，你替换成自己的来源即可：

git clone <你的仓库地址> hermes-src cd hermes-src git log -1 --oneline

git log那行是记录当前版本号，强烈建议你把这一行输出抄到笔记里。后面对比问题、决定要不要升级、出事了回滚，全靠这个版本号。我吃过一次亏：升级后行为变了，想回滚却记不清原来是什么版本，白白折腾半小时。

3.2 安装依赖与首次冷启动自检

依赖安装这一步，我的建议是分两次装：先装核心依赖，跑一次自检，成功后再装可选依赖。这样出问题的时候能立刻判断是核心链路的问题还是扩展组件的问题。

pip install --upgrade pip pip install -r requirements.txt pip install -e .

pip install -e .这步是把它以可编辑模式装进环境，好处是你改源码后不用重装，直接重启进程就生效。对经常调工具的人来说这点很关键。

装完之后不要急着配模型，先跑自检。大多数运行时框架都提供了一个自检或者版本命令，形如：

hermes --version hermes doctor

doctor这类命令会检查解释器版本、依赖完整性、配置文件是否存在、关键目录权限、网络连通性。我特别喜欢这类命令，因为它把“隐性故障”提前暴露了。第一次跑的时候我这边报了三个警告：配置文件缺失、日志目录权限不对、某个可选依赖没装。前两个必须修，第三个可以先放着。

提示：自检命令报的“警告”和“错误”要区别对待。错误必须修，警告可以带着跑，但建议记下每一条，因为后面出现诡异行为时，往往就是某条被忽略的警告。

3.3 初始化配置文件的三种方式与取舍

配置文件初始化通常有三种路子，我全试过，说说各自的适用场景。

第一种是从示例文件复制。框架一般会带一个config.example.toml之类的东西，复制成config.toml再改。优点是注释齐全、字段说明清楚；缺点是字段太多，一眼望过去容易懵。

第二种是用初始化向导。有些框架提供了交互式命令，一条条问你：用哪个模型、密钥填什么、工作目录在哪，问完自动生成配置文件。适合完全新手，缺点是它生成的东西你不一定看得懂，后面想改得反过来查文档。

第三种是自己手写最小配置。我只写四五个必填项，能跑起来之后再逐项加。这法子最适合“想搞明白每个参数在干什么”的人，也是我现在的做法。

我的建议：第一次装用第二种，把东西跑起来建立信心；同时打开第二种生成的配置文件，对照着第一种的注释文件看一遍，理解每个字段。等第二次装的时候，直接上手第三种。

配置文件放到~/hermes/conf/config.toml，然后通过环境变量指过去，或者在启动时用参数指定：

export HERMES_CONFIG=~/hermes/conf/config.toml

用环境变量的好处是：同一份代码，可以跑多套配置——测试环境用一套，正式用一套，互不干扰，切换只改一个环境变量。

4. 配置环节：让智能体真正“能干活”的关键参数

装完能启动只是及格线。真正决定它好不好用的，是配置这一节。我在这一块反复调整过很多次，最后沉淀下来的心得是：配置的核心不是把功能全开，而是把边界画准。

4.1 模型接入层：地址、密钥、超时、重试

模型接入是第一个要调的地方，涉及四个参数，每个都有讲究。

接入地址。如果你用云端推理服务，地址一般形如https://api.example.com/v1，注意别漏了版本后缀，也别多加斜杠——我因为多写了一个尾部斜杠，被服务端返回 404，排查了二十分钟才发现。用自建服务的话，地址指向你自己机器的端口，注意容器里访问宿主机要用特殊的网关地址，不是localhost。

密钥管理。这一条我要说得重一点：密钥永远不要硬编码进配置文件。配置文件是要备份、要同步、有时还要分享给别人的东西，一旦密钥写在里面，泄露几乎是必然的。正确做法是放环境变量，配置文件里只写引用：

export HERMES_API_KEY="你的密钥"

然后在配置文件里写成api_key = "${HERMES_API_KEY}"这种引用形式。我还会给密钥设一个独立的最小权限，只允许调模型接口，不允许做别的操作。多花五分钟，省心一年。

超时。默认值往往偏短，尤其是你要它做长文本处理的时候。我的经验值是：短对话 30 秒够用，长文本生成给到 120 秒，涉及多轮工具调用的复杂任务给到 180 秒。设太短会出现“任务做到一半被掐断”，而且现象很迷惑——前几步都正常，最后一步失败，你会误以为是工具的问题。

重试。建议开启，但次数别多，两到三次即可，并且要配指数退避。原因很简单：瞬时网络抖动是常态，重试能救回来；但如果服务端真的有问题，重试太多次只会让你等更久、账单更高。

4.2 工具权限与沙箱：最小可用原则

工具是它“能干活”的手脚，权限是这副手脚的笼头。这一块我见过最多的错误就是一次性全开——文件读写放开、命令执行放开、网络访问放开，图省事。这样做的风险不在于它“会主动干坏事”，而在于你给的执行范围太大，一个误判就可能删掉不该删的东西。我的原则是：先只开必须用的，跑一段时间发现确实不够，再一个一个加。

具体做法上，我把权限分成三档：

只读档：只能读工作区内的文件，不能写、不能执行命令、不能访问工作区之外的路径。适合“帮我看看这些文档讲了什么”这类任务。我日常用得最多的是这一档。

读写档：可以读写工作区内的文件，仍然不能执行命令。适合整理、归档、生成报告。注意“工作区内”这个限定很重要——路径穿越这类问题是靠限定根目录来防的。

执行档：可以执行命令，但要配合白名单。白名单里放的是常用只读命令和一些明确安全的工具，形如：

[tools.shell] enabled = true workdir = "~/hermes/workspace" allow = ["ls", "cat", "grep", "wc", "date", "mkdir"] deny = ["rm", "mv", "curl", "chmod"] timeout = 20

白名单这个机制值得展开说一下：它检查的是命令的第一个词，所以ls -la能过，ls; rm -rf这种拼接要额外做分隔符检测。如果你用的框架支持，务必把分隔符、管道、重定向这几个也纳入检测范围。我配完之后特意测了几十条拼接写法，确认拦得住才敢开。

注意：沙箱不是万能的。它的作用是“降低误伤概率”，不是“绝对安全”。真正的安全边界是：给它一个独立的、可随时重建的工作目录，重要数据不要放在那里面。我每季度会把工作目录清空重建一次，反正里面都是可再生的东西。

4.3 工作区、记忆与会话持久化

工作区就是它读写的根目录，这个路径要设成绝对路径，别用相对路径——相对路径会跟着你启动进程时的当前目录变化，某次从别的目录启动，它就会在错误的地方创建文件，然后你找了半天不知道文件去哪了。我第一次就踩了这个坑，文件被创建到了 home 目录，还以为工具没执行。

记忆这块分两层：会话记忆在单次对话内有效，关了就没；长期记忆落到磁盘，跨会话保留。长期记忆建议开启，但要控制规模。我的配置是只把明确标记为“值得记住”的内容写进去，比如任务结论、用户偏好、常用路径，而不是把所有对话都灌进去。原因很实际：记忆越多，每次拼装上下文的时间越长、消耗的 token 越多，最后你会觉得“怎么越来越慢越来越贵”。

会话持久化我强烈建议开。好处是进程重启、机器重启之后，你可以接着上次的会话继续，不用从头讲一遍背景。存储上用单个文件或者轻量数据库都行，我用的文件存储，每天一个，方便直接翻看和归档。

[workspace] root = "/home/你的用户名/hermes/workspace" [memory] enabled = true store = "/home/你的用户名/hermes/data/memory.jsonl" max_entries = 500 [session] persist = true dir = "/home/你的用户名/hermes/data/sessions"

max_entries这个值我设的是 500，跑了一个多月才接近上限，到上限之后我做了手动清理——把过期的、一次性的条目删掉，留下真正有用的。这个动作建议每月做一次，工作量很小，收益很明显。

5. 联调验证：从“能启动”到“能交付”

配置写完，不代表就能用了。我给自己定了一套验收流程，三步走完才算部署完成。这套流程看起来有点繁琐，但它的价值在于：把问题暴露在你还有精力排查的时候。

5.1 三步验收法：最小闭环、真实任务、异常注入

第一步，最小闭环测试。发一句最简单的指令，确认“接收—模型调用—返回”这条链路通了。比如让它把工作区里一个测试文件的内容原样读出来。这一步只验证链路，不验证能力。

第二步，真实任务测试。拿一个你日常真的会做的任务扔给它，比如“把这周的笔记按主题归类，生成一个目录文件”。这一步会同时压到文件读取、内容理解、文件写入、目录创建四条路径，能暴露大部分配置问题。我第一次跑的时候在这里发现工作区路径写成了相对路径，导致写入失败。

第三步，异常注入测试。故意制造几个异常，看它的表现。我常做的是三件事：把密钥临时改成错误的值，看报错是否清晰；把工作区目录的写权限去掉，看它是否会卡死；把网络断开，看它重试几次后能否正常退出。这三个测试做完，你对它的“故障行为”就有了底，以后真出问题不会慌。

5.2 工具调用的白名单验证

白名单配置完必须验，而且不能只验“允许的能跑”，更要验“禁止的跑不了”。我列了一个实测清单，你可以照着测：

这张表里，拼接绕过和路径穿越是最容易被忽略的两项。前者考验的是命令解析做得够不够细，后者考验的是路径规范化有没有做。两项我都实测过，都能拦住，才敢把执行权限开着让它跑日常任务。

5.3 性能基线记录与容量规划

最后一步是记录基线，很多人不做，但它是后面判断“是不是变慢了”的唯一依据。我记录四个数：冷启动耗时、单轮对话平均耗时、单轮平均 token 消耗、内存峰值。

第一次跑出来的数是：冷启动 3.8 秒，简单问答平均 6 秒，平均 token 消耗 1.2k，内存峰值 850M。这些数本身没什么意义，意义在于对比：后来某次升级后启动变成 11 秒，我一对比就知道有问题，翻日志发现是某个可选组件被默认加载了，关掉之后回到 4 秒。

容量规划上，我给你一个粗略的估算方式：日志按每天 20-50M 算，会话文件按每天 2-5M 算，一个月下来大概占 1G 出头。所以盘上留 10G 余量能撑很久。真正需要注意的是向量索引——如果你开启了本地检索增强，索引文件会跟着数据量线性增长，这时候得单独规划空间。

6. 常见故障与排查实录

这一节是我最想写的部分，因为前面那些顺风顺水的流程，你在文档里都能找到，而这里的内容基本只能靠踩坑攒出来。我按故障类型分了组，配了排查顺序，遇到问题照着往下走就行。

6.1 启动类问题：从进程到依赖

症状一：启动即退出，终端没有任何输出。这种情况先别怀疑代码，八成是配置文件路径不对。运行时在启动时读不到配置，很多实现会选择静默退出。排查顺序是：确认HERMES_CONFIG环境变量存在且指向真实文件，确认该文件可读，然后手动跑一次带调试参数的启动，看有没有打印加载路径。

症状二：启动报依赖缺失。常见原因是虚拟环境没激活，或者装依赖时用的 pip 和运行时的 python 不是同一个。一条命令定位：

which python && which pip && pip list | grep -i 依赖名

三个输出放在一起看，如果which python指向的不是你的.venv目录，那就是环境没激活，重新source一次。我遇到过装了依赖但pip list里看不到的情况，原因是在容器里用系统的 pip 装到了全局，而运行时用的是 venv 里的解释器。

症状三：端口被占用。如果你开了 Web 管理界面，启动会失败并提示地址被占用。查占用：

lsof -i :8080

找到进程号，确认是不是上次没退干净的自己，是就杀掉重启。这种“僵尸进程”在调试期间特别常见，因为 Ctrl+C 有时候只终止了前台进程，子进程还活着。

6.2 调用类问题：从超时到限流

症状四：任务进行到一半失败，报超时。我在 4.1 里提过超时设太短的坑，这里说排查顺序：先看是不是单次请求真的超过了设定值，方法是在日志里找请求开始和结束的时间戳；再看是不是多轮工具调用累计超时，有些实现的总超时和单次超时是分开算的，容易误判。修法是把对应那一档的时间放宽，而不是全盘调大。

症状五：报限流或额度不足。这类错误的提示通常比较明确，但要注意一个陷阱：有些服务把“并发数超限”也报成类似的错误。区别在于，如果是额度不足，降低频率没用；如果是并发超限，加个队列或者把并发数调到 1 就好了。我的做法是把并发数固定为 1，牺牲一点点速度换来稳定——日常任务量根本用不着并发。

症状六：模型返回的内容被截断。这个现象很像“它答到一半停了”，实际原因是输出长度上限。修法是调高max_output_tokens，或者把任务拆小。我的经验是：让它一次性处理超长文本很容易触发这个上限，改成“先分段摘要再合并”就稳了。

6.3 权限与路径类问题：最难查的一类

症状七：文件读到了但内容不对，或者写入成功但找不到文件。这类问题九成是路径问题。排查顺序：先确认工作区配置是绝对路径；再确认启动进程时的当前用户有没有该目录的权限；最后检查是不是软链接导致的路径解析差异。我遇到过一次，工作区是个软链接，运行时按真实路径解析，结果它的“工作区内部”判断把文件当成外部路径拒绝了，表现是“文件明明在，它却说访问不了”。

症状八：命令能跑但结果为空。常见于在容器里执行命令。宿主机的路径在容器里映射到别的位置，它执行ls看的是容器里的目录，自然是空的。修法是统一路径视角，要么全在容器里操作，要么通过挂载让两边路径一致。

我把这几类问题整理成一张速查表，贴在显示器边上，遇到直接对号：

6.4 几个只能靠踩坑才明白的细节

第一个细节：日志级别不要一上来就开 DEBUG。DEBUG 日志能救命，但它的量非常大，跑一天能吃掉几个 G，而且刷屏刷到你看不清关键信息。我的做法是平时用 INFO，出问题临时开 DEBUG，问题定位完立刻调回去。

第二个细节：改配置之后一定要重启进程。有些实现支持热重载，但我实测下来不完全可靠，部分参数改了不生效。省事的做法是改完就重启，别去猜哪个参数支持热加载。

第三个细节：别在同一个工作区跑多个实例。两个进程同时读写同一个目录，会出现“刚写的文件被另一个进程覆盖”这种灵异现象。我为此丢过一次生成的报告，从那以后每个实例单独一个工作区。

7. 长期维护与经验沉淀

装好、跑通、验证完，剩下的就是在日常使用中把它养好。这一节聊三件事：怎么升级不翻车、怎么盯住成本、以及我个人最想分享的几条心得。

7.1 升级与回滚：给自己留后路

升级这件事，我的原则是小步走、留快照。具体做法是：升级前先备份conf目录和data目录，记下当前版本号，然后拉新版本、装依赖、跑自检、跑一遍第 5 节的三步验收。全部通过再正式用，任何一个环节不对，立刻回滚。

回滚的实操就三步：切回旧版本、把备份的conf恢复、重启。因为我把配置和数据分开了，回滚只动这两处，源码目录重新 checkout 一次就行，五分钟内能完成。这套流程我第一次设计的时候觉得有点重，用了半年下来，它至少救了我两次。

版本节奏上，我不建议追最新。我的习惯是观察一到两周，看看社区有没有明显的反馈，再决定要不要跟。稳定压倒一切，尤其是这台机器还要跑日常任务的时候。

7.2 成本与日志监控：把账算清楚

成本监控我做了两件事。第一件是按天记录 token 消耗，写个小脚本从日志里统计，输出到一张表里。看趋势比看单日数字有用得多——某天突然翻三倍，那一定是有个任务跑飞了，赶紧去看是哪个。第二件是设硬上限，单日超过某个值就告警，我不是怕花钱，是怕它陷入某种循环反复调用，那种情况下不设上限会一直烧。

日志这块，我用一个每周执行一次的清理动作：保留最近 14 天的详细日志，更早的只保留错误级别，再早的直接删。这样既保证了“出问题能回溯两周”，又不会把盘占满。清理脚本很简单，但一定要配在定时任务里，靠手动清理迟早会忘。

提示：把清理脚本放在和日志不同的盘上，或者至少不同的目录层级。我见过清理脚本把自己的日志也删了，然后下次执行直接报错的乌龙。

7.3 我在实际使用中的几点体会

第一点，先让它做“可逆的事”。我给它开的第一个真实任务是整理文件、生成索引，这些操作错了可以重来。跑了两个月，确认行为稳定，我才慢慢放开一部分写入权限。这个渐进过程很重要，一次性把权限拉满，等于把风险一次性拉满。

第二点，提示词要当成配置来管。我一开始把提示词直接写在代码里，后来发现改一次要动代码、要重启、要重新验证，太麻烦。现在全部抽到独立文件，跟配置文件放一起，改完重启即可，而且能做版本管理。提示词的变化对输出质量影响很大，值得单独管理。

第三点，别指望它全自动。我的用法是“它干八成，我审两成”。让它生成，我来校对和拍板。这个比例我觉得挺健康——既省了大量机械劳动，又不会因为它的误判造成实际损失。凡是要对外发布或者不可撤销的操作，我一定人工过一遍。

第四点，也是我觉得最值的一点：把它当成一个可以随时重装的东西。我现在的做法是，所有配置和数据都在conf和data两个目录里，源码和工作区是可再生的。这意味着我换一台机器，把这两个目录拷过去，半小时就能恢复一套一模一样的环境。这个心态让我在折腾的时候完全不慌——反正搞坏了重来一遍就行。

顺着这个思路还能往下扩展：把conf目录纳入版本管理，每次改动留一条记录，出问题能 diff 出是哪次改动引入的；把日常任务写成脚本，用定时任务触发，让它在你不在的时候把整理工作做完；再进一步，把多个实例分工，一个专门做信息聚合，一个专门做文档处理，各自独立互不干扰。这些我都试过，收益是有的，但复杂度也上来了，建议先把单实例用顺了再考虑。