柏树项目：测试人工智能智能体是否能够维护公司的Markdown Wiki。

Obsidian 能在个人的项目与其编码工具之间传递上下文。计划、决策、需求和限制条件不会因单次会话的结束而消失，Claude、Codex 或其他任何工具都能读取相同的项目文件，而人类用户可以查看并修改这些文件，更换模型时也不会让项目相关知识被困在聊天记录中。这种方式在个人的项目中运作良好，因为决策大多由该人做出，且其清楚所有内容的组织方式。

在公司内部，情况则有所不同。知识分散在各种存储库、工单、会议记录、文档以及不同人员手中。各种信息相互矛盾，决策也常常被推翻。某份会议记录可能描述了团队后来放弃的想法，而经过批准的架构文档则载有最终确定的决策。因此，一个关键问题是：针对单个项目的习惯能否推广到整个组织？共享的 Markdown 格式是否能够成为员工与自动化工具之间的共识。

LLM Wiki 的构想

这一模式源自安德烈·卡帕西最近提出的一项建议，他将其命名为 LLM Wiki。它包含三个层次：

• 从不被修改的原始资料
• 由自动化工具维护、相互关联的 Markdown 维基页面
• 用于指导自动化工具如何组织及维护该维基的架构规范

有三种操作作用于这些层。Ingest功能用于引入新的数据源；Query功能则利用已存储的知识；Lint功能则会检查维基页面中是否存在缺失内容、过时信息、冲突以及组织结构混乱的问题。

提案中提到的潜在数据源包括Slack对话记录、会议内容、项目文档以及客户通话记录，这些信息会被智能体整合成知识，并在各项任务之间持续保留。这与那种每次有人提问时才检索少量相关片段的系统不同——在这里，智能体会不断留存信息，并随着新数据的加入而持续更新这些知识。

首个被证明有误的架构

对LLM Wiki的初步理解会让人认为应该设置两个独立的知识层：由智能体生成的维基页面，以及放置在其之上的Obsidian文件。但实际上这种设计并无必要，因为它会导致内容重复，并引发同步问题。

生成的 Markdown 本身就可以构成维基，而 Obsidian 只是查看、阅读和编辑页面的窗口而已。Markdown 是共同的规范，而 Obsidian 则是人们工作的平台。即便更换不同的窗口，其下的知识内容依然保持不变，这正是真正维基的运作方式。一个组织可以通过 SharePoint、Confluence 或内部门户发布经过审批的页面，而工程师和工作人员则继续在维护好的源代码上进行工作。

建议的流程如下：公司来源提供不可更改的原始证据。维基维护者代理会利用架构和治理规则提出修改建议，经审核通过后的更改会在Git支持的Markdown维基中发布。服务层负责处理身份验证、权限管理、搜索以及审计日志。人们通过Obsidian或公司维基获取知识，而代理则使用相同的服务层，并拥有各自的身份和权限。

企业知识需要的不仅仅是笔记间的链接

个人知识库之所以能发挥作用，部分原因在于其所有者能够记住文件相关的背景信息：哪份会议笔记是推测性的，哪些需求在未被所有相关页面更新的情况下发生了变化，以及哪两份文件以不同名称描述了同一个决策。企业无法依赖某一个人来记住所有这些信息。

其知识系统必须能够区分：

• 仅仅是提案与已被批准的决策
• 当前有效的内容与仅属于历史的东西
• 正式政策与会议中的随口提及
• 已解决的矛盾与尚未解决的矛盾
• 记录中的空白与尚无人做出的选择

除此之外还有具体的负责人、审核流程、对来源的引用、内容更新规则、访问权限限制，以及记录某位操作员做了哪些更改的轨迹。个人的知识库可以容忍模糊性，因为负责人会记住缺失的内容。而共享的公司级系统绝不能让一句随口的話悄无声息地变成已被批准的决策。

这就是架构重要的原因。它不仅仅用于为文件夹和文件命名。通过它，操作员能够了解该公司如何编码其知识。单个维基页面的元数据可能如下所示：

status: verified
owner: platform-team
last-reviewed: 2026-08-02
review-after: 2026-11-02
sources:
  - adr-014
  - meeting-2026-07-29
supersedes:
  - authentication-proposal-v1

让代理生成 Markdown 非常容易，而界定它应视为何种“组织事实”才是难点。

以虚构公司作为测试平台

公共软件仓库的复杂度尚不足以应对这类问题。一个结构清晰的仓库可以用于处理数据导入、链接建立以及基础查询，但它本身并不包含不断变化的客户需求、利益相关者之间的分歧、非正式笔记、过时的架构，或是权力不平等的来源。

