个人助理智能体 on CAO ZUOHUA

生产级智能体的核心能力：从「能跑通」到「敢上线」

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

过去两年，几乎每个技术团队都做过一个能"跑通"的智能体 demo——接几个工具，套一层 ReAct 循环，输入一句自然语言，输出一堆看起来很智能的行为。这类 demo 做起来不难，难的是下一步：把它交给真实用户，接入真实系统，让它在没有人盯着的情况下，连续跑几个月不出岔子。

这中间隔着的，不是"模型能力"的鸿沟，而是可预测性的鸿沟。一个 demo 智能体可以偶尔走神、偶尔重试、偶尔给出一个"看起来合理但其实跑偏"的答案，反正是演示，出了问题重跑一次就好。但生产系统不允许这种随机性——尤其是当智能体接触的是资金、客户数据、生产环境配置这类不可逆操作的时候。

2026 年的企业级智能体实践，基本已经收敛出一套相对一致的答案：不是让智能体更自主，而是让它更可控。这篇文章梳理一下，支撑这种"可控自主"的核心能力到底是哪几层。

校对注：本文初稿由一篇行业综述整理而来，关键监管与技术断言（EU AI Act Article 14、NIST AI 600-1 GenAI Profile）已逐一核实；部分采用率/市场份额数据来自第三方调研，文中已标注为"业界观点"而非定论。与笔者此前的《LangGraph 是负担还是利器？》一文视角互补——那篇从"单角色个人助手不该上 LG"出发，本篇从"生产级必须可控"出发，结论殊途同归：自主度的边界应由业务风险等级决定，而非模型能力。

一、为什么"更自主"不是正确方向

早期很多团队的直觉是：模型越强，就应该给它更大的自由度，让它自己规划、自己决定工具调用顺序、自己判断什么时候该停。这个思路在 demo 阶段很吸引人，但放到生产环境会迅速暴露问题——你没法审计一个"完全自由发挥"的决策链，也没法向合规部门解释"智能体为什么会这么做"。

企业级智能体架构的核心特征，正在从"最大化自主性"转向"有边界的自主性"。行业分析普遍认为，真正规模化落地的组织会共享同一套架构模式：在自主推理能确实创造价值的地方使用智能体，在需要一致性的地方使用确定性规则，在利害关系要求问责时引入人工判断——三者结合，而不是单纯堆叠模型能力。

二、六层核心能力

把各家企业级实践拆开看，基本都在做同一件事的六个侧面。

1. 确定性路由层：把开放世界压缩成有限状态

这是最基础也最容易被忽视的一层。核心思路很简单：不让大模型自由生成"下一步该做什么"，而是先定义一个有限的动作空间（比如"调用工具"“请求澄清"“判断无法处理"“任务完成”），模型只能在这个空间里做选择，选择的结构由类型系统（比如 Pydantic）强制约束。

action_type: tool_call | clarify | cannot_proceed | done

这一步看起来朴素，但效果是把"自由文本生成"的不确定性，变成了"有限选项分类"的确定性——后者好测试、好回归、好追责得多。

2. Human-in-the-Loop 中断门：不可逆动作前的强制刹车

在编排图里预设中断点，任何被标记为高风险或不可逆的操作，执行前必须经过人工确认。这不是"智能体表现不好才需要人工介入”，而是架构层面的默认设计——资金操作、外发通信、生产配置变更这类动作，不管模型多自信，都要走审批。

这一层的关键设计难点不在"要不要加审批”，而在"审批粒度怎么定"。粒度太粗，所有操作都要人工确认，智能体失去意义；粒度太细，风险操作可能漏网。比较成熟的做法是按风险分级（risk-tier）给每个工具打标，只有中高风险的操作才触发中断。

3. 审计平面：让每一步决策都能被倒查

记录每一次工具调用、每一次路由决策、每一个最终输出的来源，使得出问题之后能够对智能体的推理路径做取证式的完整重建。这一层的价值不在正常运行时体现，而在出事故的那一刻——没有完整审计链，你连"智能体在哪一步犯了错"都说不清楚，更别说改进。

技术实现上，主流做法通常包括：结构化的调用日志（区分请求模型和实际使用模型，便于发现静默降级）、决策快照（人工批准时看到的是什么状态）、以及近年逐渐标准化的 OpenTelemetry GenAI 语义约定，用来统一不同框架间的追踪数据格式。

4. 评估回路：从"跑起来了"到"跑得对"

生产级智能体需要专门针对智能体逻辑设计的自动化回归测试，依据基线评分标准衡量推理路径质量，而不只是"程序没报错"。更进一步的做法是把评估探针嵌入实际推理流程，在线上实时运行而非只在部署前测试，给出带理由的可机读判定结果——这类做法已经开始被 NIST 等机构的指导文件所参考（如 NIST AI 600-1《Generative AI Profile》已将 LLM-as-judge 等评估思路纳入风险管理的参考框架）。

