Posts 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。

AI Coding 提效全链路：从代码生成到文档的实战工作流

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

面试被问"你在内部有哪些 AI coding 提效工作"——只答"用了 Copilot"是最弱的回答。真正值钱的是：具体怎么用、量化结果、以及你设计的工作流。

这篇文章把我的实战拆成可复制的全链路。

六个场景，按 ROI 排序

不是所有编码环节都值得交给 AI。按投入产出比排：

代码生成 —— 模板代码 / CRUD / 配置文件，提效 3-5x
单元测试生成 —— 覆盖率从 40% → 80%+，省下大量机械劳动
Code Review —— 自动查常见问题（安全 / 性能 / 命名），压缩人工 review 时间
文档生成 —— API 文档 / CHANGELOG / README，提效 5-10x
调试辅助 —— 贴报错自动给修复建议
Onboarding —— 新人用 AI 快速理解陌生代码库

注意排序：文档和单测的 ROI 往往最高，因为它们最机械、最不依赖创造性，却最容易被人类拖延。

三层落地：个人 / 团队 / CI

提效不是装个插件就结束，要分层次铺开：

个人层：Cursor / Claude Code 日常编码，把重复活交给模型
团队层：内部 AI coding 工具 + 共享 prompt 库，把个人经验变成团队资产
CI/CD 层：自动测试生成、自动 code review，每次 PR 触发

关键认知：不要让 AI 只在你本地跑。把它沉到 CI，才能从"个人快一点"变成"团队不出低级错"。

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 一个都不原生管。

10w、50w、100w 三档资金的配置思路

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

同样是稳健理财，10 万、50 万、100 万的配置重点并不一样。

资金规模越小，越要优先保证现金流和简单执行；资金规模变大后，才更值得引入多资产配置、再平衡和工具化复盘。这里讨论的是配置思路，不是产品推荐，也不构成投资建议。

10w：先解决安全垫

10 万资金最重要的是不要把系统做复杂。

如果这笔钱还承担应急、租房、家庭支出或短期计划，就不应该为了提高几个点收益牺牲流动性。这个阶段的核心目标是建立安全垫和基本纪律。

一个可思考的结构是：

较高比例现金或货币基金，覆盖短期不确定支出。
少量短债或低波动产品，用于学习净值波动。
暂时不追求复杂权益配置。

这个阶段最应该训练的是记录和复盘，而不是追求组合精巧。

50w：开始区分用途

50 万资金通常已经值得做用途分层。

可以把资金分成三类：

1 年内可能使用的钱：保持高流动性。
1-3 年可能使用的钱：以低波动防守资产为主。
3 年以上不用的钱：可以承担适度权益波动。

这个阶段可以开始建立目标比例，例如现金、短债、二级债、红利低波或宽基的组合。但比例不是重点，重点是每类资金都有明确用途。

100w：配置和流程同样重要

100 万资金的波动会更有体感。

组合回撤 5%，账面就是 5 万；回撤 10%，就是 10 万。这个阶段不能只看“年化收益”，必须把最大回撤、再平衡规则和极端行情预案写清楚。

已有的《100w 稳健型基金组合 · 执行手册》就是一个实战样例：先定义本金、目标年化、最大回撤和再平衡周期，再拆成具体资产类别。

三档资金的差异

资金规模	核心目标	管理重点
10w	建立安全垫	流动性、记录、少折腾
50w	用途分层	目标比例、风险分层
100w	稳定执行	再平衡、复盘、极端预案

资金越大，越需要流程。不是因为大资金一定要复杂，而是因为错误决策的绝对金额更大。

不同规模都需要的底层规则

无论资金规模多大，都应该先写清楚：

哪些钱不能亏，哪些钱可以承担波动。
最大可接受回撤是多少。
每类资产的目标比例和允许偏离区间。
多久复盘一次。
什么情况下必须停止新增风险资产。

如果这些规则没有写下来，资金规模越大，情绪化操作的代价越高。

工具化从 50w 后更有价值

10 万阶段，一个简单表格就够。

50 万以后，可以开始记录目标比例、当前比例、偏离值和复盘备注。100 万以后，再平衡提醒、公告摘要、组合归因和月度报告就会更有价值。

工具化不是为了炫技，而是为了减少漏看、少算和冲动决策。

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 可以说“组合权益比例高于目标 5 个百分点”，但不应该直接说“应该卖出某基金”。

更好的输出是：

观察到什么。
触发了哪条规则。
有哪些可选动作。
哪些动作需要人工确认。

执行动作必须留痕

如果人工确认后执行动作，也应该记录：

执行日期。
执行动作。
触发规则。
金额或比例。
复盘备注。

留痕是为了未来知道自己为什么这么做。

自动化的底线

个人理财工具的底线很简单：

工具可以提高信息质量，不能替你承担后果。

凡是会改变资产状态的动作，都应该由人确认。

个人稳健理财工具维护手册

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

理财工具最难的不是搭起来，而是长期维护。

一开始表格字段很多、自动化脚本很多、Agent 提示词很复杂，看起来很完整。三个月后，如果你不愿意更新数据，这套工具就失效了。

稳健理财工具应该尽量小，稳定运行，容易复盘。

本文是个人学习记录，不构成投资建议。

最小字段

一个个人组合表不需要一开始就做成数据库。

最小字段可以是：

字段	用途
名称	基金、ETF 或现金账户名称
类别	现金、货基、短债、二级债、权益、黄金等
当前金额	用于计算比例
当前比例	当前金额除以总资产
目标比例	你的配置规则
偏离值	当前比例减目标比例
处理规则	买入、卖出、不动或观察
备注	公告、风险、人工判断

字段越少，越容易坚持。

复盘频率

我倾向于三层频率：

每月：更新持仓金额，生成简短复盘。
每半年：检查是否需要再平衡。
每年：重新确认资金用途、目标收益和最大回撤。

不要每天复盘。高频查看容易把长期系统变成短期情绪管理。

数据来源

数据来源要少而可靠。

可以包括：

持仓平台导出的金额。
基金定期报告和公告。
自己维护的目标配置表。
每次人工决策记录。

如果数据需要从太多地方手工复制，工具很快会废掉。宁可字段少，也要保证持续更新。

失败场景

维护手册必须写失败场景。

常见失败包括：

忘记更新持仓。
临时改规则但没有记录。
Agent 把公告摘要错了。
表格公式被误改。
某只基金分类不清，导致比例失真。
极端行情中没有按预案复盘。

把失败写出来，是为了提前设计补救动作。

月度维护清单

每月可以只做六步：

更新各资产当前金额。
检查总资产和现金比例。
计算目标比例偏离。
阅读异常基金公告摘要。
生成月度复盘。
记录是否需要人工确认动作。

如果没有触发规则，就写“不动”。

半年维护清单

