我把整个微信社交上下文交给了 Agent¶

这不是“做了个微信机器人”，而是把 WeFlow、ilink 和 Agent 大脑真正焊成了一套主动式个人管家系统。

TL;DR¶

我现在这套 WeChat AI Agent，并不是只会回一句“收到”的 bot。它能读取完整的聊天上下文，理解关系和承诺，并主动判断什么时候该提醒你、什么时候该闭嘴、什么时候该直接执行动作。

更重要的是，这一路径已不再是概念演示。消息监听、消息收发与智能体决策的主链路均已实现，接下来的重点是将各项“能力”持续产品化，而非从零开始验证其可行性。

先说结论：这东西为什么强¶

大多数“聊天机器人”方案，本质上仍是一个单线程的记事本。

你向 bot 发送什么，它就记录什么；你不说，它便无从知晓；你不主动汇报，它就无法构建关于你的世界模型。这样的系统可以用来提醒、问答或陪聊，但它理解不了你真实的生活上下文。

而我现在采用的方案，走的是一条完全不同的路径：

输入不是与 bot 的对话，而是微信中的全量聊天记录
理解对象不是单条消息，而是你整体的社交关系
行动方式不是等待指令，而是主动触发

这意味着 Agent 看到的，不再是一个孤立的对话框，而是一个真实的人际网络、连续的时间流以及一套承诺系统。

一句话概括：

并非给微信套上一个 AI 外壳，而是将你的微信社交生活转化为 Agent 可计算、可推理、可执行的输入层。

核心数据流¶

整个主流程可归纳为以下五步：

微信全量聊天进入系统 WeFlow 负责本地解析与监听，获取所有私聊、群聊、历史消息及新增消息。
桥接层将消息路由至 Agent ilink 处理消息收发，桥接层则负责协议转换、事件分发与统一入口管理。
Agent 理解上下文并作出决策 目前可接入 OpenClaw，后续也可切换至 Claude Code、Codex 或进行混合编排。
调度层决定触发时机 定时任务、模式匹配、事件触发、随机唤醒等方式均可组合使用。
输出层将决策发回微信或写入本地系统 支持微信提醒、消息回复、本地看板、时间轴、日报周报等形式。

从工程角度看，该体系的关键并非某个具体模型的选择，而是实现了数据闭环的建立：

微信聊天 → 解析 → 决策 → 触发 → 输出 → 新聊天继续回流

一旦闭环形成，后续所有功能都将基于这一回路进行能力叠加。

六层架构¶

1. 数据采集层¶

这一层解决的核心问题是 “能否获取充分且真实的数据”。

目前已经实现的关键能力包括： - WeFlow 全量消息监听 - ilink 接收消息 - 微信消息的持续接入

后续计划补充： - 为每条消息注入时间戳 - 提取回复延迟、长度、频率等元数据 - 采集更细粒度的会话行为特征

没有这一层，后续的 Agent 再智能，也仅是“空气推理”。

2. 桥接层¶

这一层看似朴实，却 决定了系统能否稳定运行。

其核心职责包括： - 将 WeFlow 的消息转换为 Agent 可处理的统一事件 - 将 Agent 的动作路由回微信发送端 - 处理不同组件之间的协议差异

可继续接入的组件示例： - cc-connect - CLI-WeChat-Bridge - 自定义的 Event Bus

桥接层构建得当，后续更换模型、调度器或前端，都无需伤筋动骨。

3. 智能决策层¶

这是整个系统的 核心枢纽。

当前采用 OpenClaw，但设计上并未锁定单一 Agent 栈。Claude Code、Codex 等均可接入，甚至可实现分工协作的多 Agent 模式。

后续重点强化三个方向： - 承诺提取 自动识别“我答应了你什么”、“我应在何时交付” - 情绪推断 不仅分析文本，还结合回复延迟、长度、频率、表情使用模式 - 上下文感知决策 判断当前是否应当提醒、如何提醒、提醒到何种程度

真正的价值不在于“能回答问题”，而在于“知道何时该沉默，何时必须站出来”。

4. 调度层¶

若缺少调度层，Agent 只能被动响应用户指令。

主动式系统的价值，恰恰源于其触发机制，例如： - 定时任务 - 随机唤醒 - 消息模式匹配 - Agent 自主设置的提醒队列

此层一旦就位，系统便从“工具”演进为“管家”。

5. 存储层¶

要实现长期价值，必须将会话从一次性文本转化为 结构化资产。

此层后续将沉淀的数据包括： - 承诺数据库 - 关系图谱 - 时间轴数据 - 自动生成的日记 - 社交互动统计

WeFlow 本地数据库已提供坚实基础，下一步是将 “可见的聊天记录” 转化为 “可推理的长期记忆”。

6. 输出层¶

最终输出不应只是一条回复消息。

它可以表现为： - 微信提醒 - 自动回复 - 本地前端 Dashboard - 个人生活时间轴 - 日报 / 周报 - 截图式报表推送 - 智能家居联动

当输出层足够丰富时，Agent 便不再是一个聊天窗口，而是你数字生活的“操作台”。