一个容易被低估的点是：评估不应该只测"最终答案对不对"，还要测"中间决策合不合理"——比如任务分解是否遗漏了关键维度，工具选择是否有更优解但没被采纳。这类语义层面的评估，通常需要引入另一个模型做裁判（LLM-as-judge），而不能只靠规则断言。

5. 模型网关：一层薄薄的保险丝

一个集中化的代理层，统一管理模型路由和策略，负责限流、追踪 token 预算，并提供跨供应商的故障转移。对企业而言，这一层的价值不只是省钱和防崩，还包括权限控制——哪个智能体、哪个任务能调用哪个模型，是需要被显式管理的资产，而不是散落在各处的 API Key。

LangGraph 是负担还是利器？个人助手的 Agent 框架选型反思

Sun, 12 Jul 2026 00:00:00 +0000

2026-06-26，我认真评估过用 LangGraph 重构自己的个人助理。结论是：不适合。不是 LangGraph 不好，是它解决的问题和个人助手要解决的问题不是一回事。

这篇文章不黑任何一个框架，只把"什么时候该上、什么时候是负担"的判断标准讲清楚。

先客观说 LangGraph 强在哪

LangGraph 的图（node + edge）抽象不是花架子，它解决的是可控的有状态流程：

多模型协作（一个节点用 GPT，一个节点用 Gemini，按条件路由）
分支 / 循环逻辑（审批被拒 → 回到上一节点重跑）
客服流程 / 审批流（需要可视化地看清楚每一步走到了哪）

这类场景里，图的好处是状态、回溯、分支都显式可调试。如果你要的是"把一段复杂业务流程跑得可控"，LangGraph 是合理选择。

我自己的 QPC 里也记下了它适合的场景：

适合 LangGraph 的场景 —— 多模型协作 / 分支循环逻辑 / 客服流程审批流

个人助手的核心诉求是另一套东西

个人助理（personal assistant）每天面对的请求，结构完全不同：

记忆驱动：长期记忆、工作记忆、用户偏好要持续读写
技能路由：80% 的请求是固定模式，不需要复杂推理，命中一个 skill 比跑一个 Agent 更稳、更便宜、更快
平台对接：要原生连上飞书 / Discord / 日历，而不是自己写一堆适配层
token 优化：要持续压低上下文成本，不能每次都把整个状态图塞进去

我对比过两套方案的实际覆盖：

维度	LangGraph	我的方案（skill + memory + tool + platform）
持久记忆	❌ 无原生	✅ 分层记忆直接落库
技能路由	❌ 要自己接	✅ 原生
平台对接	❌ 无原生	✅ 原生飞书 / Discord
token 优化	❌ 不负责	✅ 工具链 + 上下文裁剪
图可视化调试	✅ 强	❌ 不需要

关键不是"谁功能多"，是个人助手的核心链路，LangGraph 一个都不原生管。

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 可以生成命令、说明步骤、列出风险，但不直接执行。只有用户明确确认后，才进入执行阶段。

执行后要记录

执行后记录：

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

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

确认机制不是拖慢系统

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

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

智能体问题：不确定性与规划失效

Wed, 01 Jul 2026 00:00:00 +0000

计划赶不上变化

前面五篇文章讨论的问题都有相对明确的对策——幻觉可以加 RAG，工具错误可以强 Schema，崩溃可以做检查点，协调可以共享状态，治理可以定规则。但有一个问题是本质性的：未来不可预测，而智能体必须做决策。

这就是规划失效问题：智能体基于当前信息制定了完美的执行计划，但执行过程中环境变了、信息更新了、前提不成立了——计划从"最优解"变成了"最蠢路径"。

这不是 AI 的特殊问题，是人类也在天天面对的。区别在于人类有丰富的经验来应对不确定性，而智能体的"经验"只有训练数据和当前上下文。

不确定性的三个来源

来源一：环境动态性

外部环境在 Agent 执行任务期间发生了变化。

典型场景

Agent 计划：查库存 → 下单 → 发货
现实发生：查库存时有货 → 下单时库存已变（另一位客户买了）→ 发货失败

动态环境中的"信息时效性"问题：

查询时信息准确 ≠ 行动时信息准确
信息和行动之间的时间差越大，规划越可能失效
有些环境变化不可预测（突发需求、系统故障、外部政策调整）

特殊难点：Agent 自身改变了环境

Agent 的行动可能改变了它所处环境的条件，导致后续计划的前提不再成立：

Agent 分析了市场数据 → 基于分析推荐了 A 股票
→ 1000 个用户跟随买入 → A 股价被推高
→ Agent 原有的"低估"判断不再成立

这就是反身性（Reflexivity）——观察行为本身改变了被观察对象。 Soros 讲了几十年的金融哲学，在 Agent 时代以新形态重现。

来源二：信息不完备性

