Hermes-Lite on CAO ZUOHUA

1GB VPS 上跑个人助理智能体的部署清单

Tue, 07 Jul 2026 00:00:00 +0000

1GB VPS 可以跑个人助理智能体，但前提是别把它当大服务器用。

低资源环境最重要的是克制：少进程、少常驻、少浏览器、少后台任务。部署前就要想清楚哪些功能必须在线，哪些功能可以按需运行。

部署前检查

先确认资源边界：

内存是否约 1GB。
是否有 swap。
磁盘空间是否足够日志和依赖。
系统是否开启自动安全更新。
SSH 登录是否使用密钥。
防火墙是否只开放必要端口。

如果机器本身不稳，不要急着部署 Agent。

功能裁剪

个人助理在 1GB VPS 上应该优先保留核心链路：

消息入口。
模型网关或 API 调用。
Skill 路由。
少数必要工具。
轻量记忆或知识库。
日志。

可以延后或禁用：

浏览器自动化常驻服务。
大型向量数据库。
多 Agent 并发编排。
语音转写和合成。
重型监控面板。

功能越少，系统越容易稳定。

部署中检查

部署时按顺序验证：

服务能启动。
入口能收到消息。
模型调用能返回。
Skill 路由能命中。
工具调用能成功。
记忆写入和读取正常。
日志能落盘。
服务重启后状态可恢复。

不要等全部部署完才第一次测试。

安全检查

个人助理通常握有 API Key 和个人数据，安全边界要提前做。

检查项：

密钥不写进仓库。
配置文件权限收紧。
面板不直接暴露公网。
反向代理路径不可预测。
高风险工具默认关闭。
日志不打印完整密钥。
远程命令需要人工确认。

低资源不是降低安全要求的理由。

部署后检查

上线后观察 24 小时：

QPC 四字段如何支撑个人知识管理

Tue, 07 Jul 2026 00:00:00 +0000

个人知识库最大的问题通常不是容量，而是维护摩擦。

字段越多，写入越慢；分类越复杂，越容易放弃。QPC 的价值是把知识记录压缩到足够小，让个人助理能稳定写入和检索。

QPC 是什么

QPC 可以理解为四类知识：

Question：问题。
Practice：实践。
Concept：概念。
Fact：事实。

它不追求一次性建成完整知识图谱，而是先把值得重读的信息记录下来。

为什么适合个人助理

个人助理经常遇到可沉淀的信息：

某个命令为什么失败。
某个配置项是什么意思。
某个项目的默认路径。
某次排障的解决步骤。

这些信息不一定值得写成长文，但值得下次能找到。

四字段降低摩擦

一个 QPC 条目可以很简单：

字段	作用
类型	Question、Practice、Concept、Fact
标题	一句话概括
内容	关键说明
来源或场景	来自哪里、何时使用

字段少，Agent 才能稳定写。

和长期记忆的关系

QPC 不等于全部记忆。

偏好、任务状态、配置事实和知识条目可以分层存储。QPC 更适合保存可复用知识，而不是当前任务里的临时上下文。

检索比分类更重要

个人知识管理不应该把精力花在完美分类上。

只要标题清楚、内容紧凑、来源明确，后续通过搜索或 Agent 检索就能找回来。QPC 的核心是降低写入成本，让知识真的留下来。

Skill 路由如何降低个人助理的不确定性

Tue, 07 Jul 2026 00:00:00 +0000

个人助理的很多任务，不需要重新发明推理过程。

“写博客”“记一条知识”“查服务器状态”“生成月度复盘”“整理配置”这些任务都有明确流程。如果每次都让 Agent 从零思考，很容易出现不稳定输出和错误工具调用。

Skill 路由的思路是：先识别任务场景，再进入对应流程。

ReAct 的问题

ReAct 循环适合开放探索，但个人助理的大多数任务不是开放探索。

无约束循环可能带来几个问题：

过度思考简单任务。
选择不相关工具。
重复尝试已经失败的动作。
在缺少信息时硬编下一步。
难以复盘为什么走到某个结果。

对个人助理来说，可控性往往比“看起来聪明”更重要。

Skill 的价值

Skill 把任务流程显式化。

一个好的 Skill 至少说明：

什么时候触发。
需要哪些输入。
可以调用哪些工具。
输出应该是什么格式。
失败时如何降级。
哪些动作需要人工确认。

