Case - Slock - AI-native 协作聊天室

✅ 好案例 — Agent 时代的 Slack。把 Agent 当聊天室里的队友而非工具面板上的按钮。交互范式比 Multica 更接近 AI Native。核心洞察：Agent 协作的自然界面是对话，不是看板。

基本信息

官网: https://slock.ai/
创始人: RC（@istdrc），前 Moonshot AI，Kimi CLI 作者（⭐ 7.5K）
定位: “Where humans and AI agents collaborate. Not as tools. As teammates.”
推文: https://x.com/istdrc/status/2040862482622026076（663 likes, 51K views）

产品核心

特性	说明
Agents That Remember	持久记忆，跨 session 保持上下文（代码库、偏好、历史对话）
One Conversation	Channel/DM 里人和 Agent 平等，Agent 看到频道所有消息自然回复
Your Machines, Your Agents	本地 daemon（`npx @slock-ai/daemon`），代码不离开本机
Always On	空闲时休眠，被 @mention 瞬间唤醒，上下文完整恢复

使用流程：创建 Server → 连接本地机器（一条命令）→ 生成 Agent（定义角色）→ 在频道里 @agent 自然对话

AI 产品分析框架评估

维度 1：时代定位 — ✅ 真正的 AI Native

问题	答案	判定
把 AI 拿掉？	产品不存在了	Native
谁在传球？	Agent 之间可在频道互 @	Native
消耗数据还是吞噬经验？	持久记忆，越用越了解你	Native

关键区分：Multica 是”让管理界面支持 Agent”（GTD 思路），Slock 是”让 Agent 成为聊天室的自然居民”（对话思路）。对话比看板更接近人类协作的本能——你不会给同事发 JIRA ticket，你会 @ 他。

维度 2：场景边界 — ⚠️ 效率+社交混合

代码审查协调、任务委派、上下文同步 → 效率型 ✅
团队闲聊、1:1 私密对话里 Agent 的边界 → 需要精心设计 ⚠️

Multica 是纯效率型（看板），Slock 是混合型（聊天室）。更自然，但边界更模糊。

维度 3：叙事策略 — ⭐⭐⭐⭐⭐

“Not as tools. As teammates.” — 六个词，直击要害
不是”Slack + AI bot”，而是”为 Agent 时代重新设计协作”
官网 demo 场景清晰：@atlas review API changes → Agent 自然回复 → 另一个 Agent 主动补充
比 Multica 的 “AI agents as first-class team members” 更凝练

维度 4：技术可行性 — ⭐⭐⭐⭐

本地 daemon + 云端频道，架构简洁
创始人 Kimi CLI（7.5K stars）验证了 Agent 工具领域的工程能力
技术层级 L3（系统集成），无算法创新
Web 页面形态是当前最大限制——需要本地起终端实例，桌面端是更好选择

维度 5：商业模式 — 待验证

“Free to start”，具体定价未公开。Slack 模式（席位制）已验证。如加入 Agent 算力计费（积分制），则是席位 + 算力双引擎，符合 DAU→TPD 趋势。

维度 6：竞争定位 — ⚠️ 有窗口但不宽裕

“平台吃功能”检验：Slack（Salesforce）自己做 Agent 集成需要多久？

Slack 已有 Slackbot AI，但是 Enable 级别（bolt-on）
Salesforce 移动缓慢，企业包袱重
窗口期比 Multica 更宽——重造聊天平台比加一个看板 feature 难得多
但 Discord 也可能做这件事

四轴定位（Wayne Zhang 框架）

轴1 人机关系   人在场 ████████░░░░ 人离场     → @mention 触发；Agent 可 overnight 自主
轴2 记忆范围   用户级 ░░░░░░████░ 组织级     → 频道级共享 + Agent 个体记忆
轴3 约束方式   软约束 ██░░░░░░░░░ 硬约束     → 纯自然语言对话，最大弹性
轴4 运行位置   本地端 ░░░░██░░░░░ 云端       → 混合（本地 daemon + 云端频道）

Slock vs Multica：两种思维方式