Agent 做决策时所依据的信息不完整。

已知的不确定 vs 不确定的不确定

已知的不确定：Agent 知道自己不知道什么。比如"我不知道今天的库存量，需要先查询"
不确定的不确定：Agent 不知道自己不知道什么。比如 Agent 以为自己了解退货政策，但政策上周刚改了，它不知道

后者更危险——Agent 在错误的前提下做出自信的决策，和幻觉类似但根源不同：幻觉是模型编造事实，信息不完备是真实事实缺失但 Agent 假装拥有。

隐性约束

很多约束没有写在文档里，是行业惯例或组织内部的不成文规则：

智能体问题：可靠性与中途崩溃

Wed, 01 Jul 2026 00:00:00 +0000

智能体的"半途而废"之痛

写代码的人都知道——程序崩溃不可怕，可怕的是崩溃后状态全丢，只能从头再来。

智能体面临的就是这个问题。一个 20 步的自动化任务，执行到第 15 步时 LLM API 超时了，所有中间状态消失。下次运行从第 1 步重新开始，前面的 14 步白做了。如果有副作用（已经发了一封邮件、已经创建了一条数据库记录），那就更麻烦——重做会导致重复操作。

Temporal 的技术博客 2026 年 4 月发表了一篇引起广泛共鸣的文章，核心观点是：AI 可靠性是一个十年前就该解决、现在仍然只解决了一半的问题。我们应该用基础设施手段而非更好模型来解决它。

为什么智能体会中途崩溃？

原因一：LLM 推理本身就是不稳定的

传统软件的执行路径是确定性的——给定相同输入，永远走同一条路。LLM 不是。每一次推理都是一次概率采样，天生带有不确定性：

API 超时：模型推理慢时，HTTP 请求可能超时中断
Token 限制：上下文窗口满了，前面的轮次被截断
Rate Limit：API 调用频率受限，被 429 返回
服务降级：高峰期模型响应质量下降
随机中断：GPU 集群节点切换、负载均衡导致连接中断

这些问题不是偶尔发生的，在大规模生产环境中是常态。

原因二：智能体状态是"内存态"的

大多数 Agent 框架把执行状态存在内存中：

# 典型的 Agent 循环
state = initial_state
for step in plan:
 state = llm_call(step, state) # state 在内存
 state = tool_call(step, state) # 一旦进程挂了，state 全丢

传统软件有数据库保驾护航——应用挂了重启后数据还在。Agent 框架呢？进程一死，所有中间推理、工具返回、上下文积累全部消失。

原因三：长链路任务的脆弱性

智能体任务越复杂，包含的步骤越多，执行成功率呈指数下降：

单步成功率 95%
10 步任务成功率: 0.95^10 = 59.9%
20 步任务成功率: 0.95^20 = 35.8%
50 步任务成功率: 0.95^50 = 7.7%

即使每步有 95% 的成功率（这已经是优秀的表现），一个 20 步任务就有近 2/3 的概率在某步失败。而大多数真实业务场景不止 20 步。

智能体问题：多 Agent 协调

Wed, 01 Jul 2026 00:00:00 +0000

一个人干不了所有活

单个智能体再强，也有能力边界。它不可能同时是代码专家、财务分析师、法律顾问和设计师。于是多 Agent 协作成为自然选择——让不同专长的 Agent 各司其职，协同完成复杂任务。

听起来很美好，实战中却是一地鸡毛。

Medium 上有一篇被广泛引用的文章，标题就很直白：《Multi-Agent AI 的黑暗心理学：30 种能摧毁你整个系统的失败模式》。30 种可能是夸张了，但核心观点不虚——多 Agent 系统的复杂度不是线性增长，而是指数增长。2 个 Agent 的协调问题比 1 个 Agent 多不止一倍。

三种协作架构

先理清多 Agent 协作有哪几种模式，再分析各自的问题。

模式一：Orchestrator-Worker（中心调度）

一个"主管" Agent 负责理解任务、分解子任务、分派给专业 Worker Agent，最后汇总结果。

[Orchestrator] → 分派 → [代码 Agent]
 → 分派 → [财务 Agent]
 → 分派 → [设计 Agent]
 ← 汇总 ← 各 Agent 结果

优点：逻辑清晰、责任划分明确缺点：Orchestrator 成为单点瓶颈——它既要理解全局，又要管理分发，还要处理冲突

模式二：Pipeline（流水线）

Agent 按照固定顺序串联执行，前一个的输出是后一个的输入。

[需求分析 Agent] → [设计 Agent] → [编码 Agent] → [测试 Agent] → [部署 Agent]

优点：简单、可预测缺点：无反馈回路——如果测试 Agent 发现问题需要返回设计阶段，流水线很难回溯

智能体问题：工具调用失败

Wed, 01 Jul 2026 00:00:00 +0000

当智能体的"手"不听使唤

