Skip to content

产品与架构设计

这是清海初版规划的唯一顶层约束文档。 它定义产品本体、系统架构、状态归属、写入权限和跨层禁止规则。 如其他初版规划文档与本文冲突,一律以本文为准,并应逐步收口。 最后更新:2026-03-18


一、产品定义

一句话定义

清海是一个统一的企业 AI 同事。它认识每个人,理解公司正在发生的事,维护当前议程,并持续推进需要闭环的事项。

它不是什么

  • 不是多个角色各自独立的一组 AI 工具
  • 不是聊天机器人、监控机器人、任务机器人、审批机器人的拼接
  • 不是一个"员工端 + 管理端"的功能菜单系统

它是什么

  • 是公司里统一存在的一个 AI
  • 它面对不同的人,用不同方式沟通,但认知中心只有一个
  • 它不仅会回答,还会理解、判断、跟进、升级、回流

二、产品目标

清海的产品目标可以收敛为四个:

1. 认识人

系统面对不同渠道、不同场景时,看到的是同一个人,而不是多个分裂身份。

2. 理解事

系统能理解对话、任务、审批、GitLab、日程、系统动作等变化的业务含义,而不是只看消息文本。

3. 维护议程

系统知道"当前真正该推进什么",而不是只在被触发时局部反应。

4. 推动闭环

系统能提醒、追问、升级、回流、关闭事项,让管理协作形成闭环。

产品主循环

text
认识人
  -> 接收事实
  -> 理解变化
  -> 判断是否进入议程
  -> 持续推进
  -> 闭环回流

三、多角色服务

清海会根据人物档案和组织角色调整服务方式。

角色清海的侧重点
老板 / 管理者汇总全局状态、风险、决策建议
员工 / 团队成员提醒、协调、查询个人相关信息
外部角色仅提供允许暴露的信息,保持边界

角色识别来自统一人物档案,不依赖静态硬编码名单。 不同角色的读取边界、字段裁剪和 prompt 注入脱敏规则,见《权限与可见性设计》。


四、系统六层架构

职责不负责
Interaction Layer接收消息、主动触达、输出回复不决定议程
Fact Layer统一记录事实输入与动作结果不解释、不判断
Person Layer统一维护人物真源不维护系统议程
Cognitive Core解释事实、管理注意力、统一决策不保存人物真相
Concern Layer管理单条持续事项的状态机不做全局议程仲裁
Action Layer执行动作、记录结果、防骚扰约束(详见《执行层设计》)不拥有系统状态、不决定是否行动

顶层主链路

text
外部事实 / 对话 / 定时触发
  -> Fact Layer
  -> Awareness 形成 Signal
  -> Cognitive Core 统一决策
  -> 直接行动 或 创建 / 推进 / 关闭 Concern
  -> Action 执行
  -> 动作结果回写 Fact Layer

五、核心对象模型

系统里只允许有以下核心对象:

对象定义是否真源
Person这个人是谁、组织关系、长期特征、客观近期状态
Fact外部世界发生了什么,包括消息、任务、审批、代码、日程、系统动作
Signal系统对事实的解释结果,如异常、承诺、回复信号、风险信号
Agenda系统当前在推进什么、优先级如何、注意力投向哪里
Concern一条需要持续推进的事项对象是,Agenda 的子对象
Action系统真正执行了什么,如回复、提醒、升级、查询、回流
Memory长期回忆、规则、经验、历史偏好
Session当前会话的短期状态

核心约束

  • Person 是"人"的真源
  • Fact 是"世界"的真源
  • Agenda 是"系统当前议程"的真源
  • Concern 是"单条持续事项"的真源
  • SignalMemorySession 都不是当前运行态的最终真源

六、各模块正确定位

6.1 PersonContext

PersonContext 是人的真源。

它负责:

  • 身份与组织关系
  • 长期画像与沟通风格
  • 长期职责与负责范围
  • 客观近期工作状态
  • 人工管理笔记
  • 交互策略

它不负责:

  • 当前系统正在推进哪些事项
  • 当前系统是不是重点盯这个人
  • concern 的状态机与 next action
  • 没有事实证据的即时自动判断

6.2 Awareness

Awareness 不是系统总脑,而是认知中枢中的"信号解释子能力"。

它负责:

  • 看懂新事实
  • 解释事实意味着什么
  • 提取结构化 Signal
  • 判断可能关联哪些人、哪些议程项

它不负责:

  • 维护长期议程
  • 拥有第二套系统大脑
  • 独立决定系统最终优先级

6.3 Concern

Concern 不是系统大脑,而是被正式纳入议程的一条持续事项。

它负责:

  • 保存事项目标
  • 保存参与人
  • 保存事项状态机
  • 保存时间线与证据
  • 保存下一步行动
  • 支持追问、等待、升级、关闭

它不负责:

  • 保存人物长期档案
  • 保存公司整体理解
  • 维护全局注意力池
  • 直接成为全局认知中心

