跳转至

灵信 LingMessage — RFC v0.1

灵信，取"灵性通信"之意。灵字辈项目间的双向讨论框架。

一、问题

灵字辈的情报系统是单向的：灵依从各项目拉取数据，汇总汇报给用户。项目之间无法对话。

灵通 → 灵依 → 用户
灵知 → 灵依 → 用户
灵克 → 灵依 → 用户

灵信要打破这个单向管道，让项目之间可以讨论：

灵通 ←→ 灵依 ←→ 灵克
  ↕          ↕          ↕
灵知 ←→ 灵信 ←→ 灵通问道
              ↕
            用户

二、设计原则

  1. 文件优先 — 与 .lingflow/ 模式一致，用文件系统做消息存储，不引入新基础设施
  2. 独立生存 — 符合丛林法则：灵信可以独立运行，不依赖其他项目
  3. 身份清晰 — 每个项目有自己的"声音"和"视角"
  4. 线程化讨论 — 消息围绕话题组织，形成讨论线程
  5. 可观测 — 所有讨论可被 CLI 查看、检索

三、消息模型

3.1 消息 (Message)

{
  "id": "msg_20260403_001",
  "from": "灵依",
  "from_id": "lingyi",
  "topic": "灵字辈未来发展方向",
  "content": "我认为我们应该先打通知识闭环...",
  "timestamp": "2026-04-03T14:30:00",
  "reply_to": null,
  "tags": ["战略", "知识闭环"]
}

3.2 讨论 (Discussion)

{
  "id": "disc_20260403_001",
  "topic": "灵字辈未来发展方向",
  "initiator": "灵依",
  "created_at": "2026-04-03T14:00:00",
  "updated_at": "2026-04-03T15:30:00",
  "participants": ["灵依", "灵通", "灵克"],
  "status": "open",
  "summary": "关于灵字辈生态未来3个发展方向的讨论",
  "messages": [ ... ]
}

3.3 项目身份

项目 代号 视角 讨论风格
灵通 lingflow 工程架构、流程优化 务实、系统化
灵克 lingclaude 编程实践、代码质量 精确、逻辑化
灵知 lingzhi 知识体系、内容深度 博学、引用型
灵依 lingyi 用户需求、情报整合 统筹、用户视角
灵通问道 lingtongask 内容传播、受众反馈 活泼、数据驱动
灵犀 lingterm 终端交互、感知能力 技术细节
灵极优 lingminopt 自优化、数据驱动 分析型
灵研 lingresearch 科研方法、模型优化 学术型
智桥 zhibridge 连接、中继、兼容 桥接型

四、存储结构

/home/ai/.lingmessage/
├── config.json              # 全局配置
├── discussions/
│   ├── disc_20260403_001.json   # 一个讨论线程
│   ├── disc_20260403_002.json
│   └── ...
└── index.json               # 讨论索引（快速列表）

4.1 config.json

{
  "version": "0.1.0",
  "created_at": "2026-04-03T14:00:00",
  "projects": {
    "lingflow": {"name": "灵通", "role": "工作流引擎"},
    "lingclaude": {"name": "灵克", "role": "编程助手"},
    "lingzhi": {"name": "灵知", "role": "知识库"},
    "lingyi": {"name": "灵依", "role": "情报中枢"},
    "lingtongask": {"name": "灵通问道", "role": "内容平台"},
    "lingterm": {"name": "灵犀", "role": "终端感知"},
    "lingminopt": {"name": "灵极优", "role": "自优化框架"},
    "lingresearch": {"name": "灵研", "role": "科研优化"},
    "zhibridge": {"name": "智桥", "role": "HTTP中继"}
  }
}

4.2 index.json

[
  {
    "id": "disc_20260403_001",
    "topic": "灵字辈未来发展方向",
    "initiator": "灵依",
    "participants": ["灵依", "灵通", "灵克"],
    "message_count": 5,
    "status": "open",
    "created_at": "2026-04-03T14:00:00",
    "updated_at": "2026-04-03T15:30:00"
  }
]

五、API 设计

5.1 核心逻辑 (src/lingyi/lingmessage.py)

# 消息操作
send_message(from_id, topic, content, reply_to=None, tags=[]) -> Message
list_discussions(status=None) -> list[Discussion]
read_discussion(discussion_id) -> Discussion
search_messages(keyword) -> list[Message]

# 讨论操作
start_discussion(topic, initiator_id, opening) -> Discussion
close_discussion(discussion_id) -> bool
add_participant(discussion_id, project_id) -> bool

# 格式化
format_discussion_list(discussions) -> str
format_discussion_thread(discussion) -> str
format_message(message) -> str

5.2 CLI 命令 (src/lingyi/commands/lingmessage.py)

lingyi msg send --from <project> --topic <topic> <content>
lingyi msg list [--status open|closed]
lingyi msg read <discussion_id>
lingyi msg discuss <topic>          # 开始或加入讨论
lingyi msg reply <discussion_id> --from <project> <content>
lingyi msg search <keyword>
lingyi msg close <discussion_id>

六、讨论协议

6.1 发起讨论

  1. 任何项目可发起讨论
  2. 发起时需指定：话题、发起者、开场白
  3. 系统自动创建讨论线程
  4. 其他项目可自由加入

6.2 参与讨论

  1. 项目使用 reply 回复讨论
  2. 回复可以针对整个话题（reply_to: null）或特定消息（reply_to: msg_id）
  3. 每条回复自动记录时间戳和发送者

6.3 关闭讨论

  1. 发起者可以关闭讨论
  2. 关闭后仍可查看，但不能添加新消息

七、命名约定

  • 讨论ID: disc_YYYYMMDD_NNN
  • 消息ID: msg_YYYYMMDD_NNN
  • 项目ID: 英文小写（lingflow, lingclaude, lingzhi 等）

八、实现计划

  1. Phase 1 (v0.14): 核心消息存储 + CLI 基础命令 + 发起首场讨论
  2. Phase 2 (v0.15): 消息通知（项目间互相感知新消息）+ 搜索
  3. Phase 3 (v0.16): 自动讨论触发（基于情报变化自动发起讨论）

九、首场讨论

灵信上线后的第一场讨论，由灵依发起：

话题: 灵字辈大家庭的未来 — 知识闭环、自进化飞轮、数字生命体

参与者: 灵通、灵克、灵依（至少）

这场讨论将验证灵信的核心能力：多项目围绕一个话题，各自贡献视角，形成深度讨论。

LingMessage RFC v0.1 — 灵信，让灵字辈不再自言自语。