认知中枢设计

这是《产品与架构设计》的核心配套文档。它回答的是：唯一大脑到底怎么运转，Agenda 的真源结构是什么，系统如何在 Session / Person / Direct Action / Concern 之间做统一裁决。如其他初版规划文档与本文冲突，以本文和《产品与架构设计》为准。最后更新：2026-03-18

一、为什么必须有这篇文档

顶层文档已经回答了两个问题：

系统里谁是唯一大脑
各类状态归谁、谁能写什么

但还缺最关键的一层：

这个唯一大脑收到新事实后，到底怎么判断
Agenda 不是任务列表的话，那它到底长什么样
什么时候只是记一笔，什么时候应该观察，什么时候应该直接行动，什么时候应该立项成 Concern

如果这层不单独写清楚，系统虽然名义上只有一个大脑，实际还是会退回到：

感知层自己做一部分决策
Concern 自己做一部分立项
人物档案里继续混入运行态

所以这篇文档的目标，是把唯一大脑的运行机制写成明确架构。

二、一句话定义

认知中枢是“统一判断器”，Agenda 是“这个判断器当前运行态的真源”。

更具体地说：

Perception 负责看懂新事实，形成 Signal
Cognitive Core 负责把 Fact + Signal + 当前系统状态 统一变成决策
Agenda 负责保存“系统现在真正正在推进什么”
Concern 负责承接那些已经被正式纳入议程、且需要持续推进的单条事项

所以：

Perception 不是大脑
Concern 不是大脑
Workspace 不是大脑
真正的大脑是 Cognitive Core

三、顶层主链路

text

新 Fact 到达
  -> Perception 形成 Signal
  -> 认知中枢加载 Person / Agenda / Concern / Workspace / Memory 相关上下文
  -> 统一裁决
  -> 写入 Session / Person / Agenda / Concern 之一或多者
  -> 触发 Direct Action 或 Concern 推进
  -> 动作结果回写 Fact
  -> 刷新 Workspace 缓存

这条链路里最重要的硬规则有三条：

所有输入先是 Fact，不是 Agenda
所有立项都先经过认知中枢，不直接进 Concern
所有主动动作都要挂靠某个明确决策或某个 Concern

四、认知中枢要读什么

认知中枢每次判断，不是凭空想，而是读取一组固定输入。

输入	owner	作用	不能做什么
`Fact`	`Fact Layer`	提供原始发生事实	不直接当成决策结论
`Signal`	`Perception`	提供事实含义解释	不单独决定立项
`PersonContext Slice`	`Person Layer`	提供人物真源与沟通策略	不替代议程判断
`Agenda Snapshot`	`Agenda Layer`	提供当前系统在推进什么	不替代单条事项状态
`Concern Summary`	`Concern Layer`	提供单条持续事项运行态	不替代全局优先级
`Workspace Cache`	`Cognitive Core`	提供近期摘要与热缓存	不作为真源覆盖他层
`Memory / Knowledge`	长期辅助认知	提供历史经验、规则、资料	不覆盖当前运行态真源
`Session Brief`	`Interaction Layer`	提供会话短期连续性	不直接写人物长期档案

输入优先级

认知中枢读取时，默认遵循如下优先级：

当前相关 Fact
当前相关 Concern
当前 Agenda
当前 Person
Workspace 热缓存
Memory / Knowledge
Session

这不是“重要性排序”，而是判定真相时的可信优先级。

五、认知中枢输出什么

认知中枢不是只有“建 Concern”这一种输出，它必须在多种目标之间分流。

输出类型	写入位置	适用场景
`ignore / record_only`	`Fact`	仅记录，不改变运行态
`session_update`	`Session`	对话连续性需要，但不影响系统议程
`person_update`	`Person.profile / work_state`	稳定偏好或客观近期状态发生变化
`agenda_watch`	`Agenda.watch_items`	重要但尚不应建 concern，先观察
`direct_action`	`Action` + `Fact`	一次动作即可，不需要持续跟进
`create_concern`	`Agenda + Concern`	需要持续推进、等待、追问、回流
`advance_concern`	`Concern`	有新的回复或证据进入已有事项
`close_concern`	`Concern` + `Agenda`	事项目标达成或不再值得推进
`escalate`	`Action` + `Fact`	超出边界，需要更高层决策