为了解决这一问题，该实验设计了“雪松项目”：一个虚构的合作场景，其中Northstar AI Consulting为Prairie Health Network提供服务。这一切都是假的。这家咨询公司正在开发一种系统，能够将政策文件及质量评估记录转化为带有来源链接的摘要草案，并提供内部搜索功能。这一设想反映了现实中的诸多担忧，比如敏感数据保护、本地计算与云端计算的差异、人工审核、模型评估、架构选择、来源追溯，以及不断变化的需求。

该合成语料库包含25个初始的Markdown文档。在现实中，这些文档可能有多种格式，但测试允许这种简化处理。内容涵盖相关公司的背景信息、客户的政策与要求、架构决策、会议记录、模型评估结果、实施工作记录、进度报告以及风险项。

随后出现的另一组8个文档则反映了项目的变化：安全要求变得更加严格，模型评估结果推翻了之前的假设，验收标准也发生了变动，同时一项新的架构决策取代了原有的设计，不过某份非正式的会议记录仍继续描述着旧设计的部分内容。这些变化用于测试应用程序是否能够对已存储的知识进行更新。

还有两个仅供评估工具使用的文件。一个是知识图谱，记录了刻意植入语料库中的事实、决策、冲突及关联信息，作为真实信息的来源。另一个是一组评估问题，附有预期答案和所需的来源证据，用于判断知识是否已正确更新。维基维护代理在构建过程中绝不能看到这些文件，因此该测试旨在确认它确实重建了这家虚构公司的知识体系，而非仅仅编写了一个看似合理的维基页面。

可能失败的实验

计划中的方案分为两个阶段。

在A阶段，智能体接收初始语料库并构建第一个Markdown维基。它需要说明公司正在开发什么、有哪些约束限制着系统、原始架构的设计思路、还存在哪些未解决的风险、哪些决策尚未确定，以及每个答案的依据来自何处。在任何后续证据出现之前，该维基及其内容必须被保存下来。

B阶段会发布更新后的语料库。此时智能体必须修改所有受影响的页面，将已被取代的决策以历史记录的形式保留下来，让存在的分歧显露出来，并且避免将最新的文档视为最终结论。Git差异对比结果也会成为证据——它能显示现有知识是否保持了连贯性，还是仅仅被又一份总结所取代。

这就是完整的流程。首次真正的实现采用了不同的路径，因为它是在另一项实验中开发的——在该实验中，一个人工智能代理在长途驾驶期间完成了一个软件项目。

首次构建

第一个Cedar版本源自那次驾驶实验，其细节并无重要意义。重要的是该代理最终完成了什么任务。它的输入数据来自Cedar语料库、项目相关指令，以及一组对其隐藏的评估数据。当时使用的ChatGPT项目将上传文件数量限制在25个以内，因此最初的25份成果中只有8份传达到了代理手中，而修改后的语料库则被暂存，待日后用于测试它是否能够将更改应用到文档中。

返回的结果是一个用 Python 编写的本地命令行程序。它能够读取 Markdown 源文件及其前置信息，提取出带有确切来源行的证据，并独立于发布时间来评估信息的权威性。标明版本的文档会被标记为当前版本或历史版本。该工具还能生成 Markdown 格式的知识报告，检索与问题相关的证据，以及检查维基页面的结构缺陷。源文件与生成的 wiki/ 文件夹分开存放，而仓库则将维护指南、运行记录、评估资料及输出结果分别保存在相应位置。所有26项测试均通过。虽然由于数据量减少只能测试 Cedar 协议的一小部分功能，但这已经是一个可正常使用的初始版本。

它能否保存公司的知识体系？

在受限评估中，该系统的得分为50%。它在保留证据方面表现良好：来源引用和行级溯源信息能够准确显示提取出的事实的出处。难点在于当遇到实际问题时，如何找到并读取正确的证据。

一个真正的公司问题可能需要从多个文件中整合信息，优先考虑经过审批的决策而非随意的笔记，注意较新的文档可能具有较低的权威性，区分未解决的问题与记录中的缺失部分，并在尚未做出最终决定时保持不确定性。证据保留比证据筛选更为重要。结构审计能够发现诸如缺少元数据或布局混乱之类的技术缺陷，但语义冲突则更易被忽视，因为两份文档可能在表述上存在矛盾，而系统并不总能察觉到这种冲突。

