以人为核心的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处理后，可以同时输出三种形态：

博客：发布到blog.want.biz，结构化展示
播客：通过TTS生成音频，内嵌文字稿和封面图，同步到苹果播客
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提供思路，人类掌控执行。

它遵循三条核心原则：

做好一件事（Do one thing and do it well）：yuangs的定位不是“全能助手”，而是一个上下文治理器（Context Governor）。你始终清楚、并且显式地决定哪些文件进入AI上下文、Token预算是多少、何时采样、何时确认、什么时候允许执行。
开发者主权，而不是“方便至上”：很多终端AI工具追求“省事”，代价却是不透明——数据悄悄上传、上下文被隐式截断、执行逻辑不可审计。yuangs选择了另一条路：Swiss-Cheese采样预览（发送前看到“每一块奶酪”）、TokenPolicy（先估算、再确认）、Human-in-the-loop（切模型、发请求、跑执行，永远需要你点头）。
可编程的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遵循三条核心原则：

主权先于智能：只有拥有私钥的人类才是项目的最高统帅，AI的规则修改必须经过主权者签名。
信任但不放任（Trust, but Verify）：每一行Diff都会经过多层感知引擎（异常检测、熵值分析、风险匹配）的剥离审查。
自我感知（Self-Audit）：系统会自动监控治理健康度，识别性能漂移与权限蔓延。

5.3 技术实现

TAAGE是一个不依赖于LLM自觉性的治理引擎，通过物理脱钩的规则热加载、Ed25519签名校验、以及信用分博弈机制，为AI行为提供坚实的防御边界。

使用流程如下：

初始化：在项目根目录运行，生成主权身份——.ai/sovereign.key（主权私钥，绝不要提交到Git）和.ai/sovereign.pub（主权公钥）
配置并签署政策：创建agent.policy.yaml，定义作用域（如allow: ["src/**"]）和规则（如检查文件是否在作用域内），然后使用私钥物理签署
本地集成：通过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深度整合：

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 端到端流程

一次播客发布的完整路径：

触发：在微信/终端/编辑器中说出“把刚才那篇关于XX的文章做成播客发出去”
编排：WeClaw将消息路由到MCP服务器
生成：MCP服务器调用本地小主机执行TTS（优先微软，失败回退本地say）
封装：podcast_mixer.py生成MP3，注入元数据（标题、封面、文字稿）
存储：音频三备份——R2（分发）、iCloud（个人）、NAS（归档）
分发：更新D1数据库、刷新RSS订阅源、同步到苹果播客
通知：博客和播客同步上线

整个过程从“说一句话”到“播客上线”，全自动完成。

第九章：整合——从碎片到资产的数据流

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 设计原则的总结

回顾整个系统的构建过程，我认为以下原则是关键的：

低成本可持续：利用Cloudflare全家桶的免费额度，让系统零成本运行
本地优先：TTS、治理引擎等重计算任务在本地执行，云端只做分发
人类在环：AI提供思路，人类掌控执行——永远不把决策权完全交给AI
数据主权：所有数据存储在自己的NAS、R2、GitHub上，不依赖任何第三方平台
渐进式复杂：从单个工具开始，逐步演进为完整系统，而不是一开始就设计庞然大物
薄桥接层：每个组件只做一件事，通过API和队列连接，而不是耦合在一起

10.3 未来的方向

这套系统还在持续进化中。下一步的方向可能包括：

记忆检索MCP工具：让大模型能够查询Knowly中归档的历史知识
更智能的Agent路由：根据任务类型自动选择最合适的模型和工具链
更丰富的感知层：接入更多数据源（邮件、日历、RSS订阅）
开放化：将这套系统抽象为可复用的框架，让更多人能构建自己的AI操作系统

10.4 最后的话

构建这套系统的过程，让我深刻理解了一件事：编程的核心不是语法，而是解决问题的结构和思维。

我没有学过计算机专业——我是数学本科、世界经济学硕士，曾以两分之差惜败复旦博士。自学编程逾十年，从Python到Go到Cloudflare全家桶，一步步搭建起这套系统。

但我相信，正是非科班的背景让我更关注“系统能不能跑通、能不能持续、能不能为我所用”，而不是“这个实现是否符合教科书范式”。

这套系统还在生长。35个项目，每个都在迭代。但最重要的是，它已经从一个理念变成了每天在运行的现实——我在微信里说一句话，播客就自动生成并发布；我复制一段文字，它就自动归档到NAS；我跟AI聊一次天，它就顺便帮我发了一篇博客。

当“顺便发”成为系统调用，当对话成为操作界面，当AI成为认知引擎——这就是我理解的“个人数字操作系统”。

而它，正在每天运行着。