Barbot 所有场景 Agent，都建立在同一层知识之上：LLM Wiki。
芯片企业并不缺文档。缺的是一份版本清楚、冲突可管、结论找得到出处的知识。官网、共享盘、代码仓库、工单、个人笔记各写各的，Agent 如果只做切片检索，回答会流利，依据却对不上号。
我们不依赖把资料切碎后「大海捞针」。LLM Wiki 把散乱文档编译成可维护知识：结论可追溯，版本与冲突可管理，并持续适配 Agent 的工作方式。
它把资料变成什么
LLM Wiki 将芯片、参数、外设、API、SDK、方案和工程结论，组织成相互关联的知识对象。Agent 拿到的是完整上下文，而不是互不相干的检索片段。
典型流程是：
- 资料接入与结构解析：PDF、网页、SDK、代码、表格
- 知识编译与关系建立：型号、版本、有效期、适用条件
- 结论与证据关联：重要判断能回到具体位置
- 专家审核与持续更新：冲突先被发现，再由人裁定
核心能力
- 多来源资料统一管理
- 型号、版本与有效期管理
- PDF、网页、SDK、代码和表格解析
- 知识冲突发现与人工审核
- 企业权限、私有部署与数据隔离
对芯片原厂、代理商、方案公司和拥有大量技术资料的工程组织，价值很直接：回答更准、来源可查，专家经验不再只存在于某个人的聊天记录里，P2P Agent、AI FAE、Coding Agent 和 Harvey Agents 共用同一底座。
和「再接一个知识库」的差别
很多团队已经有向量检索。LLM Wiki 要解决的是更前面的问题：资料有没有被编译成 Agent 用得上的对象，冲突有没有人管，过期型号会不会继续被推荐。
先把知识做对，场景 Agent 才站得住。这也是 Barbot「先现场、再产品化」里，必须先建的那一层。
对外可体验的第一份库是 Barbot Selection Library：按终端应用组织汽车与工业模拟选型知识。官网右下角的 智能客服 是把它接到真实网站上的最佳实践，完整工作台在 ask.chatbarbot.com。