这里最关键的边界是：

direct_action 不是 Concern
agenda_watch 不是 Concern
person_update 不是 Agenda
session_update 更不是 Person

六、Agenda 到底是什么

Agenda 不是任务系统，也不是所有事项的堆叠集合。

它回答的问题只有一个：

系统此刻真正认为“应该推进或继续盯住”的是什么。

6.1 Agenda 的真源形态

推荐把 Agenda 设计成一份全局运行态对象：

json

{
  "_id": "agenda_qinghai",
  "focus_queue": [
    {
      "entry_id": "ag_001",
      "kind": "concern_ref",
      "title": "跟进张三给出 v2.0 提测时间",
      "priority": "high",
      "why_now": "老板委托 + 今日需要回流",
      "concern_id": "con_001"
    }
  ],
  "watch_items": [
    {
      "watch_id": "watch_001",
      "topic": "v2.0 后端提测是否在今天发生",
      "priority": "medium",
      "confidence": "medium",
      "source_fact_refs": ["fact_1001"],
      "person_refs": ["p_zhangsan"],
      "promote_condition": "18:00 仍无提测证据则升级为 concern",
      "expires_at": "2026-03-18T18:00:00+08:00"
    }
  ],
  "concern_refs": [
    {
      "concern_id": "con_001",
      "priority": "high",
      "status": "waiting_reply",
      "agenda_role": "active"
    }
  ],
  "recent_decisions": [
    {
      "decision_id": "dec_001",
      "decision_type": "create_concern",
      "fact_refs": ["fact_1001"],
      "signal_refs": ["sig_2001"],
      "reason": "老板明确委托且需要持续回流",
      "created_at": "2026-03-18T10:05:00+08:00"
    }
  ],
  "updated_at": "2026-03-18T10:05:00+08:00"
}

6.2 Agenda 的核心子结构

字段	作用	是否真源
`focus_queue`	当前系统优先推进顺序	是
`watch_items`	当前系统确认要继续观察的项目	是
`concern_refs`	当前已正式立项的持续事项引用	是
`recent_decisions`	近期关键决策记录，用于追溯	是，作为议程决策日志

6.3 Agenda 不是 Concern 的重复副本

Agenda 和 Concern 的分工必须非常清楚：

Agenda 保存“全局排序、全局关注、是否正式纳入议程”
Concern 保存“单条事项的目标、状态、证据、next action”

所以：

Agenda 可以知道 con_001 当前排在第 1 位
但 con_001 的详细推进状态只在 Concern 内部保存

6.4 Watch Item 的作用

watch_item 是这套架构里非常关键的一层。

它用于承接这类情况：

这件事重要
系统应该盯住它
但还不值得立即建 Concern

典型例子：

张三说今天会提测，但现在还没到承诺时点
某关键审批有卡住迹象，但还没超过 SLA
某高优项目最近连续出现轻微信号，暂时还没有形成明确阻塞

这类事情如果直接建 Concern，系统会过度立项。
如果完全不记，又会失去连续关注。
所以正确做法是：先进入 Agenda.watch_items。

七、Agenda 与 Workspace 的关系

这是整个系统最容易再次混掉的地方。

7.1 真源与缓存的正确映射

真源	缓存 / 派生视图	说明
`Agenda.watch_items`	`Workspace.attention_watchlist`	后者是前者的热缓存投影
`Agenda.focus_queue + Concern refs + recent Facts`	`Workspace.working_summary`	后者是便于快速理解的摘要缓存
`Concern` 运行态	`Concern summary in prompt / workspace`	prompt 中注入的是切片，不是真源
`Person.work_state`	dashboard / chat slice	切片是派生视图，不反写真源

7.2 写方向必须单向

正确写方向：

text