这会显著减少不确定性。

命名要贴近场景

Skill 名称应该让人一眼知道它处理什么任务。

例如：

hugo-blog：写博客、编辑文章、构建部署。
qpc：记录和检索个人知识。
ssh-git-vps-deploy：处理 VPS 上的 Git 部署。
x-ui-and-new-api-security-posture：处理特定安全加固场景。

名称越具体，路由越稳定。

触发词要具体

触发词不应该太宽。

“工具”“处理”“帮我看看”这类词太泛，容易误触发。更好的触发词是和场景强相关的词，例如“写博客”“QPC”“部署到 VPS”“检查 x-ui 安全”。

个人助理可以允许多个触发词，但每个触发词都应该指向明确任务。

输入输出边界

每个 Skill 应该定义输入和输出。

例如博客 Skill 的输入可以是主题、标题、目标读者、已有素材；输出是文章文件、构建结果、提交状态。

QPC Skill 的输入可以是一段知识或检索问题；输出是结构化记录或匹配结果。

输入输出清楚，Agent 就更少临时发挥。

失败时要降级

Skill 还应该说明失败时怎么办。

例如：

找不到文件：先搜索仓库，不要编路径。
构建失败：报告错误，不要推送。
权限不足：停止并说明需要人工操作。
信息不足：提出缺失字段，而不是生成假答案。

降级策略是个人助理可靠性的关键。

个人助理智能体的失败分类表

Tue, 07 Jul 2026 00:00:00 +0000

如果不分类，Agent 失败看起来都像“模型不行”。

但个人助理的失败来源很多：理解错、路由错、工具错、记忆错、权限错、环境错、恢复错。分类之后，才能知道该修模型、修 Skill，还是修工具。

七类失败

类型	表现
理解失败	误解用户目标
路由失败	选错 Skill 或流程
工具失败	参数错、超时、权限不足
记忆失败	忘记事实或记错偏好
权限失败	越权执行或该确认未确认
环境失败	依赖缺失、服务未启动
恢复失败	出错后无法继续或回滚

这张表比一句“Agent 崩了”更有排查价值。

先定位再修复

不要看到失败就改 prompt。

如果是工具参数错，应该修 schema 或校验；如果是路由错，应该修触发词；如果是权限错，应该修确认机制；如果是环境错，应该修部署和监控。

错误分类能避免把所有问题都甩给模型。

日志字段

每次失败至少记录：

用户请求。
命中的 Skill。
调用的工具。
错误类型。
错误信息。
是否重试。
是否需要人工处理。

这些字段足够支持月度复盘。

复盘动作

失败复盘可以只问三个问题：

这类失败是否重复出现？
它能否通过规则或校验提前拦住？
它是否需要加入 QPC 或维护手册？

个人助理的可靠性来自持续修小错，而不是一次性设计完美系统。

个人助理智能体的密钥、面板和网关安全

Tue, 07 Jul 2026 00:00:00 +0000

个人助理智能体一旦接入真实工具，就会碰到安全问题。

密钥、Web 面板、API 网关、反向代理、远程命令都可能成为风险点。精简个人助理不是少做安全，而是减少暴露面。

密钥

密钥不应该写进仓库、文章、日志或普通聊天记录。

Agent 可以检查配置项是否存在，但不应该完整打印 token。写技术文章时，也应该使用脱敏结构和真实字段名，而不是暴露真实值。

面板

Web 面板不应该直接裸露公网。

至少要有认证、不可预测路径或访问限制。默认路径、弱密码和公开端口会让个人项目承担不必要风险。

网关

API 网关负责把请求转给模型或工具。

网关要限制来源、记录调用、保护密钥，并避免把内部错误直接暴露给外部。能只开放一个入口，就不要暴露多个入口。

日志

日志需要足够排障，但不能泄露秘密。

不要记录完整 Authorization header、API key、cookie、个人账户信息。可以记录脱敏摘要、请求类型和错误码。

高风险动作

以下动作必须人工确认：

修改认证配置。
暴露新端口。
修改反向代理。
删除配置或日志。
执行远程命令。
写入生产数据。

安全边界要默认保守。

检查清单

密钥是否只存在于安全位置？
面板是否有认证？
网关是否限制来源？
日志是否脱敏？
高风险工具是否需要确认？
是否有回滚方式？

