上个月的一个晚上我在整理自己十年来散落在硬盘各处的项目笔记、日记和工作文档忽然意识到一个很讽刺的事实我每天都在用各种 AI 工具提升效率但这些工具里没有一个是我的。在线 AI 确实强可是把财务记录、健康档案、未发表的创意甚至只是写给自己的复盘丢进别人的服务器我心里那道坎始终过不去。后来我决定做一个自己的系统代号 CortextAI——定位很明确一个私有的、完全离线的、专为个人生产力服务的 AI 操作系统。所有模型在本机运行所有数据留在本机所有工作流由你自己定义。这篇文章不写概念只讲我实际构建时的思路、架构和踩过的坑。如果你也想给自己搭一套类似的东西可以直接照着做。1. 为什么需要私人 AI 操作系统而不是再多一个 AI 聊天框1.1 在线 AI 解决不了的问题数据主权与长期记忆先说一个最直接的问题数据。我把个人知识库、日程、任务、笔记都交给某个在线 AI 助手短期看确实方便但长期看等于把数字生活的命脉交到了别人手里。你上传的每一份文档都会成为服务商训练或存储体系的一部分哪天服务调整策略、改收费模式、甚至关闭你的记忆和流程就全断了。我见过太多人把 Obsidian 笔记、Notion 文档一股脑传给在线工具结果换工具时导出极其痛苦。在线 AI 还有一个隐性瓶颈上下文窗口。不管模型参数多大单次对话能承载的信息终究有限。个人生产力恰恰是长尾场景——你积累了三年的项目记录、客户偏好、阅读笔记、健康数据这些东西没法靠临时粘贴喂进聊天框。我需要的不是一个聪明的对话入口而是一个能长期持有数据、持续积累上下文、在需要时主动把相关信息取出来的系统。CortextAI 的核心出发点就是把数据资产和AI 能力放在同一个本地环境里让模型成为这个环境的一部分而不是隔着网线的外部服务。在线工具再强它也无法理解你上周说过某个方案要重写这类私人上下文。因为上下文不是一个 prompt 能装下的它需要结构化存储、长期积累和主动检索。这才是操作系统要干的事管理数据、调度能力、维持状态。1.2 操作系统这个定位意味着什么为什么叫操作系统而不是AI 应用因为应用是孤立的操作系统是统一调度的。一个操作系统提供文件系统、进程管理、设备驱动和统一的交互接口。CortextAI 借鉴的是这套逻辑大语言模型、嵌入模型、重排模型被当作内核资源像 CPU 和内存一样被统一调度笔记、文档、日程、任务、邮件被当作文件系统有统一的存储和检索机制定时简报、自动整理、任务抽取是进程由工作流引擎按规则触发用户看到的是一个统一的入口不必关心底层用的哪个模型、数据存在哪个目录。这个架构最大的价值是解耦。应用层不需要知道某个功能用 7B 还是 32B 模型实现底层换模型、加工具、扩展能力都不影响上层交互。我后来把主模型从 7B 换成 32B整个系统几乎没动就是靠这层抽象。1.3 适合谁不适合谁说句实话这个项目不适合所有人。它适合有明确隐私顾虑、愿意折腾本地环境的人自由职业者、研究员、写作者、独立开发者还有那些拥有大量私人资料却不敢交给云端的知识工作者。它不适合完全不想维护系统的用户——本地模型要换版本、向量库要重建、任务调度要调试这些都需要点动手能力。如果你的诉求只是随手问个问题在线工具体验确实更好没必要自己折腾。我也不建议所有人一上来就上大模型。先评估自己的真实需求你是需要长期稳定的个人知识管理还是临时处理几篇文档前者值得投入时间搭系统后者用现成工具就够了。CortextAI 在我这就是后者向前者过渡的产物。2. CortextAI 的四层架构从硬件到交互每一层都在干什么2.1 运行时与硬件底座整个系统跑在一台普通台式机上Linux 系统32GB 内存加一块 12GB 显存的显卡。这个配置不算高但足够支撑我常用的 13B 和 14B 参数量级模型。如果你手里的机器更弱也不是不能跑只是要接受更低的量化等级和更慢的推理速度。配置档位最低需求能跑什么适合场景入门档16GB 内存8GB 显存7B 量化模型 基础检索轻量问答、笔记整理主流档32GB 内存12GB 显存13B/14B 模型 重排模型知识库问答、写作为主进阶档64GB 内存24GB 显存32B 模型 多模型协作复杂任务规划、长文档分析说个很实在的经验显存不够时先用 4-bit 量化把模型塞进去推理速度慢点但能力基本保留。我试过 7B 模型在 CPU 上跑回答质量还行但一个长文档总结要等十几秒这种感觉会狠狠打击使用意愿。宁可买显卡也别省这个钱。2.2 模型层主模型、嵌入模型与重排模型CortextAI 不只有一个模型。主模型负责对话、规划和生成嵌入模型负责把文档变成向量重排模型负责在检索结果里挑出真正相关的片段。三者分工完全不同缺一个都不行。我最初犯过一个错误只把主模型接进来觉得嵌入和重排用主模型也能做。实际测下来嵌入质量差的直接后果是检索召回乱七八糟主模型再聪明也答不对因为喂进去的上下文压根不对。嵌入模型和重排模型不一定很强但一定要专用。这些模型的体量都很小跑起来几乎不占资源性价比极高。2.3 能力层统一 API、函数注册与工作流引擎能力层是整个系统最核心的部分。它做的事情是把模型能调用的工具统一注册成函数由工作流引擎决定什么时候调用、调用完怎么处理结果。以任务抽取为例模型从一段自然语言里识别出明天下午三点和张三开会然后通过一个注册好的函数写入日程表。函数定义本身是标准的 JSON Schema{ type: function, function: { name: create_event, description: 创建一条日程事件, parameters: { type: object, properties: { title: { type: string }, start_time: { type: string, format: date-time }, end_time: { type: string, format: date-time }, notes: { type: string } }, required: [title, start_time] } } }模型看到这个 schema会在需要时输出一个调用请求比如{name: create_event, arguments: {...}}。系统解析这个请求、执行对应的本地函数、把结果返回给模型。这就是 agent 循环的基本单位。工作流引擎则负责更高层的编排。比如每天早上 7 点触发晨间简报流程先读取日历和待办列表再检索昨天新增的笔记把两份信息交给主模型生成一份不超过 300 字的每日摘要。这个流程不需要人工介入完全由定时器和规则驱动。2.4 数据层与应用层本地优先的个人数据组织数据层我用了三种存储文件系统放原始文档SQLite 放结构化数据任务、日程、元数据向量数据库放嵌入后的文本块。文档一律按类型/年份/项目的目录结构组织比如notes/2025/cortex-project/、journals/2025-05.md、archive/contracts/。这个结构一开始就要定好后面做知识库摄入时才不用反复整理。应用层目前有五个模块对话助手、知识库问答、写作增强、任务与日程管理、定时代理。每个模块都只通过能力层的 API 访问数据和模型彼此不直接耦合。这样我可以单独迭代某个模块不会牵一发而动全身。3. 核心功能拆解CortextAI 在我的真实工作流里做了什么3.1 统一入口与晨间简报流程CortextAI 给我的第一感受是终于有了一个统一的交互入口。过去我用 Notion、Things、备忘录、微信收藏夹信息散成一片。现在每天早上系统会自动跑一次晨间简报告诉我今天有几件事、哪些任务快要截止、昨夜有没有新增的重要笔记。主模型会把日程表、待办列表和最近笔记压缩成几行可读的文本而不是丢给我一堆原始数据。这个流程跑通之后我明显感觉自己的启动成本降低了。过去早上要挨个打开三个应用才知道今天有什么安排现在我只需要打开 CortextAI 的界面看一段话。定时流程用的是系统自带的 cron每天早上 7 点触发一个 Python 脚本脚本从 SQLite 里取数据、调用模型、生成摘要、写入消息中心。3.2 本地知识库问答与写作增强知识库问答是性价比最高的功能。我把自己写的文章、读书笔记、会议纪要全部丢进向量库然后就能用自然语言问它去年讨论过的关于知识管理分层方案的内容帮我找出来。系统先把问题转成向量在库里检索最相关的片段再用重排模型精排最后把排名靠前的几个片段作为上下文交给主模型回答。写作增强是我真正离不开的功能。我写项目周报时直接把草稿丢给 CortextAI它会把我的零散片段整理成结构化段落关键是它能引用我自己过去写的术语和结论而不是给出千篇一律的通用表达。这个能力完全依赖本地知识库在线工具是做不到的因为它没有我这三年的私人上下文。3.3 任务抽取与日程管理任务抽取依赖上一节提到的函数调用机制。我很早就设了一个规则与 CortextAI 对话时只要提到时间、负责人、截止日期它就必须尝试抽取任务并写入待办列表。系统 prompt 里有一段固定约束用户对话中如果出现明确的时间点、任务动词和对象请调用 create_task 函数。如果存在歧义先询问用户不要贸然创建。这里最值得借鉴的经验是宁可多问一句不要自作主张。模型对下周这类相对时间经常理解偏差尤其是周一早上说下周汇报到底指的是下周一还是下下周模型分不清。我在工作流里加了二次确认机制所有任务创建写进临时区第二天晨间简报时列出待确认项由用户一键确认或修正。这不仅减少垃圾任务还让模型记住了用户对时间表述的修复模式。3.4 多 AI 协作让三个模型完成一份周报单模型跑长任务经常出现前后不一致的问题。写一份周报前面还在用项目的正式说法后面就滑成了口语化表达。我在 CortextAI 里实现了多 AI 协作模式让不同模型扮演不同角色互相配合。实际是这样做的计划模型14B先根据本周的任务记录和笔记生成大纲执行模型13B按照大纲分节撰写正文审查模型7B最后检查一遍事实性错误和表达问题。审查模型的反馈会回到执行模型手里让它做修订。这个流程跑起来后周报质量明显稳定。过去我只信越大越好后来意识到多个小模型分工效果可以超过一个中等模型单独硬扛。这里有个关键细节每个角色模型的上下文是隔离的。计划模型不需要知道执行模型用了哪些句子它只需要输出大纲结构。隔离上下文减少干扰也让每个模型专注自己的任务。3.5 文件与项目管理助手最后是文件整理。CortextAI 可以定期扫描指定目录为新文件打标签、生成摘要、建议归档位置。比如我截图保存了一篇网页文章系统会跑 OCR 提取文字、生成摘要、把原文链接和摘要一起归档到articles/2025/目录并在知识库中建立索引。当然自动归档不是永远可靠。我遇到过两次系统把财务发票错归到项目文档目录的情况。解决方案很简单归档操作先进入待确认队列批量确认后真正执行文件移动。这其实是任务抽取二次确认机制的复用。系统设计里凡是涉及修改文件系统的操作都要经过确认而不是直接执行——这是我从教训里总结出的铁律。4. 从零搭建一个最小可用版本选型、步骤与代码4.1 第一步先把模型跑起来其他事情都是次要的再漂亮的架构第一步永远是先把主模型跑通。我选择推理运行时只看一条标准能否用一套统一的 API 暴露模型能力同时支持函数调用。最终选了本地推理框架因为它管理模型版本、自动处理量化格式、提供标准接口省去大量底层开发。装好之后先做一次基础问答测试确保模型本身没有配置问题然后才进入下一步。我当时的第一条命令大概是# 启动本地推理服务加载 14B 量化模型 model-service serve --model llama-3-14b-q4 --port 8080启动成功后用 curl 做一次最小验证curl http://localhost:8080/v1/chat/completions \ -H Content-Type: application/json \ -d {model: llama-3-14b-q4, messages: [{role: user, content: 你好请告诉我你现在能正常响应。}]}这一步的关键是确认函数调用能力可用而不是只看对话。我会单独发一个带函数定义的请求观察模型是否输出符合 schema 的调用请求。这一步没过后面 agent 循环根本跑不起来。4.2 第二步搭知识库管道知识库管道由四个环节组成文档加载、文本切分、嵌入、存储。我用的向量库核心就一个 Python 脚本from pathlib import Path from document_loader import load_document from text_splitter import RecursiveCharacterSplitter from embedder import LocalEmbedder from vector_store import VectorStore splitter RecursiveCharacterSplitter(chunk_size250, overlap50) embedder LocalEmbedder(model_namebge-m3) store VectorStore(path~/cortex/vdb) def ingest(path: str): doc load_document(Path(path)) chunks splitter.split(doc) embeddings embedder.embed(chunks) store.add( chunkschunks, embeddingsembeddings, metadata{source: path, date: doc.date} )chunk_size250、overlap50 这两个参数是我调出来的后面会专门讲。这里先让管道跑通能检索就行。查询端同样简单把问题嵌入在向量库里取 TopK再做一次性重排。4.3 第三步写一个精简的 Agent 核心Agent 核心就是一个循环模型决定调用哪个函数系统执行结果回填模型继续。核心代码不需要很复杂def agent_loop(user_message: str, max_turns10): messages [{role: user, content: user_message}] for _ in range(max_turns): response llm.chat(messagesmessages, toolsFUNCTIONS) if response.tool_calls: for call in response.tool_calls: result execute_local_function(call) messages.append({ role: tool, tool_call_id: call.id, content: json.dumps(result) }) else: return response.content return Reached max turns逻辑不复杂但有两个细节必须处理一是对函数执行结果做 JSON 序列化保证不会把奇怪对象传给模型二是要设置 max_turns防止模型陷入无限调用函数的死循环。我第一版没加这个限制结果有一次模型反复调用获取天气函数几十次直接把 API 打满了。4.4 第四步接入调度器与交互界面最后一步是把系统变成能主动干活的机器而不是被动回答的聊天框。我用 cron 注册了几个定时任务每天 07:00 运行晨间简报脚本每两小时扫描一次收件箱目录新文件自动进入知识库摄入队列每周日晚 21:00 生成本周回顾和下周计划。交互界面我选了一个轻量 Web 前端支持聊天和任务确认两个视图。其实对于个人使用CLI 也足够但家人偶尔也想用用Web 界面更友好。界面本身不复杂核心仍然是通过能力层 API 转发请求。4.5 我的选型理由总结回头看这套技术栈选型的核心逻辑是本机可运行、接口标准化、组件可替换。推理框架负责最难的下层兼容向量库和结构化存储保证数据可查工作流引擎让主动任务成为可能。我不追求新潮组件只追求每个环节都能在自己机器上稳定跑三个月以上。如果只让我留一个建议先跑通端到端的最小链路再慢慢加功能。很多人一上来就铺开做十个模块结果模型还没跑通就丧失了热情。从一个能回答问题的本地模型到一个能主动管理的系统中间的跨度并没有想象中那么大。5. 真实运行中绕不开的坑以及我的调优路径5.1 模型表现不好先优化上下文和工具定义再换大模型本地模型经常会犯错。我最初也以为是模型太小脑子不够用后来才发现大部分问题出在上下文没有给够、工具 schema 写得模糊。比如create_event函数的description一开始写的是创建事件模型经常漏掉时区信息。我把描述改成创建一个日程事件支持本地时间如用户未明确指定时区默认使用系统时区误用率立刻下降。另一个经典案例是模型不知道用户当前的日期和时间导致明天下周这类表达全部错乱。我在每次请求的系统消息里自动注入当前时间和用户时区这个问题就消失了。所以遇到表现不好先检查模型需要知道的信息是否都在 prompt 里再谈模型能力上限。5.2 检索质量比想象中难调chunk、重排与混合检索知识库问答最初的效果很让我失望模型经常答非所问。排查下来罪魁祸首是文本切分太粗糙。我用过 500 token 的 chunk结果一个 chunk 里塞了三个不同话题的段落嵌入向量变得四不像。后来把 chunk 调到 250 token、重叠 50检索相关度才稳定下来。重排模型的加入让效果上了一个台阶。初检召回 20 个候选块重排后只留 5 个准确率提升非常明显。还有一个小技巧是混合检索完全匹配关键词命中的片段直接参与最终筛选不单独依赖嵌入相似度。我有一批项目文档里全是领域缩写嵌入表示很差全靠关键词兜底。5.3 定时任务的不稳定模型输出格式要认真校验晨间简报跑了几周后偶尔会出现整个流程卡死的情况。后来发现是模型偶尔输出一段带注释的 JSON或者把 markdown 代码块包裹在函数调用里解析器直接崩溃。这属于典型的长尾错误很难通过调 prompt 完全消灭。我的解决方案分三层第一解析失败就整个重试一次第二进入重试前把解析错误信息回传给模型让它自己修正输出第三所有写入数据库的操作都做 schema 级校验宁可丢弃也不准脏数据落库。加完这三层定时任务的失败率从偶尔一次降到了几乎没有。这里想强调一点本地 AI 系统的不稳定性不是小问题而是核心设计问题。在线服务有团队兜底本地系统全靠规则兜底。所以任何自动流程都默认会失败必须设计重试和人工介入通道。5.4 个人数据清洗脏数据是本地系统最大的敌人个人数据不像企业数据那么干净。我的知识库里混着 PDF 扫描件、网页截图、微信聊天导出、语音备忘录转写文本格式千奇百怪。最开始我把所有东西一股脑丢进管道结果检索时经常被 OCR 错字和不完整段落干扰。后来我加了一个归一化前置步骤每个文件进入知识库前先统一转成纯文本或 Markdown去掉乱码和多余换行长文档生成摘要索引。归档目录也做了分级inbox/是未处理文件processed/是已入库文件failed/是清洗失败需要人工处理的文件。这个三级目录结构简单但极其有效。5.5 安全与备份离线不等于绝对安全最后说说安全。很多人觉得模型离线跑就等于数据安全这是误解。离线只是避免了网络传输风险本机磁盘裸奔同样有隐患。我给系统所在分区做了全盘加密所有进程按最小权限运行SQLite 数据库文件只允许特定用户读取。备份策略是每周一次全量备份到另一块移动硬盘增量备份每天执行。关于备份我吃过一次亏某次调整向量库版本时迁移脚本把索引文件搞坏了三个月积累的知识库索引全部报废。幸好原始文档还在重建索引后数据完整但过程折腾了整整一个下午。从那以后任何涉及存储结构的操作我都会先手动备份一份再动手。还有一个细节很容易被忽略本地模型的输出也会涉及隐私。比如摘要里可能包含他人的姓名、联系方式即便在本机也建议设置访问密码。我后来在 Web 界面加了一层简单的登录认证哪怕只有自己用也开着以防万一有人临时借用电脑。现在这个系统已经稳定跑了大半年。我的真实感受是最重要的不是模型本身有多聪明而是它能不能长期、稳定地融入你的个人工作流。离线不是目的获得对数据的主权才是。第一次看到晨间简报在无人干预的情况下生成出来那种生产资料终于归自己所有的感觉是任何云端助手都给不了的。如果你也在为私人数据安全和碎片化工具头疼不妨从一个小得多的版本开始——先跑通模型再接入笔记再加一个定时任务。这套系统不值得你过度投入硬件和精力但它值得你拥有一个完全属于自己、不依赖任何外部服务的数字大脑。