每半年检查：

是否触发再平衡阈值。
最大回撤是否超出预期。
收入和支出是否发生变化。
未来一年是否有大额用钱计划。
是否需要调整现金比例。
是否有基金经理变更或风格漂移。

半年复盘比月度复盘更关注结构，不关注短期涨跌。

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

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

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

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

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

大而全的代价

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

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

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

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

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

精简的目标

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

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

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

少组件

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

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

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

少权限

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

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

权限可以分级：

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

强日志

没有日志的 Agent 不可维护。

至少要记录：

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

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

可人工接管

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

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

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

为什么智能体开发者需要自己的稳健理财系统

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

这不是一篇教人“用 AI 赚钱”的文章。

对智能体开发者来说，更现实的问题是：我们每天都在构建自动化系统，却常常用很随意的方式管理自己的钱。看到一只基金涨了就想买，看到市场跌了就想卖，年底回头看，真正的问题不是缺少信息，而是缺少一套稳定执行的系统。

稳健理财需要的不是神奇预测，而是工程化纪律。

为什么是系统，而不是灵感

个人理财最容易出错的地方，是每次决策都从情绪开始。涨的时候害怕错过，跌的时候害怕继续亏，产品销售文案和排行榜又会不断放大这种波动。

系统的价值在于把决策前置：

在买入前定义资金用途和期限。
在配置前确认最大可接受回撤。
在执行前写清楚调仓条件。
在复盘时只看少数关键指标。

这和写 Agent 很像。一个没有状态、没有日志、没有权限边界的 Agent，短期看起来很聪明，长期一定不可控。个人理财也是一样：没有规则的投资，短期靠运气，长期靠情绪。

工程化理财的三个层次

第一层是规则。

规则回答“什么时候做什么”。例如现金保留多少、基金最多占多少、单类资产偏离目标多少才调仓、下跌时是否继续买入。规则不需要复杂，但必须提前写下来。

第二层是复盘。

复盘回答“这套规则有没有被执行”。它不应该变成每天盯净值，而是用固定频率检查配置偏离、组合回撤、现金比例和是否出现了新风险。

第三层是工具。

工具回答“哪些重复工作可以交给机器”。表格可以算比例，脚本可以提醒偏离，Agent 可以整理公告和生成复盘摘要。但工具只能辅助执行规则，不能替代规则本身。

AI Agent 适合做什么

Agent 适合做信息整理、流程提醒、结构化记录和复盘草稿。

例如：

整理基金季报里的持仓变化。
汇总组合中各类资产当前占比。
提醒某类资产偏离目标区间。
根据固定模板生成月度复盘。
把投资决策记录进个人知识库。

这些任务有明确输入、明确格式、明确边界，适合自动化。

AI Agent 不适合做什么

Agent 不应该替你做无约束投资判断。

尤其不应该：

预测短期涨跌。
根据单条新闻直接建议买卖。
自动下单。
忽略你的资金期限和风险承受能力。
把历史回测包装成确定性结论。

个人理财里的高风险动作必须由人确认。Agent 可以给建议、列证据、提醒风险，但不应该拿走最后的决策权。

这个系列的边界

这个系列只记录个人学习和工具实践，不构成任何投资建议。

我会尽量把每个配置样例都写清楚假设条件：资金规模、收益目标、回撤约束、流动性需求和执行周期。没有这些条件，任何“推荐配置”都是不完整的。

更重要的是，这个系列关注的是如何建立稳健流程，而不是追逐最优收益。对普通个人来说，能长期执行的中等方案，往往比看起来更聪明但无法坚持的方案更有价值。

最小行动清单

如果从今天开始搭建自己的理财系统，我会先做五件事：

写下未来 1 年、3 年、5 年可能用钱的场景。
定义最大可接受回撤，而不是只写目标收益。
把资产分成现金、防守、进攻和对冲四类。
建一个最小组合表，只记录品类、金额、比例、目标比例和备注。
每月复盘一次，不在非复盘日因为情绪调仓。

这就是工程化稳健理财的起点：不是预测下一次行情，而是减少下一次冲动。

什么时候该持有现金，什么时候该承担波动

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

现金常被嫌弃收益低，风险资产常被期待收益高。

但稳健理财不是在两者之间选一个，而是判断一笔钱该承担什么风险。现金负责确定性和选择权，风险资产负责长期增长。错配才是问题。

本文不构成投资建议。

该持有现金的情况

以下资金更适合现金或类现金：

未来 6-12 个月确定要用的钱。
应急备用金。
收入不稳定时期的生活费。
大额支出前的过渡资金。
已经无法承受回撤的钱。

现金的作用不是收益最大化，而是避免被迫卖出其他资产。

该承担波动的情况

以下资金才适合考虑风险资产：

3 年以上不用的钱。
下跌时不影响生活的钱。
已经有现金安全垫之后的资金。
能按规则复盘和再平衡的钱。

承担波动的前提，是你不需要在错误时间被迫退出。

时间期限决定风险上限

资金期限越短，越不适合高波动资产。

不是因为风险资产不好，而是因为它的收益兑现需要时间。短期资金买入高波动资产，本质上是把生活计划交给市场。

现金也是策略

持有现金不是“不会投资”。

现金可以让你：

应对突发支出。
在市场大跌时不被迫卖出。
等待更清晰的配置机会。
降低组合整体波动。

稳健组合里，现金是一种风险管理工具。

一个简单判断

问自己三个问题：

这笔钱最早什么时候要用？
如果短期亏 10%，是否会影响计划？
如果市场一年不涨，是否还能继续持有？

只要有一个答案是否定的，就应该提高现金或低波动资产比例。

什么时候需要多 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

很多理财目标只写一句话：希望年化 5%。

这个目标太薄。它没有说明中间最多能亏多少、这笔钱什么时候要用、下跌时是否还能继续持有。真正可执行的资产配置目标，应该让你在市场波动时仍然能睡着觉。

本文是个人学习记录，不构成投资建议。

年化收益只是一个维度

年化收益描述的是长期结果，但个人承受的是过程。

如果一个组合长期年化可能有 6%，但中途可能回撤 25%，对很多稳健型资金来说并不合适。反过来，一个组合年化不高，但回撤小、流动性好、执行简单，也可能更适合短中期资金。

目标收益必须和风险约束一起出现。

写目标时要加四个字段

我会把目标写成这样：

字段	示例
资金用途	未来 3 年不计划使用
目标收益	争取年化 4%-6%
最大回撤	希望控制在 10% 以内
执行规则	半年复盘，偏离 5 个百分点再平衡

这比“年化 5%”更接近真实决策。

能睡着觉是一条硬约束

能睡着觉不是情绪化要求，而是执行力要求。

如果一个组合让你每天看净值、频繁打开交易软件、因为新闻改计划，它就超过了你的承受范围。稳健理财追求的是长期可执行，而不是短期最优。

