Latent-Space-vs-Deterministic
定义
潜在空间 vs 确定性（Latent Space vs Deterministic） 是 GBrain 的核心设计洞察：最差的 Agent 系统总是把错误的工作放在错误的一边。正确的分工是——让 LLM 在"潜在空间"中决定"做什么"（判断、分析、综合），让代码在"确定性"中保证"在哪里"和"如何做"（构建交叉验证链接、验证引用格式、执行精确计算）。
为什么重要
Agent 系统最常见的失败，不是“LLM 不够强”或“代码不够多”，而是把任务放错层：让 LLM 负责精确格式、路径和计数，或者让硬编码规则负责语义判断、取舍和综合。
GBrain 的这个分工提供了一条架构准则：不确定、语义丰富、依赖上下文的任务交给 LLM；需要可重复、可验证、可审计的任务交给代码。这样既保留模型的阅读和判断能力，又避免把文件链接、引用格式、图谱边和计算结果交给概率输出。
在 LLM Wiki 场景中，这一点尤其重要。知识编译不是一次 prompt 输出，而是长期维护的知识库。一次错误链接、错误 frontmatter 或错误格式会被持久化；一次错误判断则需要能追溯到 source summary 和 raw 证据。因此系统必须区分“由谁判断”和“由谁保证”。
关键数据点
| 对比维度 | 潜在空间（Latent Space） | 确定性（Deterministic） |
|---|---|---|
| 特点 | 智能——阅读、解释、决策 | 信任——相同输入总是产生相同输出 |
| 适合场景 | 判断、分析、综合 | SQL、计算、链接构建 |
| 执行者 | LLM 处理 | 代码处理 |
| 示例 | "这条信息是否属于某人的页面" | 构建交叉验证链接、验证引用格式 |
分工原则
交给潜在空间的任务
- 判断一段材料是否属于某个概念、人物或主题页面。
- 提炼来源的核心论点、前提、限制和反例。
- 在多个页面之间发现弱关联、冲突或可迁移结构。
- 解释模糊语境，例如作者是在提出事实、类比、立场还是猜测。
- 判断一个问题需要读 entity、topic、comparison 还是 raw 证据。
这些任务没有单一确定答案，或者答案依赖语义、语境和判断力。LLM 的价值在于能在不完整、非结构化材料中形成候选解释。
交给确定性的任务
- 检查 YAML frontmatter 是否能被解析。
- 生成和验证 wikilink、文件名、slug、索引条目和反向链接。
- 计算字节数、行长、表格列数、孤链、入链和出链。
- 执行 SQL、正则匹配、图遍历、向量初筛和缓存更新。
- 检查裸
$、重复标题、无效日期、缺失字段和 schema 违例。
这些任务的特点是：输入相同就应得到相同结果，且错误可以被程序明确检测。把它们交给 LLM 会增加随机性和维护成本。
混合接口
真实系统通常不是二选一，而是“LLM 生成候选，代码验证约束，再由 LLM 修复语义”。
LLM 判断：这段材料应该更新哪些页面
-> 代码验证：文件是否存在、frontmatter 是否合法、wikilink 是否可解析
-> LLM 修复：根据验证错误调整内容
-> 代码写入：执行格式化、索引更新、lint 和报告生成GBrain 的混合检索也是同一思想：先用向量和关键词快速过滤候选页面，再加载完整页面让模型精读；图谱反向链接、关系表和 backlink boost 则由确定性规则维护。
误用模式
| 误用 | 表现 | 后果 |
|---|---|---|
| 让 LLM 做确定性工作 | 让模型手写链接、计数、表格列、JSON/YAML 细节 | 细小格式错误被持久化 |
| 让代码做语义判断 | 用关键词规则决定概念归属或文章主旨 | 召回僵硬，错过隐含关联 |
| 没有验证接口 | LLM 直接写库，代码不检查 | 错误在 Wiki 中复利 |
| 过度代码化 | 把所有知识关系都做成规则 | 系统维护成本超过知识收益 |
| 过度模型化 | 一切都让 Agent 自己判断 | 输出不稳定，难以审计 |
这个概念的核心不是崇拜代码，也不是崇拜模型，而是把每类能力放到最适合的位置。
在 LLM Wiki 中的应用
LLM Wiki 的四类动作都可以用这个分工检查。
- compile：LLM 负责浓缩、质疑、对标；代码负责文件落点、frontmatter、链接和 lint。
- audit：LLM 负责判断概念是否薄弱、逻辑是否混乱；代码负责裸
$、长行、YAML、孤链和统计。 - produce：LLM 负责组织输出和形成判断；代码负责回填表格格式、引用路径和发布检查。
- explore：LLM 负责提出问题、反例和 source 需求；代码负责不把 agenda 当事实层证据。
这让 知识编译 变成可治理流程：语义判断可以被讨论，确定性约束可以被自动验证。
设计检查表
设计 Agent 功能时，可以用四个问题判断任务应放在哪一侧。
- 这个任务是否有唯一正确答案？
- 错误能否被程序自动检测？
- 输出是否会被长期持久化或被其他页面复用？
- 任务失败的代价是“理解偏差”还是“格式/执行错误”？
如果答案偏向唯一、可检测、持久化和格式错误，应放到确定性层。如果答案依赖语义、取舍和上下文，应由 LLM 先判断，再让确定性层约束它。
前提与局限性
- 潜在空间与确定性的边界划分依赖领域理解——如果边界划错，可能让 LLM 做它不擅长的事或浪费代码实现灵活性
- LLM 在潜在空间中的判断可能存在幻觉和不一致性
- 确定性代码的维护成本随规则复杂度增长
- 两者的交互接口设计是关键——LLM 的判断结果如何可靠地传递给确定性代码层
- 这不是固定边界。随着模型能力、工具调用和验证环境变化，某些过去必须硬编码的任务可能被模型稳定承担，某些看似语义的任务也可能被结构化成可验证流程。
- 确定性层也会出错。规则写错、schema 过时或索引策略偏差，会让系统稳定地产生错误。
- 潜在空间输出需要来源约束。没有 source summary、raw 证据和回填检查，LLM 的语义判断会变成不可追溯假设。
关联概念
- GBrain — 潜在空间 vs 确定性是 GBrain 架构的核心设计洞察
- Thin-Harness-Fat-Skills — Harness 中的确定性逻辑，Skills 中的潜在空间判断
- Progressive-Disclosure — 先用确定性索引缩小范围，再由模型按需精读
- Jagged-Intelligence — LLM"代码超人、常识脆弱"的锯齿状智能是这种分工的基础
- Verifiability — 确定性代码提供了可验证性保障，潜在空间输出则需要人工验证
- Knowledge-Compilation — LLM Wiki 的编译动作需要语义判断与格式验证协同