兰 亭 墨 苑

标题 *

URL 别名 *

内容 * (支持 Markdown 格式) # 以人为核心的AI操作系统：一个个人数字技术宇宙的构建实录 ## 引言：从工具到操作系统 2026年8月25日，我像往常一样在微信里跟AI聊了几句话，说“把刚才那篇关于XX的文章做成播客发出去”。几分钟后，一篇博客文章出现在`blog.want.biz`上，一段MP3音频自动生成并同步到了R2、iCloud和NAS三处存储，苹果播客的订阅源也随之更新。 整个过程没有打开任何一个后台界面，没有上传任何一个文件，没有填写任何一段元数据。我只是“说了一句话”。 这个瞬间让我意识到：**我构建的不再是一堆脚本和工具的集合，而是一套真正以人为核心、以AI为认知引擎的个人数字操作系统。** 这个系统由35个项目彼此连接而成——Knowly负责记忆，WeClaw负责连接与编排，yuangs负责执行，TAAGE负责治理，Sourcepack沉淀代码，TradingAgents扩展分析能力，浏览器插件成为感知器官，Cloudflare与AI Proxy提供基础设施。它们共同形成了一个属于我一个人的技术宇宙。 这篇文章，就是这套系统的完整设计记录。 ## 第一章：设计哲学——为什么需要一套个人AI操作系统 ### 1.1 问题的起点 过去几年，AI工具层出不穷。ChatGPT、Claude、Gemini、DeepSeek……每个模型都有自己的界面、自己的对话历史、自己的上下文窗口。我用它们写代码、查资料、整理思路，但每次切换工具都是一次上下文断裂，每次复制粘贴都是一次心智损耗。 更根本的问题是：**这些工具是“外挂”的，而不是“内生”的。** 它们不记得我昨天思考过什么，不知道我电脑里有哪些项目，不理解我的工作习惯和思维偏好。每次对话都是一次“从零开始”——我需要重新解释背景、重新上传文件、重新设定目标。 这就像每次开机都要重新安装操作系统一样荒谬。 ### 1.2 核心理念：以人为核心，以AI为认知引擎 我的系统设计围绕一个核心命题展开：**如何让AI从“需要被调用的工具”变成“操作系统的一部分”？** 答案是：**构建一个以人为核心的操作系统，AI是其中的认知引擎，而不是外围应用。** 这个系统的特征包括： - **感知层**：静默监听我的操作（剪贴板、浏览器、终端），自动捕获信息而不打断心流 - **记忆层**：所有捕获的信息被结构化存储，形成可检索、可关联的私有知识库 - **编排层**：多个AI Agent协同工作，根据任务类型自动路由到最合适的模型 - **执行层**：AI的决策需要人类确认才能执行，始终保持“人类在环” - **治理层**：AI的行为有规则约束，有审计日志，可追溯、可回滚 - **分发层**：一次输入，多重输出——博客、播客、笔记同步发布 这个系统不是“一个软件”，甚至不只是一个“Agent”，而是一套完整的、可扩展的、持续进化的个人数字基础设施。 ### 1.3 成本即生存：为什么选择Cloudflare 系统设计的一个重要原则是：**低成本乃至免费运行起来才能立于不败之地，否则只是空谈。** 如果一个系统再好，运维成本高到需要专门养一个人或者每月付一大笔账单，那它天然就“不可持续”。Cloudflare全家桶（D1、Workers、R2、Pages、AI Gateway、Tunnel）让这种低成本高可用变得触手可及——个人使用量远在免费额度内，全球边缘分发，零服务器运维，天然支持扩容。 这不是“抠门”，而是系统能否持续进化的生死线。 ## 第二章：Knowly——私有知识管道，对抗遗忘 ### 2.1 设计目标 Knowly（Knowledge Async）解决的是一个最朴素也最困难的问题：**如何让每一次复制，都成为知识复利**。 我们每天在电脑上复制粘贴无数次——一段文字、一张截图、一个链接。这些碎片信息如果被妥善保存和归档，就是个人知识资产的原材料；如果放任不管，就是数字世界里的熵增。 Knowly的设计目标是：**捕获时零摩擦，沉淀时零丢失**。 ### 2.2 技术实现 Knowly是一个基于Go实现的守护进程，后台静默监听Mac剪贴板： - **实时监听**：500ms轮询剪贴板变化，CPU占用极低 - **多模态支持**：自动识别并归档文本、截图（PNG）、链接，实现图文同档 - **智能识别**：自动识别URL并抓取网页标题 - **安全传输**：通过SSH协议加密传输至远程NAS，无需在服务器安装接收端 - **智能过滤**：支持敏感词过滤，避免同步密码等敏感信息 - **自动归档**：按日期自动归档到`YYYY/MM/DD/`目录结构 - **高韧性重试**：指数退避重试机制（Exponential Backoff + Jitter），网络抖动自动抚平 - **历史回溯**：`knowly history`查看最近同步记录，`knowly restore <id>`一键恢复 手机上的灵感也可以通过公网中继自动汇入，形成完整的跨设备知识采集链路。 ### 2.3 发布引擎：一次输入，三重输出 Knowly最独特的设计是内置的**Blog/Podcast/IMA发布引擎**。 一次输入——无论是剪贴板捕获的文字、手机发来的灵感，还是浏览器保存的链接——经过AI处理后，可以同时输出三种形态： 1. **博客**：发布到`blog.want.biz`，结构化展示 2. **播客**：通过TTS生成音频，内嵌文字稿和封面图，同步到苹果播客 3. **IMA笔记**：保存到腾讯IMA个人知识库 这让碎片信息在复利中沉淀为个人资产，真正实现了“对抗遗忘”的使命。 ### 2.4 K.N.O.W.L.Y.的多重内涵 Knowly这个名字本身就可以生长出一组丰富的内涵： - **官方正解**：Knowledge Async（知识的异步传输）——不打断心流、后台静默运行 - **哲学层**：Keep Notions Always Saved（让一切念头永不丢失）——对抗遗忘，对抗数字熵增 - **架构层**：Kapture, Normalize, Archive, Syndicate（捕获、标准化、归档、分发）——数据流四部曲 - **价值观层**：Keep NAS As Sanctuary（让NAS成为知识圣殿）——强调私有化、自主可控 ## 第三章：WeClaw——连接与编排的神经中枢 ### 3.1 设计目标 如果说Knowly是系统的“记忆”，那WeClaw就是系统的“神经”——负责连接与编排。 WeClaw的设计目标是：**用微信作为统一入口，无缝接入多个AI Agent，让对话成为系统调用的自然界面**。 为什么选择微信？因为微信是我每天使用频率最高的应用，它天然是移动端的“操作系统界面”。WeClaw把微信变成了AI Agent的远程控制台——从手机发一条消息，电脑上的Agent就能响应并执行。 ### 3.2 技术实现 WeClaw是一个基于Go的多Agent消息网关，一个二进制文件`scp`上去直接跑，零依赖。 核心功能包括： - **多Agent路由**：一个微信账号同时对接多个AI——DeepSeek、GPT、Claude、Gemini等，通过`@Claude`、`/i`等指令随时切换 - **图片理解**：发图给Agent自动识别，支持GPT-4o视觉模型 - **长期记忆**：`/memoryadd`记住用户偏好，每次对话自动注入，Agent越用越懂你 - **每日日志**：`/logtoday`查看今天聊了什么，按对话轮次自动归档 - **定时任务**：`/cron`定时推送、定时执行，微信端就能配置 - **多Agent协作**：`/debate`辩论模式、`/roundtable`圆桌讨论，多个AI一起帮你分析 - **MCP工具**：接入知乎搜索、文件操作等外部工具，Agent不只是聊天 - **Admin管理**：Web界面管理Agent、记忆、日志、定时任务，手机也能用 ### 3.3 设计哲学：薄桥接层 WeClaw的设计原则是**保持桥接层足够薄，不重新发明编排系统**。它只负责把微信入口、智能体调用、发送和日志拼成一个可预测的闭环。 这意味着WeClaw不做重度的业务逻辑，而是专注于“连接”——把微信消息路由到正确的Agent，把Agent的响应发送回微信。真正的智能和编排，交给上层的Agent和MCP服务器。 这种“薄桥接层”的设计，让WeClaw既轻量又灵活——它不仅能做“聊天机器人入口”，也可以被其他系统当成一个微信发送网关来调用。 ## 第四章：yuangs——可编程的Agent基础设施 ### 4.1 设计目标 如果说WeClaw是“连接”的神经，那yuangs就是“执行”的肌肉。 yuangs的设计目标是：**为终端而生的AI治理运行时——不OOM，不惊喜，始终有人类在环**。 它解决的是一个更难的问题：**当不可控的AI进入极端强调可控性的终端，秩序该如何重建？** ### 4.2 设计哲学 yuangs的核心理念是：**AI提供思路，人类掌控执行**。 它遵循三条核心原则： 1. **做好一件事（Do one thing and do it well）**：yuangs的定位不是“全能助手”，而是一个**上下文治理器（Context Governor）**。你始终清楚、并且显式地决定哪些文件进入AI上下文、Token预算是多少、何时采样、何时确认、什么时候允许执行。 2. **开发者主权，而不是“方便至上”**：很多终端AI工具追求“省事”，代价却是不透明——数据悄悄上传、上下文被隐式截断、执行逻辑不可审计。yuangs选择了另一条路：Swiss-Cheese采样预览（发送前看到“每一块奶酪”）、TokenPolicy（先估算、再确认）、Human-in-the-loop（切模型、发请求、跑执行，永远需要你点头）。 3. **可编程的Agent基础设施，而不是Prompt Wrapper**：yuangs发布到npm的不是一个“命令”，而是一套可组合的Agent运行时。核心抽象包括PendingContextItem、上下文估算/解析分离、能力感知的执行策略、可回放可审计的执行记录。 ### 4.3 核心特性 yuangs具备以下核心能力： - **No OOM, No Surprise**：再大的仓库、再长的日志，没有确认就不会吃内存、不会发送 - **Human-in-the-loop, Always**：系统永远不会替你做黑盒决策 - **Power of Syntax**：`@file`、`#dir`、意图语法，比拖拽文件更快、更酷 - **可回放、可审计**：每一次AI行为都能复盘、复现、调试 - **可解释、可治理**：通过`explain`和`replay`命令，理解系统决策过程 - **AI Governance Web Console (Beta)**：可视化治理面板，提供R3级风险的全屏阻断与视觉警报 ### 4.4 架构概览 yuangs的架构体现了“本地优先、加密隧道、治理前置”的设计思路： ``` 用户 → yuangs本地CLI → Express Web Server ├── WebSocket → Web Terminal (xterm.js) ├── 本地治理引擎 (Governance Engine) └── SSH连接 → 远程服务器 (加密隧道) ``` 治理引擎会拦截/阻断风险操作，SSH会话会录制为`.cast`/`.md`审计日志。 ## 第五章：TAAGE——主权优先的AI治理引擎 ### 5.1 设计目标 TAAGE（Trusted AI Agent Governance Engine）解决的是一个日益紧迫的问题：**当AI Agent获得了读写文件、调用API、操作系统的权限后，如何确保它们的行为是可控的、可审计的、可回溯的？** TAAGE的设计理念是：**主权先于智能（Sovereignty Over Intelligence）**。 ### 5.2 核心原则 TAAGE遵循三条核心原则： 1. **主权先于智能**：只有拥有私钥的人类才是项目的最高统帅，AI的规则修改必须经过主权者签名。 2. **信任但不放任（Trust, but Verify）**：每一行Diff都会经过多层感知引擎（异常检测、熵值分析、风险匹配）的剥离审查。 3. **自我感知（Self-Audit）**：系统会自动监控治理健康度，识别性能漂移与权限蔓延。 ### 5.3 技术实现 TAAGE是一个不依赖于LLM自觉性的治理引擎，通过**物理脱钩的规则热加载、Ed25519签名校验、以及信用分博弈机制**，为AI行为提供坚实的防御边界。 使用流程如下： 1. **初始化**：在项目根目录运行，生成主权身份——`.ai/sovereign.key`（主权私钥，绝不要提交到Git）和`.ai/sovereign.pub`（主权公钥） 2. **配置并签署政策**：创建`agent.policy.yaml`，定义作用域（如`allow: ["src/**"]`）和规则（如检查文件是否在作用域内），然后使用私钥物理签署 3. **本地集成**：通过`TrustedGuard.evaluate()`一键评估AI提案——自动加载政策、校验签名、执行审计并记录日志 运行一段时间后，引擎会自动发现“信任模式”（AI经常成功修改的路径，建议提拔为信任域）和“频繁违规”（频繁被拦下的规则，建议加强硬化），所有洞察存储在`.ai/governance_assets.json`。 TAAGE的许可证基于MIT协议分发，开发者拥有对AI的最高指挥权。 ## 第六章：Sourcepack——代码快照，为AI辅助开发而生 ### 6.1 设计目标 Sourcepack解决的是一个非常具体的痛点：**如何把一个项目代码库完整、结构化地喂给LLM？** 直接复制粘贴代码文件，会丢失目录结构；逐个文件上传，效率太低；用压缩包，LLM又无法直接解析。Sourcepack的做法是：**一键将项目代码库转换为AI可读的Markdown快照**。 ### 6.2 技术实现 Sourcepack是一个用Go编写的极简、高性能工具： - **生成的快照包含**：项目结构树（目录优先、字母排序）、文件目录（带锚点跳转的文件索引）、完整源码（自动语法高亮、智能处理嵌套代码块） - **智能过滤**：自动处理`.gitignore`和`.gdignore`，支持`!`否定、`**`通配等完整gitignore语法；自动跳过二进制文件 - **统计功能**：`-s`输出多维度统计（文件、目录、语言、Token分布） - **便捷操作**：`-c`一键复制到剪贴板，`-p`一键推送到远端中继（如knasync API） - **极速处理**：Go编写，秒级处理万行代码 ### 6.3 与系统的整合 Sourcepack通过`-p`参数与knasync API深度整合： ```bash export SOURCEPACK_PUSH_URL="https://api.want.biz/submit" export SOURCEPACK_AUTH_KEY="your-secret" sourcepack -p # 推送完整文档 sourcepack -s -p # 只推送统计数据 ``` 这意味着，一个项目的代码快照可以一键推送到系统的知识管道中，被Knowly归档、被AI Agent读取、被博客系统引用——代码资产和知识资产在同一个系统中流动。 ## 第七章：基础设施——Cloudflare与API网关 ### 7.1 knasync API：队列分发系统 `https://api.want.biz`是整个系统的“消息总线”——一个基于Cloudflare Workers + D1数据库的远程剪贴板/内容队列分发系统。 核心接口包括： - **POST `/submit`**：手机/外部来源提交内容到输入队列，自动识别知乎链接分流至对应队列 - **GET `/pull`**：消费者拉取输入队列（Chrome扩展拉取知乎队列，Knowly拉取通用队列） - **GET `/peek`**：只读查看待处理任务 - **POST `/push`**：消费者推送处理结果到广播结果队列 - **GET `/results`**：所有客户端增量拉取处理结果（支持游标） - **POST `/publish`**：IMA/博客/播客一站式发布 这个API网关的设计体现了“队列即总线”的架构思想——所有组件通过队列通信，解耦了生产者和消费者，让系统可以异步、可靠地运行。 ### 7.2 各客户端的接口映射 | 客户端 | 动作 | 调用接口 | |--------|------|----------| | 手机快捷指令 | 提交链接/文本 | POST `/submit` | | Chrome扩展 | 拉取知乎任务 | GET `/pull?queue=zhihu` | | Chrome扩展 | 推送处理结果 | POST `/push` | | Knowly Relay | 拉取通用任务 | GET `/pull?queue=general` | | Knowly Relay | 推送处理结果 | POST `/push` | | Knowly ResultPuller | 拉取广播结果 | GET `/results?since=...` | | WeClaw | 推送Q&A对/断线通知 | POST `/push` | ### 7.3 关联服务 - **IMA笔记发布**（`https://api.yuangs.cc/api/ima/import`）：将Markdown内容保存至IMA个人知识库 - **博客发布**（`https://api.yuangs.cc/api/publish`）：将文章发布至`blog.want.biz` - **播客生成**（`https://api.yuangs.cc/api/publish` with `targets:["nas"]` + `transform:"read"`）：推送到NAS朗读队列，生成音频 ## 第八章：播客生产线——从对话到音频的全自动流程 ### 8.1 设计目标 播客生产线的设计目标是：**让“发一期播客”从“打开后台、上传音频、填标题、写简介、选封面、点发布”变成对话里的一个自然动作**。 ### 8.2 技术架构 播客生产的核心是一个Python脚本`podcast_mixer.py`，它实现了： **双TTS引擎互为备份**： - **微软Edge TTS**：主力引擎，提供高度自然的神经语音 - **本地macOS `say`命令**：离线备用引擎，零成本、即时可用 - 通过环境变量`PODCAST_TTS_ENGINE`切换，微软引擎失败时自动回退到本地引擎 **情绪驱动系统**： - `EMOTION_VECTORS`将情绪标签（happy、sad、angry、calm等）映射为连续维度（valence、arousal、dominance） - `EMOTION_TO_RATE`将情绪映射为具体语速 - `smooth_emotion_vectors`实现整集情绪的平滑过渡 - `detect_climax`检测情绪高潮点 **智能音频处理**： - `detect_topic_changes`根据话题变化自动检测BGM切换点 - `mix_audio_with_multi_bgm`支持多段BGM切换和淡入淡出 - `silenceremove`自动去除音频首尾静音 **元数据自动注入**： - 使用`mutagen`库将标题、封面图、文字稿（`USLT`帧）写入MP3文件 - 封面图存储在R2，通过CDN加速分发 **并发渲染**： - 使用`ThreadPoolExecutor`实现多段TTS并发生成 - 限制并发数为2，避免macOS CoreAudio资源竞争 ### 8.3 端到端流程 一次播客发布的完整路径： 1. **触发**：在微信/终端/编辑器中说出“把刚才那篇关于XX的文章做成播客发出去” 2. **编排**：WeClaw将消息路由到MCP服务器 3. **生成**：MCP服务器调用本地小主机执行TTS（优先微软，失败回退本地`say`） 4. **封装**：`podcast_mixer.py`生成MP3，注入元数据（标题、封面、文字稿） 5. **存储**：音频三备份——R2（分发）、iCloud（个人）、NAS（归档） 6. **分发**：更新D1数据库、刷新RSS订阅源、同步到苹果播客 7. **通知**：博客和播客同步上线 整个过程从“说一句话”到“播客上线”，全自动完成。 ## 第九章：整合——从碎片到资产的数据流 ### 9.1 完整数据流 整个系统的数据流可以概括为： **捕获层**（Knowly剪贴板监听、浏览器插件、手机Taio、Markdown编辑器）→ **传输层**（SSH加密隧道、knasync API队列）→ **处理层**（AI Agent编排、TTS生成、代码快照）→ **存储层**（D1数据库、R2对象存储、NAS文件系统、iCloud）→ **分发层**（博客、播客、IMA笔记） ### 9.2 闭环系统 这个系统不是线性的，而是**闭环的**： - 博客文章可以被Knowly的剪贴板监听再次捕获，进入知识库 - 播客音频的文字稿可以反向成为博客文章的内容 - 代码快照（Sourcepack）可以喂给AI Agent进行代码审查 - AI Agent的对话记录可以通过WeClaw归档到Knowly 每一次输入都在为下一次输出积累素材，每一次输出都在丰富系统的知识资产。这就是“知识复利”的工程化实现。 ## 第十章：总结与展望 ### 10.1 系统的本质 回顾这个系统的全部设计，我认为它的本质是：**把“数据”转化为“知识资本”的持续交付流水线。** 它不是“一个软件”——它是一整套基础设施。 它不是“一个Agent”——它是多Agent协同的编排系统。 它不是“一个工具”——它是35个项目彼此连接的生态系统。 它的核心价值在于：**让AI从“需要被调用的外部工具”变成“操作系统内在的认知引擎”** 。 ### 10.2 设计原则的总结 回顾整个系统的构建过程，我认为以下原则是关键的： 1. **低成本可持续**：利用Cloudflare全家桶的免费额度，让系统零成本运行 2. **本地优先**：TTS、治理引擎等重计算任务在本地执行，云端只做分发 3. **人类在环**：AI提供思路，人类掌控执行——永远不把决策权完全交给AI 4. **数据主权**：所有数据存储在自己的NAS、R2、GitHub上，不依赖任何第三方平台 5. **渐进式复杂**：从单个工具开始，逐步演进为完整系统，而不是一开始就设计庞然大物 6. **薄桥接层**：每个组件只做一件事，通过API和队列连接，而不是耦合在一起 ### 10.3 未来的方向 这套系统还在持续进化中。下一步的方向可能包括： - **记忆检索MCP工具**：让大模型能够查询Knowly中归档的历史知识 - **更智能的Agent路由**：根据任务类型自动选择最合适的模型和工具链 - **更丰富的感知层**：接入更多数据源（邮件、日历、RSS订阅） - **开放化**：将这套系统抽象为可复用的框架，让更多人能构建自己的AI操作系统 ### 10.4 最后的话 构建这套系统的过程，让我深刻理解了一件事：**编程的核心不是语法，而是解决问题的结构和思维。** 我没有学过计算机专业——我是数学本科、世界经济学硕士，曾以两分之差惜败复旦博士。自学编程逾十年，从Python到Go到Cloudflare全家桶，一步步搭建起这套系统。 但我相信，正是非科班的背景让我更关注“系统能不能跑通、能不能持续、能不能为我所用”，而不是“这个实现是否符合教科书范式”。 这套系统还在生长。35个项目，每个都在迭代。但最重要的是，它已经从一个理念变成了每天在运行的现实——我在微信里说一句话，播客就自动生成并发布；我复制一段文字，它就自动归档到NAS；我跟AI聊一次天，它就顺便帮我发了一篇博客。 当“顺便发”成为系统调用，当对话成为操作界面，当AI成为认知引擎——这就是我理解的“个人数字操作系统”。 而它，正在每天运行着。

配图 (可多选)

标签