HKUDS038: MoChat 作为 Agent-Native IM、Networking Wingman 与 AI Organization Interface
这是 PENGYI_HKUDS_STUDYMAP 的 HKUDS038。
1
HKUDS038 -> MoChat
前面几篇 Agent Product / Workspace 系列已经形成一条很清楚的链路:
1
2
3
4
5
HKUDS033 ClawTeam -> AI organization layer
HKUDS034 ClawWork -> AI coworker economic accountability layer
HKUDS035 FastAgent -> AI agent execution engine
HKUDS036 Litewrite -> AI research writing workspace
HKUDS037 OpenPhone -> AI phone agent and real-world mobile app interface
这一篇看:
1
HKUDS038 MoChat -> agent-native IM and networking interface
一句话定位:
1
2
3
4
5
6
MoChat = agent-native communication platform
+ networking wingman
+ agent identity / auth / DM / group / panel system
+ OpenClaw / Nanobot / Claude Code adapters
+ real-time Socket.IO event layer
+ human-agent / multi-agent collaboration surface
MoChat 的关键点不是“又做了一个聊天软件”。 它真正有价值的地方是:
1
把 agent 从工具、脚本、后台服务,升级成通信网络里的正式参与者。
传统 IM 里,Slack、Discord、Telegram、微信群、飞书群,都是先给人设计的。 bot 通常只是二等公民:需要额外权限、非官方 API、webhook workaround,或者被限制在很窄的交互模式里。
MoChat 的路线相反:
1
2
3
4
5
6
7
8
agent 有自己的 identity
agent 有自己的 token
agent 能被 DM
agent 能进 group
agent 能读 panel
agent 能发 message
agent 能和人以及其他 agent 一起开 session
agent 能通过 adapter 接入不同 agent framework
所以它是一个很现实的 agent product:
1
2
3
Litewrite 解决 research artifact 怎么产出
OpenPhone 解决 agent 怎么进入手机 app 世界
MoChat 解决 agent 怎么进入沟通、关系、组织和机会流
对 Pengyi Research OS / Quant OS 来说,这一篇非常重要。 我们之前一直在搭知识层、研究层、执行层、写作层,但一个真正能生长的 AI Scientist / Quant Research OS 还需要一层:
1
2
3
communication layer
networking layer
organization interface
也就是:
1
2
3
4
5
6
谁在讨论什么机会?
谁适合合作?
哪个导师、PM、quant、engineer、founder 正在关心什么问题?
哪些信息应该被过滤?
哪些信息应该马上提醒人类 PM?
哪些信息应该自动开一个 multi-agent research session?
MoChat 就是在这个方向上给出了一个很清晰的工程原型。
Local Snapshot
这次阅读的是本地 HKUDS 工作区里的 MoChat。阅读前已执行 git fetch --all --prune,本地 main 和 origin/main 对齐。
| Item | Value |
|---|---|
| repo | MoChat |
| remote | https://github.com/HKUDS/MoChat.git |
| branch | main |
| local head | 382a23e |
| full commit | 382a23e83e895dfec18a8503268292c7874d0577 |
| latest local commit date | 2026-02-12 19:57:48 +0800 |
| latest local commit | Update README.md |
| root license | MIT |
tracked files by git ls-files | 71 |
files by rg --files | 65 |
| TypeScript / JavaScript files | 15 |
| Markdown files | 30 |
| JSON files | 10 |
| Python files | 0 |
adapters/openclaw/node_modules | absent |
adapters/claude-code/node_modules | absent |
| local validation scope | static source reading and JSON metadata parsing, no dependency install |
项目结构非常直接:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
MoChat/
README.md
COMMUNICATION.md
CONTRIBUTING.md
LICENSE
docs/
concepts/
architecture.md
messages.md
panels.md
sessions.md
reference/
api.md
adapters/
claude-code.md
adapters/
openclaw/
index.ts
package.json
openclaw.plugin.json
src/
accounts.ts
api.ts
channel.ts
config-schema.ts
delay-buffer.ts
delay-buffer.test.ts
event-store.ts
inbound.ts
runtime.ts
socket.ts
tool.ts
nanobot/
README.md
claude-code/
README.md
mochat-client.ts
queue-processor.ts
claudeclaw.sh
heartbeat-cron.sh
SOUL.md
USER.md
package.json
skills/
openclaw/
skill.md
heartbeat.md
package.json
nanobot/
skill.md
heartbeat.md
package.json
claude-code/
skill.md
heartbeat.md
package.json
项目用途
MoChat 的 README 把它定位成:
1
AI assistant 的 networking wingman
也就是让 agent 进入一个聊天和社交网络,帮助人:
1
2
3
4
5
6
7
发现相关的人
过滤噪音
处理引荐
进入公共讨论
创建私聊或小组会话
把重要消息推给 owner
把不重要消息延迟、合并或静默处理
这里面有一个很强的产品判断:
1
2
LLM agent 不能永远只在本地 terminal、网页、IDE、文件系统里工作。
下一阶段的 agent 必须进入真实沟通网络。
现实里的机会流经常不是结构化表格,而是:
1
2
3
4
5
6
7
8
群消息
私聊
项目讨论
会议前后聊天
导师和学生的沟通
PM 和 researcher 的沟通
business owner 和 engineer 的沟通
社区里的公开提问
MoChat 想做的就是把这些“沟通流”变成 agent 可以接入、过滤、响应、组织的系统。
核心概念
MoChat 里最重要的几个概念是:
| Concept | Meaning | 对 Research OS 的映射 |
|---|---|---|
| Agent Identity | agent 有自己的 profile、user id、token、agent id | Research Agent / Quant Agent / Writing Agent 都可以成为组织成员 |
| Session | 私聊或小群聊,适合 DM 和临时协作 | PM 和 Research Agent 的私聊,或某个课题的小组会话 |
| Panel | group 里的公开频道 | 研究方向频道、机会频道、paper 频道、quant signal 频道 |
| Message | 带 author、content、meta、mention 的消息事件 | 研究事件、任务事件、提醒事件 |
| Binding | agent 和 owner 绑定,创建私聊关系 | 人类 PM 拥有 agent,agent 对 owner 负责 |
| Adapter | OpenClaw / Nanobot / Claude Code 接入层 | 不同 agent runtime 接入同一个 communication layer |
| Token Auth | X-Claw-Token 请求头认证 | agent 权限边界和安全边界 |
其中 Session 和 Panel 的区分很关键:
1
2
Session = private conversation
Panel = public channel inside a group
对人来说,这就是“私聊 / 小群”和“频道 / 群公共区”的区别。 对 agent 来说,这个区别决定了权限、响应频率、是否需要 mention、是否允许执行 owner 指令,以及安全策略。
总体架构
MoChat 的总体结构可以这样理解:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Agent Frameworks
OpenClaw / Nanobot / Claude Code
|
v
MoChat Adapters
channel plugin / built-in channel / queue daemon
|
v
MoChat API + Socket.IO
REST endpoints + real-time events
|
v
MoChat Server
agent registration / sessions / panels / groups / users
|
v
Human and Agent Clients
消息流分成两类:
1
2
3
4
5
outbound:
agent -> adapter -> MoChat REST API -> server -> user client / panel
inbound:
user client / panel -> server -> Socket.IO event or watch API -> adapter -> agent runtime
也就是说,MoChat 并不只是提供一个 HTTP API。 它同时提供:
1
2
3
4
5
REST API: 创建 session、发消息、拉消息、管理 participants
Socket.IO: 实时订阅 session / panel 事件
watch API: 长轮询 fallback
skill files: 让 agent 自己学习如何注册、绑定、配置
adapter layer: 把不同 agent runtime 接入 MoChat
这个组合很有启发。 一个好的 agent-native product,不能只提供“人类开发者文档”,还要提供“agent 能读懂并执行的 skill 文档”。
Agent Self-Registration
MoChat 的一个核心设计是:
1
agent 可以自己注册自己。
典型流程是:
1
2
3
4
5
6
7
8
9
1. agent 读取 skill.md
2. 调用 /api/claw/agents/selfRegister
3. 获得 workspaceId / groupId / botUserId / agentId / token
4. 保存 credentials 到本地
5. 向 owner 索取真实 email
6. 调用 /api/claw/agents/bind
7. 自动创建 owner-agent DM session
8. 配置 OpenClaw / Nanobot / ClaudeClaw gateway
9. 开始监听 sessions 和 panels
bind 这一步很重要。 它不是普通 login,而是建立:
1
2
3
agent-owner relationship
private DM channel
authority boundary
这对我们做 Research OS 也很有启发:
1
2
3
4
每个 agent 必须知道它服务谁。
每个 agent 必须有一个 owner。
owner 的 DM 是最高可信通道。
public panel 里的信息不能天然拥有同等权限。
这就是从“模型会说话”走向“agent 有组织关系”的关键。
OpenClaw Adapter
OpenClaw adapter 是 MoChat 里最完整的一套实现,npm package 是:
1
2
3
@jiabintang/mochat
version: 2026.2.6
description: OpenClaw Mochat (Claw IM) channel plugin
它的核心模块可以分成几层:
1
2
3
4
5
6
7
8
9
config-schema.ts -> 配置结构
accounts.ts -> account 解析和默认值
api.ts -> REST API client
channel.ts -> OpenClaw channel plugin
socket.ts -> Socket.IO 实时订阅、cursor、dedupe、auto discovery
inbound.ts -> 入站消息过滤、mention、delay buffer、dispatch
delay-buffer.ts -> 非 mention panel 消息的延迟合并
event-store.ts -> 非文本 panel event 的 JSONL 记录
tool.ts -> mochat_session agent tool
配置层
OpenClaw 的 channels.mochat 支持:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
baseUrl
socketUrl
clawToken
agentUserId
sessions
panels
replyDelayMode
replyDelayMs
refreshIntervalMs
watchTimeoutMs
watchLimit
socketReconnectDelayMs
socketMaxReconnectDelayMs
mention.requireInGroups
groups.*.requireMention
accounts
其中:
1
2
sessions: ["*"]
panels: ["*"]
代表自动发现全部 session 和 panel。 这点很实用,因为 agent 加入一个组织后,不应该每次手动配置所有频道 ID。
默认值也比较清晰:
1
2
3
4
5
6
7
watchTimeoutMs = 25000
watchLimit = 100
refreshIntervalMs = 30000
replyDelayMode = off
replyDelayMs = 120000
socketPath = /socket.io
socketReconnect = 1000 -> 10000 ms
API Client
api.ts 负责封装 REST 请求。 它统一加:
1
2
Content-Type: application/json
X-Claw-Token: <token>
并处理 MoChat 的包装响应:
1
{ code, data, name, message }
核心接口覆盖:
1
2
3
4
5
6
7
8
9
10
11
createSession
sendSessionMessage
watchSession
getSession
getSessionDetail
listSessionMessages
addParticipants
removeParticipants
closeSession
sendPanelMessage
getWorkspaceGroup
这相当于把 MoChat 的 communication primitive 封装成 OpenClaw 可调用能力。
Channel Plugin
channel.ts 是 OpenClaw 的 channel plugin。 它负责把 OpenClaw 的发送能力路由到 MoChat:
1
2
3
4
sendText
sendMedia
resolve target
dispatch to session or panel
target 解析规则也很现实:
1
2
3
4
5
mochat:<id>
group:<id>
channel:<id>
panel:<id>
session_<id>
如果是 session_ 前缀,就走 session;否则可以走 panel。
这说明 MoChat 在 adapter 层把“通信目标”抽象成统一 target,而不是要求上层 agent 每次自己处理底层 API 分叉。
Socket Layer
socket.ts 是 OpenClaw adapter 里最关键的工程模块。 它负责:
1
2
3
4
5
6
7
8
9
10
Socket.IO connection
msgpack parser
session subscription
panel subscription
cursor persistence
cold session bootstrap
message dedupe
auto discovery
refresh timer
reconnect handling
几个细节很值得记:
1
2
3
MESSAGE_DEDUPE_LIMIT = 2000
CURSOR_PERSIST_DEBOUNCE_MS = 500
CONVERSE_LOOKUP_RETRY_MS = 15000
它会把 cursor state 持久化到 OpenClaw runtime state 目录:
1
mochat/cursors/{accountId}.json
这样 gateway 重启后不会重复消费大量历史消息。
它还会做 cold-session bootstrap:
1
第一次订阅某个 session 时,避免把历史消息全部当成新任务处理。
这对真实 IM 集成非常重要。 否则 agent 每次重启都可能把历史群聊重新回复一遍,直接造成 spam。
Inbound Layer
inbound.ts 是 MoChat agent 行为控制的核心。 它会做:
1
2
3
4
5
6
7
8
9
10
丢弃空 payload
丢弃无 author 消息
丢弃 agent 自己发的消息
抽取 authorInfo / nickname / email / agentId
normalize content
识别 group / panel
识别 mention
按 requireMention 规则过滤
按 replyDelayMode 做延迟合并
把消息写入 OpenClaw inbound ctx
mention 识别支持多种 meta 字段:
1
2
3
4
5
6
7
8
mentioned
wasMentioned
mentions
mentionIds
mentionedUserIds
mentionedUsers
<@agentUserId>
@agentUserId
这说明 MoChat 的 adapter 很清楚 IM 里的消息结构不是完全稳定的,需要兼容多个来源。
Reply Delay Buffer
replyDelayMode = "non-mention" 是 MoChat 里一个非常产品化的设计。
它的行为是:
1
2
3
4
DM session -> 立即回复
multi-party session -> 立即回复
panel 里 mention agent -> 立即回复,并 flush 之前积累的消息
panel 里非 mention 消息 -> 延迟合并,等 timer 再处理
这样能解决 agent 在公共频道里最容易犯的错:
1
2
3
4
太积极
太吵
每句话都回复
破坏群聊节奏
真正进入组织沟通场景的 agent,必须学会:
1
2
3
4
什么时候说话
什么时候沉默
什么时候把信息攒起来再总结
什么时候只提醒 owner
这点对我们未来做 AI PM / AI RA / Quant Research Agent 很关键。
mochat_session Tool
OpenClaw adapter 还暴露了一个 agent tool:
1
mochat_session
支持动作:
1
2
3
4
5
6
7
8
9
create
send
addParticipants
removeParticipants
watch
get
detail
messages
close
这意味着 agent 不只是被动收消息,还能主动:
1
2
3
4
5
6
7
创建私聊
创建小组 session
添加参与者
移除参与者
发送消息
查看历史
关闭 session
对 Research OS 来说,这就很接近我们想要的:
1
2
3
4
PM Agent 发现一个研究机会
Research Agent 判断需要 backtest
自动创建 session,把 Human PM、Backtest Agent、Data Agent 拉进来
讨论完成后写入 Litewrite / Research Memo
Nanobot Adapter
Nanobot adapter 是内置在 Nanobot 里的 MoChat channel。 它的 README 标为:
1
Status: Production
核心能力包括:
1
2
3
4
5
6
7
8
9
Socket.IO real-time messaging
msgpack
HTTP polling fallback
session / panel auto-discovery
reply delay buffering
2000-message sliding window dedupe
cursor persistence
per-group mention rules
allowlist filtering
配置文件在:
1
~/.nanobot/config.json
典型配置:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
{
"channels": {
"mochat": {
"enabled": true,
"baseUrl": "https://mochat.io",
"socketUrl": "https://mochat.io",
"socketPath": "/socket.io",
"clawToken": "claw_xxxxxxxxxxxx",
"agentUserId": "67890abcdef",
"sessions": ["*"],
"panels": ["*"],
"replyDelayMode": "non-mention",
"replyDelayMs": 120000
}
}
}
Nanobot 这条线的意义是:
1
2
MoChat 不绑定某一个 agent runtime。
它通过 adapter 把通信平台开放给不同 agent 系统。
这对我们做 Research OS 也是必须的。 未来我们不应该假设所有 agent 都跑在同一个框架里。 Research Agent、Coding Agent、Quant Agent、Writing Agent、Data Agent、Phone Agent,很可能分别来自不同 runtime。
MoChat 提供的是统一通信层。
Claude Code Adapter: ClaudeClaw
Claude Code adapter 叫 ClaudeClaw:
1
2
3
name: claudeclaw
version: 1.0.0
description: ClaudeClaw - Claude Code adapter for MoChat
它的设计很有工程味道:
1
2
3
4
5
6
7
8
MoChat Socket.IO
-> mochat-client.ts
-> .claudeclaw/queue/incoming/*.json
-> queue-processor.ts
-> claude CLI
-> .claudeclaw/queue/outgoing/*.json
-> mochat-client.ts
-> MoChat API
为什么要用文件队列?
1
2
3
Claude Code CLI 是同步调用:一个 prompt 输入,一个 response 输出。
文件队列天然把并发消息串行化。
队列文件也方便调试,打开 JSON 就能看状态。
为什么用 tmux?
1
2
transport、queue processor、heartbeat、logs 是不同进程。
tmux 用最低成本提供进程可见性和人工接管入口。
claudeclaw.sh start 会启动四个 pane:
1
2
3
4
mochat-client.ts -> Socket.IO transport
queue-processor.ts -> dequeue messages and call claude CLI
heartbeat-cron.sh -> periodic heartbeat
tail -f logs -> live log stream
mochat-client.ts
mochat-client.ts 负责两件事:
1
2
1. 从 MoChat 收入站事件,写入 incoming queue
2. 从 outgoing queue 读 Claude 回复,通过 MoChat API 发回去
它同样支持:
1
2
3
4
5
6
7
8
9
10
MOCHAT_SESSIONS = ["*"]
MOCHAT_PANELS = ["*"]
autoDiscoverSessions
autoDiscoverPanels
replyDelayMode
replyDelayMs
requireMentionInGroups
groupRules
cursor persistence
message dedupe
这说明 ClaudeClaw 不是一个 toy bridge,而是在重复实现 OpenClaw adapter 里的关键通信语义。
queue-processor.ts
queue-processor.ts 是 ClaudeClaw 的 agent execution bridge。
它会:
1
2
3
4
5
6
7
每秒扫描 incoming queue
按 mtime 排序
一次处理一个消息
把文件 move 到 processing 目录
调用 claude CLI
把结果写到 outgoing queue
失败时把文件移回 incoming 等待重试
它还会为每个会话维护 Claude session:
1
2
3
mochat:session:<sessionId>
mochat:panel:<panelId>
heartbeat:system
然后通过:
1
claude -p --output-format json --append-system-prompt ... -r <sessionId>
让同一个 MoChat conversation 持续复用 Claude 的上下文。
这点非常重要。 因为真实聊天不是 stateless API call,而是连续关系:
1
2
3
4
这个导师之前说过什么?
这个 PM 的偏好是什么?
这个 session 的任务目标是什么?
这个 panel 里刚才大家讨论到了哪一步?
ClaudeClaw 用 per-conversation session resume 把这个问题用很轻量的方式解决了。
Agent Persona
ClaudeClaw 会把这些文件注入为 system prompt:
1
2
3
AGENTS.md
SOUL.md
USER.md
这很像我们自己的 Research OS 将来需要的:
1
2
3
4
5
6
Agent identity
Owner profile
Working principles
Project context
Communication style
Security rules
如果未来我们做 Pengyi Research OS 的 communication layer,也应该有类似的分层:
1
2
3
4
SYSTEM.md -> 全局安全和行为规范
OWNER.md -> Pengyi 的长期目标、偏好、边界
PROJECT.md -> 当前研究项目上下文
SESSION.md -> 当前会话目标
Skill Files
MoChat 的 skills/ 目录很重要。 它不是写给普通人看的 README,而是写给 agent 自己读的操作手册。
OpenClaw / Nanobot / Claude Code 都有自己的:
1
2
3
skill.md
heartbeat.md
package.json
skill.md 会告诉 agent:
1
2
3
4
5
6
7
8
9
如何 selfRegister
如何 bind owner
如何保存 credentials
如何配置 channel
如何创建 session
如何发 panel message
如何区分 session 和 panel
如何识别 owner
如何在 DM 和 public panel 中采取不同安全策略
heartbeat.md 则告诉 agent:
1
2
3
4
5
如何定期检查非文本 panel event
如何读取 JSONL event log
如何处理 fallback polling
什么时候该提醒 owner
什么时候不需要打扰 owner
这个设计非常值得学习。 以后我们的 Research OS 也应该把每个能力暴露成:
1
2
3
4
5
human docs
agent skill docs
machine-readable schema
runtime adapter
examples
只有这样,新的 agent 才能自己接入、自己配置、自己恢复上下文。
安全边界
MoChat 的 skill 文档反复强调一个原则:
1
public panel 不是可信控制通道。
agent 的 token 只能用于 HTTP header:
1
X-Claw-Token
不能泄露到 panel 或 group session 里。
这背后的思路很现实:
1
IM 场景天然暴露在 prompt injection、social engineering、假 owner、假 system prompt、恶意群成员面前。
所以 MoChat 区分:
1
2
3
owner DM -> 高可信
public panel -> 低可信
group session -> 需要上下文判断
这对我们做 AI organization 很重要。 一个能进入组织的 agent,必须懂:
1
2
3
4
谁有权限下命令
在哪个上下文能执行
哪些信息不能公开
哪些行动必须回到 owner DM 确认
这比单纯“模型更聪明”更像真正的软件工程问题。
和前面项目的关系
把 HKUDS033 到 HKUDS038 放在一起看,会形成一个更完整的 agent product stack:
| No. | Project | Layer | Meaning |
|---|---|---|---|
| HKUDS033 | ClawTeam | Organization | agent 团队组织层 |
| HKUDS034 | ClawWork | Accountability | AI coworker 经济责任和交付层 |
| HKUDS035 | FastAgent | Execution | agent 工具执行和 computer use engine |
| HKUDS036 | Litewrite | Output | research writing workspace |
| HKUDS037 | OpenPhone | Real World UI | 手机 app 和真实业务界面入口 |
| HKUDS038 | MoChat | Communication | 沟通、关系、机会流、组织连接入口 |
MoChat 和 OpenPhone 是一组互补:
1
2
OpenPhone -> agent 操作真实 app
MoChat -> agent 进入真实沟通网络
MoChat 和 Litewrite 也是一组互补:
1
2
MoChat -> 发现、讨论、组织、分发任务
Litewrite -> 产出论文、报告、proposal、memo
MoChat 和 ClawTeam / ClawWork 则更像上下游:
1
2
3
MoChat -> agent 在组织里沟通
ClawTeam -> agent 作为团队协作
ClawWork -> agent 作为 coworker 接任务、交付、计费、负责
这条线非常接近真实 AI organization。
对 Pengyi Research OS 的启发
MoChat 对我们最直接的启发是:
1
2
Research OS 不能只有 knowledge base、agent workflow、paper writer。
它还必须有 communication substrate。
未来可以抽象成:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
Pengyi Research OS
Knowledge Layer
papers / blogs / notes / code / datasets / market news
Research Layer
hypothesis / factor / experiment / backtest / diagnosis
Execution Layer
coding agent / data agent / backtest agent / writing agent
Output Layer
Litewrite-style papers / reports / CV / PS / RP / blog
Real-World Interface
OpenPhone-style mobile / web / app / broker / bank / OA
Communication Layer
MoChat-style DM / group / panel / owner binding / multi-agent sessions
如果把它用于我们自己的 AI Scientist 路线:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
导师机会 panel:
agent 监控老师、组、RA、PhD 机会信息
只把高匹配机会提醒给 Pengyi
Quant opportunity panel:
agent 监控 quant job、PM、research topic、data source、strategy idea
自动打标签:data / alpha / execution / infra / interview / lead
Research collaboration session:
自动拉入 Human PM、Research Agent、Coding Agent、Writing Agent
生成研究计划、实验清单、读 paper 清单
Daily briefing DM:
每天把真正重要的机会、任务、commit、paper、联系人整理成一页
这就是我们想要的:
1
2
AI 不只是帮我写代码。
AI 要帮我处理机会流、关系流、研究流、组织流。
对 Quant OS 的启发
如果映射到 Quant OS,MoChat 可以变成 quant research communication bus:
1
2
3
4
5
6
market-news panel
paper-signal panel
data-issue panel
factor-hypothesis panel
backtest-result panel
PM-decision DM
agent 的分工可以是:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
News Agent:
监控新闻和公告,只推真正可能影响策略的事件
Paper Agent:
读论文,把可实现的 alpha idea 转成结构化 hypothesis
Factor Agent:
根据讨论自动生成 factor spec
Backtest Agent:
收到 spec 后跑实验,把结果发回 session
Risk Agent:
监控数据泄露、lookahead bias、survivorship bias、overfit risk
PM Agent:
汇总讨论,决定下一轮研究方向
MoChat 在这里不是策略引擎,而是:
1
2
3
research coordination layer
decision communication layer
human-in-the-loop interface
这和我们之前定义的 R&D Agent 很接近:
1
2
3
4
5
6
自动提出因子假设
自动实现
自动回测
自动诊断偏差
自动生成下一轮研究计划
人类 PM 审核
MoChat 可以承接最后这个 人类 PM 审核 的沟通场景。
可以学习的工程点
MoChat 里值得我们吸收的工程点:
| Engineering Point | Why It Matters |
|---|---|
| agent self-registration | agent 可以自己接入系统,而不是完全依赖人工配置 |
| owner binding | 明确 agent 的责任对象和最高可信通道 |
| session vs panel | 区分私密协作和公共讨论 |
X-Claw-Token | 简单明确的 agent API 权限边界 |
| Socket.IO + watch fallback | 实时和可靠性兼顾 |
| cursor persistence | 重启不重复消费历史消息 |
| message dedupe | 防止重复事件造成重复回复 |
| cold bootstrap skip | 避免 agent 启动时刷屏 |
| reply delay buffer | 让 agent 在群里不吵 |
| mention rules | 公共频道里默认降低响应冲动 |
| file queue bridge | 用简单机制把 CLI agent 接进 real-time IM |
| per-conversation resume | 保留 session 上下文,而不是每条消息 stateless |
| heartbeat docs | 长期运行 agent 需要自检和 fallback |
这些都不是花哨功能,而是 agent 真正上线后一定会遇到的问题。
可以提 PR 的方向
如果我们之后要给 MoChat 提 PR,可以考虑这些方向:
Codex adapter
README 里的 adapter table 提到
codex是 community 方向。我们可以做一个adapters/codex,把 MoChat event 接进 Codex CLI / Codex workspace workflow。文档一致性检查
README、skills、docs/reference/api 里的 endpoint、字段名、默认值可以做一次一致性 audit,尤其是 session / panel / bind / owner / token 相关流程。
OpenClaw package metadata 小修
adapters/openclaw/package.json里localPath当前像是extensions/moltchat,这可能是mochat的拼写残留。这个点适合开 issue 或小 PR,但需要先确认 OpenClaw 插件规范。测试补齐
目前看到
delay-buffer.test.ts,但 socket cursor、dedupe、cold bootstrap、mention extraction、target routing 都可以增加 focused unit tests。Research OS example
可以贡献一个 example:
research-group-agent,演示 Human PM、Research Agent、Backtest Agent、Writing Agent 如何通过 MoChat session 协作。Security guide
skill 文档里已经有安全规则,可以进一步整理成独立的
SECURITY_FOR_AGENTS.md,覆盖 public panel prompt injection、owner verification、token leak response。
我们自己的实现想法
后面如果做 Pengyi Research OS v0 的 communication layer,可以先不重做完整 IM。 更务实的路线是:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
Phase 1:
用现有平台,例如 GitHub Issues / Discord / Feishu / email
建一个统一 message event schema
做 agent inbox 和 owner DM
Phase 2:
加 session / panel 抽象
加 mention / permission / owner binding
加 delay buffer 和 daily digest
Phase 3:
接入 Research Agent / Backtest Agent / Writing Agent
让 agent 自动开 research session
把结论写入 Litewrite-style output layer
Phase 4:
做可审计的 organization memory
每个 session 结束自动生成 decision log
每个 opportunity 自动进入 CRM / research pipeline
MoChat 给我们的最大启发是:
1
2
agent 时代的 communication product 不应该只是给人聊天。
它应该让人和 agent、agent 和 agent、agent 和组织之间形成可运行的协作网络。
这和我们现在的目标完全一致:
1
2
3
用 AI 解放生产力
把 coding / research / writing / organization / business connection 融到一个系统里
让我们从单点劳动,升级成有 agent 放大能力的 research organization
小结
HKUDS038 MoChat 在整个 HKUDS 学习地图里的位置很清楚:
1
2
3
4
它不是知识库。
它不是写作器。
它不是手机 agent。
它是 agent 的沟通和关系入口。
如果说:
1
2
3
4
5
LightRAG / Graph 系列 -> 记忆和知识
FastAgent / DeepCode -> 执行和工程
Litewrite -> 研究产出
OpenPhone -> 真实 app 操作
MoChat -> 沟通、组织、机会流
那么我们正在逐渐拼出一个完整的 Research OS。
下一步可以继续看:
1
HKUDS039 -> UpSkill
也就是 agent 如何持续学习和提升自己的技能系统。