简而言之，引用被保留了下来，但却没有人判断哪些引用具有实际价值。这对于企业知识管理而言是个重大缺陷，因为即便引文众多，如果其依据的来源权威性较低、忽略了后来被认可的决策，或是将本不应关联的事实拼凑在一起，那么这样的答案依然可能是错误的。

不完整的数据集也限制了结论的可靠性。该系统从未接收到更新后的数据集，因此此次测试并未涉及原始设计中最棘手的部分：在权威来源发生变化时更新现有知识，同时将旧状态作为历史记录保留下来。目前的部分结论是，智能体能够构建企业知识的结构化、带来源标注的表示形式，但目前还缺乏足够证据表明它能够在企业不断变化的情况下可靠地维持这种表示形式。

维基需要企业专用界面

该实验还阐明了关于架构的一个要点。Obsidian非常适合查看生成的Markdown内容、点击链接、检查元数据以及手动修改页面。这对于个人设置或原型开发已经足够，但任何公司都无法让每位员工和代理直接访问同一个存储库。在Markdown维基与其用户之间，一个真正的系统需要一个中间层，该层应具备以下功能：

• 由公司的身份验证服务处理登录流程
• 与用户、团队、项目及角色相关的访问规则
• 为每位代理分配具有不同权限的独立身份
• 对代理提出的每项修改进行审核和批准流程
• 根据请求者可查看的内容筛选搜索结果
• 评论、通知及内容所有权管理
• 支持同时编辑并处理版本冲突
• 记录下修改每页内容的人员或系统，形成审计追踪

数据保留与删除策略

非技术人员也能实际使用的界面

身份认证用于确定请求者是谁，而授权则决定该身份可以访问哪些资源，包括数据来源、页面及操作内容。代理也遵循同样的划分原则。由于财务团队的文件与临床记录都存储在同一个维基中，其代理不应能够访问临床记录，因此代理需要拥有独立的身份标识、受限的权限以及与人类相同的审计要求。当代理对信息进行修改时，权限设置也必须随之调整：即便某个页面看似无害，但从公开架构文档中提取的项目摘要以及受限的安全审查内容仍可能泄露敏感信息。

Obsidian 可以继续作为维护人员和技术审阅者的工作台，而大多数员工则通过维基网站或内部门户获取知识，这些平台通过受控服务读取相同的维护后的知识内容，而不会创建副本。该架构由四部分组成：

1. 证据层：保留原始权限的不可更改的公司资料
2. 知识层：基于 Git 的 Markdown 维基及其源代码关联关系
3. 控制层：身份认证、权限管理、审核流程、审计记录及搜索功能
4. 接口层：供维护维基的人员使用的 Obsidian、供员工使用的公司维基网站，以及为自动化工具提供的受限 API

公司接口不会复制知识内容，而是控制用户和自动化工具与这些知识的交互方式。

下一步需要测试的内容

下一次运行应使用完整的Cedar语料库：导入最初的25个文档，对初始的维基页面进行评分并保存，接着加入8个变更后的文档，检查该系统是否更新了所有受影响的页面、将旧决策标记为已被取代、保留有价值的历史记录、遵循来源权威性规则、展示尚未解决的分歧、避免擅自做出决策，同时生成可供人审查的Git差异文件。

检索性能应与维护功能分开评估。某个系统可能拥有正确的知识，但在回答问题时却检索到错误的证据；或者虽然通过搜索原始资料给出了正确答案，但其维护的维基内容却已经过时——这类故障需要不同的评估标准。在后续阶段，应在语料库中加入用户和智能体的身份信息，这样就能确保只有经过授权的审核者才能获得正确答案，而其他用户则无法获取受限信息。这使实验更接近于实际企业环境中的应用。

智能体能否维护企业的知识库？

Cedar的第一个版本仅支持生成符合标准的答案。该系统能够处理类似企业文档的内容，保留来源引用，为文档版本加标签，生成Markdown格式的wiki，并对其结构进行审核。但评估结果显示这些功能仍显不足，因为维护企业知识还需要具备恰当筛选证据、判断信息权威性、识别冲突、处理不确定性以及实施审核与访问控制的能力。

Markdown可以作为一种通用载体，但企业仍需要为其建立规范的接口管理机制。无论是人员还是智能代理都需要身份认证，权限必须从源头传递到生成的页面中，智能代理的编辑内容需要审核，每项被接受的更改都需要留下记录。创建维基页面只是较简单的一部分，真正需要耗费精力的是确定企业认为哪些内容属于知识资产、谁有权限查看这些内容，以及智能代理如何被允许对其进行修改。