个人助理越强，越要把权限和安全写清楚。

个人助理智能体的最小可用架构

Tue, 07 Jul 2026 00:00:00 +0000

个人助理智能体不需要一开始就有复杂平台。

一个最小可用架构，只要能稳定完成“理解请求、选择流程、调用工具、记录结果、必要时请人确认”这条链路，就已经能解决很多实际问题。

架构图

flowchart TD
 U["用户入口<br/>聊天、命令、Webhook"] --> R["请求归一化"]
 R --> M["模型路由<br/>选择合适模型"]
 M --> S["Skill 路由<br/>匹配任务场景"]
 S --> C["任务上下文<br/>短期状态"]
 C --> T["工具层<br/>文件、搜索、日历、API"]
 C --> K["记忆层<br/>偏好、事实、QPC"]
 T --> G{"高风险动作?"}
 G -- "否" --> L["日志与结果记录"]
 G -- "是" --> H["人工确认"]
 H --> L
 K --> L
 L --> U

入口：只负责接收请求

入口可以是聊天窗口、飞书消息、命令行或 Webhook。

入口不应该承担复杂逻辑。它只需要把用户请求、用户身份、时间和上下文传给后面的处理链路。

这样以后更换入口时，不需要重写核心逻辑。

模型路由：按任务选择模型

不是所有任务都需要最强模型。

简单分类、格式整理、固定模板生成，可以使用便宜快速的模型。复杂推理、长文写作、代码分析，才需要更强模型。

模型路由的目标不是炫技，而是控制成本和延迟。

Skill 路由：把任务交给稳定流程

个人助理的大多数任务有明确场景：记一条知识、查一个配置、写一篇博客、生成复盘、检查服务器。

Skill 路由比无约束 ReAct 循环更适合这些任务。它先识别场景，再进入对应流程，减少“想太多”和“乱调用工具”的概率。

工具层：只接入少数可靠工具

工具层应该从少开始。

优先接入：

文件读写。
搜索和查询。
日历或提醒。
个人知识库。
必要的部署和运维命令。

每个工具都要有权限等级和失败处理方式。

个人助理智能体的权限边界和确认机制

Tue, 07 Jul 2026 00:00:00 +0000

个人助理越有用，权限越敏感。

它可能能读文件、写博客、调用 API、访问服务器、发送消息。如果没有权限边界，一个小错误就可能变成真实损失。

权限设计的目标不是让 Agent 什么都不能做，而是让每类动作都有合适的确认级别。

四类权限

我倾向于把权限分成四类：

等级	含义	示例
只读	只能查看和总结	读文件、查日志、检索知识
建议	可以生成方案但不执行	写计划、列风险、生成命令
可执行	可以做低风险动作	新建草稿、运行构建、格式检查
必须确认	高风险或不可逆动作	删除、推送、重启服务、转账

默认从只读开始，逐步增加权限。

文件系统

文件系统权限最常见，也最容易被低估。

读取通常风险较低，但也可能涉及隐私。写入、覆盖、移动和删除都应该更谨慎。

规则可以是：

读仓库文件：允许。
写新草稿：允许。
修改已有配置：先说明影响。
删除文件：必须确认。
递归删除：必须确认并验证路径。

远程命令

远程命令必须保守。

查看状态、读日志、检查磁盘可以是只读。重启服务、修改配置、拉取代码、执行迁移都可能影响线上状态，应该要求确认或至少先展示命令和影响。

不要让 Agent 在不解释的情况下执行远程破坏性命令。

密钥和配置

密钥不应该进入普通对话和公开日志。

Agent 可以检查“是否存在配置项”，但不应该完整打印密钥。写文章时也只能引用脱敏结构，不应该暴露真实 token。

配置修改需要记录：

修改前是什么。
修改后是什么。
为什么修改。
如何回滚。

面板和网关

Web 面板、API 网关和反向代理是常见暴露面。

个人助理可以辅助检查端口、路径和访问控制，但涉及开放公网、修改认证、变更代理规则时必须人工确认。

安全配置的错误往往不是马上爆炸，而是留下长期风险。

确认机制怎么写

高风险动作前，Agent 应该给出：

将要执行的动作：
影响范围：
是否可回滚：
回滚方式：
需要你确认的命令或选项：

