1. 为什么我要用 Trae 搭一个 LLM Wiki 知识库如果你手头有一堆 Markdown 笔记、论文摘要、项目复盘每次想查点东西都得靠记忆翻文件夹那 LLM Wiki 这个思路值得试一次。它和传统 RAG 最大的区别是RAG 每次提问都去原始文档里重新检索一遍而 LLM Wiki 让模型把知识「编译」成结构化的 wiki 页面之后查询直接读这些页面不用每次重新推导。简单说就是把 LLM 从「临时工」变成「专职维护者」。Trae 在这里扮演的是前端 IDE 加 Agent 执行器的角色你负责往raw/丢源文档、提问题、审核结果Agent 负责写总结页、维护交叉引用、更新索引和日志。这套流程跑通之后个人知识库的维护负担会明显下降。但实际搭的时候有个绕不开的问题Trae 里的 Agent 要调用 LLM检索链路里可能还要接 embedding 或 rerank 模型如果每个模型都单独配一套 Key 和 Base URL配置会变得很碎。我这次的做法是用 TaoToken 做统一 Key 和 API 通道把对话模型、检索模型都收敛到一个入口Trae 侧只维护一份配置。下面把从文档入库到 Agent 问答的完整链路拆开讲配置骨架可以直接复制。2. TaoToken 前置统一 Key 与 API 通道准备TaoToken 在这里的作用是提供一个兼容 OpenAI 风格的 API 入口让你用同一个 Key 访问多个模型。对 Trae 这种需要同时配对话模型和检索模型的场景来说省掉了到处找 Key、改 Base URL 的麻烦。你需要先拿到两样东西API Key 和 Base URL。Key 在控制台的 API Keys 页面创建Base URL 用https://taotoken.net/api。注意这个地址后面不加任何路径后缀具体端点由客户端自己拼。创建 Key 的入口在这里控制台 API Keyshttps://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite拿到 Key 之后建议先别急着往 Trae 里塞用 curl 验一次确认通道是通的。这一步能帮你排除掉后面一半的「配置没错但就是不通」的问题。curl https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer sk-你的Key \ -H Content-Type: application/json \ -d { model: gpt-4o-mini, messages: [{role: user, content: ping}] }返回里能看到choices字段就说明 Key 和通道都正常。如果返回 401检查 Key 有没有复制全返回 404检查 Base URL 是不是多写了/v1之外的路径。模型名这块TaoToken 的模型列表可以在文档里查对话模型和 embedding 模型都有对应的名称。我实测下来对话用gpt-4o-mini做 ingest 总结够用检索链路里的 embedding 用text-embedding-3-small性价比不错。具体可用模型以文档为准接入文档https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite3. 可复制配置config.toml 与 settings.json 骨架Trae 的配置分两块一块是项目级的config.toml管 Agent 行为和模型通道一块是settings.json管编辑器侧的模型接入。下面这份骨架是我跑通之后整理的你把 Key 替换成自己的就能用。先看config.toml放在项目根目录# neo_wiki/config.toml [project] name neo_wiki raw_dir raw wiki_dir wiki schema AGENTS.md [llm] provider openai-compatible base_url https://taotoken.net/api api_key sk-你的Key chat_model gpt-4o-mini embedding_model text-embedding-3-small timeout 60 [agent] trigger_ingest /ingest trigger_query /query trigger_lint /lint max_context_files 20 log_file wiki/log.md [retrieval] mode hybrid top_k 8 rerank false几个参数说明一下。base_url只写到/api不要带/v1客户端会自己补。max_context_files控制单次 ingest 时 Agent 最多读多少个 wiki 页面超过 100 个源文档之后这个值要调小不然上下文会爆。retrieval.mode设成hybrid是关键词加向量混合检索纯向量在专有名词多的时候容易漏。再看settings.json这是 Trae 编辑器侧的模型配置放在.trae/目录下{ models: { chat: { provider: openai, baseUrl: https://taotoken.net/api, apiKey: sk-你的Key, model: gpt-4o-mini }, embedding: { provider: openai, baseUrl: https://taotoken.net/api, apiKey: sk-你的Key, model: text-embedding-3-small } }, agent: { configPath: ./config.toml, autoApprove: false } }autoApprove建议先设false让 Agent 每次写文件前都问你一下等流程稳定了再考虑放开。两个配置文件里的 Key 是同一个这就是统一 Key 的好处换模型只改model字段不用动 Key。目录结构按 LLM Wiki Pattern 的三层来neo_wiki/ ├── AGENTS.md # SchemaAgent 工作规范 ├── config.toml ├── .trae/ │ └── settings.json ├── raw/ # 不可变源文档 │ └── article.md └── wiki/ # Agent 生成的页面 ├── index.md ├── log.md ├── summary/ ├── concept/ └── entity/AGENTS.md是给 Agent 看的规范文档告诉它 ingest 时该写哪些页面、交叉引用怎么加。这个文件的内容按你自己的知识领域写核心是明确「总结页放 summary/、概念页放 concept/、实体页放 entity/」这几条规则。4. 端到端验证从文档入库到 Agent 问答配置就位之后跑一次完整链路。第一步往raw/丢一篇源文档cp ~/notes/transformer-survey.md neo_wiki/raw/第二步在 Trae 里触发 ingest/ingest raw/transformer-survey.mdAgent 会读源文档然后在wiki/summary/下生成总结页更新wiki/index.md再根据内容创建或更新concept/和entity/下的页面最后往wiki/log.md追加一条操作记录。整个过程你能在 Trae 的对话面板里看到它读了哪些文件、写了哪些文件。第三步验证检索链路。触发一次查询/query Transformer 的注意力机制和 RNN 的主要区别是什么Agent 会先走检索从wiki/里找出相关页面再基于这些页面综合出答案。如果检索命中正常你会在回答里看到它引用了具体的 wiki 页面路径。第四步用 curl 单独验一次 embedding 通道确认检索用的模型也通curl https://taotoken.net/api/v1/embeddings \ -H Authorization: Bearer sk-你的Key \ -H Content-Type: application/json \ -d { model: text-embedding-3-small, input: 注意力机制 }返回里有data[0].embedding数组就说明检索通道没问题。这一步和对话通道分开验是因为两个端点虽然同源但模型名写错时表现不一样分开查更快定位。跑通之后日常使用就是「丢文档 → /ingest → /query」这个循环。文档多了之后定期跑一次/lint让 Agent 检查有没有孤立页面、矛盾内容、失效的交叉引用。5. 本篇常见错排查配置过程中最容易卡住的几个点我按出现频率排一下。报错401 Unauthorized九成是 Key 没复制全或者config.toml和settings.json里的 Key 不一致。两个文件都检查一遍注意 Key 前后不要有空格。报错404 Not FoundBase URL 写错了。正确写法是https://taotoken.net/api不要写成https://taotoken.net/api/v1也不要漏掉/api。客户端会自己拼/v1/chat/completions这类路径。Agent 触发/ingest没反应检查config.toml里的trigger_ingest字段和你在 Trae 里输入的触发词是否一致。另外确认raw_dir路径是相对项目根目录的不是相对配置文件。ingest 时上下文超限源文档超过 100 个之后max_context_files要往下调比如从 20 降到 10。同时可以在AGENTS.md里加一条规则让 Agent 优先读index.md再决定读哪些页面而不是全量扫描。检索结果不相关先把retrieval.mode从hybrid改成keyword试一次如果关键词模式反而更准说明 embedding 模型和你的文档领域不匹配可以换一个 embedding 模型再试。另外top_k设太大也会引入噪声8 到 10 之间比较稳。写入文件权限报错Trae 的 Agent 写文件需要目录可写。确认wiki/及其子目录的权限Linux 下chmod -R 755 wiki/能解决大部分情况。6. 后续怎么用把统一 Key 的价值用满这套配置跑通之后最省心的地方是模型切换。比如你发现gpt-4o-mini做 ingest 总结质量不够想换成更强的模型只需要改config.toml和settings.json里的model字段Key 和 Base URL 都不用动。检索链路同理embedding 模型想换就换不影响对话通道。如果你打算把 Agent 检索链路长期跑起来比如做成定时 ingest 或者接进 CI可以了解一下 Coding Plan它更适合这种持续性的编码和 Agent 任务Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite想先在网页里试一下模型对话效果确认模型选型再往 Trae 里配可以用模型对话页面模型对话https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewrite我自己的习惯是新领域的第一批文档先用模型对话页面快速过一遍确认总结质量可以接受再批量丢进raw/跑 ingest。这样能避免 Agent 生成一堆质量不行的 wiki 页面之后还要回头清理。文档多了之后/lint的频率可以提到每周一次让 Agent 帮你盯着交叉引用和矛盾内容这部分人工做确实容易漏。