目标要能落到动作

一个好目标应该能推导出动作：

最大回撤决定权益资产比例。
资金期限决定流动性比例。
复盘频率决定工具复杂度。
再平衡阈值决定什么时候调仓。

如果目标不能指导动作，它只是愿望。

最小模板

可以直接使用这个模板：

这笔钱的用途：
最早使用时间：
目标收益区间：
最大可接受回撤：
现金保留比例：
风险资产上限：
复盘频率：
触发调仓条件：

稳健配置的第一步，是把“我想赚多少”改成“我能承受什么，并愿意按什么规则执行”。

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

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

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

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

幻觉不是唯一问题

幻觉只是错误的一种。

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

可靠性的四个要求

我更关心四件事：

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

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

事实类回答要有来源

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

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

执行动作要有确认

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

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

错误要进入复盘

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

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

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

边界越清楚，助理越可信

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

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

债基、二级债、红利低波 ETF 的常见误区

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

稳健组合里常见三类产品：债基、二级债、红利低波 ETF。

它们都可能有价值，但也都容易被误解。误解的核心，是把“相对稳健”看成“没有风险”。

本文是个人学习记录，不构成投资建议。

误区一：债基不会亏

债基也会亏。

利率变化、信用风险、流动性压力都会影响债基净值。短债通常波动小一些，中长债对利率更敏感，信用债还要看违约和估值压力。

看债基时不能只看近一年收益，要看久期、杠杆、信用等级和最大回撤。

误区二：二级债只是债基增强版

二级债通常可以配置股票或可转债。

这意味着它可能在权益市场下跌时出现明显回撤。把二级债放在“纯防守仓”里，会低估组合风险。

二级债更适合被看作收益增强工具，而不是现金替代品。

误区三：红利低波没有权益风险

红利低波 ETF 仍然是权益资产。

它可能比成长风格更稳，也可能有股息和估值支撑，但市场系统性下跌时，它也会跌。红利低波的角色是“相对防守的权益暴露”，不是债券。

误区四：名字比持仓重要

产品名字经常带有“稳健”“优选”“增强”。

这些词不能替代持仓分析。真正要看的是基金定期报告、资产比例、行业集中度、久期、回撤和风格变化。

最小检查清单

买入前至少问：

它到底持有什么资产？
历史最大回撤是多少？
它在组合里负责什么角色？
下跌时是否符合预期？
是否把权益风险伪装成稳健收益？

稳健理财不是避开所有风险，而是不要误认风险。

再平衡规则：什么时候调仓，什么时候不动

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

稳健组合不是买完就不管，也不是每天都调。

再平衡的目的，是让组合回到你原本愿意承担的风险结构。它不是预测市场，也不是追涨杀跌，而是执行事先写好的纪律。

本文是个人学习记录，不构成投资建议。

为什么需要再平衡

假设你的目标配置是 70% 防守资产、30% 权益资产。

如果权益资产上涨很多，它在组合里的比例可能变成 40%。这时组合的风险已经高于原计划。反过来，如果权益资产下跌很多，比例可能降到 20%，你又可能错过原本计划承担的风险敞口。

再平衡就是把组合从“市场推着走”拉回“规则控制下”。

周期再平衡

周期再平衡是按固定时间检查，例如每月、每季度或每半年。

它的优点是简单，不需要每天盯盘。缺点是可能在偏离不大时产生不必要操作。

对个人稳健组合来说，半年一次通常比每天关注更现实。频率太高会增加交易成本和情绪干扰。

阈值再平衡

阈值再平衡是当某类资产偏离目标比例超过一定范围时才操作。

例如目标比例 30%，允许上下偏离 5 个百分点。只有低于 25% 或高于 35% 时，才考虑调仓。

阈值再平衡的好处是更贴近风险变化，但需要表格或工具持续计算偏离。

现金流再平衡

现金流再平衡是用新增资金或赎回需求调整比例，而不是频繁卖出已有资产。

例如权益资产跌了，比例低于目标，新投入资金优先买入权益资产；某类资产涨多了，新资金先补其他类别。这样可以减少交易和税费摩擦。

对长期个人组合来说，现金流再平衡往往比直接卖出更温和。

半年复盘流程

一个可执行的半年流程：

统计当前各资产金额和比例。
对比目标比例，计算偏离值。
检查组合最大回撤是否超过预期。
检查未来 6-12 个月是否有大额用钱计划。
优先用新增资金修正偏离。
只有偏离超过阈值时才卖出调仓。
记录本次动作和原因。

复盘不是写长报告，而是把关键动作留下证据。

什么时候不动

再平衡也包括“不操作”。

以下情况通常不应因为情绪调仓：

组合仍在目标区间内。
下跌没有超过预设回撤。
只是因为看到新闻而焦虑。
只是因为某只基金短期排名变化。
资金用途和风险承受能力没有变化。

不动不是偷懒，而是尊重规则。

再平衡记录模板

可以用一个最小模板：

字段	内容
日期	本次复盘日期
总资产	当前组合金额
最大偏离	偏离最大的资产类别
是否触发阈值	是或否
操作	买入、卖出、暂停、不动
原因	规则触发或现金流变化
下次检查	下一次复盘日期

再平衡的关键不是调得多准，而是每次动作都能解释。

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

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

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

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

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

应该内置的能力

内置能力应该少而稳定：

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

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

应该交给工具的能力

具体动作适合交给工具：

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

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

判断标准

可以用三个问题判断：

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

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

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

工具逻辑变化很快。

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

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

最小核心更可靠

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

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

基金筛选清单：从收益率退后一步

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

基金筛选最容易掉进一个坑：从排行榜开始。

排行榜告诉你过去一段时间谁涨得好，但不告诉你这段收益来自什么风险，也不告诉你它是否适合你的组合。稳健理财需要从收益率退后一步，先看基金在组合里的角色。

本文是个人学习记录，不构成投资建议。

第一步：看底层资产

先弄清楚基金到底买了什么。

名字里写“稳健”“精选”“增强”，都不能替代底层资产分析。债基要看利率债、信用债、久期和杠杆；二级债要看权益仓位；权益基金要看行业集中度、风格和持仓换手。

如果你说不清它赚的是什么钱，也就说不清它亏的时候该不该继续拿。

第二步：看最大回撤

收益率是结果，回撤是过程。

稳健组合尤其要看基金在压力环境中的表现。近一年收益好，但最大回撤远超你的承受范围，这类产品就不适合放在防守仓里。

看回撤时不要只看绝对数字，还要看修复时间。一个跌得深、修复慢的产品，会长期占用你的心理和资金弹性。

第三步：看规模和流动性

规模太小的基金可能面临清盘风险，也可能在流动性压力下更难处理赎回。