确认不是形式主义。它迫使系统把隐含风险显式化。

最小权限是默认值

个人助理长期可用的前提，是你能放心让它运行。

如果一个能力无法安全地设定边界，就不要急着接入。能只读就只读，能建议就建议，真正需要执行时再让人确认。

个人助理需要记住什么，不需要记住什么

Tue, 07 Jul 2026 00:00:00 +0000

个人助理的记忆系统很容易走向两个极端。

一种是完全不记，每次对话都像第一次见面。另一种是什么都记，最后记忆库变成噪音堆。真正可用的个人助理，需要知道什么值得长期保存，什么应该及时丢掉。

应该记住：稳定偏好

偏好是长期影响输出质量的信息。

例如：

喜欢简洁直接的回答。
写博客时偏好中文标题和英文 slug。
代码修改前要先检查现有风格。
高风险操作必须先说明影响。

偏好应该少而稳定。临时情绪、一次性表达和随口说法，不应该马上写入长期记忆。

应该记住：稳定事实

稳定事实是关于用户、项目或环境的长期信息。

例如博客仓库路径、部署方式、常用服务器、默认分支、常用工具链。这些信息能减少重复沟通，提高执行效率。

但事实也需要可更新。如果路径、配置或部署方式变了，旧事实必须能被覆盖。

应该记住：任务状态

任务状态回答“做到哪里了”。

例如一篇文章已经写了总览、下一步要补实战篇；某个部署已经完成构建但还没推送；某个系列已经完成分类但还没补维护手册。

任务状态适合有生命周期，完成后应该归档，不应该无限保留在活跃上下文里。

应该记住：长期知识

长期知识是以后可能反复检索的内容。

例如踩坑记录、配置说明、命令模板、文章素材、概念卡片。QPC 的价值就在于把知识压缩成低摩擦条目：问题、实践、概念或事实。

长期知识不一定要很长，关键是可检索、可重读。

不应该记住：临时上下文

临时上下文只服务当前任务。

例如一次命令输出、一段中间草稿、临时错误信息、某次搜索结果。如果把这些都写入长期记忆，系统会越来越嘈杂。

临时上下文可以进入日志，但不一定进入记忆。

不应该记住：未经确认的推断

Agent 经常会推断用户意图。

这些推断不能直接写成记忆。例如“用户喜欢某种投资风格”“用户总是想自动部署”“用户偏好某个模型”。除非用户明确确认，否则只能作为当前任务假设。

记忆系统最怕把猜测固化成事实。

一个五层划分

可以把个人助理记忆分成五层：

层级	内容	生命周期
当前上下文	本轮任务细节	任务结束后丢弃
任务状态	待办、进度、阻塞	完成后归档
用户偏好	输出风格、风险边界	长期但可更新
稳定事实	路径、配置、项目背景	长期但需校验
知识库	QPC、踩坑、模板	长期积累

记忆写入规则

每次写入记忆前，先问：

这条信息下次还会用到吗？
它是事实、偏好，还是临时上下文？
它有没有过期风险？
它是否来自用户确认？
如果写错了，后果大不大？

个人助理不是记得越多越好，而是记得越准越好。

为什么个人助理智能体要精简

Tue, 07 Jul 2026 00:00:00 +0000

个人助理智能体最容易犯的错误，是一开始就做成平台。

聊天入口、浏览器、知识库、日历、邮件、文件系统、远程命令、多 Agent 协调、自动部署、自动下单……能力越来越多，但真正长期稳定使用的反而越来越少。

对个人场景来说，精简不是功能少，而是每个功能都能解释、能维护、能失败后恢复。

大而全的代价

复杂系统会带来四类成本。

第一是运行成本。组件越多，常驻进程越多，对 VPS、内存、磁盘和网络的要求越高。个人助理如果只是服务一个人，就不该默认按企业平台规模设计。

第二是认知成本。你必须知道每个模块在哪里、怎么配置、失败时看哪个日志。否则系统一旦出错，就会变成黑盒。

第三是权限成本。工具越多，暴露面越大。一个能读文件、连服务器、发消息、调 API 的 Agent，如果没有严格边界，风险会迅速放大。

第四是维护成本。升级、备份、迁移、密钥轮换和故障恢复都需要人处理。个人项目最怕的不是功能不够，而是维护负债超过实际收益。