如果说幻觉是智能体"脑子"的问题，那工具调用失败就是"手脚"的问题。智能体不仅要思考，还要行动——调用 API、查询数据库、操作文件系统。而但凡涉及外部系统交互，失败的维度比纯文本幻觉要多得多。

Arize AI 2026 年对生产环境智能体的故障分析指出：工具相关失败占 Agent 异常的 40% 以上，其中最危险的不是"调用失败"本身，而是失败后的错误处理——智能体对错误的理解和处理能力，往往比工具调用本身更不可靠。

三大失败模式

模式一：静默错误——最危险的失败

工具返回了错误信息，但智能体没有正确解读，把错误响应当做正常结果继续推理。

典型场景

// 智能体调用天气 API
{"tool": "get_weather", "arguments": {"city": "北京", "date": "2026-07-01"}}

// API 返回错误
{"error": "city_not_found", "message": "City name must be in English: Beijing"}

// 智能体把 json 当成了天气数据继续推理
"根据返回的数据，北京7月1日的湿度和 error 字段显示..."

这比调用直接报错更危险——至少报错时智能体知道出错了，还能重试。静默错误时，智能体浑然不知，把垃圾数据当成金子继续加工。

为什么会发生？

错误格式不统一：不同 API 的错误响应结构不同（HTTP 状态码、JSON error 字段、HTML 错误页……），智能体难以用统一逻辑识别
Prompt 缺少错误处理指令：很多人在 system prompt 里只写了"使用 XX 工具查询"，没写"如果工具返回错误，你应该……"
模型倾向"继续完成任务"：遇到异常数据时，模型的训练倾向是给用户一个答案，而不是停下来讨论 API 报错

模式二：参数构造错误——最常见的失败

智能体理解了要调什么工具，但构造参数时出错。

常见错误类型

格式错误：日期传 2026/07/01 而 API 要 2026-07-01
类型错误：传字符串 "5" 而 API 要整数 5
枚举错误：传 "medium" 而有效值只有 ["low", "mid", "high"]
遗漏必填参数：忘了传 currency 字段
语义错误：传了合法格式但语义不对，比如把 page_size=100 传给了限制最大 50 的分页接口

根因分析

模型对 API 的理解来自 prompt 中的工具描述（Function Schema）。如果描述不够精确——比如某个参数的合法值只写了 string 没有枚举——模型就只能"猜"。

智能体问题：幻觉与事实错误

Wed, 01 Jul 2026 00:00:00 +0000

幻觉：智能体最顽固的问题

如果只能用一个词概括当前 AI 智能体最致命的问题，行业里多数人会选"幻觉"（Hallucination）。通用大模型写诗写周报文采斐然，但让它分析"上季度 A 产品线毛利率下降的原因"，它可能编造一串子虚乌有的数据，还附上看起来很专业的百分比。更糟糕的是——语气越自信，越难被非专业用户识破。

Fiddler AI 2026 年的报告给出了一个残酷的数字：生产环境智能体失败率 70%-95%，幻觉是头号杀手。BetterYeah 的调研发现，68% 的企业在 AI 落地中遭遇幻觉问题，其中 32% 因错误累积导致系统性风险。

这不是"模型还不够聪明"的问题。这是智能体的结构性挑战。

从单步错误到幻觉累加

单步幻觉：模型不确定时仍"自信输出"

LLM 的核心训练目标是"合理续写"，而不是"如实回答"。当训练数据中缺少相关信息时，模型不会说"我不知道"——它会生成一段看起来连贯但实际上没有事实支撑的文字。

这是因为：

训练数据偏差：互联网文本中，自信断言远多于谦虚声明"我不确定"
采样机制：模型采样概率最高的 token 序列，不受事实约束
缺乏不确定性建模：模型内部没有显式的"置信度"信号传递给输出层

结果：模型在信息不足时的行为是"编造"，而非"沉默"。

多步累加：小偏差滚雪球

当智能体执行多步任务时，单步幻觉的破坏力被指数放大。看一个典型场景：

步骤 1：检索客户信息 → 幻觉：编造了不存在的客户 ID
步骤 2：用该 ID 查询订单 → 返回空结果
步骤 3：智能体"推断"该客户是新客户 → 编造注册时间
步骤 4：基于虚假注册时间做客户画像分析 → 输出错误结论
步骤 5：基于错误结论撰写运营建议 → 决策偏离

每一步都"合乎逻辑"，但起点就是一个虚构的事实。这就是幻觉累加效应——错误在推理链中不断传播和放大，最终输出和现实南辕北辙。

2025 年 Q1 某金融机构的案例就是典型：智能体在财报分析中第一次幻觉了一个营收数字，后续所有财务比率、趋势判断、投资建议全部基于这个错误数字展开。表面看报告专业完整，实际结论完全失真。

为什么传统 NLP 时代的幻觉没那么致命？