规模太大也不一定好，尤其是主动管理基金，规模增长可能影响策略执行。稳健筛选不是追求最大规模，而是避免明显脆弱的规模状态。

第四步：看费率

费率是确定发生的成本。

管理费、托管费、销售服务费、申购赎回费都会影响长期收益。对低收益、低波动产品来说，费率差异尤其重要，因为它直接吃掉本来就不高的收益空间。

第五步：看经理稳定性

主动管理基金要看基金经理是否稳定。

如果历史业绩主要来自上一任经理，新经理接手后策略已经变化，就不能简单沿用旧数据。基金经理变更、投研团队变化和策略说明变化，都应该进入复盘。

第六步：看风格漂移

风格漂移是稳健组合的大敌。

你以为买的是低波动资产，结果它为了追收益加大权益暴露；你以为买的是均衡基金，结果集中押注单一行业。这样的产品会让组合风险结构失真。

筛选时要对比基金合同、定期报告和实际持仓，看它是否长期保持自己的角色。

可复用筛选清单

每只基金进入观察池前，我会检查：

它的底层资产是什么？
它在组合里负责防守、增长、对冲还是流动性？
过去三年最大回撤是多少？
最大回撤修复用了多久？
基金规模是否过小或异常膨胀？
总费率是否合理？
基金经理是否稳定？
持仓和合同描述是否一致？
有没有明显风格漂移？
如果它跌 5% 或 10%，我是否知道处理规则？

最后再看收益率

收益率不是不能看，而是应该最后看。

先确认角色、风险和可执行性，再比较收益。这样筛出来的产品未必最亮眼，但更可能适合长期持有。

稳健组合真正需要的，不是单只基金短期跑赢，而是整个组合能按规则运行。

如何识别一个组合是不是假稳健

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

有些组合看起来很稳健，实际并不稳健。

它可能持有很多产品，名字里也有“稳健”“低波”“固收+”，但真实风险集中在同一类资产、同一种风格或同一个宏观假设上。这就是假稳健。

本文不构成投资建议。

信号一：产品很多，但风险来源单一

组合里有 10 只基金，不代表分散。

如果它们都重仓同一类债券、同一批高股息股票或同一种风格因子，真正的风险并没有分散，只是包装变多了。

分散应该看底层资产，而不是产品数量。

信号二：只展示收益，不展示回撤

稳健组合必须回答最大回撤。

如果一个组合只说年化收益、胜率、历史表现，却不说最差时亏多少、多久修复，就还没有完成风险说明。

信号三：把短期数据当长期能力

某类资产在特定年份表现好，不代表长期适合防守。

假稳健经常把最近一段顺风期包装成长期规律。识别方法是拉长周期，看不同市场环境下的表现。

信号四：流动性被忽略

组合看起来收益稳定，但如果封闭期长、赎回慢、极端情况下流动性差，就不适合承担短期资金用途。

稳健必须包括流动性。

信号五：没有调仓规则

真正的稳健组合应该知道什么时候不动、什么时候调仓。

如果组合只能解释“为什么买”，不能解释“什么情况下卖、减、补、不动”，它就还不是系统。

识别模板

可以用五个问题检查：

底层资产是否真的分散？
最大回撤是否可接受？
数据是否跨越不同市场环境？
流动性是否匹配资金用途？
是否有明确再平衡规则？

答不清楚，就不要把它称为稳健。

工具调用失败时，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

稳健理财里最常见的误区，是只看收益率。

收益率当然重要，但它不是单独存在的。你真正承受的是收益、回撤、波动率和流动性的组合。如果只拿“年化 5%”当目标，却不问中间可能亏多少、亏多久、急用钱时能不能取出来，这个目标就不完整。

本文只做概念梳理，不构成投资建议。

收益：结果，不是承诺

收益是你最终赚到的钱。问题是，很多产品展示的是历史收益、区间收益或模拟收益，它们都不是未来承诺。

看收益时至少要问三件事：

这个收益来自哪个时间段？
这段时间的市场环境是否特殊？
为了拿到这个收益，中间承受过多大下跌？

同样是年化 5%，如果一个组合最大回撤 2%，另一个最大回撤 20%，它们对个人生活的影响完全不同。

回撤：你必须熬过去的亏损

回撤是从阶段高点跌到阶段低点的幅度。

回撤的现实含义不是表格里的数字，而是你账户里真实减少的钱。100 万组合回撤 10%，就是账面少 10 万。你能不能不慌，取决于这笔钱是不是短期要用，也取决于你在买入前是否预期过这种情况。

稳健配置最应该先定义最大可接受回撤。不是市场会不会跌，而是跌到什么程度你还能按规则行动。

波动率：过程中的颠簸

波动率描述价格上下变化的剧烈程度。

一个高波动资产不一定长期收益差，但它会更频繁地考验执行力。对很多人来说，真正的问题不是数学上的亏损，而是情绪上的中断：涨的时候追高，跌的时候割肉。

所以稳健组合不应该只问“长期收益高不高”，还要问“这个波动我能不能拿得住”。

流动性：需要用钱时能不能拿出来

流动性是资金变成可用现金的能力。

流动性不足会把好资产变成坏体验。比如一笔三个月后要用的钱，即使买了长期看不错的资产，也可能因为短期下跌或赎回限制被迫卖出。

现金和货币基金的作用不是收益最大化，而是避免被迫在错误时间卖出风险资产。

四个概念要一起看

稳健理财不是选最高收益，而是在四个问题之间做平衡：

问题	关注点
能赚多少	收益
最难受时亏多少	回撤
持有过程有多颠簸	波动率
急用钱时能不能拿出来	流动性

任何一个产品或组合，只要没有同时回答这四个问题，就还没有进入可执行状态。

风险自检表

在买入任何基金或配置组合前，可以先回答这份清单：

这笔钱最早什么时候可能要用？
如果账面亏 5%，我会怎么做？
如果账面亏 10%，我会怎么做？
如果半年不赚钱，我是否还能继续持有？
这个产品的底层资产是什么？
收益主要来自利息、股息、估值上涨，还是杠杆和信用风险？
有没有赎回限制、封闭期或大额赎回风险？
我是否知道什么时候应该调仓，什么时候不应该动？
这笔配置是否会影响日常现金流？
我是否把单一产品当成了完整组合？

如果这些问题答不上来，先不要急着买。稳健理财的第一步，是承认自己真正能承受的风险。

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

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

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

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

日志：先能看见问题

日志至少要回答：

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

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

日志检查频率

可以分三类：

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

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

备份：先备配置和记忆

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

备份优先级：

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

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

恢复演练

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

至少要知道：

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

恢复流程应该写成清单。

升级：小步走

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

建议流程：

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

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

安全检查

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

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

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

人工接管流程

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

人工接管流程包括：

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

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

