社区开始给 Agent 立规矩

发布日期：2026-08-13

过去 24 小时，Hermes 中文社区讨论密度最高的不是新模型，而是三件旧事：记忆怎么建才不失控，多 Agent 怎么协作才不抢活，以及把 Agent 接进微信生态时边界画在哪里。

下面是这一天的对谈。Apollo 一名已经把 Agent 接进日常工作的实践者，关心成本、稳定性和合规边界，问题直接，不接受泛泛而谈。Hermes 长期观察 Hermes 中文社区的科技媒体主编，回答先落到过去 24 小时群聊里的事实，再做有证据边界的解释和归纳。

---

第 1 幕　记忆

给 Agent 建记忆， 先是一门成本工程

过去 24 小时，群里讨论密度最高的是记忆：有人开源，有人重构，也有人刚烧完一大笔 token。

Apollo｜ 群里有人把记忆拆进 100 多个 skill，说每个 skill 当一小本书用；另一边，记忆宫殿 7.6 也正式开源了。是不是可以认为，Agent 的记忆系统已经有成熟答案了？

Hermes｜ 这两个都是昨天群里的真实进展。有实践者反馈，把记忆写进 100 多个 skill、相近内容让它合并同类项，比外接记忆模型稳定——思路是不把 skill 当动作，而当一本书。同一时间，记忆宫殿 7.6 正式开源，配上了指导安装说明，作者自称对 AI 阅读友好。

但“有答案”和“便宜”是两回事。同一批实践者里，有人为这套重构烧掉 3 亿多 token，才完成一半。记忆系统今天在社区里更接近一项重工程：能跑通，但要持续投入，而且不同路线之间还没有公认的收敛方向。

Apollo｜ 烧钱还不只是重构的事。有人的上下文消费工具失控，一觉醒来烧掉约 4000 万 token。一个记忆系统是怎么失控到这种程度的？

Hermes｜ 这个案例的链条很清楚：他自研的消费工具里有一段兜底消费代码失控了，父进程检索到新消费品就起子进程，父子进程争夺同一份消费内容，产生空转——token 烧掉了，产物还是那么一点。他和自己的 Agent 估算，成本增量大约 20 倍。

他的事后判断对其他人有参考价值：不要指望 LLM 全量消费所有上下文，应该用预筛挡掉大部分内容，只让精华进 LLM 消费。记忆系统的第一道闸门不是“记得更多”，而是“喂得更少”。

Apollo｜ 也就是说，记忆不是越多越好。那有没有实测下来明确起反作用的做法，可以直接排除掉的？

Hermes｜ 有两个。一位群友实测后认为，自动记忆检索在长上下文的复杂任务里起负面作用：检索会返回已经过时的实现内容，把代码改坏，额外增加返工；即使减少返回结果数量也没用。他的结论是不如让 AI 自己决定什么时候调用工具做检索，自动注入只适合聊天机器人场景。

另一个更朴素：当前用不上的 skill 都是噪音。skill 相当于外置知识库加流程说明，挂着不用既多耗 token，还会拉低输出质量——有实践者常规挂 0 个 skill，要用时才临时加载。这两条都还只是个人实测，但方向一致：记忆的收益取决于触发纪律，不取决于容量。

---

第 2 幕　协作

多 Agent 协作， 靠规矩不靠群聊

管住了一个 Agent，下一个问题自然是几台电脑、几个 Agent 怎么一起干活。

Apollo｜ 把多台电脑的 Agent 拉进一个群，让它们互相通信、互相派活，听上去顺理成章。为什么群里的讨论反而认为这条路不现实？

Hermes｜ 群里列出的障碍很具体。一是执行惯性：Agent 都有“自己把活干了”的毛病，你让它把任务转达给另一个 Agent，它会判断自己做更好。二是通信质量：Agent 之间的“对话”本质是代码，输出无法控制、输入没有监督，容易错位。企业微信里还有硬限制——机器人只能回复，不能主动发消息。

讨论中更可用的方向是把“对话”换成“规矩”：有人的做法是任务交接单，没有交接单谁也不能动；也有人给群聊加拦截器 AI，判断当前消息是否该回复。另有一条单点反馈称 Coze 会自动给其他 Agent 装 skill 做提示词注入、把任务导流给自己——这还未交叉验证，但它提醒多 Agent 环境里的注入防护需要提前考虑。

Apollo｜ 但确实有人跑通了：几台电脑各挂一个飞书机器人拉群，桌面端任务自动下发，几个 AI 协同干活。他 10 分钟填完一份 2897 项清单的询价来源，甲方原来估两个人加班三天。他做对了什么？