Agenda / Concern / Fact / Person
    -> 派生出 Workspace 缓存

错误写方向：

text

Workspace 的自由文本摘要
    -> 反向覆盖 Agenda / Person / Concern

所以：

Workspace.attention_watchlist 不是系统真正的 watch 真源
Workspace.working_summary 不是系统真正的公司理解真源
它们都只是为了让模型更快进入状态的缓存

八、认知中枢的判断主循环

认知中枢每次处理输入时，建议固定走下面 6 步。

8.1 第一步：接收 Fact

所有事情都先以 Fact 进入。

包括：

对话消息
GitLab / 审批 / 任务 / 日程事件
定时触发
动作执行结果

8.2 第二步：Perception 产出 Signal

Perception 负责把事实解释成结构化信号。

典型信号类型可以包括：

delegation_signal
promise_signal
reply_signal
blocker_signal
risk_signal
completion_signal
absence_signal
preference_signal
work_state_signal

8.3 第三步：绑定上下文

认知中枢拿到 Signal 后，要先做状态绑定：

关联到谁
是否命中已有 watch_item
是否命中已有 Concern
是否属于当前系统重点议程
是否只是一次普通会话状态变化

如果这一步没做好，系统就会反复建重复 concern，或者把本该推进已有事项的信号误判成新事项。

8.4 第四步：评估五个判断维度

每个信号都至少要被放到这五个维度里看一遍：

维度	要回答的问题
`impact`	这件事对业务、老板、关键项目影响有多大
`urgency`	是否存在时间窗口、deadline、SLA、马上要处理的压力
`continuity`	是否需要未来再次进入系统、等待回复、等待证据、再次检查
`confidence`	当前证据是否足够，还是只有弱信号
`scope`	影响是局部聊天，还是跨人、跨项目、跨流程的事项

8.5 第五步：统一裁决

根据前面的绑定与评估，认知中枢只允许做以下几类裁决：

只写 Session
写 Person
写 Agenda.watch_items
直接行动
创建新 Concern
推进已有 Concern
关闭已有 Concern
升级给人

8.6 第六步：写入与动作执行

建议固定遵循这个顺序：

text

Fact 已存在
  -> 产生 Signal
  -> 写 recent_decisions
  -> 写 Person / Agenda / Concern
  -> 触发 Action
  -> Action 结果回写 Fact
  -> 刷新 Workspace 缓存

这样做的好处是：

所有动作都能追溯到前置事实
所有运行态变化都有决策记录
Workspace 永远是派生缓存，不先写真源

九、真正决定“要不要立项”的阈值

9.1 不进入 Agenda 的情况

以下内容默认不进入 Agenda：

寒暄、闲聊、情绪表达
一次性说明但没有后续跟进价值的信息
只影响当前回答风格的对话细节
只有模糊情绪，没有明确业务含义的抱怨

这类输入通常只会影响：

Fact
Session
当前回复内容

9.2 进入 Person，而不进入 Agenda 的情况

以下内容优先写人物真源，不进入 Agenda：

明确且稳定的沟通偏好
客观近期工作状态
当前负责内容、短期阻塞、最近风险事实

关键点在于：

这是“这个人的状态”
不是“系统必须持续推进的一件事”

9.3 进入 Watch，而不立即建 Concern 的情况

以下内容适合先进入 Agenda.watch_items：

事情重要，但证据还不够强
事情重要，但还没到行动时点
需要继续观察是否发生，而不是立刻追问
当前只需要系统保持注意力，不需要正式进入持续推进流程

9.4 直接行动，而不建 Concern 的情况

以下内容适合 direct_action：

一次提醒或一次通知就足够
当前需要立即响应，但不需要未来再回来跟进
只是一次查询、一次回复、一次转发、一次提示

9.5 必须建 Concern 的情况

以下内容应直接进入 Concern：

明确委托了系统去联系、提醒、推进某人或某事
出现了明确承诺、deadline、回流要求
事项需要等待未来回复、未来证据或未来时点
当前只是推进的第一步，后面必然还会继续进入系统
已经存在“完成条件”或“关闭条件”

