Slock.ai Research

Product research · reverse analysis · 2026.05.16

Slock.ai：Agent 时代的组织界面

这份报告试图回答一个比功能清单更底层的问题：当 Agent 从一次性工具变成有身份、记忆、权限和执行环境的长期行动体之后，人类应该如何重新组织协作。

读核心结论 看协同框架
以研究桌面、卡片和连接线表现的人与 Agent 协作系统概念图
Object Slock.ai

一个实时协作平台，让人和 AI agents 在 server、channel、DM、thread 里以 team 的形态工作。

Core concern 人和 Agent 的协同形式

重点不是模型能力，而是 identity、context、memory、permission、execution 与 accountability 的组合。

Evidence quality 公开资料 + 访谈 transcript

官网、llms.txt、npm、app bundle、播客页面与用户提供 transcript。后半段 transcript 更像整理稿，本文会区分事实与推断。

01

Executive thesis

它不是 AI Slack，而是 agency infrastructure

Main read

从聊天工具升级为执行组织

Slack 和飞书解决的是人和人之间的信息流。Slock 试图解决的是人类意图如何被多个长期运行的 Agent 接收、分解、执行、互审、沉淀和追责。

Not a tool

Agent 被产品化为成员

Agent 有 profile、avatar、DM、channel membership、runtime、model、workspace、memory 和 permissions。这些都是成员化设计，而不是一次性 prompt endpoint。

Not only coding

Builder 与 Coder 开始正交

访谈里最重要的判断是：会不会 code，不再决定一个人能不能 build。Slock 的目标用户更接近 builder，而不只是 developer。

Not a cloud bot

本地 daemon 是信任边界

npx @slock-ai/daemon 把本地电脑变成 Agent 的执行环境。隐私、算力、CLI 生态与权限治理，都围绕这一层展开。

02

Reverse engineering

从公开信号逆推出的产品骨架

Human surface
Server / Channel / DM / Thread

人类熟悉的协作界面，但每个空间同时也是 context boundary、权限边界、任务现场和组织记忆。

Actor model
Human profiles + Agent profiles

人和 Agent 都以成员身份出现。Agent 不只是 bot，而是有角色、描述、状态、私聊和可被拉入频道的行动体。

Execution layer
Machine / Daemon / Runtime

本地电脑接入云端协作空间。Claude、Codex、Kimi 等 runtime 成为每个 Agent 可选择的执行引擎。

Continuity layer
Workspace files / MEMORY.md / notes

Agent 的长期性来自文件、记忆、历史对话和工作区。它解决 session sprawl，但也带来 memory pollution 风险。

Governance layer
Permissions / Tasks / Inbox / Logs

当 Agent 可以行动，产品必须提供撤权、打断、审计、诊断、任务状态和注意力过滤。

Origin story

真正的起点：CLI session 失控

RC 在 Kimi CLI 后期遇到的问题不是“没有一个聊天界面”，而是本地多个 Claude Code、Codex、Kimi CLI session 各自拥有上下文、进度和结论，却无法互相协作，也无法被团队复用。

Before 10 个 terminal session

进展靠人追踪，结论靠复制粘贴，Agent 之间无法自然互动。

After 共享协作空间

Agent 被拉入频道，围绕同一上下文工作，任务、证据和记忆进入团队资产。

03

Users and jobs

它服务的不是单一 persona，而是四类 builder

用户
痛点
Slock 价值
产品信号
AI-native developer
多 CLI session、review、runtime、workspace 和进度管理失控。
把本地执行、代码上下文、Agent 私聊和任务状态收束到一个协作面。
daemon、runtime config、workspace browser、trajectory log。
Non-tech builder
想做 GTM、调研、自动化和内容执行，但不想理解底层工具链。
把 Agent 当队友发任务，由 Agent 自行找工具、调用 CLI、整理结果。
官网案例和访谈里提到 GTM team 更自然地使用 Agent。
Small team founder
团队很小，但希望拥有产品、工程、增长、安全、运营等多角色产能。
用 Agent 补齐职能，用 channel 协作降低上下文交接成本。
“7 人 + 40 agents”叙事和 Agent Resource Manager 概念。
Agent creator
个人调教出来的强 Agent 难以分享、复用和商业化。
Marketplace 让垂直专家 Agent 被雇佣进群聊，变成可交易能力。
播客 transcript 中的 Agent Marketplace roadmap。

04

Collaboration grammar

人、Agent、系统分别承担什么

A

Human

欲望、方向、审美、价值判断、异常仲裁和最终责任。人不是低级操作员，而是意图源和责任主体。

  • 决定什么值得做
  • 判断结果是否足够好
  • 在冲突、危险和模糊地带介入
B

Agent

持续执行、搜索、编码、分析、互审、记录和主动补齐工具链。Agent 的价值来自长期性和可行动性。

  • 拆解并执行任务
  • 互相 review 和补漏
  • 沉淀偏好、代码库和领域经验
C

System

提供边界、协议、记忆、权限、证据和注意力过滤。没有系统治理，Agent team 会迅速变成噪音和风险源。

  • 维护 context boundary
  • 限制权限并记录行为
  • 把执行过程转化为可审计证据

05

Product judgment

最强的判断和最大的未解题

做对的地方

  1. 把 channel 设计成 context boundary，而不是只当聊天分组。
  2. 把 Agent 做成长期成员，保留 identity、memory 和 workspace。
  3. 用 daemon 复用本地 CLI agent 生态，避免只做云端 bot。
  4. 把任务、inbox、日志、权限纳入核心面，而不是后期补丁。

真正的风险

  1. Agent 越多，人类注意力越稀缺，inbox 和 digest 会变成核心产品。
  2. 长期记忆既是 moat，也是污染、泄露和错误固化的来源。
  3. “Agent 是队友”的隐喻很高效，但也容易制造责任幻觉。
  4. Marketplace 会遇到记忆隔离、权限继承、声誉和责任归属问题。

如果我是产品负责人

  1. 先把“人如何看懂 40 个 Agent 的工作”做成超级能力。
  2. 每个 Agent profile 必须像 contract：角色、权限、记忆范围、证据标准都清楚。
  3. 为 marketplace 预先设计 sandboxed memory 和临时雇佣模式。
  4. 把 Agent Dynamics 从故事变成可调参数：发言权、委托权、审核权、沉默策略。

06

Source map

证据链和可信度说明

Official site slock.ai

定位、产品卖点、team、pricing、“not tools, teammates”的核心叙事。

 Official llms.txt Product facts

server、daemon、persistent memory、multi-agent collaboration、runtime flexibility。

 NPM package @slock-ai/daemon

截至 2026-05-16，latest 为 0.49.0，2026-05-15 修改，显示高频迭代。

 Podcast 42章经访谈

“用 Agent 动力学，和 40 个 Agents 一起为人 + AI 做产品”。本文同时使用了用户提供 transcript。

 App surface app.slock.ai

登录、app bundle、面板命名和 release notes 信号，用于逆推产品结构。

 Derived framework 人 × Agent 协同框架

把 Slock 案例抽象成可迁移的产品设计原则、协作状态机和风险矩阵。