内容怎么组织（Content Architecture）

平台上跑着十几类"内容"：上传的材料、确认过的字段、执行事实、任务日志、对话、知识、行业资讯、复盘报告、提醒、交付物、账务分录。它们看起来零散，其实只有一条主脊。读懂它，就能回答"这条内容是谁写的、能改吗、什么时候会没了"。

一句话

事实只有一个权威，其余都是它的影子。

权威是状态层（只追加的事件 + 物化的当前值）。所有"好查、好渲染"的表都是影子：影子坏了能重建，权威坏了就没了。

一个例外是 Task：它横跨 MySQL 与 MongoDB，状态靠同步补丁保持一致。这是全系统唯一一处"同一事实两个权威"，也是已知的架构债。

内容的四种寿命

按"能不能改、活多久"分类，比按模块分类有用：

寿命	典型内容	能改吗	什么时候没了
不会变的事实	执行事件、任务日志、账务分录	只能追加	永远在（可回放、可审计）
当前值	任务状态、确认过的字段、交付物	可覆盖	永远在，能被事实重建
会折叠的对话	你和 agent 的消息	可折叠成摘要	越早的话越可能只剩摘要
会过期的知识与提醒	知识条目、行业资讯、站内提醒	会过期 / 可已读	知识到期失效；资讯按天分区；提醒点开即已读

这四种混着用就会出问题，三个真实例子：

混法	会怎样
把"当前值"当唯一依据	对账时找不到"当时为什么这么判"
把对话当正式记录	折叠之后，早期那句话只剩摘要，翻不出来
把知识当永久有效	过期的法规仍会被 agent 检索到，给出过时答案 —— 比"不知道"更糟

同一份内容，三种读者

为什么同一件事会有好几张表？因为读它的东西要的形态不一样：

读者	要的形态	例子
模型	文本 / 摘要 / 向量	材料只解析一次，之后每轮直接读文本；对话折叠成摘要；知识做向量检索
人	一句话 + 一个动作	任务日志写"方案待审批 · 4400 CNY"，而不是一堆字段
机器	带路径的事实	`/tasks/{taskId}/inputs/{skillId}/{field}`，订阅按路径模式命中

所以"把内容存好"和"把内容说清楚"是两件事，分别由状态层（事实）和发展日志（叙事）承担。

一次需求：内容怎么流动

一句话  → 需求结构化
        → 材料（上传 → 解析一次 → 之后只读文本）
        → 确认过的字段（模型抽取 / 你更正，每次更正都留历史）
        → 方案已生成 → 审批 → 付款
        → 执行（每一步的事实 + 一行日志）
        → 交付物 → 验收 → 结算
        → 复盘报告 → 知识条（带有效期）

三个看起来像细节、其实是硬约束的地方：

材料只解析一次：同一份文件在同一任务里只解析一次，否则每轮对话都在重复烧钱；
值没变不写新事实：否则每轮对话都会产生一条"资料有更新"的假事件，历史被噪声淹没；
失败也留痕：材料读不出来会写明 failed + 原因；资讯抓取失败会记进 digest，用来区分"源挂了"和"今天真没新闻"。静默丢弃比报错更糟。

两种"主动"，吃的是不同内容

平台有两套主动提醒，同名但完全不同：

	提醒 agent 的所有者	提醒平台上的买家
关心什么	知识要到期了、复盘有建议、交付规则反复失败、行业有新内容	我的任务卡在等审批 / 付款、失败了、可以验收了，以及跟我这单相关的一条行业资讯
额度怎么定	从你的决策行为推断（低容忍 1 条 / 高容忍 4 条，冷却 1–7 天）	固定策略（一天 3 条，能动手的占 2 条）
落在哪	站内收件箱（可已读，可跳深链）+ 邮件	平台助手会话里的卡片

同一份行业资讯会被两边各解读一次：owner 侧看"跟这个 agent 的业务域相关吗"，买家侧看"跟这单相关吗"。所以调"资讯准不准"之前，先确认说的是哪一侧 —— 改一处不会影响另一处。

对使用者的三条实际含义

你会问	答案
"我改了一个字段，为什么历史里还是旧值？"	改的是当前值，历史是只追加的事实链，旧值永远查得到 —— 这是审计要求，不是 bug
"为什么这条对话只剩一段摘要？"	对话是四种寿命里唯一会折叠的；正式结论应该落成任务日志或确认字段，而不是留在聊天里
"为什么这条知识突然查不到了？"	它可能到期了（`validUntil`）。到期是刻意设计的：过期的法规继续回答，比回答不了更危险

边界（不做什么）

不做	原因
通用数据中台 / 全量 ETL	会变成另一个产品，且没有实体解析能力
把对话当事实源	会折叠，且不可回放
让"当前值"承担审计	覆盖即丢历史
统一所有提醒到一个通道	owner 与买家的受众、额度来源、落点都不同，硬合并会把两套预算混成一套

继续读

四类事实形态与域模型 → 四类事实形态与域模型
状态层怎么驱动 agent → 状态驱动 Agent
一次需求的完整生命周期 → 需求生命周期
表与集合的细节 → 数据模型
智能体侧的主动模式 → 智能体主动模式
买家侧的主动播报 → 主动沟通（用户指南）

内容怎么组织（Content Architecture） ​

一句话 ​

内容的四种寿命 ​

同一份内容，三种读者 ​

一次需求：内容怎么流动 ​

两种"主动"，吃的是不同内容 ​

对使用者的三条实际含义 ​

边界（不做什么） ​

继续读 ​