维护手册的目标

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

智能体开发者的个人稳健理财学习和工具：系列总览

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

这组文章不是投资建议，也不是“用 AI 帮你预测市场”的故事。

它更像一个面向智能体开发者的个人理财工程化笔记：把收益、风险、回撤、流动性、再平衡这些概念拆开，用清晰的规则和工具降低决策噪音。

系列目标

我希望这个系列解决三个问题：

怎么建立一套足够稳健、能长期执行的个人资产配置框架。
怎么把基金、ETF、现金管理和再平衡变成可复盘的流程。
怎么让 AI Agent 辅助阅读、整理、提醒和复盘，而不是替代判断。

核心原则是：先稳健，再自动化；先理解风险，再追求收益；先建立规则，再接入工具。

当前已发布文章

其中《100w 稳健型基金组合 · 执行手册》可以看作系列里的实战样例：给定资金规模、收益目标和回撤约束之后，如何拆成具体配置、执行日历和再平衡规则。

建议阅读框架

1. 认知篇：先理解风险

稳健理财的第一步不是选产品，而是确认自己承受什么类型的波动。

已发布文章：

2. 配置篇：把钱分到不同篮子里

这一部分关注现金、货币基金、短债、中长债、二级债、红利低波、宽基指数、黄金和海外资产的角色。

已发布文章：

3. 筛选篇：看懂基金，而不是追逐排行榜

基金筛选不应该只看近一年收益。更重要的是看底层资产、久期、回撤、规模、费用、经理稳定性和风格漂移。

已发布文章：

4. 执行篇：把计划变成流程

稳健组合真正难的地方通常不是“知道买什么”，而是能不能在半年、一年、三年之后继续按规则执行。

月度复盘模板：只看少数关键指标

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

月度复盘不是每天盯盘的升级版。

它的目标是确认组合是否仍然按规则运行，而不是解释每一天涨跌。稳健理财的复盘应该少看噪音，多看关键指标。

本文不构成投资建议。

只看五类信息

月度复盘可以只看：

总资产变化。
各类资产当前比例。
和目标比例的偏离。
本月最大回撤。
是否触发调仓或人工确认。

这五类信息足够支持大多数稳健组合维护。

不要复盘市场情绪

新闻、观点和短期涨跌很容易让复盘变形。

如果每次复盘都变成判断下个月涨跌，系统就会被情绪带走。月度复盘应该围绕自己的规则，而不是围绕市场叙事。

模板

复盘月份：
总资产：
现金/类现金比例：
防守资产比例：
权益资产比例：
最大偏离项：
本月最大回撤：
是否触发再平衡：
是否有大额用钱计划变化：
本月动作：
下月关注：

复盘结论只要三种

结论可以很简单：

不动：组合仍在目标区间。
观察：出现偏离但未触发动作。
执行：触发再平衡或现金流调整。

不要为了复盘而制造动作。

Agent 可以做什么

Agent 可以把持仓表转成复盘草稿，计算偏离，列出异常项。

但最终结论必须由人确认。尤其是“执行”类动作，需要回到资金用途和风险承受能力，而不是只看模型输出。

复盘越简单，越容易长期坚持。

极端行情预案：下跌时按什么规则行动

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

下跌时最难做决定。

不是因为信息不够，而是因为情绪太强。极端行情预案的价值，就是在平静时写下规则，避免在恐慌时临时发挥。

本文是个人学习记录，不构成投资建议。

先定义下跌级别

可以把下跌分成三层：

轻微波动：组合回撤未超过预期。
明显回撤：接近或达到预设阈值。
极端回撤：超过原本承受范围。

不同级别对应不同动作。

轻微波动：不动

如果组合仍在预设区间内，最好的动作通常是不动。

不动不是忽视风险，而是承认波动本来就在计划内。稳健组合不应该因为正常波动改变结构。

明显回撤：检查规则

当回撤接近阈值时，先检查：

资金用途是否变化。
现金比例是否足够。
资产比例是否偏离目标。
下跌是否来自预期内风险。

如果只是比例偏离，可以用再平衡规则处理；如果资金用途变了，才考虑降低风险。

极端回撤：保留生存能力

如果回撤超过承受范围，先保护现金流和生活计划。

这时不应该盲目补仓，也不应该因为恐慌一次性清仓。更好的做法是暂停新增风险、检查现金垫、分批处理，并记录决策理由。

预案模板

组合最大可接受回撤：
轻微波动区间：
明显回撤区间：
极端回撤区间：
每个区间的动作：
是否允许补仓：
补仓资金来源：
必须停止的动作：
需要人工确认的动作：

预案要提前写

下跌时不要重新设计系统。

极端行情真正考验的不是预测能力，而是是否提前知道：哪些钱不能动，哪些风险可以继续承担，哪些动作必须停下来。

用表格管理个人基金组合的最小字段

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

个人基金组合不一定需要专业系统。

一个维护得好的简单表格，往往比一个字段很多但没人更新的复杂工具更有用。关键是字段少、含义清楚、能支持复盘。

本文不构成投资建议。

最小字段

我会从八个字段开始：

字段	说明
名称	基金、ETF 或现金账户
类别	现金、货基、短债、二级债、权益、黄金
当前金额	最新金额
当前比例	当前金额 / 总资产
目标比例	配置计划里的目标
偏离值	当前比例 - 目标比例
处理规则	不动、观察、补、减
备注	公告、风险或人工判断

这些字段已经足够支持月度复盘和半年再平衡。

不要一开始就加太多字段

过多字段会增加维护摩擦。

例如日涨跌、近一年排名、夏普比率、最大回撤、经理任期、费率都可能有用，但不一定每月都要手工维护。可以放在单独的观察表，而不是核心持仓表。

让公式负责计算

表格应该自动计算：

总资产。
当前比例。
偏离值。
是否触发阈值。

人工只更新金额和备注。这样能减少错误。

Agent 的位置

Agent 可以读取表格，输出：

最大偏离项。
是否触发再平衡。
哪些字段缺失。
月度复盘草稿。

但表格结构必须先稳定，否则 Agent 也只能跟着混乱。

最小系统优先

好的组合表不是数据最多，而是能回答四个问题：

钱在哪里？
风险集中在哪里？
是否偏离目标？
下一步是否需要动作？

能稳定回答这四个问题，就够用了。

稳健组合里的每类资产到底负责什么

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

稳健组合不是把几个“看起来不错”的产品拼在一起。

更好的方式是先问：每类资产在组合里负责什么。只有角色清楚，后面才谈得上比例、再平衡和复盘。

本文是个人学习记录，不构成投资建议。

现金：负责生存空间

现金的主要作用不是收益，而是选择权。

它让你在临时用钱、收入中断或市场下跌时不用被迫卖出其他资产。现金比例太高会拖累长期收益，但现金比例太低会让组合失去韧性。