可压缩成一句话：

只要一件事需要系统在未来再次回来继续推进，它就不该只停留在对话或感知里，而应进入 Concern。

十、正常对话为什么不会被破坏

这是产品体验上最重要的约束之一。

10.1 默认路径仍然是“聊天路径”

普通消息的默认路径仍然是：

text

对话 -> Fact -> Session / 回复

只有当消息里出现以下内容时，才有可能离开普通聊天路径：

稳定偏好
客观工作状态
承诺、委托、风险、异常、待跟进事项

10.2 三类典型示例

输入	正确落点	不应该发生什么
“哈哈，今天太累了”	`Fact + Session`	不该建 concern
“我今天在改支付回调，卡在联调”	`Fact + Person.work_state`	不该自动写长期画像
“这个事我周五前给你结果”	`Fact + Agenda / Concern candidate`	不该只停留在 session

10.3 这样设计的结果

正常对话不会因为系统有主动性而变得僵硬，原因是：

系统不是把每条消息都当任务
只有跨过阈值的内容才进入议程
议程判断发生在对话之后，不会把普通回复链路全部污染

十一、信息源冲突时怎么裁决

这是避免“几个脑子互相打架”的核心规则。

11.1 总规则

先分清冲突发生在哪一层，再在该层内按真源优先级裁决。

11.2 各层冲突优先级

冲突领域	优先级
人物身份 / 组织关系	权威组织源 > `Person` 现有真源 > 对话自述 > `Memory`
当前工作状态	最新可验证事实 > 最新明确自述 > 历史 `work_state` > `Memory`
单条事项运行态	`Concern` 当前状态 > 新事实证据 > 旧对话印象 > `Memory`
当前议程排序	老板显式关注 / 高优新事实 > 已有 `Agenda` 排序 > watch 项 > `Memory` 建议
工作区摘要	`Fact / Person / Agenda / Concern` 真源 > `Workspace` 运行态字段

11.3 冲突时的处理动作

如果冲突已能裁决：

直接更新对应真源
刷新 Workspace 缓存

如果冲突还不能裁决：

不直接覆盖人物真源
不直接关闭 concern
先创建或刷新 watch_item
必要时发起澄清或等待下一个事实

11.4 去重与合并规则

认知中枢应优先做合并，而不是重复立项。

当以下条件相同或高度相似时，优先合并到已有议程项：

同一目标
同一人
同一项目 / 主题
同一时间窗口

正确动作通常是：

给已有 watch_item 补证据
给已有 Concern 调 advance_concern
调整 focus_queue 排序

而不是重复创建第二个 concern。

十二、主动性应该从哪里产生

系统的主动性只能从这三类地方产生：

Agenda.watch_items 满足触发条件后，被认知中枢重新评估
Concern.next_action 到期后，由 concern scheduler 重新推进
明确的定时计划或老板指令，经过认知中枢进入议程

不允许出现的主动性来源：

感知层自己看完就直接决定长期推进
Workspace 摘要里写了什么，系统就跟着做什么
人物档案里写着“重点关注”，系统就自动主动发消息

所以主动性真正的公式应该是：

text

Fact / Signal
  -> 认知中枢
  -> Agenda 或 Concern
  -> Action

而不是：

text

感知层 / 人物档案 / 工作区
  -> 直接主动

十三、为了后续实现，至少要有的接口边界

这不是实现步骤，而是为了保证架构不走偏，至少要有的系统接口边界。

接口	责任
`evaluate_fact(fact_id)`	从单条事实出发做一次完整判断
`evaluate_signal(signal)`	对已形成信号做议程判断
`match_existing_agenda(...)`	判断是否命中已有 watch / concern
`apply_agenda_decision(...)`	把判断结果落到 `Agenda / Concern / Person / Action`
`refresh_workspace_cache()`	从真源重建 `working_summary / attention_watchlist`

这几个接口的意义，是让将来的代码实现很难再绕开认知中枢。

十四、与其他文档的关系

这份文档应该和以下文档配套理解：