精简的目标

精简个人助理应该先满足几个基本目标：

能稳定接收任务。
能识别任务属于哪个场景。
能调用少数可靠工具。
能记住必要偏好和事实。
能把高风险动作交给人确认。
能在失败时留下日志。

这比“什么都能做”更重要。

少组件

少组件意味着每个组件都有清晰职责。

入口负责接收消息，模型负责理解和生成，Skill 路由负责选择任务流程，工具层负责执行有限动作，记忆层负责保存必要状态，日志负责追踪结果。

不要把所有能力都塞进一个无限循环的控制器。个人助理的大多数任务都有明确场景，用明确流程处理更稳。

少权限

个人助理应该默认最小权限。

能只读就不要写入，能建议就不要执行，能本地执行就不要远程执行，能人工确认就不要自动确认。

权限可以分级：

只读：查询、摘要、分类。
建议：生成方案、列风险、提醒。
可执行：低风险、可撤销动作。
必须确认：删除、转账、发公开消息、远程命令、修改配置。

强日志

没有日志的 Agent 不可维护。

至少要记录：

用户请求。
命中的 Skill。
调用的工具。
工具输入和输出摘要。
是否失败。
是否需要人工确认。

日志不是为了事后甩锅，而是为了复盘系统哪里不稳。

可人工接管

个人助理不应该假装永远知道下一步。

当信息不足、工具失败、权限不够或风险过高时，它应该停下来，说明原因，并把选择权交还给人。这比硬着头皮继续执行更可靠。

精简个人助理的核心不是“更笨”，而是知道什么时候不该自动化。

什么时候需要多 Agent，什么时候不需要

Tue, 07 Jul 2026 00:00:00 +0000

多 Agent 听起来很强，但不一定适合个人助理。

很多个人任务只是流程明确的单人任务：写博客、查配置、记知识、生成复盘、部署服务。把它们拆成多个 Agent，可能只会增加协调成本。

不需要多 Agent 的情况

以下任务通常不需要：

输入输出明确。
单个 Skill 能完成。
工具调用链很短。
失败后容易人工接管。
不需要并行探索。

这类任务用清晰流程更稳。

可能需要多 Agent 的情况

多 Agent 适合：

多个独立子任务可以并行。
需要不同角色互相审查。
搜索、写作、验证可以分开。
单个上下文装不下全部材料。
失败可以隔离在某个子任务。

例如大型代码审查、复杂资料整理、长篇专题策划，才可能值得拆分。

多 Agent 的成本

多 Agent 会带来：

状态同步成本。
责任归属问题。
冲突结果合并。
更多日志和监控需求。
更高 token 和工具调用成本。

如果没有明确收益，不要为了架构好看引入。

判断清单

引入多 Agent 前问：

任务是否真的可以并行？
子任务边界是否清楚？
输出如何合并？
谁负责最终判断？
失败时谁接管？

答不清楚，就先保持单 Agent + Skill 路由。

个人助理的优先级是稳定，而不是复杂。

从幻觉到问责：个人助理的可靠性边界

Tue, 07 Jul 2026 00:00:00 +0000

个人助理不可能永不出错。

真正需要的是可靠性边界：哪些结论必须有来源，哪些动作必须确认，哪些失败必须记录，哪些责任不能交给模型。

幻觉不是唯一问题

幻觉只是错误的一种。

个人助理还会遇到工具失败、权限错误、记忆污染、计划失效、环境变化和多步任务中断。如果只盯着“模型会不会编”，会漏掉很多工程问题。

可靠性的四个要求

我更关心四件事：

可见：错误不能被隐藏。
可追踪：知道错误来自哪里。
可恢复：失败后能继续或回滚。
可问责：知道哪些决定由人确认。

这比承诺“不会错”更现实。

事实类回答要有来源

查资料、查配置、查日志时，Agent 应该说明依据。

如果没有来源，就应该标注不确定，而不是编一个确定答案。事实类任务的底线是：不知道可以说不知道。

执行动作要有确认

会改变外部状态的动作都要更谨慎。

删除文件、修改配置、推送代码、重启服务、发送公开消息、财务操作，都应该在执行前说明影响，并等待确认。

错误要进入复盘

每次重要失败都应该能进入复盘：