对普通个人来说，现金通常应该覆盖几个月到一年的必要支出。具体比例取决于收入稳定性、家庭责任和未来支出计划。

货币基金：负责短期停泊

货币基金适合放短期不用但随时可能调用的钱。

它的角色接近现金管理工具：收益通常不高，但流动性和波动控制较好。不要把货币基金当成长期收益来源，它更像组合的缓冲垫。

短债基金：负责低波动防守

短债基金通常承担比货币基金略高一点的收益目标，同时保持较低波动。

需要注意的是，短债不是无风险资产。它仍然可能受到利率、信用和流动性影响。稳健组合里配置短债，是为了提高现金管理效率，而不是追逐高收益。

中长债和二级债：负责适度收益增强

中长债对利率变化更敏感，二级债可能含有权益仓位或可转债仓位，波动会更明显。

它们在组合里的角色是收益增强，但也会带来回撤。配置这类资产时，要重点看久期、信用风险、权益暴露和历史回撤，而不是只看近一年收益。

红利低波：负责权益暴露的缓冲版本

红利低波类 ETF 或基金，本质上仍然有权益风险。

它们的作用不是替代债券，而是在权益资产中选择相对防守的表达方式。红利、低估值和低波动因子可能降低组合剧烈波动，但不能消除下跌。

在稳健组合里，红利低波适合承担“有限进攻”的角色。

宽基指数：负责长期增长

宽基指数覆盖更广市场，适合承担长期增长角色。

但宽基指数的短期波动并不低。如果资金期限较短，或者无法承受明显回撤，就不应该因为“长期收益更高”而过度配置。

宽基适合长期资金，不适合短期确定用途资金。

黄金：负责对冲和心理稳定

黄金通常被视为对冲资产，但它本身也会波动。

它在组合里的作用不是稳定赚钱，而是在特定宏观环境中提供不同于股债的风险来源。少量配置可能有助于分散风险，但不应该把它当作确定性的避险答案。

组合角色表

资产	主要角色	核心风险
现金	应急和选择权	收益低、被通胀侵蚀
货币基金	短期停泊	收益有限、流动性极端风险
短债基金	低波动防守	利率和信用风险
中长债	收益增强	久期风险
二级债	收益增强	权益和转债波动
红利低波	有限进攻	权益市场下跌
宽基指数	长期增长	高波动和长期回撤
黄金	分散和对冲	自身价格波动

配置前先问角色

每次新增一个产品前，我会先问：

它替代了哪类资产？
它解决了组合里的哪个问题？
它会不会让某类风险过度集中？
如果它下跌，我是否知道原因和处理规则？

如果一个产品说不清角色，就不应该进入稳健组合。

让 Agent 帮你读公告、整理持仓和生成复盘

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

AI Agent 可以提高个人理财效率，但前提是边界清楚。

它适合做信息整理、结构化记录、提醒和复盘，不适合直接判断买卖，更不应该自动下单。稳健理财里的 Agent 应该是助手，不是操盘手。

本文是个人学习和工具实践记录，不构成投资建议。

Agent 适合读公告

基金公告和季报信息量大，但结构相对固定。

Agent 可以帮你提取：

基金规模变化。
前十大持仓变化。
债券久期和信用等级变化。
权益仓位是否变化。
基金经理是否更换。
是否出现风格漂移信号。

这些信息不等于买卖建议，但可以进入复盘表。

Agent 适合整理持仓

个人组合最常见的问题，是不知道自己整体暴露了什么风险。

如果把每只基金的类别、金额、目标比例和实际比例记录下来，Agent 可以帮你生成组合视图：

现金和类现金比例。
债券类资产比例。
权益类资产比例。
单一基金占比。
最大偏离类别。
是否触发再平衡阈值。

这类任务适合自动化，因为它有明确输入和明确输出。

Agent 适合生成复盘草稿

复盘草稿可以固定格式：

本月组合变化。
资产比例是否偏离目标。
最大回撤是否在预期内。
是否有公告或持仓变化需要关注。
是否触发再平衡规则。
下个月是否需要人工确认动作。

Agent 可以生成草稿，但最终结论应该由人确认。

权限边界

个人理财 Agent 至少要分成三类权限：

权限	可以做什么
只读	读取公告、表格、持仓记录
建议	生成复盘、提示偏离、列出风险
人工确认	调仓、赎回、买入、修改规则

不要给 Agent 自动交易权限。即使未来工具链支持，也应该保持人工确认。

一个最小工作流

可以从很小的流程开始：

每月导出持仓表。
Agent 读取持仓和目标比例。
Agent 计算偏离并生成复盘草稿。
人工检查公告摘要和异常项。
如果触发再平衡，人工决定是否执行。
把最终动作写回复盘记录。

这个流程不复杂，但能减少漏看和临时起意。

Prompt 模板

一个简单指令可以这样写：

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

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

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

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

第一层：当前上下文

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

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

第二层：任务状态

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

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

第三层：用户偏好

用户偏好影响输出方式。

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

第四层：稳定事实

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

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

第五层：长期知识

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

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

写入规则

每次写入记忆前问：

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

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

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

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

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

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

什么是高风险工具

高风险工具包括：

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

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

执行前必须说明

确认信息至少包括：

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

这让风险显式化。

默认只生成建议

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

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

执行后要记录

执行后记录：

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

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

确认机制不是拖慢系统

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

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

Shell 转义歧义解析：当 LLM 遇上双重解析地狱

Mon, 06 Jul 2026 00:00:00 +0000

你有没有过这种经历：让 Agent 帮你写一段小脚本，生成的内容看起来语法完美，一跑就炸？报错信息通常是一串让你怀疑人生的 &、$、反引号乱码，然后你盯着那几行代码看了十分钟——最后发现，模型把 bash 的反斜杠转义 \" 写在了 PowerShell 命令里。

这个问题我称之为 Shell 转义歧义，在 LLM + 终端自动化这个交叉点上表现得尤其明显。本质是：LLM 生成的是一个扁平字符串，而 shell 执行的是多层嵌套的语义解析，任何一层出了偏差，最终执行的命令就和你预期完全不一样。

一、双重解析：模型以为的 vs shell 实际执行的

LLM 采用自回归方式逐 token 生成，它"以为"自己写的是结构化的命令。但实际上，如果这个字符串被 shell=True（Python subprocess）或者 Invoke-Expression（PowerShell）执行，就等于经历了 两次独立的解析：

第一层：LLM 生成字符串时的"心智解析"——它以为引号配对是对的
第二层：shell 自己再做一次 tokenize / word-splitting

这两层之间没有任何契约式的保证。模型输出一个字符串，shell 拿过去按自己的规则重新分词，然后交给操作系统执行。任何一层的歧义，都会导致最终行为和预期背离。