这套系统最猛的 9 个能力¶

1. 承诺追踪器¶

聊天中随口答应的事，往往最容易忘记。
本系统能自动将这类“社交待办”提取为任务，无需等你事后想起。

2. 上下文感知打断¶

它不会随意打扰你，而是先判断你当前状态：是在专注工作，还是已进入闲聊节奏。
这一判断，直接决定了 Agent 表现得像个智能助手，还是无脑的干扰源。

3. 关系衰减预警¶

重要关系很少突然断裂，多是联系频率逐渐降低。
系统能从聊天频次与间隔中察觉这种变化，并主动提醒你维护那些不愿疏远的人。

4. 跨对话信息回溯¶

微信原生搜索在此类场景下往往不太够用。
Agent 支持跨所有对话进行语义回溯，直接帮你找到“谁、在何时、说过什么”。

5. 情绪感知与交互自适应¶

如果你今天明显疲倦、回复慢、语句简短、几乎不用表情，系统便不应机械催促。
此时，它会自动切换至另一套交互策略。

6. 生活轨迹时间轴¶

很多人难以坚持生活记录，不是因为不想，而是嫌麻烦。
如果聊天内容能自动反推你的行动轨迹，时间轴与生活日志便可自动生成。

7. 自动日记系统¶

每晚自动总结当天发生的事、见到的人、情绪波动、以及尚未履行的承诺。
一旦运转起来，其长期价值会非常显著。

8. IoT 联动控制¶

提醒你起床只是初级功能。
真正的联动在于：提醒无效后，Agent 能直接控制窗帘、音乐、灯光等物理环境。

9. 社交日程整合¶

从聊天中自动提取约饭、会议、聚会等安排与临时承诺，进行冲突检测并提前提醒。
这比手动录入日历更贴近真实生活节奏。

为什么这条路线比普通 bot 方案高一个量级¶

已有不少现成方案能够实现“接入微信、发送消息、运行模型”。
但真正的差距，并不在于能否收发消息，而在于数据视野的广度。

能力维度	普通 bot 路线	WeFlow + ilink + Agent 路线
数据来源	仅限与 bot 的对话	全部微信聊天记录
上下文理解	仅知晓你主动告知的内容	了解你的完整社交环境
时间追踪	依赖手动汇报	从聊天行为自动推断
打断策略	随机轮询	基于实时上下文判断
承诺追踪	无法实现	支持自动提取与跟踪
关系管理	无法实现	可构建长期关系图谱
信息检索	只能检索与 bot 的对话	支持跨所有聊天记录搜索
情绪判断	仅基于你发送给 bot 的文本	可结合更丰富的行为元数据进行判断
输出能力	仅支持发送消息	除发送消息外，还可扩展至报表、前端、IoT 等输出形式

正因如此，我认为这并非“又一个微信自动化项目”，而是一条明显更具想象力的个人 Agent 技术路径。

最现实的边界¶

这套方案能力很强，但必须明确其边界。

低风险部分¶

ilink 收发消息
本地 Agent 运行
本地前端与本地存储

以上环节本质上仍属于个人工作流的增强。

中风险部分¶

WeFlow 读取本地微信数据
第三方接口及框架的稳定性

此类风险主要来自技术上的模糊地带以及平台策略的可能变化。

高风险部分¶

将系统开放为公开产品
处理他人聊天数据并提供对外服务
进行商业化部署

一旦走向产品化与商业化，问题就不再仅限于技术层面，而是涉及隐私、合规、平台协议及法律责任。

因此，目前的判断很明确：

自己用，狠狠干；对外做产品，先别在微信上硬刚。

更稳妥的路径是：先在自己的场景中跑通逻辑、验证能力，再将同样的 Agent 决策层迁移至 Telegram、自建 IM 或其他可控环境中。

现在最该补强的，不是“换个模型”¶

做到这一步，许多人会陷入纠结：

选 Claude 还是 Codex？
用 OpenClaw 还是其他 Agent 框架？
要不要引入多 Agent？

这些固然重要，但并非当前阶段的首要任务。

我认为接下来最有价值的三件事是：

将承诺提取固化为稳定模块
让关系衰减与时间轴切实落地
构建一个可供长期审视的本地前端输出层

因为模型随时可更换，真正难以替代的是：

你独有的数据闭环
你的行为结构
你的长期记忆资产

谁能率先完成这三件事，谁就不再是演示原型，而是在打造个人的 Agent 基础设施。

最后¶

这个项目最让我兴奋的，并非“AI 接入了微信”，而是它朝着一个更真实的方向迈进：

Agent 不再只是理解你告诉它的话，
而是开始理解你的人际关系、时间安排、承诺体系，以及你日常生活的惯性。

这才像是一个真正的个人 AI 助手。

它不是聊天玩具，
也不是自动回复脚本，
而是一套有机会长期陪伴你、管理你、提醒你，甚至介入你生活节奏的系统。

这条路，我会继续往下打。

原始来源

本文整理自本地架构稿 /Users/mac/Desktop/Projects/wechat-agent/wechat-agent-architecture.html，改写为站内博客版本。