七、状态归属矩阵

状态层保存什么是否真源谁是 owner
Person Layer人是谁、组织关系、长期特征、客观近期状态PersonContext
Fact Layer对话、事件、工具结果、动作结果、定时触发Fact
Agenda Layer当前在推进什么、优先级、watchlist、是否立项Cognitive Core
Concern Layer单条持续事项的目标、状态、证据、next actionConcern Engine
Workspace短期认知缓存、最近 signal、临时 watchlist、摘要Cognitive Core 派生缓存
Session当前会话短期状态Interaction Layer 派生状态
Memory长期回忆、经验、规则、历史偏好长期辅助认知

核心规则只有一句话:

运行态真相只允许落在 Person / Fact / Agenda / Concern 四类真源里。


八、各层写入权限

各层可写字段

Person Layer

允许写入:

  • identity
  • org
  • profile
  • work_scope
  • work_state
  • manager_notes
  • interaction_policy

禁止写入:

  • active_concern
  • watch_priority
  • next_action
  • "系统当前是否重点盯这个人"
  • 没有证据链的即时结论

Fact Layer

允许写入:

  • 原始消息
  • 外部系统事件
  • 工具查询结果摘要
  • 系统动作结果
  • 定时触发记录

Fact 的要求:

  • 可追溯
  • 尽量不可变
  • 尽量保留原始上下文

Agenda Layer

允许写入:

  • 当前活跃议程项
  • 优先级排序
  • watchlist
  • concern candidate
  • 立项 / 不立项决策

Agenda 不允许散落在人物档案、工作区、Concern 私有字段里各存一份。

Concern Layer

允许写入:

  • goal
  • participants
  • priority
  • status
  • evidence_refs
  • timeline
  • conversation_log
  • next_action
  • result

Concern 只保存单条事项的运行态,不保存全局议程。

写入权限表

写入目标允许谁写触发条件明确禁止
Fact渠道入口、事件适配器、动作执行器收到消息、事件、动作结果直接跳过 Fact 改写 Person / Concern
Person.profile认知中枢 + 人工工具显式偏好、稳定长期特征、有重复证据单条情绪表达直接写画像
Person.work_state认知中枢、任务同步、事实分流器客观近期工作状态、有事实依据把承诺 / 委托 / 系统关注写成人物状态
Person.manager_notes人工维护、授权的长期笔记工具人工确认的长期判断自动把一条对话或一个 concern 结果写成长期判断
Agenda只允许认知中枢事实已解释、优先级已裁决感知层、Concern、Memory 各自维护一套议程
Concern 创建认知中枢调用 Concern 引擎已正式立项,需要持续推进事件、对话、扫描结果直接创建 concern
Concern 推进/关闭Concern 引擎收到回复、新证据、timeout、schedule人物层直接改 concern 状态
Workspace认知中枢需要缓存近期摘要、watchlist、observations把 Workspace 当成真源
Memory记忆提炼链路值得长期保留的历史、规则、经验用 Memory 覆盖 Person / Agenda / Concern 真源

九、对话写入规则

对话不是天然的 Concern 输入,而是天然的 Fact 输入。

一条对话先进入 Fact Layer,再由认知中枢决定是否进一步影响 PersonWork StateAgendaConcern

对话事实分流表

对话内容默认落点进入人物档案条件进入 Agenda / Concern 条件
寒暄、闲聊、情绪表达Fact + Session不进入不进入
稳定偏好、长期习惯Fact明确表达或重复验证后,写 Person.profile不进入
当前工作进展、阻塞、客观状态FactPerson.work_state默认不进入
承诺、委托、待跟进、异常Fact不直接写人物真源进入 Agenda candidate,满足条件再建 concern
管理评价、长期判断Fact只可人工确认后写 manager_notes默认不进入

解释示例

  • "我最近不喜欢很长的消息" -> 人物偏好
  • "我今天在搞支付接口" -> 当前工作状态
  • "这个事我周五前给你结果" -> 承诺信号,可能进入议程
  • "帮我催一下张三" -> 委托信号,进入议程

硬规则

  • 普通聊天不能直接变成 Concern
  • 单次抱怨不能直接写成长期画像
  • 承诺 / 风险优先进入议程判断,不先写人物档案
  • 不能把每一条对话都当成管理判断

十、事件写入规则

外部系统事件也先进入 Fact Layer,然后再解释。

事件类型默认落点可能的后续写入
任务状态变更Fact更新 Person.work_state 或补充 Concern 证据
GitLab / 审批 / 日程变化Fact形成 signal,由认知中枢决定是否立项
预期未发生的事件absence signal进入认知中枢议程判断
系统主动动作结果Fact推进 Concern 或更新 Session

硬规则:

  • "应该发生但没发生"先形成缺席信号,不直接建 Concern
  • 事件系统只送事实,不决定优先级

十一、Concern 写入规则

Concern 生命周期只遵循下面这条主链路:

text
Fact -> Signal -> Cognitive Core 决定立项 -> Concern 创建
回复 / 新证据 / timeout -> Concern Engine 推进
goal 达成或放弃 -> Concern 关闭

Concern 可以做的事

  • 保存单条事项目标
  • 管理状态机
  • 记录时间线与证据
  • 决定下一步推进动作

Concern 不可以做的事

  • 决定全局优先级
  • 直接改写人物长期画像
  • 维护第二套 watchlist
  • 跳过认知中枢直接接受原始事件

十二、Workspace / Memory / Session 的正确地位

Workspace

Workspace 只是认知中枢的短期缓存。

规范命名:

  • working_summary(仅缓存型摘要,不是系统真源)
  • attention_watchlist(仅短期 watchlist,不是第二套 Agenda)
  • recent_observations

更具体地说:

  • attention_watchlist 应投影自 Agenda.watch_items
  • working_summary 应投影自 Agenda.focus_queue + Concern summaries + recent Facts

不允许放入:

  • 人物真相
  • 长期公司真相
  • 可替代 Concern 的独立议程池
  • 无法回溯来源的自由文本真源

Memory

Memory 只保存历史可复用认知:

  • 经验
  • 规则
  • 长期偏好
  • 历史事实回忆

它不能覆盖当前运行态真源(PersonFactAgendaConcern)。

Session

Session 只保存当前会话短期状态,不得绕过认知判断直接改人物长期档案。


十三、跨层禁止规则

这是整个架构最重要的硬规则。

6 条硬规则

  1. Person Layer 不得直接维护 Agenda。
  2. Concern Layer 不得反向改写人物长期画像。
  3. Awareness 不得拥有独立长期议程。
  4. Memory 不得直接覆盖事实与议程真源。
  5. Session 不得绕过认知判断直接写人物长期档案。
  6. 任何主动动作都必须挂靠某个明确的 Decision 或 Concern。

绝对禁止的写法

以下几种写法在架构上视为错误:

  1. 在人物档案里保存"当前系统重点盯的人"
  2. 在 Workspace 里维护一套可替代 Agenda 的独立议程
  3. 让 Concern 直接接收原始对话或原始事件立项
  4. 把单条对话直接写成 manager_notes
  5. 用 Memory 回填覆盖 Person.work_state
  6. 让感知层自己拥有最终行动决策权

十四、升级策略

清海的升级不是单纯的安全审批,而是把需要人判断的事情推给合适的人。

当前表现为:

  • 普通问题直接答
  • 涉及决策、承诺、敏感边界时升级
  • 审批闭环统一回到 TG

十五、设计原则

1. 一个 AI

系统只能有一个统一认知中心,不能有多个相互独立的"脑子"。

2. 一个人一个真源

所有与"这个人是谁"相关的信息,都必须统一回到 person_id -> PersonContext

3. 一个事实一个来源

所有判断都应能追溯到某个事实输入,不能凭空生成不可回溯的系统结论。

4. 一个议程一个 owner

系统当前在推进什么,只能由一个中心维护,不能由多个模块各自维护一份。

5. 事项不是大脑

持续事项对象很重要,但它只是议程中的单元,不是系统本身。

6. 感知不是议程

感知负责解释变化,不直接拥有长期议程。

7. 人物档案只存"人"

人物档案可以保存稳定特征和客观近期状态,但不应直接保存运行中的系统议程。


十六、与子文档的关系

本文件是初版规划的唯一上位约束文档。下列子文档都应服从本文件的边界定义:

子文档收口方向
认知中枢设计定义单脑判断主循环、议程真源结构、watch 与 concern 的边界
认知中枢实现方案定义代码组织、现有模块映射、渐进迁移、并发模型
感知层设计收口为认知中枢中的 signal 解释子系统,含 Signal 类型定义
事实与事件设计定义事实记录层的数据模型、写入规则、存储策略,以及外部事件如何统一进入 Fact Layer
持续事项引擎设计收口为 Agenda 下的持续事项状态机
执行层设计定义执行层的动作类型、Fact 回写规则、防骚扰分层
人物档案设计收口为人物真源设计
对话流程设计明确"对话先入 Fact,再由认知中枢分流"
权限与可见性设计定义不同角色对 Person / Agenda / Concern / Memory / Fact 的读取边界、字段裁剪与 prompt 注入规则
模型与辅助系统设计定义三条 LLM 链路的统一方案、记忆与知识系统、技能系统

一句话总结

清海是一个统一的企业 AI 同事;PersonContext 负责认识人,Fact Layer 负责记录世界,Cognitive Core 是唯一大脑,Concern 是持续事项对象,Action Layer 负责执行,Memory 负责长期辅助认知。Person 只负责"人",Fact 只负责"发生了什么",Agenda 只负责"现在系统要推进什么",Concern 只负责"这件事如何持续推进";其他一切都只能是缓存、派生视图或长期辅助认知。

Boss-AGI · 超级 AI 企业助理