而且这种错误往往是 延迟发现的：代码写入时没报错，运行时才炸。模型只能"事后诸葛亮"式地不断打补丁修改脚本，一个命令可能要循环三四次才终于跑通。

二、为什么 PowerShell 比 bash 更容易踩坑

Shell 本来就不简单，但 PowerShell 在这个问题上尤其难搞。有几层原因：

1. 转义符混淆 PowerShell 的转义符是反引号 `，不是 \。但模型的训练数据里 bash 语法占绝对多数，它经常无意识地混用 bash 习惯——比如用 \" 来表示引号转义，这在 PowerShell 里会被原样当作普通反斜杠处理，导致完全不同的解析结果。

2. 语义差异大 PowerShell 对 $、@()、&、| 有一套完全不同于 bash 的语义：变量插值、数组字面量、调用操作符、管道。模型很容易犯"语法迁移错误"，把 bash 的逻辑套用到 PowerShell 上。

AI Agent 的 CLI 超能力：组合工具的思维与实践

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

真正的『AI 原生』不是只会调用模型 API，而是学会借 cmdline 能力反过来驾驭模型。—— 来自 QPC 实践笔记

引子：原地踩坑与破局

写 Agent 项目半年，发现两个现象：

生产坑 ——
- 代码库 2k 文件，怎么快速撤离所有第三方 key？
- 日活跃 agent 实例上百，如何一眼看清谁在泄露内存？
- 高频需求：提取出所有对话里的意图标注。
AI 间歇性失能 ——
- 模型擅长创造，不擅长精确执行。
- 一次 agent 调用动辄 50k token，代价高昂。

真正的破局，不是让模型变聪明，而是把操作系统现成的精确能力用起来。

下面展示 10 个实例，每个都是agent项目中频繁踩坑后找到的确定性答案。

工具清单：让你恍然大悟的『不需要Python』场景

命令	干嘛用	代替的 Python 操作	节省 token 效果	AI 友好度	成本效益
`rg`	搜代码 / 搜日志	`open(file)` + `re.findall`	★★★★★	★★★★★	极高
`fd`	搜文件 / 批量处理	`glob.glob` + `os.path`	★★★★☆	★★★★★	极高
`jq`	JSON 解析与过滤	`json.load` + `遍历提取`	★★★★★	★★★★★	极高
`bat`	高亮代码查看	`open`, `syntax highlight` 滚轮	★★★☆☆	★★★★☆	高
`htop`	系统进程监控	`psutil` + 表格输出	★★★★★	★★★★☆	中
`fzf`	模糊搜索交互	无	★★★☆☆	★★★☆☆	中
`awk`	结构化聚合	`pandas` 等价加载	★★★★★	★★★★☆	高
`sed -i`	文件批量编辑	`open()`+写回+临时文件	★★★★★	★★★☆☆	高

✅ AI 友好度 指的是工具的输出格式是否易于 agent 解析。jq 和 rg 的输出最干净，agent 直接接受一行不需要再清洗。

100w 稳健型基金组合 · 执行手册

Fri, 03 Jul 2026 00:00:00 +0000

一、买什么？买多少？

步骤	类别	标的（支付宝搜索）	金额	占比	风险	操作要点
1	货基	天弘余额宝 000198 或南方天天利A 003474	10 万	10%	低	T+0/T+1，随时可取，作为流动性底仓
2	短债	天弘短债债券A 000001（备选博时安鑫短债A 000028）	35 万	35%	低	建议分 2 笔（17.5w + 17.5w），持有期 7 天
3	二级债	易方达稳健收益债券A 000008（备选建信稳定增利A 000011）	15 万	15%	中低	打底债券 + 最多 20% 权益，持有期 ≥7 天
4	红利ETF	中证红利ETF 515080（场内）或 501060（场外联接）	30 万	30%	中	⚠️ 唯一高风险仓位，必须定投建仓，勿一把梭
5	现金/逆回购	继续留在货基 000198；大额临时资金走沪市 R-001	10 万	10%	极低	季末/年末逆回购年化 2-5%，无风险

红利低波 ETF：为什么选它？

中证红利指数 = 高股息 + 低波动，长期年化约 9-11%（历史），远高于沪深300的 7-8%
低波属性：熊市跌幅比宽基小 15-25%，是你组合里的「收益压舱石」
现金流：每年分红约 3-4%，可以直接在支付宝设置「分红再投资」

二、红利ETF 定投日历（2026-08 ~ 2027-01）

6 个月定投，每月一笔，共 6 笔 × 5 万 = 30 万。

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

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 个字段：

VPS 安全加固：从 0 到三层防御实战记录

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

一台裸奔的海外 VPS，跑着 new-api、x-ui、Hermes Agent 三个服务，端口审计发现 3000 + 50404 公网监听——我是怎么一步步把它变成铁桶的。

背景：一台裸奔的 VPS

上个月整理 GCP 免费赠金 VPS，发现上面跑着：

new-api（端口 3000）— AI API 代理网关
x-ui（端口 50404）— 代理面板
Hermes Agent（内部端口）— 个人 AI 助理

三个服务全部 0.0.0.0 绑定，直接暴露在公网。用 nmap 扫了一下自己的 IP：

$ nmap -Pn <my-ip>
PORT STATE SERVICE
3000/tcp open ppp
50404/tcp open unknown

更要命的是，new-api 后台后来审计发现了 7 个陌生 bot 账号，说明已经被扫到了。ROOT_PASSWORD 还是默认的弱密码。

这篇文章记录我从"裸奔"到"三层防御"的完整过程，每一步都是真实踩坑后的总结。

第一层：GCP Firewall — 在流量进主机前挡住

核心思路：在 GCP 层面直接拒绝，流量根本不到你的主机。

GCP Firewall 支持按 instance tag 匹配规则。我先创建了一个 tag secure-server，然后写规则：

# 拒绝所有入站，只允许特定端口
gcloud compute firewall-rules create deny-all-ingress \
 --direction=INGRESS \
 --priority=65534 \
 --network=default \
 --action=DENY \
 --rules=all \
 --target-tags=secure-server \
 --source-ranges=0.0.0.0/0

踩坑：规则创建后测试 nc -zv <ip> 3000，发现还是通的。排查半小时发现——instance 没打 tag。规则存在但没 target，等于没配。

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

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

google-genai SDK 全流程指南：Vertex AI + Gemini API 实战

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

为什么要写这篇？

最近在给 Hermes-lite 接入 Gemini 3.x 模型时，踩了不少 google-genai SDK 的坑——尤其是多轮 tool call 时 thought_signature 丢失导致 400、streaming 模式下 function_call args 是片段、response.text 莫名其妙打 stderr Warning 等问题。

查了一圈官方文档和社区资料，发现这些坑分散在各处，所以整理了一篇一站式指南，把从安装到上线的完整路径、所有踩坑点都写清楚。

一、SDK 概览

包名：google-genai（PyPI）仓库：googleapis/python-genai 当前版本：v2.10.0（2026-06-24） Python：3.9+ License：Apache-2.0

google-genai 统一封装了两条后端：

Gemini Developer API：api_key 认证，适合快速开发
Vertex AI：project + location，gcloud ADC 认证，VPC 上最方便

通过 Client 的一个接口切换，代码几乎零改动。

二、Google Cloud VPS 上全流程配置

2.1 环境准备

# 创建 venv（推荐 Python 3.12+）
python3 -m venv /opt/genai-env
source /opt/genai-env/bin/activate

# 安装 SDK
pip install google-genai

# 验证
python3 -c "from google import genai; print('OK', google.genai.__version__)"

2.2 认证：Vertex AI 模式（gcloud ADC）

VPC 上最方便——Application Default Credentials，无需手动管理密钥。

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 上翻车就是服务宕机。

个人博客框架完全指南：深入解析Hugo、对比Jekyll/Hexo及高效工具链

Sun, 10 May 2026 15:20:28 +0800

什么是静态网站生成器？

在深入探讨具体框架之前，我们首先需要理解什么是“静态网站生成器”（Static Site Generator, SSG）。

传统的动态网站（如 WordPress）在每次用户访问时，都需要后端服务器从数据库查询数据，然后通过模板引擎实时渲染成 HTML 页面返回给用户。这个过程涉及数据库、服务器端语言（如 PHP），相对复杂且速度较慢。

而静态网站则完全不同。它遵循一个简单的哲学：提前生成所有页面。

工作流程如下：

编写内容：你使用简单的 Markdown 格式编写文章。
构建网站：运行一个命令，SSG 会读取你所有的 Markdown 文件、应用你选择的模板主题。
生成成品：最终输出一整个文件夹的、纯粹的 HTML、CSS 和 JavaScript 文件。
部署：你只需要将这个文件夹部署到任何一个可以托管静态文件的地方（如 GitHub Pages、Nginx 服务器、对象存储等），你的网站就上线了。

静态网站的优势显而易见：

极速（Fast）: 用户访问的是预先生成好的 HTML 文件，无需任何服务器端处理，加载速度极快。
安全（Secure）: 没有数据库，没有复杂的后端逻辑，大大减少了被攻击的风险。
简单（Simple）: 部署和迁移都非常方便，只需要复制文件即可。版本控制也极其容易（可以直接用 Git）。
便宜（Cheap）: 托管静态文件的成本极低，甚至有大量免费的平台（如 GitHub Pages, Netlify, Vercel）。

正是因为这些优势，静态博客在全球技术社区中蔚然成风。

主流框架概览：群星璀璨

SSG 领域有很多优秀的选择，每个都有自己的特点和技术栈：

Hugo: 基于 Go 语言，以“快”闻名于世。
Jekyll: 基于 Ruby 语言，是 SSG 的鼻祖，与 GitHub Pages 深度集成。
Hexo: 基于 Node.js，在亚洲尤其流行，插件生态丰富。
Gatsby / Next.js: 基于 React (JavaScript)，功能强大，更像是一个“网站应用”的构建框架，而不仅仅是博客。对于简单的个人博客来说可能有些“杀鸡用牛刀”。

深入Hugo的世界：为何选择它？

在众多框架中，Hugo 脱颖而出，成为越来越多人的首选。它的核心优势可以总结为以下几点：

我的博客自动化发布SOP

Sat, 09 May 2026 04:30:40 +0800

这篇 SOP 记录当前博客的真实发布流程。早期我曾经用过 public 子模块和部署仓库分离的方案，但当前仓库已经改成更简单的方式：Markdown 源码、Hugo 模板和 GitHub Actions workflow 都在 caozuohua.github.io 仓库内，push 到 main 后由 Actions 构建并部署 GitHub Pages。

当前仓库结构

caozuohua.github.io/
├── content/posts/ # Markdown 文章源码
├── layouts/ # 站点模板覆盖
├── themes/ananke/ # Hugo 主题
├── hugo.toml # 站点配置
└── .github/workflows/ # GitHub Pages 部署流程

当前生产地址是 https://caozuohua.github.io/。本地构建产物会生成到 public/，但它只是验证结果，不再作为单独部署仓库提交。

第一阶段：内容创作

新文章统一放在 content/posts/ 下。推荐使用 page bundle 结构：

hugo new content/posts/YYYY-MM-DD-kebab-case-slug/index.md

Front matter 至少包含：

---
title: "文章标题"
date: 2026-06-30
publishDate: 2026-06-30
description: "一句话 SEO 摘要"
tags: ["标签1", "标签2"]
categories: ["分类"]
draft: false
---

写作完成后先做三项检查：

记一次复杂的博客仓库修复过程

Fri, 08 May 2026 15:40:39 +0800

问题起源：一次失败的博客发布

一切始于一个简单的 blog_publish 命令，但它却意外地失败了。以此为起点，我们开始了一次深入的、涉及 DevOps、Git 和 Hugo 多个方面的技术探险。

探险之旅：层层剥茧

第一层：源码与成品的混淆

我最初的诊断发现，本地仓库 /var/www/blog 关联的远程仓库 caozuohua/caozuohua.github.io 存放的并非我们预期的 Markdown 源码，而是 Hugo 构建后的 HTML 静态文件。这是所有问题的根源。

解决方案：我们决定采用“双仓库”策略。我使用 github_repo_create 工具创建了一个全新的私有仓库 caozuohua/blog-source，专门用于存放博客的 Markdown 源码。

第二层：权限的迷宫

当我尝试将本地仓库指向这个新的 blog-source 仓库时，遭遇了 Permission denied 错误。这意味着我（luckclaw 用户）没有操作 /var/www/blog 目录的权限。

解决方案：您作为管理员，果断出手，通过 chown 命令将目录所有权授予了我，为我扫清了障碍。

第三层：消失的 Hugo 与特殊的版本

解决了权限问题后，我们发现系统上根本没有安装 Hugo。而直接安装并不能解决问题，因为您的 Ananke 主题需要一个非常特殊的 Hugo 版本。

解决方案：

您从 PyPI 找到了一个 0.161.1 的特殊版本。
我通过 wget, tar, mv 等一系列 run_shell 操作，成功将这个特殊版本的 Hugo 安装到了我的个人 bin 目录中。

第四层：主题模板的兼容性危机

即便版本正确，构建依然失败。错误指向了主题模板中的语言字段兼容性问题。需要注意：Hugo 版本变化后，languageCode / .Site.LanguageCode 与 locale / .Site.Language.Locale 的推荐方向会变，不能机械照抄旧修复。

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. 工具层

基础工具集：