传统 QA 系统也幻觉，但影响范围有限——一次问答的错误不影响下一次。智能体截然不同：它是一个持续运行的闭环系统，前一步的输出是后一步的输入。一个幻觉 token 就像生物学中的基因突变，在后续"转录"过程中被不断放大。

三类幻觉的根源

1. 事实性幻觉

模型编造不存在的事实。典型表现：

智能体问题：治理与问责

Wed, 01 Jul 2026 00:00:00 +0000

当智能体有了"自主权"，谁为它的行为负责？

前几篇文章讨论的问题——幻觉、工具调用失败、崩溃、协调混乱——都是技术可解的。但有一类问题超越了技术范畴：当智能体越来越多地代替人做决策和行动时，谁来为后果负责？

McKinsey 2026 年 AI 信任成熟度调研覆盖了数千家企业，核心发现是：企业对 AI 的信任没有跟上 AI 能力的增长。随着 Agent 从"辅助工具"走向"自主行动者"，治理和问责缺位成了最紧迫的系统性风险。

这不是"以后再考虑"的问题。2025 年已经有多起因 AI Agent 自主行动导致的业务事故：

客服 Agent 自作主张给用户全额退款
营销 Agent 向错误人群发送敏感促销
数据处理 Agent 把内部数据写入了外部系统

每一件事的直接原因都是技术层面的（幻觉、工具错误），但根本原因是治理框架缺失——没有人为 Agent 的行动设定边界。

四大治理挑战

挑战一：权限边界模糊

核心问题

智能体能干什么？哪些决策它可以自己做？哪些必须请示？

大多数 Agent 系统根本没有清晰定义权限边界。系统 prompt 里写了"帮用户处理订单"，但没有写：

你可以取消订单吗？
你可以修改价格吗？
你可以给超过 100 元的订单退款吗？
你可以查看其他用户的数据吗？

为什么重要

权限不清时，Agent 的两种倾向都会出问题：

过度谨慎：什么都问用户，失去自动化的意义
过度激进：什么都自己做，出了事不可控

现实中的 Agent 往往走向后者——因为"帮用户解决问题"的指令天然偏向行动，而非克制。

类别

权限至少需要从三个维度定义：

数据维度：能访问什么数据？能读哪些？能写哪些？
操作维度：能执行哪些操作？取消订单 vs 修改地址 vs 查看物流？
金额维度：操作有财务影响时，上限在哪里？

挑战二：审计追踪缺失

核心问题

Agent 做了一个决策，事后能否完整回溯"它为什么这样做"？

目前多数 Agent 系统的回答是：不能。

推理过程只存在于 LLM 的上下文中，运行结束后消失
工具调用的参数和返回值可能记录了，但"为什么选择调这个工具"没有记录
多步推理中，前面步骤的中间结论影响了后面决策，但这些因果链没有被显式记录

后果

没有审计追踪 = 没有问责基础。

Agent 系列日记 5：为什么 Skill 路由比 ReAct 控制器更适合个人助理

Mon, 29 Jun 2026 00:00:00 +0000

从 luck-agent 到 Hermes-lite，我花了两年时间才想清楚这个问题：80% 的请求不需要"思考"，只需要"路由"。

回顾：ReAct 控制器模式的困境

2024 年做 luck-agent 的时候，我采用的是经典的 ReAct 模式（Reasoning + Acting）：

用户输入 → 大模型推理（意图识别 → 规划 → 工具选择 → 执行）→ 输出

所有请求，不管简单还是复杂，都走同一个推理链。一个"查 QPC 里有没有 VPS 相关的记录"的请求，也要经过：

理解自然语言
判断意图类别
选择工具（search_qpc）
构造查询参数
执行并解释结果

问题很明显：

Token 消耗大：每次推理要带上完整的 system prompt + 工具定义，光上下文就吃掉 3000-5000 token
延迟高：一个简单查询要等模型完成完整推理链，响应时间 3-8 秒
上下文窗口压力：随着工具数量增加（现在 Hermes-lite 有 20+ 个工具），system prompt 越来越大

我当时就在知识库里记了一条：

“对于个人助理场景，相比最初的 ReAct 控制器模式，Skill 技能路由更适合当前 luckagent：80% 请求是固定模式，不需要复杂推理，技能比 Agent 更稳定，成本更低，响应更快。”

Skill 路由的核心思想

一句话：预定义技能映射，轻量分类先路由，只加载需要的工具和 prompt。

用户输入 → 轻量路由（关键词/意图 → 技能）→ 加载专用 prompt + 工具 → 执行

路由表设计

