Tolaria 与 Portent 模板：八种默认类型、双关系字段与「捕获-整理-归档」知识库生命周期

Tolaria 与 Portent 模板八种默认类型、双关系字段与「捕获-整理-归档」知识库生命周期【免费下载链接】tolariaDesktop app to manage markdown knowledge bases项目地址: https://gitcode.com/GitHub_Trending/to/tolariaPortent 是 Tolaria 仓库内src-tauri/resources/agent-docs/pages/templates/portent.md 与 site/templates/portent.md定义并文档化的一套面向工作与个人知识库的开放规范它用 8 个默认类型、belongs_to/related_to两个图状关系字段以及「捕获 → 整理 → 归档」三阶段生命周期给 Vault 提供开箱即用的组织结构。读完本文你将理解 Portent 的核心理念如何逐项映射到 Tolaria 的类型文档、关系字段、Inbox 与自定义视图等既有机制上并能直接基于模板 Vault 快速搭建一个对人机含 AI Agent都友好的 Markdown 知识库。一、Portent 定位规范加模板而非又一层应用功能Portent 被描述为「an open specification and template for work and personal knowledge bases」。它对 Tolaria Vault 的作用是提供一小套组织信息的默认约定清晰的类型clear types回答「这条笔记是什么」通用的图状关系generic graph-like relationships回答「它和什么相关」简单的知识生命周期a simple lifecycle for captured knowledge回答「它处于什么状态」。其目标是让知识库对人和 AI Agent 都有用而不要求每个人或团队先设计一套私有本体ontology。规范本身不绑定 Tolaria 的内部实现——Tolaria 是其首个预期实现同样的模型可以工作在任何本地 Markdown Vault、笔记应用、文档工具或 Agent 可读的知识库之上。这一点与 Tolaria 的整体架构取向一致文件系统是唯一事实来源笔记就是带 YAML frontmatter 的 Markdown 文件因此 Portent 定义的「结构」全部落在文件内容里天然可移植、可被外部工具包括 Agent解析。二、核心问题用「约定」代替「配置」Portent 明确主张 convention over configuration。它不追问「这条信息应该放在哪个文件夹」而是追问三个问题What is this?它是什么——对应 Tolaria 的类型文档type documentsWhat is it useful for?它有什么用——对应 Tolaria 的关系字段与自定义视图Is it captured, organized, or archived?它是刚捕获、已整理、还是已归档——对应 Tolaria 的 Inbox、整理后的组织态与归档行为。这三个问题正是 Tolaria 数据模型的三个正交维度而不是文件夹层级类型是语义分组关系是跨分组的连接生命周期状态是视图过滤条件。三、八种默认类型PORT 组与 ENTP 组Portent 定义 8 个默认类型按「是否可执行actionable」分为两组PORT 类型可执行类型语义Project项目Operation运营中的事务/运作Responsibility职责Task任务ENTP 类型不可执行的知识记录类型语义Event事件Note笔记Topic主题Person人物PORT/ENTP 的命名恰好取自两组类型首字母P-O-R-T / E-N-T-P-P 中 Portent 前缀的拆分思路前一组是「要做的事」后一组是「知道的事」。官方说明强调这些默认类型以近乎零配置覆盖个人与职场知识的常见形态你当然可以之后添加自定义类型但 Portent 的最佳实践是先使用默认词汇表再按需扩展。落到 Tolaria类型文档Type DocumentsTolaria 中每个类型由一份type: Type的 Markdown 类型文档描述该文档决定侧边栏分组、类型图标与颜色、侧边栏顺序与标签、置顶属性以及该类型新建笔记的模板详见 src-tauri/resources/agent-docs/pages/concepts/types.md--- type: Type _icon: folder _color: blue _sidebar_label: Projects _order: 10 --- # Project两个对 Portent 落地很关键的机制type:字段是显式的不从文件夹推断。把文件移进别的文件夹不会改变它的类型Tolaria 明确「Prefer Types Over Folders」这正是 Portent 能成立的前提——结构语义来自 frontmatter而非路径。类型文档可定义空属性和默认值。例如 Project 类型文档若声明status: Active则每个新建项目笔记都以 Active 起步声明为空的属性会以占位符形式出现在 Properties 面板中等待填写。这意味着 Portent 的 8 个类型可以「预装」一套统一的状态/关系占位字段新笔记创建即带骨架。仓库内 demo-vault-v2/type/ 目录即是一组类型文档示例project.md、note.md、person.md、event.md、topic.md、procedure.md、responsibility.md、area.md等其中 demo-vault-v2/type/note.md 展示了 Note 类型文档的最小形态frontmatter 声明类型元数据正文用一句话说明该类型的用途边界「Notes capture references, ideas, or QA artifacts that do not need a more specific type.」。这种「一句话说清类型适用边界」的写法本身就是 Portent 风格在类型文档中的体现。四、关系建模belongs_to 与 related_to 两个默认边Portent 把知识建模为图并只保留两个默认关系belongs_to主要归属、组合关系或上下文所有权/组成/语境related_to更松散的语义连接。在 Tolaria 中这些关系写在 YAML frontmatter 里用 wikilink 指向其他笔记从而保持图的可移植、可搜索、且在应用外依然可读见 src-tauri/resources/agent-docs/pages/concepts/relationships.mdbelongs_to: - [[product-work]] related_to: - [[documentation]] - [[editor-research]]仓库文档与实现给出的几个补充事实任何包含 wikilink 的 frontmatter 字段都会成为关系字段——单条或数组均可。Tolaria 开箱支持belongs_to、has、related_to三个默认关系并会动态识别自定义关系字段如blocked_by。默认关系有自动计算的反向边如果一条笔记belongs_to某个 Project该 Project 会自动在其反向关系has下展示这条笔记无需手写反向链接related_to则天然双向。关系的消费入口出入边关系出现在 Properties 面板与 Neighborhood邻域模式中后者让笔记列表变成以选中笔记为中心的图视图实现侧可参见 src/components/inspector/RelationshipsPanel.tsx。文档同时给出了一条实用判断准则正文 wikilink 用于「写作中自然出现的引用」frontmatter 关系字段用于「重要到需要在导航、过滤、邻域模式、属性面板中呈现的连接」。Portent 的belongs_to/related_to属于后者因此放 frontmatter 是规范推荐做法。五、生命周期捕获、整理、归档三阶段Portent 的核心工作流把「捕获」与「组织」刻意解耦Capture——快速捕获信息保证不丢失Organize——为其赋予类型与有用的关系Archive——当它完成使命后归档。Tolaria 对这条生命周期有直接支撑且每一步都有可验证的源码/文档依据Inbox捕获的笔记先进入 Inbox。在实现中Inbox 是一个命名过滤选择器见 src/utils/organizationWorkflow.ts 中的INBOX_SELECTION{ kind: filter, filter: inbox }说明 Inbox 本质上是一个一等视图过滤而非物理文件夹。Organize为笔记赋类型、写关系字段后它就进入「组织态」可被正常视图与自定义视图检索Archive归档会把过时或失效的笔记从活跃界面侧边栏、常规视图隐藏但内容仍然保留、可被找回——符合「归档不是删除」的安全模型。这套机制对应 Portent 的第三个核心问题「Is it captured, organized, or archived?」生命周期状态不是额外负担而是决定笔记出现在哪个视图的过滤维度。六、为什么要用 Portent空 Vault 的代价文档给出的论点值得展开一个空白 Vault 固然灵活但它要求你在还没有任何积累动能momentum之前就做出结构决策——类型叫什么、关系怎么命名、状态词表是什么。这种前期设计成本是个人知识库最常见的弃坑原因。Portent 的取舍是用 8 个默认类型 2 个默认关系换取「立刻可以捕获、组织、检索」因为全部结构都落在 Markdown 文件与 frontmatter 里同一套模型可跨本地 Vault、笔记应用、文档工具与 Agent 可读知识库复用规范不依赖 Tolaria 内部实现未来迁移不受锁死。换言之Portent 的价值不在「功能更多」而在把最常见的本体决策前置为默认值让你把精力花在内容而不是建模上。七、快速上手从 Portent 模板 Vault 开始官方文档给出的最快起点是 Portent 模板 Vaultrefactoringhq/portent-vault-template 仓库见 src-tauri/resources/agent-docs/pages/templates/portent.md 中的「Start From The Template」一节。文档建议三种使用方式原样使用克隆模板 Vault 后直接作为 Tolaria Vault 打开重命名适配语言把类型名、关系名改成你的工作语言当作参考模型不直接采用模板仅以其为蓝本设计自己的 Tolaria 结构。由于 Portent 的类型、关系、状态全部以 frontmatter 约定形式存在落地时你实际要做的只是准备类型文档type: Type的 Markdown、在笔记 frontmatter 中写type:与belongs_to:/related_to:、并按 Inbox → 整理 → 归档的节奏工作。Tolaria 侧无需任何额外插件或配置。八、Portent 概念与 Tolaria 实现对照表Portent 概念Tolaria 对应机制仓库内可查证位置类型8 种默认type:字段 Type 文档src-tauri/resources/agent-docs/pages/concepts/types.md、demo-vault-v2/type/关系belongs_to / related_tofrontmatter 中 wikilink 关系字段 自动反向边src-tauri/resources/agent-docs/pages/concepts/relationships.md、src/components/inspector/RelationshipsPanel.tsx捕获CaptureInbox 过滤视图src/utils/organizationWorkflow.ts整理Organize类型字段 关系字段 自定义视图src-tauri/resources/agent-docs/pages/reference/frontmatter-fields.md归档Archive归档隐藏出活跃视图、内容保留site/templates/portent.md状态字段lifecycle statestatus约定字段src-tauri/resources/agent-docs/pages/reference/frontmatter-fields.md需要注意的边界Tolaria 的 frontmatter 采用「约定而非强制 schema」_前缀字段保留给系统行为如_icon、_order、_pinned_properties自定义关系字段则自由添加——Portent 的规范完全运行在这一约定之上因此它对 Vault 的改造是纯文件级的随时可用 Git 回退或迁移。小结Portent 用最小的默认词汇表——8 个 PORT/ENTP 类型、belongs_to与related_to两条默认关系边、捕获/整理/归档三阶段生命周期——回答了知识库设计中最常被延期的三个结构问题。在 Tolaria 中这些约定全部落在带 frontmatter 的 Markdown 文件上类型即type:文档关系即 wikilink 字段状态即视图过滤。遵循 模板页 的指引从 Portent 模板 Vault 起步配合 Tolaria 的 Inbox 与 Neighborhood 模式即可在不设计私有本体的前提下得到一个对人、对 AI Agent 都可读的结构化知识库。【免费下载链接】tolariaDesktop app to manage markdown knowledge bases项目地址: https://gitcode.com/GitHub_Trending/to/tolaria创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考