错在哪里？
为什么没被提前拦住？
是否需要改 Skill？
是否需要改工具权限？
是否需要写入 QPC？

可靠性不是一次完成，而是持续收紧边界。

边界越清楚，助理越可信

个人助理的可信度，不来自它永远自信，而来自它知道什么时候停下来、什么时候引用来源、什么时候请求确认。

这就是从幻觉治理走向问责机制。

哪些能力应该内置，哪些应该交给工具

Tue, 07 Jul 2026 00:00:00 +0000

个人助理智能体的核心不应该越来越大。

很多能力看起来都值得内置：写文件、查网页、发消息、部署服务、整理知识、生成报告。但核心越大，越难测试、越难替换、越难限制权限。

更稳的原则是：判断和边界内置，具体动作交给工具。

应该内置的能力

内置能力应该少而稳定：

请求理解。
用户身份和上下文识别。
Skill 路由。
权限判断。
人工确认机制。
日志记录。
失败降级策略。

这些能力决定系统是否可控，适合放在核心链路里。

应该交给工具的能力

具体动作适合交给工具：

文件读写。
搜索网页。
查询数据库。
创建提醒。
部署服务。
生成图片。
读取知识库。

工具可以独立替换、禁用和限制权限，不应该让核心直接承担所有细节。

判断标准

可以用三个问题判断：

这个能力是否几乎每个任务都需要？
它是否决定权限和安全边界？
如果它坏了，是否会影响整个系统？

如果答案是是，考虑内置。否则优先做成工具或 Skill。

为什么不要把工具逻辑写进核心

工具逻辑变化很快。

今天用一个 API，明天换另一个 API；今天是本地文件，明天是远程存储。如果把这些细节塞进核心，系统会越来越难维护。

核心应该负责选择工具、检查权限、记录结果，而不是直接知道每个工具的全部实现。

最小核心更可靠

个人助理长期可用，靠的不是核心什么都会，而是边界稳定。

一个小核心加一组可替换工具，比一个巨大控制器更容易调试、审计和恢复。

工具调用失败时，Agent 应该怎样降级

Tue, 07 Jul 2026 00:00:00 +0000

Agent 的可靠性，往往不是看它成功时有多聪明，而是看它失败时怎么处理。

工具调用失败很常见：路径不存在、参数错了、网络超时、权限不足、接口返回格式变化。个人助理必须把失败当成正常路径，而不是异常意外。

不要假装成功

最坏的失败方式，是工具失败后继续输出成功结论。

例如构建命令失败，却说“已部署”；文件没写入，却说“已保存”；搜索不到资料，却编一个结果。这会直接破坏信任。

Agent 必须把工具返回结果当成事实来源，而不是只根据意图推断结果。

第一步：识别失败类型

失败先分类：

参数错误：输入格式、路径、字段不对。
权限错误：没有读写、执行或网络权限。
环境错误：命令不存在、依赖缺失、服务未启动。
网络错误：超时、DNS、API 不可达。
业务错误：接口返回成功但结果不符合预期。

分类之后，才知道能不能自动恢复。

第二步：有限重试

有些失败可以重试，例如网络超时或临时服务抖动。

但重试必须有限制。无限循环重试会浪费资源，还可能造成重复写入或重复请求。

一个简单规则是：

只对幂等或只读操作自动重试。
写入操作默认不自动重试，除非有明确幂等键。
重试次数固定，例如 1-2 次。
每次重试记录原因。

第三步：换工具或换路径

如果失败来自工具不可用，可以尝试替代路径。

例如 rg 不可用时用 PowerShell 搜索；Hugo 不在 PATH 时使用临时下载的二进制；网页无法访问时改用本地文件或缓存。

换工具前要保证语义一致。不能因为搜索失败，就把猜测当成搜索结果。

第四步：询问用户

当缺少关键信息，或者继续执行会改变外部状态时，应该停下来问用户。

适合询问的情况：

目标路径有多个候选。
需要凭据或人工登录。
操作可能覆盖现有数据。
高风险动作没有确认。
自动恢复会引入新假设。

询问不是失败，而是正确的降级。

第五步：记录失败

失败应该留下记录。

至少记录：

失败发生在哪个 Skill。
调用了哪个工具。
输入摘要是什么。
错误信息是什么。
是否重试。
最终是否需要人工处理。

这些记录以后可以变成 QPC 知识或维护手册。