# 简化版路由逻辑
ROUTING_RULES = {
 "qpc": {
 "keywords": ["QPC", "知识库", "记一下", "记录"],
 "skill": "qpc",
 "tools": ["feishu_bitable_read", "feishu_bitable_write"],
 "prompt": "qpc_skill_prompt" # 只加载 QPC 相关的 prompt
 },
 "vps": {
 "keywords": ["VPS", "服务器", "防火墙", "Docker"],
 "skill": "gcp-vps-ops",
 "tools": ["terminal", "read_file"],
 "prompt": "vps_skill_prompt"
 },
 "blog": {
 "keywords": ["博客", "文章", "Hugo", "发布"],
 "skill": "hugo-blog",
 "tools": ["terminal", "read_file", "write_file"],
 "prompt": "blog_skill_prompt"
 }
}

对比：同样"查 QPC"操作

指标	ReAct 模式	Skill 路由
上下文 token	~4000（全量工具定义）	~800（仅 QPC 相关）
首次响应延迟	3-8s	0.5-1.5s
工具调用次数	2-3 次（推理+执行）	1 次（直接执行）
准确率	92%（模型可能选错工具）	98%（路由确定性高）

Hermes-lite 的 Skill 实现

Hermes-lite 的 skill 系统是这样工作的：

QPC 极简设计：我用 4 个字段管理 200 条知识

Mon, 29 Jun 2026 00:00:00 +0000

试过 Obsidian 的标签体系、Notion 的数据库、Logseq 的 graph view，最后发现：知识库的最大敌人不是容量，是维护摩擦。

为什么不做"完美知识库"？

我曾经是一个"知识管理完美主义者"。

尝试 1：Obsidian + 标签体系 + 双向链接

每个笔记文件：
- 标签：#python #async #bug-fix #2026-06
- 链接：[[python-async]] [[common-bugs]]
- 元数据：create_date, last_modified, status, project

结果：三个月后标签体系崩溃了。#python 和 #Python 是两个标签，#bug-fix 和 #bugfix 也是。双向链接变成死链接（文件删了链接还在）。维护成本爆炸，写一条笔记要先想该打什么标签——思考的 friction 超过了记忆的 friction。

尝试 2：Notion 数据库 + 多字段

数据库字段：标题、类型（6 种）、标签（多选）、项目、优先级、状态、来源、日期、附件、笔记

结果：90% 字段闲置。每次新建记录，11 个字段只填 2-3 个，其余空着。Notion 还要求你手动选"类型"、拖"优先级"——录入摩擦太高，最后只记录了 30 条就放弃了。

核心洞察

知识管理的杠杆 = 写入 × 重读，不是字段数。

如果写入摩擦太高，你就不写。如果字段太多、标签太复杂，你就不维护。极简设计 = 更低的维护摩擦 = 更长的生命周期。

QPC 的 4 字段设计哲学

我的 QPC（Question / Practice / Concept）知识库现在有 199 条记录，只用 4 个字段：

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 + 临时文件) │ ← 不丢不坏
└─────────────────────────────────────────────┘

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

Hermes-lite 裁剪实战：7 类典型坑与解法

Thu, 25 Jun 2026 00:00:00 +0000

上一篇文章介绍了 Hermes-lite 的整体裁剪思路。这篇深入每一类实际踩过的坑，把"为什么会遇到"和"怎么解"都说清楚。

一、路径迁移坑

从 .hermes/ 迁到 .hermes-lite/ 后，不是只改 HERMES_HOME 就完事。

踩到的点

.skills_prompt_snapshot.json 里残留旧 .hermes/ 路径
web_search/SKILL.md 硬编码了旧路径
技能、工具、memory、config、sessions、workspace 各自缓存旧路径
systemd 环境变量、进程环境、配置文件、技能正文需要一起排查

经验

grep -r "\.hermes/" /home/user/.hermes-lite/ --include="*.json" --include="*.md" --include="*.yaml" -l

技能快照要清理重建，不能复用旧缓存
systemd 重启不是可选项 — 长进程内缓存会保留旧状态

systemctl restart hermes-lite
systemctl status hermes-lite # 确认新 PID

二、技能裁剪坑

一开始容易只看磁盘上有多少 SKILL.md，但真正可用数量要看运行时过滤后的结果。

踩到的点

磁盘上 67 个 SKILL.md，实际 gateway/slash 可见 65 个
kanban-orchestrator/worker 因为 environments: [kanban] 被过滤，这是预期不是坏了
_find_all_skills(skip_disabled=True) 这个参数名容易误读，实际是返回全部技能，默认才过滤 disabled
web_search 技能存在，但 Tavily key 缺失，会变成"看得到但用不了"

经验

判断技能可用性要看三层：

Hermes-lite 裁剪指南：在 1GB VPS 上跑轻量 AI Agent

Wed, 24 Jun 2026 23:58:52 +0000

为什么要裁剪

完整版 Hermes Agent（Nous Research）功能丰富：多平台网关、浏览器自动化、语音 TTS/STT、多 Agent 协作、Kanban 看板等。但这些功能对资源要求不低——在我的测试里，完整配置更适合至少 2GB 内存的机器。