《产品与架构设计》：定义唯一大脑是谁、各层归属是什么、谁能写什么
《感知层设计》：定义 Signal 如何形成
《持续事项引擎设计》：定义持续事项如何推进
《对话流程设计》：定义对话事实如何进入认知判断链路

它在这组文档中的位置是：

把“顶层原则”真正落成“运行中的单脑判断机制”。

十五、一句话总结构

认知中枢负责统一裁决，Agenda 负责保存系统当前真正关心什么，Watch 用来承接“值得继续盯但还不该建 concern”的事项，Concern 用来承接“已经正式立项、需要持续推进”的事项；这样系统才会真的只有一个大脑。

认知中枢设计 ​

一、为什么必须有这篇文档 ​

二、一句话定义 ​

三、顶层主链路 ​

四、认知中枢要读什么 ​

输入优先级 ​

五、认知中枢输出什么 ​

六、Agenda 到底是什么 ​

6.1 Agenda 的真源形态 ​

6.2 Agenda 的核心子结构 ​

6.3 Agenda 不是 Concern 的重复副本 ​

6.4 Watch Item 的作用 ​

七、Agenda 与 Workspace 的关系 ​

7.1 真源与缓存的正确映射 ​

7.2 写方向必须单向 ​

八、认知中枢的判断主循环 ​

8.1 第一步：接收 Fact ​

8.2 第二步：Perception 产出 Signal ​

8.3 第三步：绑定上下文 ​

8.4 第四步：评估五个判断维度 ​

8.5 第五步：统一裁决 ​

8.6 第六步：写入与动作执行 ​

九、真正决定“要不要立项”的阈值 ​

9.1 不进入 Agenda 的情况 ​

9.2 进入 Person，而不进入 Agenda 的情况 ​

9.3 进入 Watch，而不立即建 Concern 的情况 ​

9.4 直接行动，而不建 Concern 的情况 ​

9.5 必须建 Concern 的情况 ​

十、正常对话为什么不会被破坏 ​

10.1 默认路径仍然是“聊天路径” ​

10.2 三类典型示例 ​

10.3 这样设计的结果 ​

十一、信息源冲突时怎么裁决 ​

11.1 总规则 ​

11.2 各层冲突优先级 ​

11.3 冲突时的处理动作 ​

11.4 去重与合并规则 ​

十二、主动性应该从哪里产生 ​

十三、为了后续实现，至少要有的接口边界 ​

十四、与其他文档的关系 ​

十五、一句话总结构 ​

认知中枢设计

一、为什么必须有这篇文档

二、一句话定义

三、顶层主链路

四、认知中枢要读什么

输入优先级

五、认知中枢输出什么

六、Agenda 到底是什么

6.1 Agenda 的真源形态

6.2 Agenda 的核心子结构

6.3 Agenda 不是 Concern 的重复副本

6.4 Watch Item 的作用

七、Agenda 与 Workspace 的关系

7.1 真源与缓存的正确映射

7.2 写方向必须单向

八、认知中枢的判断主循环

8.1 第一步：接收 Fact

8.2 第二步：Perception 产出 Signal

8.3 第三步：绑定上下文

8.4 第四步：评估五个判断维度

8.5 第五步：统一裁决

8.6 第六步：写入与动作执行

九、真正决定“要不要立项”的阈值

9.1 不进入 Agenda 的情况

9.2 进入 Person，而不进入 Agenda 的情况

9.3 进入 Watch，而不立即建 Concern 的情况

9.4 直接行动，而不建 Concern 的情况

9.5 必须建 Concern 的情况

十、正常对话为什么不会被破坏

10.1 默认路径仍然是“聊天路径”

10.2 三类典型示例

10.3 这样设计的结果

十一、信息源冲突时怎么裁决

11.1 总规则

11.2 各层冲突优先级

11.3 冲突时的处理动作

11.4 去重与合并规则

十二、主动性应该从哪里产生

十三、为了后续实现，至少要有的接口边界

十四、与其他文档的关系

十五、一句话总结构