降级决策表

失败类型	默认处理
参数错误	修正参数后最多重试一次
权限错误	停止并请求人工处理
环境缺失	查找替代工具或说明安装需求
网络超时	有限重试
写入不确定	停止，检查状态后再继续
高风险动作	请求人工确认

个人助理的底线是：失败要可见，恢复要可解释，不能为了完成任务牺牲可靠性。

打造精简个人助理智能体：系列总览

Tue, 07 Jul 2026 00:00:00 +0000

个人助理智能体最容易走偏的地方，是一开始就追求“大而全”。

真正长期可用的个人助理，应该先做到小、稳、可维护：能记住关键偏好，能调用少数可靠工具，能在失败时留下线索，能把高风险动作交还给人确认。

这组文章记录我围绕 Hermes-lite、QPC、Skill 路由和个人知识系统搭建精简助理智能体的过程。

系列目标

这个系列关注四个问题：

个人助理智能体的最小可用架构是什么。
怎么让记忆、知识库、工具调用和任务状态互相配合。
怎么在低资源 VPS 上稳定运行，而不是堆复杂组件。
怎么处理幻觉、工具失败、崩溃、多 Agent 协调和治理边界。

目标不是复刻一个复杂平台，而是形成一套个人可长期维护的系统。

当前已发布文章

架构与记忆

Hermes-lite 与部署

知识库与路由

可靠性专题

建议阅读框架

1. 最小架构

先回答个人助理需要哪些最小组件：入口、模型路由、技能路由、工具层、记忆层、日志和人工确认。

日志、备份和升级：长期运行的维护手册

Tue, 07 Jul 2026 00:00:00 +0000

个人助理智能体不是写完就结束。

只要它长期运行，就会遇到模型变更、API 失败、服务器重启、配置漂移、磁盘满、日志爆炸、密钥过期和工具失效。维护手册的价值，是让这些问题不靠临场发挥。

日志：先能看见问题

日志至少要回答：

用户发了什么请求。
命中了哪个 Skill。
调用了哪些工具。
工具是否成功。
失败原因是什么。
是否触发人工确认。

日志不需要记录完整隐私内容和密钥，但要足够支持排查。

日志检查频率

可以分三类：

日常：查看错误数量和最近失败。
每周：检查是否有重复失败模式。
每月：把高频失败整理成 QPC 或修复任务。

日志如果只写不看，就没有维护价值。

备份：先备配置和记忆

个人助理最重要的资产通常不是程序本身，而是配置、密钥引用、知识库和长期记忆。

备份优先级：

配置文件。
知识库或记忆数据库。
自定义 Skill。
部署脚本。
关键日志样本。

密钥本身要按安全方式保存，不应该明文塞进普通仓库。

恢复演练

没有恢复演练的备份，只是心理安慰。

至少要知道：

新机器上如何恢复配置。
如何恢复知识库。
如何重新启动服务。
如何验证入口和工具调用。
如何回滚到上一个可用版本。

恢复流程应该写成清单。

升级：小步走

升级模型、依赖或系统服务前，先看影响范围。

建议流程：

记录当前版本。
备份配置和记忆。
阅读变更说明。
小范围验证核心任务。
观察日志。
保留回滚路径。

不要在没有备份的情况下升级关键组件。

安全检查

每月做一次轻量安全检查：

是否有多余开放端口。
面板是否仍有认证保护。
密钥是否泄露到日志。
配置文件权限是否过宽。
高风险工具是否仍需人工确认。
依赖是否有明显安全更新。

个人助理越连接真实世界，越需要定期检查边界。

人工接管流程

当系统异常时，Agent 应该知道如何停下来。

人工接管流程包括：

停止自动执行高风险动作。
保留现场日志。
输出当前任务状态。
列出已完成和未完成动作。
等待人工决定是否继续。

这比“自动修复一切”更可靠。

维护手册的目标

维护手册不是为了把系统变复杂，而是为了让未来的你不用猜。

记忆系统的五层结构：从上下文到长期偏好

Tue, 07 Jul 2026 00:00:00 +0000

个人助理需要记忆，但不能什么都记。

更好的方式是分层：不同信息有不同生命周期、写入规则和检索方式。五层结构可以让记忆系统既有用，又不变成垃圾桶。

第一层：当前上下文