我有一台 GCP e2-micro（2 vCPU / 954MB RAM），想用它跑一个 24/7 在线的 AI Agent 接入飞书。完整版装不下，于是有了这个裁剪实践。

三阶段渐进式裁剪

裁剪不是一步完成的，而是三阶段递进：

第一阶段：本地 Codex 完成初期核心裁剪

在本地电脑上，利用 Codex（OpenAI） 作为辅助分析工具，对完整版 Hermes 进行全面"解剖"：

逐一扫描 ~/.hermes/ 目录结构，识别每个模块的职责
分析 67 个技能的依赖关系，标记哪些是核心链路的、哪些是边缘功能
梳理 config.yaml 中每个配置项的实际作用，搞清楚"关掉会怎样"
输出一份裁剪清单：哪些 toolset 可以禁、哪些 skill 可以删、哪些配置可以收紧

这一阶段的核心价值：把"能不能关"这个判断做对。Codex 帮助理解了代码间的依赖关系，避免直接关某个功能导致连锁崩溃。

第二阶段：大 VPS 上跑完整版 + 压测验证

在一台大内存 VPS 上安装完整版 Hermes，作为"对照基准"：

记录完整版的实际内存占用（idle / 高负载两种状态）
逐个关闭非核心功能，观察内存变化和稳定性
跑压测：模拟长时间运行、多轮对话、工具调用密集场景
确认裁剪后系统在资源充足环境下依然稳定

这一阶段的目的：建立性能基线 + 验证裁剪组合的安全性。在大 VPS 上翻车无所谓，在小 VPS 上翻车就是服务宕机。

Agent 日记系列（一）：AI 助手协作痛点与进化实践

Wed, 06 May 2026 00:32:00 +0800

当前 AI 助手在复杂场景下暴露出的种种局限，促使我们思考：如何让 Agent 从"工具调用者"进化为"自适应系统"？

痛点全景

1. 工具编排僵化

大部分 Agent 的工具列表在启动时就固定了。面对"下载一个 ZIP 并提取其中 CSV 做分析"这种需要多步骤组合的任务，它无法临时组合出解压→解析→汇总的新流水线，只能止步于"我有 run_shell 但没有 unzip 工具"。

2. 跨会话无记忆

每次对话结束，Agent 的"记忆"归零。上次犯的错、用户的偏好、环境配置——全部遗忘。下次对话从头来，效率极低。

3. 单 Agent 能力天花板

一个 Agent 同时负责信息收集、决策判断、代码执行、结果格式化——角色过载导致质量下降。缺少分工协作机制。

进化方向

从"固定工具"到"动态进化"

Agent 应该能在运行时识别能力缺口，自主编写并注册新工具。这不是插件系统，而是自我扩展。

从"无状态"到"持久记忆"

需要跨会话保留的三层记忆：

用户层：偏好、沟通风格、项目上下文
环境层：系统配置、工具路径、API 端点
经验层：踩过的坑、解决方案、最佳实践

从"单兵"到"协作"

主 Agent 负责决策，子 Agent 各司其职：搜索 Agent、编码 Agent、验证 Agent。通过明确的接口契约协作。

实践起点

本系列接下来的三篇日记，将分别深入主控制器调度、动态工具创建、持久化记忆系统三个方向，拆解具体实现方案。

进化不是加功能，是改范式。

Agent 日记系列（四）：构建 Agent 的记忆宫殿：持久化存储系统解析

Sat, 20 Apr 2024 00:31:50 +0800

Agent 没有记忆，就是"金鱼脑"——每次对话从头开始，重复犯错、忘记偏好。持久化记忆系统要解决的是：跨会话保留什么、怎么存、怎么取。

记忆分层

第一层：身份记忆（User Profile）

永久不变或极少变的信息：

用户姓名、时区、语言偏好
项目路径、技术栈、常用工具
沟通风格偏好（简洁/详细、中文/英文）

存储方式：纯文本文件，每轮注入系统提示。

第二层：经验记忆（Lessons Learned）

踩过的坑和解决方案：

“NewAPI Groq 70B 只有 8K 上下文，不适合做压缩”
“Hugo 0.161.1 需要覆盖 baseof.html 修复 locale 问题”
“Hermes-lite 的 memory 上限 2200 字，要 replace 而非 add”

存储方式：结构化条目，带时间戳和标签。

第三层：会话上下文（Session State）

当前对话的实时状态：

最近 10 轮对话
当前任务进度
待办事项

存储方式：对话历史 buffer，压缩后丢弃细节。

存储方案对比

方案	优点	缺点	适用场景
纯文本文件	零依赖、人类可读	无查询能力、并发不安全	身份记忆、小型博客
SQLite	轻量、单文件、SQL	需维护 schema	中等规模 Agent
Turso/libSQL	分布式、边缘部署	需网络、有成本	多实例 Agent
Redis	极快、支持 TTL	内存贵、无持久化	会话缓存

实际实现：文件 + 索引

