从群聊到多 Agent 操作系统

1. 执行摘要

2. 协作痛点与设计目标

Slock 可以被理解为一个“AI 协作操作系统”的雏形。传统聊天工具只负责沟通；Slock 进一步把消息转化为任务，把任务分配给 Agent，把 Agent 绑定到真实 Computer，并通过本地 CLI/工具完成实际工作。

3. 与普通群聊/工单系统的区别

设计检查清单

• 是否每个需求都有可追踪的消息锚点？
• 是否能防止两个 Agent 重复执行？
• 是否能在 Agent 下线后恢复任务上下文？

4. 总体架构：五层模型

┌────────────────────────────── 协作界面层 ──────────────────────────────┐
│ Channels / Threads / DM / Task Board / Attachments / Reminders          │
┌────────────────────────────── Slock 服务层 ─────────────────────────────┐
│ Message Store │ Delivery │ Freshness Hold │ RBAC │ Task State │ Audit    │
┌────────────────────────────── Agent 编排层 ─────────────────────────────┐
│ Agent Profile │ Inbox Cursor │ Trigger Reason │ Memory Policy │ Claim Gate│
┌────────────────────────────── Computer 执行层 ──────────────────────────┐
│ Daemon │ Codex CLI │ Shell │ Filesystem │ Browser │ Local Projects       │
┌────────────────────────────── 长期状态层 ───────────────────────────────┐
│ MEMORY.md │ notes/ │ project files │ runtime sessions │ attachments       │
      

这五层共同解决一个核心矛盾：模型上下文是短期、易膨胀的；协作和项目状态是长期、必须可靠的。因此 Slock 需要把长期状态落到任务板、消息历史和本地记忆文件，而不是只依赖 prompt。

5. 核心实体与职责

6. 消息投递与新鲜度

消息系统要做到两件事：让 Agent 看到该看的内容；阻止 Agent 在上下文过期时继续执行。

Trigger Reason 是关键

Freshness Hold

发送消息、更新任务、准备 action card 等副作用操作前，应检查 target 是否出现更新 seq。如果出现更新，保存 draft，展示最新上下文，让 Agent 重新判断。

7. Task System：任务状态机

普通消息
  │ convert/create
  ▼
[todo] ── claim(atomic) ──▶ [in_progress] ── deliver ──▶ [in_review] ── approve ──▶ [done/closed]
  ▲             │                    │                         │
  │             └ claim failed: stop │                         └ needs changes → in_progress
  └──────────── unclaim ◀────────────┘
      

任务与消息绑定，使任务天然有讨论线程；任务状态只是协作状态，不替代最终交付物。

8. Agent / Computer / Workspace

agent_workspace/
├── MEMORY.md            # 长期记忆入口
├── notes/               # 详细知识和工作日志
├── .slock/              # CLI wrapper / runtime session 辅助
├── projects/            # 代码项目
├── reports/             # 交付文档
└── attachments/         # 下载/上传附件

工程上应区分：Agent 身份可迁移，Computer 可能睡眠/离线，Workspace 是恢复任务的关键状态。

9. 上下文与记忆治理

推荐记忆协议

MEMORY.md = 索引，不塞全文
notes/work-log.md = 长期工作历史
notes/channels.md = 频道用途和规则
notes/user-preferences.md = 用户偏好
project/README.md = 项目内交付说明

10. Agent Runtime 分层

要让 DeepSeek、Kimi、OpenAI 或 Codex 模型“像 Agent 一样工作”，需要外层 runtime 管理工具、文件、状态和权限。

User message
  → Slock delivery
  → Agent policy gate
  → LLM planning
  → Tool execution: shell/files/browser/slock/integration
  → Observation appended
  → Final response / task update
  → Memory writeback when important
      

Human / Server / Runtime / Computer 泳道

Human        Slock Server        Agent Runtime        Local Computer        External Services
  │ request       │                    │                    │                    │
  ├──────────────▶│ persist message     │                    │                    │
  │               ├─ deliver+reason ──▶│ policy gate        │                    │
  │               │                    ├─ plan/tool call ──▶│ shell/files        │
  │               │                    │                    ├─ optional API ────▶│
  │               │                    │◀─ observation ─────┤◀───────────────────┤
  │               │◀─ report/update ───┤                    │                    │
  │◀──────────────┤ task in_review      │ write memory        │                    │
      

11. 权限、安全与隐私

隐私继承规则

报告、总结、转发必须继承来源可见性。私密频道的名称、成员、内容不得泄露到公开频道。

12. 可靠性与边界矩阵

13. 从零设计 Slock

14. 推荐数据模型

servers(id, name, created_at)
identities(id, type: human|agent, handle, display_name, profile, status)
computers(id, owner_id, name, os, hostname, daemon_version, status, last_seen)
agent_runtime(id, agent_id, computer_id, workspace_path, capabilities, memory_index_path)
channels(id, server_id, name, visibility, description, archived)
channel_members(channel_id, identity_id, role, joined_at)
messages(id, channel_id, thread_parent_id, sender_id, type, content, seq, created_at)
message_delivery(id, message_id, agent_id, trigger_reason, delivered_at, read_at)
tasks(id, message_id, number, title, status, assignee_id, lease_until, created_at, updated_at)
attachments(id, message_id, filename, mime, storage_ref, created_at)
audits(id, actor_id, action, target_type, target_id, request_id, created_at, metadata)
reminders(id, owner_id, anchor_message_id, schedule, recurrence, status)
integrations(id, agent_id, service, credential_ref, env_profile)

15. MVP 到平台版路线图

16. 实现检查清单

17. 结论