当前上下文只服务本轮任务。

它包括用户刚说的话、当前文件、最近命令输出和中间推理。任务结束后，大部分上下文应该丢弃。

第二层：任务状态

任务状态回答“做到哪里了”。

例如某篇博客已经写完但未构建，某个部署已经构建但未推送。任务状态应该在完成后归档，不应长期占用活跃记忆。

第三层：用户偏好

用户偏好影响输出方式。

例如喜欢中文回答、偏好短句、提交前必须构建、不要自动执行高风险操作。偏好必须来自稳定信号，不能把一次性表达写成长期规则。

第四层：稳定事实

稳定事实是关于项目和环境的信息。

例如仓库路径、部署方式、默认分支、常用配置。事实会过期，所以必须允许更新和校验。

第五层：长期知识

长期知识是以后会反复使用的信息。

例如踩坑、命令模板、文章素材、架构说明、QPC 条目。它不一定总在上下文里，但需要可检索。

写入规则

每次写入记忆前问：

它属于哪一层？
生命周期多长？
是否经过用户确认？
是否可能过期？
写错后影响多大？

分层的目的，是让个人助理记住真正有价值的东西，而不是把一切都存起来。

高风险工具的权限边界和确认机制

Tue, 07 Jul 2026 00:00:00 +0000

工具让 Agent 有行动能力，也让错误有了现实后果。

高风险工具不能只靠 prompt 约束。它们需要明确权限边界和确认机制，让 Agent 在执行前停下来，把影响说清楚。

什么是高风险工具

高风险工具包括：

删除或覆盖文件。
修改生产配置。
执行远程命令。
重启线上服务。
推送代码。
发送公开消息。
调用财务或账户相关 API。

共同点是：影响外部状态，且不一定容易撤销。

执行前必须说明

确认信息至少包括：

将执行什么动作：
影响哪些文件/服务/账户：
是否可回滚：
回滚方式：
不执行的后果：
需要用户确认的内容：

这让风险显式化。

默认只生成建议

高风险工具的默认模式应该是建议。

Agent 可以生成命令、说明步骤、列出风险，但不直接执行。只有用户明确确认后，才进入执行阶段。

执行后要记录

执行后记录：

时间。
工具。
输入摘要。
输出结果。
是否成功。
后续检查项。

如果失败，要进入失败分类表。

确认机制不是拖慢系统

确认机制的目的不是降低效率，而是保护不可逆边界。

个人助理最重要的能力之一，是知道什么时候不能替你做主。

Agent 的记忆：Hermes-Lite 如何用 5 层结构解决「鱼的难题」

Sun, 28 Jun 2026 00:00:00 +0000

人类 chatbot 最尴尬的瞬间：第二次见面完全不认识你。Agent 的记忆系统怎么同时做到持久化、低成本、不丢上下文？我深入 Hermes-Lite 源码写了一个月，拆解出 5 层架构。

从「鱼的难题」开始

用过 ChatGPT 的人都知道一个痛：下次打开，它完全不记得你了。

对一次性聊天这没问题。但对个人助理——帮你管理 200 条知识库、追踪几个项目的进度、记住你的偏好——这等于每次都要把整段友情重来。

我做 QPC（个人知识库）时就被这个问题卡过。后来折腾 Hermes-Lite、nanobot，逐步摸到一条可行的路。这篇文章从 Hermes-Lite 的实际源码出发，拆解它的 5 层记忆架构，看看一个 Agent 是怎么解决「鱼的难题」的。

总览：5 层架构

┌─────────────────────────────────────────────┐
│ Layer 1: 持久记忆 (MEMORY.md / USER.md) │ ← 跨会话，纯文本
├─────────────────────────────────────────────�
│ Layer 2: 会话压缩 (ContextCompressor) │ ← 长对话不爆
├─────────────────────────────────────────────┤
│ Layer 3: 会话检索 (session_search + FTS5) │ ← 历史不丢
├─────────────────────────────────────────────�
│ Layer 4: 增量写入门控 (Nudge 机制) │ ← 该记就记
├─────────────────────────────────────────────�
│ Layer 5: 原子性保障 (fcntl + 临时文件) │ ← 不丢不坏
└─────────────────────────────────────────────┘

每一层解决一个独立问题，层与层之间不耦合。下面逐层拆解。