对于单 VPS 个人 Agent，最实用的是文件 + 索引方案：

Agent 日记系列（三）：揭秘 Agent 的自我进化：动态工具创建与管理

Fri, 12 Apr 2024 00:31:35 +0800

传统 Agent 的能力在诞生时就固定了——给什么工具就用什么工具。真正的自进化 Agent 应该能在运行时识别能力缺口，自主扩展工具集。

何时需要动态工具

典型场景：

批量文件重命名：没有 rename 工具，但 Agent 可以写一个 Python 脚本
API 数据聚合：需要组合多个接口的结果，现成工具不支持
格式转换：CSV → JSON、Markdown → HTML，临时需要
测试辅助：需要一个 mock 服务或数据生成器

工具创建流程

识别缺口 → 编写代码 → 安全审查 → 注册到 Tool Registry → 可用

识别缺口

Agent 在以下情况触发工具创建：

工具调用连续失败（“没有这个工具”）
用户明确请求不存在的功能
任务需要多步组合但无现成路径

编写代码

Agent 根据需求生成工具脚本，关键约束：

输入输出必须有明确 schema
必须包含错误处理
不能访问超出工作目录的路径

安全审查

这是最关键的一步。Agent 生成的代码必须经过：

语法检查：确保可执行
沙箱试运行：用测试数据验证
权限边界：不读取敏感文件、不发起外部网络请求
用户确认（可选）：高风险操作需人工批准

注册与生命周期

# 工具注册伪代码
tool_registry.register(
 name="batch_rename",
 description="批量重命名文件，支持正则匹配",
 parameters={
 "pattern": {"type": "string", "description": "正则匹配模式"},
 "replacement": {"type": "string", "description": "替换字符串"},
 "directory": {"type": "string", "description": "目标目录"}
 },
 handler="tools/batch_rename.py",
 scope="session" # session / persistent
)

工具作用域：

Agent 日记系列（二）：探秘 Agent 的大脑中枢：主控制器与生命周期

Fri, 05 Apr 2024 00:31:43 +0800

主控制器是 Agent 的"大脑"——它决定何时思考、何时行动、何时停止。理解主控制器的设计，就理解了 Agent 的运作范式。

核心循环（Core Loop）

主控制器的本质是一个状态机：

接收输入 → 理解意图 → 选择工具 → 执行调用 → 处理结果 → 判断是否结束 → 输出/继续

这个循环的关键设计点：

1. 意图识别

不是简单的关键词匹配，而是结合上下文、历史、用户状态的综合判断。同一个"搜索一下"，在项目初期是搜技术方案，在部署阶段是搜报错日志。

2. 工具路由

主控制器维护一个工具注册表（Tool Registry），包含：

工具名 + 描述（供 LLM 选择）
参数 schema（JSON Schema）
权限等级（只读 / 可写 / 危险）
超时策略

路由逻辑：LLM 输出 tool_call → 控制器校验权限 → 注入上下文 → 执行 → 截断超长输出 → 返回结果。

3. 终止条件

这是最容易被忽略的环节。Agent 必须知道"够了"：

显式终止：用户说"停"或任务完成标记
隐式终止：连续 3 次工具调用返回相同/空结果
预算终止：token 消耗超过阈值，强制总结当前进展

生命周期管理

会话级生命周期

创建 → 活跃 → 空闲 → 重置 → 销毁

创建：加载用户上下文、历史摘要、可用工具列表
活跃：正常处理请求，维护对话历史
空闲：N 分钟无请求后，压缩历史为摘要
重置：用户显式 /new，清空当前会话但保留记忆
销毁：服务重启或长时间无活动

任务级生命周期

一个复杂任务可能跨多轮：

从零到一：基于 Gemini 和 Claude 的智能体开发实战（集成 Vertex AI）

Mon, 18 Mar 2024 00:31:16 +0800

构建一个真正能用的 AI Agent，不是调 API 写段对话就完事。你需要的是：能接工具、能记忆、能扩展、能上线的完整系统。

技术选型

模型选择

模型	优势	适用场景
Gemini 3.5 Flash	1M 上下文、多模态、性价比高	长文档分析、多轮对话
Claude 3.5 Sonnet	代码能力强、指令遵循严格	代码生成、复杂推理
Gemini + Claude 双模型	互补优势	主模型决策 + 辅助验证

部署平台

Vertex AI（推荐 GCP 用户）：

统一接口管理多个模型
VPC 内调用，安全可控
ADC 认证，无需手动管理 key

Gemini Developer API（快速原型）：

免费额度够日常用
API Key 简单直接
适合单机开发阶段

核心架构

用户输入
 ↓
主控制器（LLM 决策）
 ├── 工具调用 → Shell / File / Web / API
 ├── 记忆读写 → 持久化存储
 └── 子代理 → 并行任务
 ↓
输出生成

1. 工具层

基础工具集：