chore: 更新博客草稿 - 替换为真实learnings案例,移除个人隐私内容
This commit is contained in:
@@ -33,24 +33,6 @@
|
||||
3. 提炼 learnings(学到了什么、踩了什么坑、下一步怎么做)
|
||||
4. 把有价值的经验更新到长期记忆(LanceDB)
|
||||
|
||||
以星辉(我的个人助理agent)为例,复盘后的输出大概长这样:
|
||||
|
||||
```markdown
|
||||
# 2026-04-02 日记
|
||||
|
||||
## 今日状态
|
||||
- 用户主动对话: 0条
|
||||
- 系统/定时任务: 1个
|
||||
|
||||
## 待确认事项(延续)
|
||||
- 任务"给圆圆起一个英文名字"(截止日期4/1)- 需确认是否完成
|
||||
|
||||
## 明日待办
|
||||
- [ ] 确认任务完成状态
|
||||
```
|
||||
|
||||
这种结构化的输出,让任何agent第二天都能快速接手工作,而不是从头摸索"昨天干什么了"。
|
||||
|
||||
---
|
||||
|
||||
## 从AGENTS.md设计一个"懂行"的agent
|
||||
@@ -67,6 +49,74 @@
|
||||
|
||||
---
|
||||
|
||||
## 真实案例:记忆如何改变了agent的行为
|
||||
|
||||
下面从我真实的使用日志里摘几个例子,来看记忆系统到底怎么work的。
|
||||
|
||||
---
|
||||
|
||||
### 案例一:同一个坑踩了两次,但第二次快速修好了
|
||||
|
||||
我给所有agent配置了Telegram通知。创建cron任务时,需要指定 `--to 5038825565`(我的chat ID)。
|
||||
|
||||
第一次,星辉踩坑了:我在delivery配置里用了 `--to user:5038825565`,结果Telegram报错"chat ID must be numeric"。当时我不知道为什么,折腾了一阵才找到原因。
|
||||
|
||||
**如果没有记忆**:一周后我再创建另一个cron任务,大概率会再踩一次同样的坑。
|
||||
|
||||
**有了记忆之后**:我把这个错误记进了LEARNINGS.md,标注了正确写法"用纯数字,不用user:前缀"。一周后我让星辉再建一个cron任务,它直接去记忆里查,一分钟搞定,没有再踩坑。
|
||||
|
||||
这就是"fact层记忆"的作用——**存住事实,下次遇到秒级解决**。
|
||||
|
||||
---
|
||||
|
||||
### 案例二:装了一个工具,但OAuth还没授权完成
|
||||
|
||||
3月27日,星辉安装了 `gog`(Google Workspace CLI)这个技能。装完了我让它去查日历,它说还没授权。
|
||||
|
||||
**如果没有记忆**:下次我让它用gog,它可能再次尝试直接使用,然后再次失败,我再去找解决方法。一来一回好几次。
|
||||
|
||||
**有了记忆之后**:星辉把"gog已安装,OAuth未完成授权"记进了当天的复盘笔记。第二天我让它用gog,它直接说"gog需要先完成OAuth授权,请执行 `gog auth add`"——不需要我重新解释背景。
|
||||
|
||||
这就是"workflow记忆"的作用——**记住当前状态,避免重复确认**。
|
||||
|
||||
---
|
||||
|
||||
### 案例三:所有cron任务加前缀,改了一次,全部生效
|
||||
|
||||
3月26日,我决定给所有cron任务名称加上agent的中文名作为前缀,比如`[星辉]每日复盘`、`[星曜]服务检查`,这样在日历里一眼就能区分是谁的任务。
|
||||
|
||||
手动一个个改太麻烦了。我让星辉去批量更新。
|
||||
|
||||
**如果没有记忆**:下次新建cron任务时,它可能又忘了加前缀,我需要再次提醒。
|
||||
|
||||
**有了记忆之后**:星辉把"cron任务命名规范:加[]中文前缀"记进了LEARNINGS.md。之后所有新建的任务,星辉自动遵循这个规范,不需要我再说一遍。
|
||||
|
||||
这就是"decision层记忆"的作用——**记住决策原则,让规范自动执行**。
|
||||
|
||||
---
|
||||
|
||||
### 案例四:备份脚本跑成功了,但传输到NAS那步忘了
|
||||
|
||||
3月27日,星辉执行每日Obsidian备份。它成功打包了文件,但传输到NAS那步忘了——因为那步是手动执行的,不在脚本里。
|
||||
|
||||
**如果没有记忆**:第二天它继续跑备份,打包继续成功,传输继续忘。周而复始。
|
||||
|
||||
**有了记忆之后**:星辉在复盘里记录了这次执行结果。第二天它跑备份时,主动检查了上一条记录,发现"传输那步容易漏",这次就记住了。
|
||||
|
||||
这就是**每日复盘的价值**——不是记流水账,而是**主动发现流程漏洞并修复**。
|
||||
|
||||
---
|
||||
|
||||
### 案例五:密码存在哪了?
|
||||
|
||||
3月31日,星辉需要用 `gog` 访问Google Calendar。但gog的认证信息存在Macmini的Keychain里,需要先解锁。我把密码存在了记忆里。
|
||||
|
||||
之后任何需要用到这个密码的场景,星辉直接去记忆里查,不再需要我问"那个Keychain密码是什么来着"。
|
||||
|
||||
这就是**长期记忆的作用**——存住那些不常用但重要的信息。
|
||||
|
||||
---
|
||||
|
||||
## 实战技巧:让这套系统真正work
|
||||
|
||||
说几个真正管用的经验:
|
||||
@@ -85,7 +135,7 @@
|
||||
|
||||
用了两个月,我最直接的感受是:**agent真正开始"认识"我了**。
|
||||
|
||||
它知道我默认用163邮箱发邮件、知道我的女儿圆圆有个英文名叫Leo、知道遇到服务器问题先SSH进服务器看看日志而不是慌。它不再每次都问我"你的邮箱是什么",也不再在我提到"那个任务"时一脸茫然。
|
||||
它知道我默认用163邮箱发件、知道遇到服务器问题先SSH进服务器看看日志而不是慌、知道每次创建cron任务要加agent中文名前缀、知道gog需要OAuth授权才能用。它不再每次都问我重复的问题,也不再在我提到"那个任务"时一脸茫然。
|
||||
|
||||
错误率也下来了。以前同一个坑踩两三次是常态,现在agent能从记忆里找到之前的解决方案,第一次就能做对。
|
||||
|
||||
|
||||
Reference in New Issue
Block a user