我在本机做了一套自己用的 agent——一个挂在 QQ 上的 qqbot，和一个跑在 Telegram 上的 personal agent，到现在都还在用。这篇想把它怎么来的、中途踩了什么坑、以及我为什么认为这件事值得做，认真写一遍。
起点
启发来自两处。一是 joye 的站点（joyehuang.me），我第一次看到一个人真的可以有一个属于自己的 agent；二是我常在的那个 QQ 群（831907794）里的日常交流，让我确认这事在我身上是有真实场景的。
于是我想做一个属于自己的 personal agent（下称 pa）和一个 qqbot（下称 qb），并且长期用下去。
我先想清楚的其实不是技术，是动机。我见过自己动手做的 agent，大多数是为了做而做，做完了连自己都不会再打开第二次。所以这次的标准不是”能不能做出来”，而是”我明天还会不会用它”。能被我长期使用、长期推进的 agent，才值得动手。
先做 qqbot
先做的是 qb。选它是因为它最容易实现——挂在 QQ 上，不需要界面，不需要复杂的部署。一开始我其实很懵，不知道从哪下手，真正动手试过才发现，原来这么简单。
qb 最初只有基础问答。后来慢慢加了定时任务：每天在宿舍群里发第二天的课表。这是我第一次把完整的登录信息交给一个 agent——学校某个网址、我的账号、密码。它当然也能查到别的东西，但我只让它针对我个人。
技术上其实没什么花活：agent 本身是 pi 做的，接上 QQ 靠的是 NapCat。NapCat 是基于 NTQQ 的协议端实现，把 QQ 的消息收发包装成标准的 OneBot 接口（WebSocket / HTTP），agent 只要跟这些接口打交道，就等于能收发 QQ 消息。也就是说我不需要去逆向什么 QQ 协议，只需要连上一条已经铺好的线——这件事容易上手，原因就在这里。
再往后我继续完善它，参考了 MaiBot 的做法。它那种自动接话的方式很有意思，像人一样。所以我也给 qb 加了一个娱乐模式，专门用来闲聊。
两个 agent，两种放手程度
qb 面向的是多人，所以它的能力和权限都控得很有限——能回什么、能做什么，都收着。
pa 不一样，它是我要深度使用的那个，交互在 Telegram 上。我会逐渐给它放手：写代码这类任务，让它通过后台调度去连接其他 coding agent（codex、claude code、kimi code……）。最终的效果是，我只面对 pa 给出的最后结果，需要精修的时候再回到 GUI 里。
我也把 pa 和 qb 桥接了起来，两者可以互相通信。qb 在群里，pa 在我电脑上，中间这条线让”在群里发现的问题”能直接变成”电脑上的一次修复”。
有天晚上我躺在床上，发现 bot 的一点 bug，就干脆在 QQ 里传信给 pa 让它修。最后确实是由其他 coding agent 去操作的，但好像还有些 bug，没修好。
这算不上什么惊奇的成果，但是一次奇妙的开始：我第一次在完全离开电脑的状态下，发起并推动了一次开发。
给它一个身份
我也尝试给 pa 更多能力。其中一项是参考 joye 的做法，给 agent 一个邮箱。
说实话，我不太习惯用邮箱，也不太明白邮箱对一个 agent 到底有多大用处。但后来我让 pa 自己去注册一个 GPT 账号，那一刻我确实有点惊叹。整个过程中我要做的只有一件事：过人机验证。剩下的全是它自己完成的。
或许未来，我们会越来越放手让 agent 帮我们做事。
X 上有人发帖说，用 grok bot 把楼下路灯损坏的问题写成邮件发给有关部门，几天后路灯真的修好了。也有一些产品可以连接你的手机使用情况、Gmail、GitHub，成为更了解你的助手。国内也持续在推出 pa 连接其他 app 的生态。
给 agent 一个邮箱、让它自己注册账号，意义其实不在邮箱本身。它开始有了自己的身份，不再只是借用我的账号。这是”放手”的一个前提：没有独立身份的东西，你不敢把事情真正交给它。
另一项能力是操作浏览器。我一开始用的是 browser-use，一个开源方案，pa 靠它去打开网页、点击、填表。昨天晚上（2026-10-19），Windows 上可以用 ego-lite 了：一个同时面向人和 agent 设计的浏览器。pa 接手的不再是单个动作，而是一整串我们的需求。
这两件事放在一行里看：邮箱给了它身份，浏览器给了它手脚。手脚能伸到的地方越多，“放手让 agent 帮我们做事”就越不是一句展望。
构建时的两个技术问题
pa 和 qb 都是基于 pi 构建的 agent。构建过程中有两个问题困住了我。
harness 不必复杂
一开始我在想：我要怎么构建这个 harness？
最后我的总结是一句很朴实的话——不是越复杂越高级就越好，简单实用再调整。我一直认为 agent 这个方向没有所谓最牛的设计，只有符合你自己的设计。这个行业本身也在发展，你在使用中会慢慢有感受，也会慢慢调整。
所以路径就是：能用 → 常用 → 好用。先让它能跑，再让它被频繁使用，最后才是好用。
桥接层：不是错误，而是一种方式
一开始我不太懂桥接层，很多设计就交给 AI 去定。结果就是大量输入不会直接交到模型，而是先进一个写死的程序：关键词、概率匹配，命中就直接返回结果。用久了就会出问题。
它确实能几乎不花 token 就给出输出，但和我们想要的效果相差甚远。同时也会看到，越来越多能力被塞进桥接层：一个 tool 的实现、记忆……
先说明：这不是错误，而是一种方式。问题不在”用代码”，而在”用代码去理解意思”。
桥接层指的是外部消息入口（QQ、Telegram）和模型之间的那一层转发、路由、预处理。它存在的必要性没有争议：鉴权、白名单、限流、格式规范、重试、日志，这些本来就不该让模型来判断——它们要的是确定性，不是理解力。
分界线只有一条：这一步需不需要”听懂”。
- 能不能发、发给谁、这个人是不是白名单里的、这条消息是不是重复的 → 不需要听懂，代码做，快且零成本。
- 他这句话到底想要什么、该调哪个工具、要不要追问 → 需要听懂，交给模型。
而它的典型形态，就是 AI 一开始写出的一堆 slop：输入没有进模型，进的是一个死程序。它一开始特别好用，几乎不花成本就能给结果，但代价随需求增长：写死的匹配盖不住真实用法，换个说法就失效；失败时往往静默，不报错也不追问；最要命的是无法泛化——死程序在猜意思，而猜总会错。这就是”用着用着就出问题”的具体机制。
能力为什么会不断被吸进桥接层？因为入口处最方便：改一行就能加一个功能，不用改提示词，不用重新想上下文。但代价是这些能力脱离了 agent 的视野：模型既不知道自己有它，也无法在需要时组合它，出了问题也没法自己解释和修复。功能在，但不可组合、不可观察。
正确的收拢方向是：桥接层只保留”必须确定”的那部分；具体能力做成模型能看见、能调用、能报错的工具，而不是藏在转发路径上的分叉。
它和别的 agent 有什么区别
可能别人会问：你的 personal agent 和 openclaw、grok bot 这些，区别是什么？
我没有标准答案，甚至我自己也不确定该怎么回答。
我能确定的是：这是一个我会长期使用的产品，一个拥有独属于我的记忆和数据的 agent。比起其他的，我更愿意用我自己的那个。
我也听过另一种说法：pa 是没有必要的。这一点我不认同。我觉得每个人都应该有一个属于自己的 pa——它实现起来并不复杂，而且你会愿意用。
学习上，它是你学 agent 的一个反馈；认知上，它会让你接触到更多的体验与产品。
更具体一点说，区别不在功能，在归属和复利。别家的 agent 每次对话都从零开始理解你；我这个是越用越知道你。半年攒下来的上下文，任何一个新产品都买不到。pa 的价值也不在它今天多强，而在于它在哪些地方错过、现在知道怎么不重蹈覆辙——这种知识只长在自己的日志里。
还有一个我很看重、但很少被提到的角度：自己做出来的东西，你能立刻用，也能直接拿给别人用。这可能是让别人评价你产品最快的方式——不用等发布，不用做推广，身边就有人能用，反馈当天就回来了。而且因为我自己每天都在用，它会被一直维护下去，不是为了发版，而是因为坏了最先难受的是我。这两件事加起来，其实比功能本身更能说明它为什么值得做。
把记忆放到 Notion
后面我又试了一件事：把 Notion 装进 pa，让它把记忆搬了进去。
搬进去的东西很具体：长期使用里攒下来的记忆、它记下的我的 taste、每天的聊天上下文，都写进了 Notion，还会定时去更新、追加。放进去之后，这件事就不只是”躺在本地的某个目录里”了——它在一个平台上：电脑能打开，手机能打开，我随手就能改，pa 随时能读。
另一层好处是共享。做某个项目的时候，pa 和别的 agent 可以读写同一份东西，像在同一个仓库里协作，而不是各自守着自己的一份副本。
真正的意外收获，是看它提炼上去的内容。pa 会定期把这些东西重新提炼后再追加，有时翻到它写的那条还挺有趣——里面确实有我自己看不到的细节。像是旁边多了个旁观者，替我把没留意的东西记了下来。
也有人会问为什么不直接用 Obsidian。这是两种不同的取舍：Obsidian 是本地优先，文件就在自己硬盘上，快、离线可用、数据完全归自己，但跨设备要靠自己搭同步（网盘、Git、同步插件），多端同时改的时候容易打结，agent 要读写也得落在本机文件上。Notion 天生在云端，多端同步、共享、API 都是现成的，代价是依赖网络和第三方，数据和你不在一起。所以这不是谁替代谁，是要看你更在意”东西在自己手里”，还是更在意”哪里都能改、谁都能读”。
还没结束
写到这里，我的结论其实很朴素：做 agent 的门槛已经很低了，低到”能不能做出来”不再是个问题。真正的问题是做出来之后，你还会不会用它。