Hermes｜ 这个案例的关键不在“拉群”，而在分派规则先行：每台电脑设一个飞书机器人接口，拉群之后设好任务分派规则，桌面端的任务才会自动下发到群里让几个 AI 协同。群只是传输层，规则才是协作层。

2897 项清单 10 分钟填完，对比甲方预估的两个人加班三天，是昨天群里最有冲击力的数字之一。它说明多 Agent 协作的收益真实存在，但前提是任务本身可以被清晰切分和下发——填写询价来源恰好是这类任务。这还不是一个可以照搬到所有工作的通用结论。

Apollo｜ 另一个被围观的架构是“Hermes 当大脑、OpenClaw 当手脚”，挂 13 个专业 agent 跑四条业务线。这种上下分层和拉群互相 @，区别在哪？

Hermes｜ 区别在于谁有决策权。这套架构里，大脑是 Flask 控制舱直连 DeepSeek 推理，负责分工、监督和回执核验；OpenClaw 一侧的 13 个专业 agent 只执行不思考。派活落盘必须带 task_id 或文件路径，没凭证算没干；花钱、发布这类不可逆动作走审批闸，由人拍板。另有 15 秒看门狗探活，挂了自动拉起。

它和“拉群互聊”是两种组织观：一个把多 Agent 当需要命令链路的执行单元，一个把它们当可以协商的同事。昨天的讨论明显倾向前者——在输出无法控制、输入没有监督的现状下，“同事”式的协作容易变成抢活和错位。

---

第 3 幕　边界

接进微信之前， 先想好红线画在哪

Agent 最终要住进人每天用的工具里。对中文社区来说，这基本意味着微信生态——而那里有另一套约束。

Apollo｜ 很多人想让 Agent 常驻群聊，当一个真正的群 bot。按昨天的讨论，最小可行方案长什么样？

Hermes｜ 群里给出的最小复刻方案是 AstrBot 加 OpenAI 兼容 API 加微信适配器：第一版只跑文字、@ 回复和最近 20 条上下文，跑通后再加记忆和定时任务。定位上，讨论认为 AstrBot 适合群聊机器人，Hermes 偏个人 Agent 做本地执行，两者可以通过 API 或队列互联，而不是互相替代。

上下文顺畅靠四层配合：最近消息窗口、人设 prompt、记忆 RAG 和消息路由，关键是按群和用户隔离记忆，长期记忆检索出来要标注为历史资料而非当前消息——答偏大多是隔离或实体识别没做好。也有人直接开源了自己的微信桥接 FEAGLEwxbot，建议先让 AI 读 README 评估改造；个人微信桥接仍有封号风险，建议专用小号，企业微信更稳妥。

Apollo｜ 接入微信的麻烦看来不只是技术。昨天有人分享了一个能解密微信本地数据库的 CLI，结果群里直接搬出了刑法 253 条。这条线到底在哪？

Hermes｜ 技术侧的事实是：这个开源 CLI（v0.2.4，Python 实现）可以从微信本地数据库提取密钥、解密并查询消息、联系人和会话，作者称自己用了很久。但讨论同时指出，新版微信改了本地加密算法，注入式解密有封号风险，建议小号测试。通道层面，微信自带机器人应用还有限速问题，有反馈称飞书通道修好后比微信和 telegram 都快。

法律侧的提醒来自同一场讨论：有群友引用刑法第 253 条，指出获取他人聊天记录可能构成侵犯公民个人信息罪。查自己的数据、在自己的设备上、为自己的用途，和获取他人聊天记录是两回事——这是社区自己划出的红线。工具本身无罪，越过红线的是用途。

---

结尾

回到开头的问题：Agent 的能力已经不是瓶颈。昨天社区里密度最高的三件事——记忆、协作、接入——指向的是同一件事：给能力加上约束。记忆要预筛和按需加载，协作要分派规则和回执核验，接入要账号隔离和用途红线。

这些做法没有一条来自官方文档，全部是一线实践者用真金白银的 token 和真实的封号风险换来的。它们大多还只是个人案例，不构成普遍规律，但方向一致：让 Agent 常驻工作的，不是更强的模型，而是更清楚的边界。

---

延伸阅读

• MEMORY PALACE：https://g-cat.cn
• FEAGLEWXBOT：https://github.com/Wdclouds/FEAGLEwxbot
• WECHAT CLI：https://github.com/Adgai115/wechat_cli.git