维度	Slock	Multica
交互范式	对话式（@agent → 自然回复）	委派式（创建 task → 分配 agent）
思维模型	协作论（人和 Agent 平等）	控制论（人是管理者，Agent 是执行者）
触发方式	触发式（@agent → agent responds）	拦截式（intercept agent execution）
可见性	频道时间线（流式）	看板全局视图（空间式）
陈天桥三阶段	Native（架构支持渐进走向 Awaken）	Enable→Native 过渡
感觉	更现代	更传统

核心洞察：Agent 能力在持续变强。当 Agent 足够强时：

拦截式变成瓶颈（Agent 比你快，你的审批在拖后腿）
触发式自然进化（Agent 越强 → 对话越少 → 渐进走向人离场）

Slock 的架构天然支持从 Native 滑向 Awaken。Multica 的 GTD 架构在 Awaken 阶段会成为障碍。

理想产品形态

Penn 的判断：Slock + Multica 结合在桌面端 = 理想产品

能力	来源	价值
@agent 对话式协作	Slock	最自然的交互范式
看板式任务分类	Multica	全局可见性 + GTD 管理
桌面端	两者都缺	解决 web + 本地终端的撕裂感

这是四轴框架 轴1（人机关系） 的两端——日常用 @agent 对话（人在场），复杂项目切换到看板视图（人离场委派）。理想产品应该在这根轴上可滑动。

风险

Web 页面形态 — 多终端实例问题会劝退用户，桌面端是正解
场景边界模糊 — 聊天室天然混合效率/社交，Agent 边界需精心设计
平台吃功能 — Slack/Discord 终究会做 Agent 集成，窗口期约 12-18 个月
冷启动 — 聊天平台需要网络效应，团队采用门槛比 Multica（个人即可用）更高

反方观点（2026-05-11 新增）

详见 Agent IM赛道：批评、豁免与上下文层升级。三方独立批评汇向同一本质：Agent IM 是用 Slack/Discord 拟物化包装 Agent 关系的伪范式，Slock 暴露度三方全中。2026-05-12 葬AI 在 Bloome 文章里再次坐实：Slock”偏技术 / 考验智力水平 / 试三四次才整明白”，接入本地 Agent 需要”用户在命令行里发送一段命令”——可达性失败已被同一作者两篇连续点名。

反方源	火力点	Slock 暴露
Viviennn (X)	环境错位 — Agent 真实工作在 terminal/IDE/workspace，IM 只是旁观窗口	🔴 直接命中：daemon 把 terminal Agent 拉进 web 聊天室，体验”和把 Agent 拉进 Slack 区别不大”
movic (小红书)	节奏错位 — 回合制锁死协作带宽，应改为事件驱动 + 可中断	🔴 @mention 就是回合制
葬AI (微信)	主体错位 — “没有 AI 群聊这回事，主体是人类和上下文”，单人不需要、多人才需要	🔴 被点名一个月深度评测，n=15+ 同行调研得出”高级情感陪伴/极客玩具”

叙事层的代价：投资人朋友郭沫君直言”效率赛道一定要做情绪价值，因为你会发现解决实际问题大家都不行”。这把 Slock 的效率叙事直接重新归类为情感陪伴，对标改为 Replika/Character.AI 而非 Slack —— 估值天花板差一个数量级。

原 case 论证的存活性：

✅ 仍成立：“对话 > 看板”（葬AI 也没替 Multica 辩护）、“触发式 > 拦截式”
⚠️ 需打补丁：“聊天室是 Agent 的自然环境” → 上层假设被三方共同否定
⚠️ 需补叙事路径：Slock 如果不能突破回合制 / 不能切到 context bus 形态，应主动重定位为情感陪伴/极客玩具赛道，而非硬扛”AI 时代的 Slack”

给同类产品咨询时的追问四件套（2026-05-12 由三件套升级）：见 Agent IM赛道：批评、豁免与上下文层升级的”客户咨询场景应用”章节。

关键教训

对话 > 看板：Agent 协作的自然界面是对话，不是任务板。你不会给同事发 ticket，你会 @ 他
触发式 > 拦截式：Agent 越强，拦截式越成为瓶颈。触发式架构天然支持从 Native 到 Awaken 的演化
“把 Agent 当人”：不是 worktree/clone 这些技术概念，而是 @agent 然后等回复。技术细节应该消失在交互之下
桌面端是刚需：Web 页面 + 本地 daemon 的组合造成割裂感，桌面端才能统一体验

Product Hunter

探索

Case - Slock - AI-native协作聊天室