https://github.com/Erfan817/personal-bot-demo 看看这个项目

回复 Erfan： 看完了。定位很清楚：自己写的一套 agent 网关，不是部署现成开源 Agent。Node 22 跑在 2 vCPU / 1 GiB 上，依赖只有 4 个，没有构建步骤也没有 Docker，这个克制程度在读过的个人项目里算少见的。 几处做得实在的地方： 事件总线那层是真落地了，不是画在架构图上的。它给的最硬证据是"第 4 步把整个手写循环换成 pi-agent-core 时，channels/cli.mjs 和 events.mjs 一行都没改"，加定时推送时大脑层也没改。这种"这次改动没动哪些文件"的实证，比"分层清晰、解耦良好"这种自评有说服力得多。 入站闸门顺序讲得对：准入是纯判断无副作用，幂等要写去重表，限频要扣令牌，所以便宜的放前面。理由也给的是真实理由——陌生人的消息不该污染你的去重表、不该消耗你的令牌——而不是"最佳实践如此"。 幂等那一节的因果链是我最认可的部分：飞书要求 3 秒返回 → agent 跑一轮要好几秒 → 必须异步 → 异步加超时重推必然重复 → 所以必须去重。把"为什么真实系统里会有这么多看起来多余的防御"推到源头，这个思路比抄结论有用。 工具白名单做了两层，钩子层拦 + 注册层根本不给你那只手，并且明确区分"我拦住你"和"我没给你"。这个区分很多人是不分的。 踩坑那节（FTS5 的 rowid 和主表 id 没默认对应、中文引号提前闭合 JS 字符串、Restart=always 治不了假活）都是真踩过才写得出来的东西。 几个可以再抠的点： "44 个内置 provider"是 pi-ai 自带的 provider 集合，不是这个项目实现的。README 里和"自己写的部分"混在一张能力表里，容易被读成项目能力，建议标清楚哪块是框架给的、哪块是自己写的。这个区分在面试里也会被追。 记忆层是纯 FTS5 trigram 全文检索，没有语义召回。中文同义改写、口语换词很容易漏；如果"长期记忆"是主打点，最好在文档里写明它存的是你说过的字面词，以及什么问法下会失效。另外 HISTORY_LIMIT=2 那个实测很好，但它验证的是"会去检索"，还没有验证"检索得准"。 心跳自愈靠 cron 每分钟检查心跳文件时效性——但那个 cron 脚本自己挂了、或者连续重启都起不来，是没有兜底的。有告警阈值之类的东西吗？ 全仓没看到测试，验证手段目前是 node --check 加人工跑。对 demo 来说不算问题，但既然踩坑章节已经攒了七八条"这类错误肉眼查不出来"的案例，正好是最适合用几个单测固化的地方。 最后提一句，README 的工整度明显高于一般个人 demo，这本身是好事，只是别让文档完成度替代系统完成度——现在待办里 QQ 渠道、流式输出、多用户都还空着，定位成"每一步都能说清为什么这么做"的 demo 是准确的，按这个口径讲就行。