通过 yuangs、TAAGE、Knowly、wsstunnel 等 24 个项目，构建以“主权先于智能”为核心的个人技术操作系统，实现 AI 可治理、知识可沉淀、网络可穿透、决策可审计的完整闭环。

一个人的技术宇宙

—— 苑广山（yuanguangshan）24 个项目的全景透视

写于 2026 年 6 月

这不是一份简历。这是一次技术人格的深层扫描——当一个人同时撰写 AI 治理协议、构建 WebSocket 隧道、设计多智能体交易系统、制作每日播客、并且用 Go/Python/TypeScript 武装到牙齿时，他到底在建造什么？

序章 · 三根支柱，一个灵魂

如果你打开 /Users/ygs/ygs/ 这个目录，你会看到 24 个独立的项目文件夹。初看像是一个极客的游乐场——从 Python 到 Go，从 Cloudflare Workers 到本地守护进程，从微信聊天到期货交易，从终端插件到 AI 治理引擎。但当你深入每一条代码的纹理，你会发现一条清晰的主线贯穿所有项目：

主权先于智能。治理先于能力。人，永远是最终的执行者。

这不是一句口号。这是每一行代码背后沉默的共识。

这个宇宙由三根支柱撑起：

支柱一：AI 治理与增强工具（主权之柱）

yuangs CLI — AI‑Augmented Shell，让 AI 提供思路，人类掌控执行
vsyuangs — VS Code 中的 AI Agent 插件，治理型 AI 编程助手
TAAGE — 可信 AI 代理治理引擎（Node.js + Python 双实现）

支柱二：个人知识系统（沉淀之柱）

Knowly — 剪贴板→NAS 的私有知识管道
knasync — Cloudflare 边缘内容队列
chats — AI 热点内容创作与实时协作平台
wxwatcher — 文件变更监控 + 微信通知

支柱三：网络与终端基础设施（穿透之柱）

wsstunnel — WebSocket 远程 Shell 隧道
WireGuard — 多节点私有 VPN 网络
Tmux-FSM — 有限状态机驱动的 tmux 模式插件
Sourcepack — 代码快照生成器
poeapi_go — 多模型 API 代理网关

而在这三根支柱之间穿针引线的，是 WeClaw（微信 AI 桥接器）、WeChatBot（微信聊天机器人）、TradingAgents（多智能体交易系统）、Podcast（自动化播客系统）、Mini Blog（无服务器博客）等一个个功能完备的应用——它们像卫星一样围绕核心轨道运行，彼此形成数据闭环。

这不是一堆项目。这是一个人的技术操作系统。

接下来，我们将逐层剥开这个宇宙。

第一幕 · AI 治理：当 AI 可以替人做决定

1.1 问题意识：为什么需要治理？

2024-2025 年间，AI 编码工具大爆发。Cursor、Copilot、Claude Code、Codex……它们能写代码、能跑命令、能读文件。但它们带来一个根本性的问题：当 AI 可以替人做决定时，如何确保人仍然是最终的主人？

大多数工具的答案是"信任 AI"。但这位开发者的答案是：不信任，要治理。

这就是 yuangs 的起点。

1.2 yuangs CLI：AI‑Augmented Shell

项目位置: npm_yuangs/
技术栈: TypeScript, Node.js
npm 包名: yuangs
版本演进: v1.3 → v2.40+

核心思想

yuangs 不是又一个"聊天机器人 CLI"。它的设计文档中有一段话，是理解整个项目的钥匙：

"AI 除非被明确要求，否则不应该比输入看起来更聪明。"

这句话的精髓是：AI 的能力是被授予的，而不是默认拥有的。每一次上下文注入、每一次命令执行、每一次文件读取，都必须经过明确的用户关卡。

架构骨架

从 src/ 目录的树形结构可以看出 yuangs 的分层设计：

src/  
├── cli.ts                          # CLI 入口（Commander 解析）  
├── index.ts                        # 库导出（供 embedder 使用）  
│  
├── agent/                          # Agent 运行时层  
│   ├── AgentRuntime.ts             # Agent 编排核心  
│   ├── LLMCaller.ts                # LLM 调用封装  
│   ├── PreFlightChecker.ts         # 执行前检查  
│   ├── ExecutionHandler.ts         # 安全执行处理器  
│   ├── smartContextManager.ts       # 智能上下文管理  
│   ├── governance/                  # 治理引擎集成  
│   │   ├── core.ts                 # 政策评估核心  
│   │   ├── bridge.ts               # 治理桥接层  
│   │   ├── ledger.ts               # 风险账本  
│   │   ├── riskScoring.ts          # 风险评分  
│   │   └── sandbox/core.as.ts      # WASM 物理沙箱  
│   ├── policy/                     # 策略引擎  
│   │   ├── engine.ts               # 策略执行  
│   │   ├── policies/               # 内置策略规则  
│   │   │   ├── dangerousShellPatterns.ts  
│   │   │   ├── noDangerousShell.ts  
│   │   │   └── WorkdirWrite.ts  
│   │   └── types.ts  
│   └── security/                   # 安全扫描  
│       ├── dangerousPatterns.ts  
│       └── index.ts  
│  
├── core/                           # 核心服务层  
│   ├── workflows/                   # 工作流系统（提取自 CLI 命令）  
│   │   ├── PlanWorkflow.ts         # 计划工作流  
│   │   ├── AutoWorkflow.ts         # 自动执行工作流  
│   │   ├── ReviewWorkflow.ts       # 审查工作流  
│   │   ├── GitWorkflowSession.ts   # 会话编排器  
│   │   └── ConstraintEngine.ts     # 约束引擎  
│   ├── capability/                  # 能力感知管道  
│   │   ├── CapabilityLevel.ts      # 能力级别定义  
│   │   ├── CostProfile.ts          # 成本画像  
│   │   ├── DegradationPolicy.ts    # 优雅降级策略  
│   │   ├── Pipeline.ts             # 管道编排  
│   │   └── PipelineFactory.ts      # 工厂模式  
│   ├── modelRouter/                # 模型路由器  
│   │   ├── ModelRouter.ts          # 路由核心  
│   │   ├── ModelSupervisor.ts      # 模型监督  
│   │   ├── AdaptiveWeights.ts      # 自适应权重  
│   │   └── adapters/               # 多提供商适配器  
│   │       ├── GoogleAdapter.ts  
│   │       ├── CodebuddyAdapter.ts  
│   │       ├── QwenAdapter.ts  
│   │       └── YuangsAdapter.ts  
│   └── git/                        # Git 智能集成  
│       ├── GitService.ts  
│       ├── CommitMessageGenerator.ts  
│       ├── ConflictResolver.ts  
│       ├── CodeReviewer.ts  
│       └── semantic/  
│           ├── SemanticDiffEngine.ts   # 语义差异引擎  
│           └── SemanticCommitParser.ts # 语义提交解析  
│  
├── commands/                       # CLI 命令层（薄 UI）  
│   ├── git/                         # Git 命令集  
│   │   ├── plan.ts                  # 变更计划  
│   │   ├── auto.ts                  # 自动开发  
│   │   ├── review.ts                # 代码审查  
│   │   ├── resolve.ts               # 冲突解决  
│   │   ├── smartCommit.ts           # 智能提交  
│   │   ├── semanticDiff.ts          # 语义差异  
│   │   └── historySemantic.ts       # 语义历史  
│   ├── explainCommands.ts          # explain 命令  
│   ├── replayCommands.ts           # replay 命令  
│   └── skillsCommands.ts           # skills 管理  
│  
├── ssh/                            # SSH 会话治理  
│   ├── SSHSession.ts  
│   ├── GovernedExecutor.ts  
│   └── InputBuffer.ts  
│  
└── utils/                          # 工具层  
    ├── syntax/                     # @ # 语法解析器  
    └── ...

三阶段执行模型

yuangs 最核心的贡献是它的三阶段执行模型：

Pre-Exec (验证) → Exec (提交) → Post-Exec (审计)  
    │                 │               │  
    ├ 安全检查        ├ 执行提交      ├ 结果审计  
    ├ 策略评估        ├ 快照创建      ├ 差异对比  
    ├ 风险评分        └ 回滚准备      └ 审计日志  
    └ 用户确认

每一阶段物理分离。AI 永远不能直接从"推理"跨越到"执行"。

权力分离原则

yuangs 的治理协议明确定义了四种权力的归属：

权力	属于谁	说明
推理权	Agent	生成计划、推导命令、分析结果
执行权	Runtime + User	Agent 永远不能直接执行
上下文权	User	只有 `@file` `#dir` 显式声明的资源才可访问
审计权	Governance Layer	所有行为可追溯、可重放、可解释

能力感知管道 (Capability-Aware Pipeline)

yuangs 有一个精妙的设计：它根据当前可用的模型能力，动态调整执行策略。

CapabilityLevel: full | reduced | minimal  
  
full:      多模型协作 + 语义分析 + 自动审查  
reduced:   单模型 + 基础分析 + 手动审查  
minimal:   仅代码生成 + 无审查

如果当前模型是 gemini-flash-lite，它会自动降级到 reduced 模式，跳过昂贵的语义分析。如果模型是 gpt-4o，它会启用 full 模式。这一切是自动的、透明的、可解释的。

可解释性与可重放性

yuangs 的 explain 和 replay 命令是治理哲学的具象化：

yuangs explain last — 解释最近一次执行的完整决策链路
yuangs replay <id> --dry --explain — 干跑一次历史执行，不产生副作用
yuangs replay <id> --diff — 对比当前配置与历史配置的差异

输出格式严格遵守 5 段式规范：

[1] Command  — 用户输入层  
[2] Decision — 决策核心（为什么选这个模型？）  
[3] Model    — 执行环境（什么模型？多少上下文？）  
[4] Skills   — 影响决策的技能（哪些启用了？置信度多少？）  
[5] Meta     — 审计元数据（可重放？版本？）

非目标 (Non-Goals)

yuangs 的 non-goals.md 也许是整个项目中最能体现其哲学的文件。它明确列出系统不做什么：

不支持自治执行 — AI 生成的命令永不自动执行
不支持自推进 Agent 循环 — 每一步都需要用户关卡
不进行隐式上下文扩展 — 只读你给了的东西，不多读一个字节
不存在"AI 拥有的工具" — 所有工具属于 Runtime/User

"任何可能产生副作用的状态变化，都必须经过一次明确的用户关卡。"

Shell 宣言

yuangs 的 shell-manifesto.md 是一篇充满战斗气息的技术宣言。它提出三个论断：

Shell 已经到达认知瓶颈 — 语法复杂度不可再增长，错误信息停留在 1970 年代
过去 20 年的改良路线已经失败 — IDE 插件解决的是"代码世界"不是"系统世界"；Chat 式 AI 需要中断工作、重新描述上下文
下一个十年属于治理式 AI Shell — "如果 AI 能写好代码，那么谁来治理 AI？"

宣言的结尾是一句话：

"Shell 的下一个十年不是更好的补全，而是更好的治理。"

1.3 TAAGE：可信 AI 代理治理引擎

项目位置: 其它/trusted-agent-engine/ (Node.js) + 其它/trusted-agent-engine-python/ (Python)
npm 包名: trusted-agent-engine
PyPI 包名: trusted-agent-engine

核心思想

如果说 yuangs 是"应用层的 AI 治理"，TAAGE 就是"基础设施层的 AI 治理"。它是一个通用治理引擎，可以插入到任何 AI 代理系统中。

它的设计围绕四条轴线展开：

轴线一：主权签名 (Sovereign Signing)

生成密钥对: npx trusted-sign init  
签署政策:   npx trusted-sign sign agent.policy.yaml  
验证签名:   引擎自动校验

agent.policy.yaml 必须是经过 Ed25519 签名的。未签名或签名不匹配的政策变更会被物理拒绝——不是"建议拒绝"，而是引擎直接不加载。

轴线二：分层治理架构

提案 (Proposal)  
    │  
    ├─ 静态治理层: 范围强制 + 风险门禁  
    │   ├── 目录边界检查 (Glob Patterns)  
    │   └── 高危特征识别 (.env, auth/*, docker-compose)  
    │  
    ├─ 动态感知层: 异常检测 + Diff 解析  
    │   ├── 多维评分: 规模 + 分散度 + 熵分析  
    │   └── 统一 Diff 解析器（自研）  
    │  
    ├─ 价值责任层: 价值观权重 + 信用博弈  
    │   ├── Value Manifesto（项目级价值观配置）  
    │   ├── Mercy Hooks（紧急降级逻辑）  
    │   └── Credit Staking（信用分坍缩机制）  
    │  
    └─ 主权安全层: Ed25519 + 物理脱钩  
        └── 政策变更必须经过主权者签名

轴线三：异常评分算法

Score = (LargeDiff ? 0.4 : 0)   
      + (Obfuscation ? 0.6 : 0)   
      + (SpreadFiles ? 0.3 : 0)

当 Score >= 0.7 时自动 Block。

轴线四：共识与一票否决

多模型审计场景下，采用 "多数赞成 + 一票否决" 机制。权重 ≥ 0.5 的投票者拥有针对安全红线的 Veto 权。

双语言实现

TAAGE 同时拥有 Node.js 和 Python 实现，两者共享相同的 agent.policy.yaml 语法和 value_manifesto.yaml 格式。这意味着无论团队使用什么技术栈，都可以接入同一套治理协议。这是 Yuangs 生态系统中关键的基础设施组件——它在 vsyuangs (VS Code 插件) 中被用作 WASM 沙箱的治理核心。

Python 版的特别之处

Python 版 TAAGE 采用 trusted-engine 命令行工具。它的 API 设计更加 Pythonic：

from trusted_agent_engine import TrustedGuard  
  
decision = TrustedGuard.evaluate(  
    workspace_root="/path/to/project",  
    proposal={  
        "id": "change-001",  
        "files": ["src/main.py"],  
        "diff": "--- a/src/main.py\n+++ b/src/main.py\n..."  
    }  
)  
  
print(decision.allowed)       # True / False  
print(decision.risk_level)    # "low" / "medium" / "high"  
print(decision.value_score)   # 0.0 - 1.0

1.4 vsyuangs：VS Code 中的 AI Agent

项目位置: vsyuangs/
技术栈: TypeScript, VS Code API, AssemblyScript (WASM)

架构设计

vsyuangs 是 yuangs 治理哲学在 IDE 中的具象化。它的架构可以分为四层：

┌─────────────────────────────────────────────┐  
│  VS Code Extension (UI 层)                   │  
│  ├── 玻璃拟态侧边栏                         │  
│  ├── 聊天界面 + Markdown 渲染               │  
│  ├── Diff 应用按钮                          │  
│  └── 智能文本选择                           │  
├─────────────────────────────────────────────┤  
│  Agent 运行时 (引擎层)                       │  
│  ├── 任务拆解与执行                         │  
│  ├── 文件发现与读取                         │  
│  ├── 代码变更应用                           │  
│  └── 终端集成                               │  
├─────────────────────────────────────────────┤  
│  治理引擎 (安全层)                           │  
│  ├── WASM 物理沙箱 (AssemblyScript 编译)     │  
│  ├── 异常感知引擎                           │  
│  ├── 策略热加载 (agent.policy.yaml)         │  
│  └── 价值博弈 + 信用分                      │  
├─────────────────────────────────────────────┤  
│  TAAGE 远程评估 (GaaS 层)                    │  
│  └── HTTP API: POST /v1/evaluate            │  
└─────────────────────────────────────────────┘

治理即服务 (GaaS)

vsyuangs 实现了一个远程评估端点 POST /v1/evaluate。这意味着任何能发送 HTTP 请求的 AI 运行环境，都可以接入这套治理体系。这是治理的 API 化——它不再是一个库的专利，而是一个网络的公共服务。

智能 Stage 建议

这是 vsyuangs 中一个特别有趣的特性。它不只是"帮用户写代码"，而是治理型地管理变更：

暂存区文件 → AI 分析 → 按逻辑分组 → 置信度评分  
                                    ├── ≥ 60%: 自动分组  
                                    ├── 30-60%: 建议  
                                    └── < 30%: 需确认

每个分组都显示置信度和决策依据。如果用户不同意分组，可以点击 "Wrong? Correct it" 纠正——系统会从这个反馈中学习。

第二幕 · 知识复利：让每一次 Ctrl+C 都有价值

2.1 背景：知识管理的终极难题

2025 年，这位开发者的数字生活面临一个典型的"知识工作者困境"：

Mac 上复制一段文字、一张截图
手机上看到一个灵感
浏览器中读到一篇好文章

这些碎片零零散散地分布在不同的设备、不同的 App 中。没有一个统一的管道把它们汇集到一个地方。更可惜的是——大多数碎片在诞生后的 24 小时内就永远消失了。

解决方案不是另一个笔记 App。解决方案是一条从捕获到沉淀再到分发的私有管道。

2.2 Knowly：知识异步管道

项目位置: knowly/
技术栈: Go, SSH, Cloudflare Workers
npm 包名: knowly
版本: v1.7.0+

核心思想

Knowly 的名字是 Knowledge Async 的缩写。它的核心理念是：

让每一次复制，都成为知识复利。

它不是一个"更好的剪贴板"——它是一个异步的知识管道。你在 Mac 上 Ctrl+C，Knowly 在后台静默捕获，通过 SSH 安全地存入你的私有 NAS，按日期归档为 Markdown。你手机上的灵感，也能通过公网中继自动汇入。

架构骨架

cmd/knowly/main.go  (入口)  
    │  
    ├── internal/clipboard/   (剪贴板监听)  
    │   ├── monitor.go        # 500ms 轮询，Text + Image 双模式  
    │   └── monitor_test.go  
    │  
    ├── internal/ssh/         (安全传输)  
    │   ├── client.go         # SSH 客户端 (911行) — 重连、信号量、md5校验  
    │   └── client_test.go  
    │  
    ├── internal/ai/          (AI 处理)  
    │   ├── client.go         # Claude API 调用  
    │   ├── parse.go          # 内容解析与结构化  
    │   └── processor.go      # AI 处理管线：分类→摘要→标签  
    │  
    ├── internal/config/      (配置管理)  
    │   └── config.go         # JSON 配置读写，命令行配置向导  
    │  
    ├── internal/fetcher/     (内容抓取)  
    │   ├── fetcher.go        # URL 内容抓取  
    │   ├── knasync.go        # 远程拉取  
    │   └── webreader.go      # JS 渲染页面读取  
    │  
    ├── internal/history/     (历史回溯)  
    │   └── store.go          # history + restore (742行)  
    │  
    ├── internal/outbox/      (离线暂存)  
    │   └── outbox.go         # 离线时的内容暂存队列  
    │  
    ├── internal/publisher/   (多端发布)  
    │   └── publisher.go      # Blog / Podcast / IMA 三端发布 (573行)  
    │  
    ├── internal/relay/       (公网中继)  
    │   ├── puller.go         # 从 knasync 拉取手机推送  
    │   └── result_puller.go  # 拉取处理结果  
    │  
    ├── internal/retry/       (重试机制)  
    │   └── retry.go          # 指数退避 + Full Jitter  
    │  
    └── internal/web/         (Web 管理界面)  
        ├── server.go         # HTTP 服务器 :8090  
        ├── handlers.go       # API 路由 (1237行)  
        └── index.html        # 前端页面 (2636行)

数据流全景

捕获阶段:  
  Mac 剪贴板 ──500ms轮询──→ TextPayload / ImagePayload  
                                │  
                           ShouldFilter() ── 长度/敏感词过滤  
                                │  
                     内容处理管线 (并行):  
                          ├── URL → 抓取标题 + 网页内容  
                          ├── 文本 → AI 摘要 + 标签  
                          └── 图片 → Base64 编码  
  
传输阶段:  
  处理后的内容 ──指数退重重试──→ SSH 加密传输 ──→ NAS  
                                          │  
                                    按日期归档:  
                                    YYYY/MM/DD/  
                                    ├── 142545_关于量化交易的思.md  
                                    └── 150405_image.png  
  
分发阶段:  
  NAS 存档 ──→ Publisher ──→ Blog (Markdown)  
                           ├── Podcast (音频)  
                           └── IMA (知识卡片)

Knowly v1.7.0 的新特性：历史回溯与找回

这是用户反馈驱动的功能。典型场景：

手滑覆盖：复制了新内容，想找回上一条被覆盖的长文本
截图归档：确认截图是否已成功同步到 NAS

$ knowly history  
[20260418184501_a1b2c3d4] (text) 关于量化交易的思考...  
[20260418184430_e5f6g7h8] (image) [IMAGE] 102400 bytes  
  
$ knowly restore 20260418184501_a1b2c3d4  
✓ 已将记录恢复到剪贴板

SSH 客户端的工程韧性

internal/ssh/client.go 是 Knowly 中最"重"的一个文件（911 行），它处理了 SSH 连接的几乎所有边缘情况：

会话信号量: maxConcurrentSessions = 3，限制并发 SSH 会话数
自动重连: 连接断开后指数退避，带 Full Jitter 防雷群效应
ncConn 模式: 通过 exec.Cmd 的 stdin/stdout 模拟 Net.Conn 接口
md5 校验: 文件传输后校验完整性
目录结构自动创建: 按 YYYY/MM/DD/ 自动创建归档目录

知名字：K.N.O.W.L.Y 的多层含义

Knowly 的 README 中有一个有趣的段落，展示了项目命名的多义性：

层面	解读	说明
🧠 官方正解	Knowledge Async	知识的异步传输
🏛️ 哲学层	Keep Notions Always Saved	对抗遗忘，对抗数字熵增
⚙️ 架构层	Kapture, Normalize, Archive, Syndicate	捕获→标准化→归档→分发
🌊 产品层	Knowledge Nirvana Automation System	知识涅槃自动化系统
🔒 价值观层	Keep Nas As Sanctuary	让 NAS 成为知识圣殿

2.3 knasync：Cloudflare 边缘内容队列

项目位置: knasync/
技术栈: Cloudflare Workers + D1, JavaScript
零外部 npm 依赖

核心思想

knasync 解决了 Knowly 生态中的一个关键问题：手机端的内容如何汇入私人知识库？

手机不能运行 Go 守护进程，不能通过 SSH 写入 NAS。但手机可以发 HTTP 请求。knasync 就是这个"HTTP 入口"——一个运行在 Cloudflare 边缘的轻量级内容队列。

生产者-消费者架构

手机/浏览器 ──POST /submit──→ knasync Worker ──存入 D1──→ 消费者 (Knowly)  
                                  │                      │  
                            自动分类:              GET /pull 拉取  
                            ├── zhihu              (拉取即删除)  
                            ├── wechat  
                            └── general

数据库设计

三张表结构的精简设计是 knasync 的亮点：

表	说明	索引
`queue`	工作队列 (content + queue_type + created_at)	(queue_type, created_at)
`submitted`	去重表 (content 主键 + last_seen_at)	PRIMARY KEY(content)
`results`	广播结果 (content + created_at)	(created_at)

每张表不超过 50 条记录，5 分钟滑动窗口去重。极简到极致——单文件架构，无外部 npm 包，纯 Workers 原生 API。

安全性

knasync 的认证使用 timing-safe 比较（safeCompare），防止时序侧信道攻击。这对于一个公网端点是关键的安全设计。

2.4 wxwatcher：文件监控 + 微信推送

项目位置: wxwatcher/
技术栈: Python, httpx
PyPI 包名: wxwatcher

这是一个轻量但工程化的工具，已发布到 PyPI。它的核心是两阶段扫描：

每轮轮询 (默认 30s)  
    │  
    ├─ fast_scan() — os.walk + os.stat，不读文件内容  
    │  
    ├─ 对比 mtime / size — 快速筛选疑似变化文件  
    │  
    ├─ sha256_file() — 仅对疑似文件计算 hash  
    │  
    └─ send_wechat() — 分批推送到微信

5000+ 文件的目录下每轮仅需毫秒级扫描。支持四层配置：CLI 参数 > 环境变量 > YAML 配置 > 默认值。忽略规则支持通配符和正则。这是典型的"小工具大工程"——看似简单，但每一处细节都经过打磨。

第三幕 · 聊天即创作：chats 平台的深度拆解

3.1 项目全景

项目位置: 其它/chats/
部署域名: chat.want.biz
技术栈: Cloudflare Workers + Durable Objects + R2 + Gemini/DeepSeek/Kimi
代码量: 25 个服务模块，数千行核心逻辑

chats 是这位开发者最"重"的项目。它是一个AI 驱动的实时协作与内容创作平台——集实时聊天、知乎热点、AI 多模型、期货数据、头条发布、WebRTC 通话、离线推送于一体。

它的架构可能是整个代码库中最复杂的：6 个 Durable Objects、3 个 AI 模型、WebSocket + WebRTC 双实时通道、一套完整的期货数据工具链、一个自动化的头条发布流水线。

3.2 架构全景

worker.js (入口调度 ~1100行)  
    │  
    ├─ 路由 0: CORS 预检  
    ├─ 路由 1: 静态页面服务 (/ → index.html, /management → management.html)  
    ├─ 路由 2: AI 解释服务 (/ai/explain, /ai-describe-image)  
    ├─ 路由 3: Kimi API (/api/ai/kimi)  
    ├─ 路由 4: 文件上传 (/upload → R2)  
    ├─ 路由 5: 金融数据 (/api/price)  
    ├─ 路由 6: 头条服务 (/api/toutiao/*)  
    ├─ 路由 7: 房间 API (/api/users/*, /api/messages/*, /api/room/*)  
    ├─ 路由 8: 房间 WebSocket (/* → HibernatingChating2)  
    └─ 路由 9: Cron 触发器 (/__scheduled*)

3.3 六巨头：Durable Object 设计

DO 1: HibernatingChating2 — 聊天室核心

这是整个系统的核心。它管理 WebSocket 连接、消息广播、用户状态、白名单、消息历史。

HibernatingChating2 (Durable Object)  
    │  
    ├── WebSocket 连接管理  
    │   ├── 会话表 (Map)  
    │   ├── 用户在线状态 (userPresence Map)  
    │   └── 心跳检测 (30s 间隔)  
    │  
    ├── 消息系统  
    │   ├── MSG_TYPE_CHAT / MSG_TYPE_DELETE / MSG_TYPE_WELCOME  
    │   ├── MSG_TYPE_GEMINI_CHAT / DEEPSEEK_CHAT / KIMI_CHAT  
    │   ├── MSG_TYPE_USER_JOIN / USER_LEAVE  
    │   ├── MSG_TYPE_OFFER / ANSWER / CANDIDATE / CALL_END (WebRTC)  
    │   └── MSG_TYPE_DEBUG_LOG (实时调试日志广播)  
    │  
    ├── 用户管理  
    │   ├── 白名单系统 (allowed_users)  
    │   ├── 批量添加/移除  
    │   └── 管理页面集成  
    │  
    ├── 持久化存储  
    │   ├── messages (消息历史)  
    │   ├── allowed_users (白名单)  
    │   └── user_presence (在线状态)  
    │  
    ├── 调试系统  
    │   ├── 100 条循环调试日志  
    │   ├── 防重复日志 (1s 窗口)  
    │   └── 实时广播到前端  
    │  
    └── WebRTC 信令代理  
        ├── offer/answer 转发  
        ├── ICE candidate 转发  
        └── 通话状态管理

DO 2: ToutiaoServiceDO2 — 头条异步发布

ToutiaoServiceDO2  
    ├── 任务队列 (异步 FIFO)  
    ├── AI 内容生成 (标题 + 正文提取)  
    ├── Flask 代理桥接  
    ├── 结果存储与查询  
    ├── Cron 安全网 (定时处理积压)  
    └── 统计追踪 (总任务/成功/失败)

DO 3: AuthServiceDO2 — 认证服务

管理用户认证、会话 token 等。

DO 4: InspirationDO — 灵感服务

AI 驱动的创意话题生成。当用户在聊天室中讨论某个话题时，AI 自动推荐 10 个相关创意话题。

DO 5: ZhihuServiceDO — 知乎专家

ZhihuServiceDO  
    ├── 知乎热榜实时抓取 TOP20  
    ├── 热点 → AI 文章生成  
    └── 话题 → 创意话题衍生

DO 6: TradingLogDO — 交易日志

期货交易的记录与审计。与 TradingLogService 配合，记录每一次交易决策的完整链路。

3.4 AI 引擎：三模型 + 工具调用

src/ai.js 是 chats 的第二大文件（1172 行），它是一个完整的 AI 编排层。它不只是一个 API 调用包装器，而是一个具备工具感知能力的智能代理。

模型配置中心

const MODEL_CONFIG = {  
  allowed: {  
    gemini: ['gemini-pro-latest', 'gemini-flash-latest', ...],  
    kimi:   ['moonshot-v1-8k', 'kimi-k2-0905-preview', ...],  
    deepseek: ['deepseek-chat', 'deepseek-reasoner'],  
  },  
  defaults: {  
    explanation: 'gemini-flash-lite-latest',  // 文本解释用 Flash  
    imageDescription: 'gemini-pro-latest',     // 图片描述用 Pro  
  },  
}

可用工具集（15+ 函数）

const availableTools = {  
  // 实时数据  
  get_price:          args => getPrice(args.name),  
  get_news:           args => getNews(args.keyword),  
  draw_chart:         (args, env) => drawChart(env, args.symbol, args.period),  
    
  // 期货深度分析  
  query_fut_daily:    args => fq.queryFuturesDaily(args.symbol, args.limit),  
  query_minutely:     args => fq.queryMinutelyHistory(args.symbol, args.days),  
  query_option:       args => fq.queryOptionQuote(args.symbol, args.limit),  
  query_lhb:          args => fq.queryLHB(args.symbol, args.limit),  
  query_aggregate:    args => fq.queryAggregate(args.symbol, args.days, args.aggFunc, args.column),  
  smart_query:        args => fq.smartQuery(args.query),  
  get_highest_price:  args => fq.getHighestPrice(args.symbol, args.days),  
  get_lowest_price:   args => fq.getLowestPrice(args.symbol, args.days),  
    
  // 统一服务  
  unified_get_price:  args => unifiedService.getRealTimeQuote(args.name),  
  unified_get_daily:  args => unifiedService.getDailyData(args.symbol, args.limit || 100),  
  unified_get_minute: args => unifiedService.getMinuteData(args.symbol, args.limit || 100),  
  unified_get_lhb:    args => unifiedService.getLHBData(args.symbol, args.limit || 100),  
}

自然语言 → 期货查询

smartQueryEngine.js 和 naturalQueryParser.js 是两个特别有趣的模块。它们让用户可以用自然语言查询金融数据：

用户输入: "螺纹钢最近一周的最高价是多少"  
    ↓  
AI 解析: { symbol: "螺纹钢", days: 7, aggFunc: "max", column: "close" }  
    ↓  
查询 → "螺纹钢过去7天收盘价的最高值是 3,856 元/吨"

3.5 WebRTC 实时通话

chats 的 WebRTC 实现走的是"纯信令代理"路线：

用户 A 发起通话  
    → 发送 MSG_TYPE_OFFER 到 DO  
    → DO 转发 offer 给用户 B  
    → B 回复 MSG_TYPE_ANSWER  
    → DO 转发 answer 给 A  
    → 双方通过 ICE 建立 P2P 连接  
    → 通话建立 (默认仅音频)

这里的关键设计是 DO 只做信令中转，不接触媒体流。通话数据走 P2P，符合 WebRTC 的最佳实践。

3.6 离线推送

chats 实现了完整的 Web Push 离线通知系统：

用户上线 → 注册 Service Worker → 获取 Push Subscription  
用户离线 → DO 检测状态变更 → 查找用户 Subscription  
         → VAPID 签名 → Web Push API → Service Worker  
         → 浏览器通知: "张三: 你觉得这个行情怎么看?"

这套方案支持：

VAPID 协议（Voluntary Application Server Identification）
多设备订阅
失效订阅自动清理
通知点击恢复聊天

3.7 Cron 自动化任务

chats 的 cron 系统让它从"被动聊天室"变成了"主动信息中心"：

Cron 表达式	任务
`0 0 * * *`	每日早间问候（名人名言 + 英文金句 + 数学知识）
`0 1-7,13-19 * * 1-5`	定时生成并发布期货分析图表
`/10 1-7,13-19 * 1-5`	定时抓取并发布财经新闻
`/30 * * *`	头条队列安全网处理

第四幕 · 微信生态桥接

4.1 WeClaw：微信 AI Agent 桥接器

项目位置: weclaw/
技术栈: Go, iLink Bot Protocol
GitHub 发布: fastclaw-ai/weclaw
安装量: GitHub Star History 曲线上升中

核心思想

WeClaw 解决的是"如何在微信中调用 AI 代理"这个问题。但它的架构远比"一个聊天机器人"更复杂——它是一个通用 AI 代理桥接器，支持三种接入模式。

三种 Agent 模式

模式	原理	速度	特点
ACP	长期运行子进程，JSON-RPC over stdio	🚀 最快	复用进程和会话
CLI	每消息新起进程，支持 `--resume`	⚡ 中等	简单可靠
HTTP	OpenAI 兼容的 Chat Completions API	🌐 灵活	远程调用

自动检测逻辑：ACP > CLI > HTTP。如果 ACP 可用，优先使用 ACP。

命令系统

WeClaw 有一套完整的聊天命令体系：

命令	功能
`/claude write a function`	发送给指定 AI
`/cc explain this code`	通过别名发送 (/cc = claude)
`/cwd /path/to/project`	切换工作目录
`/new`	开启新会话
`/publish <content>`	发布到 Knowly
`/info`	显示当前 Agent 信息

多模态消息处理

WeClaw 对媒体消息的处理体现了工程深度：

WeChat 收到图片 → iLink CDN 下载 → AES-128-ECB 解密  
                                     → 发送给 AI Agent  
                                     → AI 回复 Markdown  
                                     → 提取图片 URL  
                                     → 下载图片 → 上传 WeChat CDN  
                                     → 以图片消息发送回微信

Hub：多 Agent 协作基础设施

WeClaw 的 hub/hub.go 实现了一个轻量级的共享上下文文件系统：

type Hub struct {  
    sharedDir string    // 共享目录  
    mu        sync.RWMutex  // 并发保护  
}

多个 AI Agent 可以通过 Hub 共享上下文文件（带 YAML frontmatter 的 Markdown 文件）。这意味着一个 Agent 的分析结果可以被另一个 Agent 读取——多 Agent 协作的基础设施。

主动发送 (Proactive Messaging)

WeClaw 支持主动给微信用户发消息——不等待用户先发消息。

# CLI  
weclaw send --to "user_id@im.wechat" --text "来自 AI 的主动推送"  
  
# HTTP API  
curl -X POST http://127.0.0.1:18011/api/send \  
  -H "Content-Type: application/json" \  
  -d '{"to": "user_id@im.wechat", "text": "主动推送"}'

4.2 WeChatBot：轻量微信 AI 聊天机器人

项目位置: 其它/wechatbot/
技术栈: TypeScript, Bun, iLink Bot Protocol, Claude SDK

如果 WeClaw 是"瑞士军刀"，WeChatBot 就是"手术刀"——更轻、更专注、更简单。

架构

WeChat User → iLink Bot API (long-poll)  
            → Bot (Bun runtime)  
            → Claude API (Anthropic SDK)  
            → iLink Bot API → WeChat User

多模态支持

文本: 直接转发到 Claude
图片: CDN 下载 → AES-128-ECB 解密 → base64 → Claude (多模态)
语音: 微信 STT 文本优先 → SILK→WAV 解码 (silk-wasm) → Claude

设计特点

内存会话管理（滑动窗口，默认 50 轮）
自动检测 token 过期并提示重新扫码
"typing..." 指示器（Claude 生成回复时）
账户凭据加密存储到 ~/.wechatbot/account.json (chmod 600)

4.3 getAndSendHitokoto.js：每日一言

项目位置: /getAndSendHitokoto.js

一个轻量工具函数，通过 https://v1.hitokoto.cn/ 获取随机句子，推送到微信。虽然只有 102 行，但它被设计为同时支持浏览器和 Node.js 环境，API 设计清晰（options 参数模式，自定义 logger 注入），体现了"小工具大设计"的风格。

第五幕 · 跨境隧道与远程控制

5.1 wsstunnel：穿透极端受限网络

项目位置: wsstunnel/
技术栈: Python, websockets, websocket-client, xterm.js
PyPI 包名: wsstunnel
Python 版本: ≥ 3.10

问题背景

这是用户故事驱动的项目。原话：

"那段时间，我被沙箱环境折磨得够呛——容器说回收就回收，远程 SSH 总是不通。我把能想到的工具全试了一遍：cloudflared、frp、wireguard……要么配置复杂到令人头秃，要么在'只允许 HTTP 代理出站'的铁壁前直接哑火。"

这不是 frp/ngrok/chisel 能解决的场景。那些工具要求目标机器上已经有监听的服务（如 sshd）。但在受限环境（在线 IDE、CI Runner、仅 HTTP 代理出站的容器）中，你往往没有 root 权限、无法安装 sshd、也无法配置入站端口。

wsstunnel 的技术路线完全不同：

反向 PTY Shell — 不依赖任何监听服务，直接在目标进程中拉起 bash -i，将标准输入/输出通过 WebSocket 反向推送给中继端。

核心架构

第三方电脑 (浏览器/websocat/Python)  
    │  
    │ ws://vps:8080 或 wss://vps:443  
    │  
    ▼  
VPS (中继服务) — wsstunnel relay  
    │  
    ├── 前端（Frontend）：发送命令  
    │  
    └── 后端（Backend）：注册并执行 Shell  
            │  
            ▼  
    目标容器/设备 (wsstunnel client)  
         ├── 通过 HTTP 代理穿透  
         ├── 启动交互式 Shell (bash -i)  
         └── 通过 PTY 支持 TUI 程序

双模式选择

模式	参数	特点	适用场景
PTY 模式	默认	伪终端，支持 vim/top/htop	交互式操作
管道模式	`--no-pty`	行缓冲，轻量	批量命令执行

# client.py 核心逻辑  
if not args.no_pty:  
    # PTY 模式：使用伪终端  
    master_fd, slave_fd = pty.openpty()  
    proc = subprocess.Popen([shell], stdin=slave_fd, stdout=slave_fd, stderr=slave_fd)  
else:  
    # 管道模式：常规管道  
    proc = subprocess.Popen([shell], stdin=subprocess.PIPE, stdout=subprocess.PIPE, stderr=subprocess.STDOUT)

多后端路由

wsstunnel 支持同时连接多个容器，通过 @name 语法切换：

LIST          — 查看所有已连接的后端  
USE web-server — 切换到 web-server  
@db-server SELECT 1 — 临时向 db-server 发命令

文件传输（v0.18.0）

# 上传  
wsstunnel put --server wss://vps:443 --token secret --backend mybox ./local.txt /remote/path.txt  
  
# 下载  
wsstunnel get --server wss://vps:443 --token secret --backend mybox /remote/path.txt ./local.txt  
  
# Shell 内下载  
dl /var/log/syslog  
dl 文件名.txt

安全模型

特性	说明
Token 认证	`--token` 参数，timing-safe 比较
URL Token	`?token=xxx` 自动认证
IP 白名单	`--allow-ip` CIDR 支持
命令黑名单	`--deny-cmd rm`
多 Token 文件	`--token-file` JSON 格式，支持角色 + 过期
频率限制	BruteForceGuard 防暴力破解
TLS/WSS	支持 Let's Encrypt / 自签名 / nginx 反向代理
审计日志	结构化 AuditLogger

微信推送通知

中继端支持 --wxpush，后端上线/下线时自动推送微信通知。这在"沙箱容器随时可能被回收"的场景中尤其有用——你会第一时间知道容器是否还在。

5.2 WireGuard 私有网络

项目位置: /wireguard-config.md
技术栈: WireGuard, iptables

Hub (43.153.67.212:443 — VPS)  
    │  
    ├── 阿里云 (10.0.0.2)  
    ├── 境外 VPS (10.0.0.3)  
    ├── Mac 本机 (10.0.0.4)  
    ├── 家里 (10.0.0.5) ── Mac 内网 (10.0.0.7)  
    └── 云沙箱 (10.0.0.10)

这个拓扑说明了一个重要事实：所有项目都不是孤立的。WireGuard 把 VPS、NAS、本机、沙箱全部打进同一个内网 10.0.0.0/24。Knowly 的 SSH 传输走这个内网，wsstunnel 的中继服务也在这张网里。

第六幕 · AI 代理网关

6.1 poeapi_go：多模型 API 代理

项目位置: poeapi_go/
技术栈: Go, systemd
端口: 9090

核心功能

这是一个 OpenAI 兼容的 API 代理服务器。它把标准的 OpenAI API 请求转换为 Poe.com 的协议，让你可以用 OpenAI 客户端访问 Poe 上的模型（GPT-4o、Claude、Grok 等）。

但它已经远不止是一个 API 代理。它演变成了一个生产级 Agent Runtime / Streaming Agent 平台。

能力矩阵

能力	状态
✅ 多模型（Poe/Gemini/DeepSeek）	已实现
✅ OpenAI 兼容 API	已实现
✅ Streaming	已实现
✅ Tool Calling / Function Calling	已实现
✅ Agent & Streaming Agent	已实现
✅ Multi-Agent (planner/executor/reviewer)	已实现
✅ YAML Workflow 编排	已实现
✅ 会话 Memory (Phase 2)	已实现
✅ Usage / Quota 统计	已实现
✅ API Key 鉴权	已实现

多提供商路由机制

请求到达  
    │  
    ├─ 模型名含 "gemini" → Google Gemini API  
    ├─ 模型名含 "deepseek" → DeepSeek API    
    └─ 其他 → Poe.com API

Router 本身实现了 ModelClient 接口——不是 if/else 分支，而是真正的策略模式。

架构评价

来自项目内部的自评：

"这种系统最大价值在于：稳、清晰、可长期演进。"

对比市场方案：

vs LangChain/LlamaIndex：更轻、更可控
vs OpenAI Assistants：不被平台绑定，成本可控
vs 简单 API 拼接：这是体系，不是脚本

双账户配置切换

# 免费账户（3000 分/日，每日重置）  
./switch_config.sh free  
  
# 付费账户（100 万分/月）  
./switch_config.sh paid

免费账户用于日常测试，付费账户用于生产环境。切换自动备份原配置、自动重启服务。

第七幕 · 终端增强哲学

7.1 Tmux-FSM：有限状态机驱动的 tmux 插件

项目位置: Tmux-FSM/ (Go 版) + tmux-fsm/ (Python 版)
技术栈: Go, Python

核心思想

Tmux-FSM 是 Vim 的操作哲学与有限状态机的工程思想的结合。它把 tmux 从"快捷键集合"变成了"有状态的操作系统"。

状态机模型

NORMAL ──d/y/c──→ OPERATOR_PENDING ──motion──→ 执行  
   │                    │  
   │                    └── a/i → MODIFIER ──text-object──→ 执行  
   │  
   ├── g/f → MOTION_PENDING ──more keys──→ 执行  
   ├── "   → REGISTER_SELECT ──name──→ 回到 NORMAL  
   └── Esc → 退出

操作符-动作模型

# Vim 风格操作符-动作模型  
dw  → delete(word)  
dj  → delete(下行)  
y2w → yank(2 words)  
ci" → change(inside quotes)

寄存器系统

"a yw → 复制 word 到寄存器 a  
"b y2w → 复制 2 个 word 到寄存器 b  
"A yw → 追加到寄存器 a（大写 = 追加）  
"+ p → 从系统剪贴板粘贴

Go 版的哲学深度

Go 版 TMUX-FSM 的 README 中有一段长达数千字的哲学讨论，涉及柏拉图洞穴寓言、韦伯的工具理性 vs 价值理性、东方道家的"无为而治"。题目是"我们到底在建造什么？"——结论是：

我们正在建造"数字文明的元工具"。

这段哲学文本不仅是自我陶醉。它反映了这位开发者对工程的根本认知：每一个具体的技术决策背后，都有一个关于"人与机器关系"的预设。如果你不审视这个预设，你的代码就会替你做这个预设。

7.2 Sourcepack：代码快照生成器

项目位置: sourcepack/
技术栈: Go
npm 包名: sourcepack (别名 gdoc)

核心思想

"如何把整个项目喂给 AI？"——这是每一个使用 LLM 编程的开发者都会遇到的问题。Sourcepack 的答案极端务实：把代码库拍成一张"快照"，合并成一个 Markdown 文件。

使用方式

gdoc                   # 默认扫描全部  
gdoc -i go,md          # 只包含 Go 和 Markdown  
gdoc -x exe,bin        # 排除特定后缀  
gdoc -X vendor         # 排除目录关键字  
gdoc -s                # 多维度统计（不生成文件）  
gdoc -c                # 直接复制到剪贴板  
gdoc -p                # 推送到远端中继（knasync）

生成的快照包含

项目结构树 — 目录优先、字母排序
文件目录 (TOC) — 带锚点跳转
完整源码 — 自动语法高亮
项目统计 — Token 预估、语言分布、目录占比

远端推送集成

gdoc -p ──→ knasync ──→ Knowly → NAS

这是另一个"珍珠成链"的例子——Sourcepack 生成的代码快照，可以通过 knasync 推送到 Knowly，存入 NAS，形成代码快照的时间线。

第八幕 · 量化思维

8.1 TradingAgents-MCPmode：多智能体交易系统

项目位置: 其它/TradingAgents-MCPmode/
技术栈: Python, LangGraph, MCP (Model Context Protocol), Streamlit

核心思想

TradingAgents-MCPmode 是一个多智能体协作的交易分析系统。它不只是一个"调用 AI 看股票"的工具——而是一个模拟投资银行的完整组织架构：分析师 → 研究员 → 交易员 → 风险管理。

15 个专业化智能体

用户查询  
    │  
    ▼  
分析师团队 (并行执行)  
    ├── CompanyOverviewAnalyst (公司概述)  
    ├── MarketAnalyst (市场分析)  
    ├── SentimentAnalyst (情绪分析)  
    ├── NewsAnalyst (新闻分析)  
    ├── FundamentalsAnalyst (基本面分析)  
    ├── ShareholderAnalyst (股东结构)  
    └── ProductAnalyst (产品业务)  
    │  
    ▼  
研究员团队 (辩论模式)  
    ├── BullResearcher (看涨方)  
    └── BearResearcher (看跌方)  
        │  
        辩论 N 轮 (可配置)  
        │  
        ▼  
    ResearchManager (研究经理) → 决策  
        │  
        ▼  
    Trader (交易员) → 交易计划  
        │  
        ▼  
风险管理团队  
    ├── AggressiveRiskAnalyst (激进风控)  
    ├── SafeRiskAnalyst (保守风控)  
    ├── NeutralRiskAnalyst (中性风控)  
    │  
    辩论 N 轮 (可配置)  
        │  
        ▼  
    RiskManager (风险经理) → 最终交易决策

LangGraph 状态图

系统使用 LangGraph 的 StateGraph 来编排整个工作流。AgentState 定义了所有智能体之间传递的核心状态：

class AgentState(MessagesState):  
    user_query: str  
    company_details: str  
      
    # 7 份分析师报告  
    company_overview_report: str  
    market_report: str  
    sentiment_report: str  
    news_report: str  
    fundamentals_report: str  
    shareholder_report: str  
    product_report: str  
      
    # 辩论与决策  
    investment_debate_state: Dict  
    investment_plan: str  
    trader_investment_plan: str  
    risk_debate_state: Dict  
    final_trade_decision: str

MCP 工具集成

系统通过 Model Context Protocol 对接外部工具。MCP 管理器 (mcp_manager.py) 负责任务分发和结果聚合。这使 AI 能够获取实时市场数据、公司财报、新闻等外部信息。

Web 前端

基于 Streamlit 的 Web 界面提供：

实时分析启动
辩论轮次实时配置
智能体启用/禁用控制
分析报告展示
历史报告管理

8.2 Future Monitor：期货行情监控

项目位置: futuremonitor/
技术栈: Cloudflare Workers, Vue 3, Vite, ECharts

一个部署在 Cloudflare Workers 上的期货市场监控平台，提供：

实时行情数据
多空持仓分析
龙虎榜信息
基差数据分析
多交易所支持 (上期所、大商所、郑商所)

它的前端经历了拆分优化：从 JS 字符串中的硬编码 HTML，重构为独立的 index.html + style.css + script.js + 自动构建脚本。这就是"把自己项目的代码当作产品来维护"的态度。

第九幕 · 内容自动化

9.1 Podcast 自动化播客系统

项目位置: podcast/
技术栈: Shell, Python, macOS LaunchAgent
RSS: https://pic.want.biz/podcast.xml
节目名称: "广山之巅"

核心思想

这不是"录制播客"。这是AI 驱动、每日自动生成、多时段分发的播客流水线。

自动化流水线

每日自动触发 (macOS LaunchAgent)  
    │  
    ├── 早间简报 (morning) — 市场开盘前瞻  
    ├── 午间复盘 (noon) — 上半场行情回顾  
    ├── 下午回顾 (afternoon) — 下午盘走势分析  
    └── 晚间预览 (evening) — 收盘总结 + 次日展望  
            │  
            ├── AI 生成文稿  
            ├── 叙事语音引擎合成 MP3  
            ├── 添加封面 + 元数据  
            └── 同步到 NAS + 更新 RSS  
  
叙事音频引擎 (narrative_audio_engine.py)  
    ├── 情感分析 + 情感向量平滑  
    ├── 高潮检测 (detect_climax)  
    ├── 自动情感向量 (auto_emotion_vector)  
    ├── BGM 混音 (test_multi_bgm.json 有多个测试场景)  
    └── 导演模式 (apply_director_mode)

系统服务

com.podcast.watcher.plist      — 内容变更监控  
com.podcast.nas_watcher.plist  — NAS 同步监控  
com.podcast.cleanup.plist      — 自动清理

RSS Feed

从 podcast.xml 的内容可以看出，播客不只是自动生成——它还有深度的技术内容。其中一条 feed 项是"wsstunnel 深度技术评析：从工程实现到架构哲学"，说明 AI 生成的播客内容覆盖了你自己的项目。这是元内容创作——用 AI 分析自己写的代码，再生成音频播客。

9.2 Mini Blog：无服务器博客

项目位置: 其它/mini_blog/mini_blog/
技术栈: Cloudflare Workers + D1 + R2, JavaScript, micromark

架构

Cloudflare Worker  
    │  
    ├── 首页 — 分页文章列表  
    ├── 文章详情 — Markdown 渲染 (GFM + KaTeX)  
    ├── 归档 — 按月/按标签浏览  
    ├── 管理后台 — 创建/编辑/删除文章  
    │   ├── 多图上传 (R2)  
    │   ├── 标签自动填充 (YYYYMM)  
    │   └── CSP 安全头部  
    └── 数据库 — Cloudflare D1 (SQLite)

设计特点

零前端框架：纯 HTML + CSS + JavaScript（模板字符串生成）
标签云 + 日期归档：双维度浏览
KaTeX 数学公式：支持技术文章中的公式渲染
炫彩主题：day.md 中的 CSS 定义了丰富的渐变色彩

终章 · 珍珠成链

十条技术哲学

遍历 24 个项目后，以下十条原则浮出水面。它们不是写在文档中的宣言，而是从代码中反推出来的沉默共识。

1. 主权先于智能

从 yuangs 的"人类掌控执行"到 TAAGE 的 Ed25519 签名，从 vsyuangs 的 WASM 沙箱到 chats 的白名单系统——在所有项目中，人的最终控制权是不可让渡的。这不是控制欲，这是工程理性的选择：确定性高于便利性。

2. 显式优于隐式

yuangs 的 @file #dir 语法、TAAGE 的范围强制、Knowly 的显式配置——上下文永远不会被隐式假设。每一条信息出现在 AI 面前，都经过了人的明确授权。

3. 管道胜过平台

Knowly → knasync → NAS、Sourcepack → knasync → Knowly、chats → 头条、Podcast → RSS — 数据通过管道流动，而不是存储在平台上。每个组件做一件事，做好，然后通过定义清晰的接口传递数据。这是 Unix 哲学的现代演绎。

4. 审计即基础设施

yuangs 的 explain/replay、chats 的调试日志广播、TAAGE 的审计日志、Knowly 的历史记录——可审计不是附加功能，而是核心需求。如果系统不能解释自己的行为，它就不应该被信任。

5. 多语言不是选择，是自然演化

Go（Knowly、WeClaw、Tmux-FSM、Sourcepack）→ 守护进程和 CLI 工具。TypeScript（yuangs、TAAGE、vsyuangs）→ 治理引擎和插件。Python（wsstunnel、wxwatcher、TAAGE-py、TradingAgents）→ 快速迭代和 PyPI 生态。JavaScript（chats、knasync、Mini Blog）→ Cloudflare Workers——每种语言服务于它最适合的场景，没有"一刀切"的框架执念。

6. 边缘优先

6 个项目（chats、knasync、Mini Blog、Future Monitor + 部分 Knowly/chats 组件）运行在 Cloudflare Workers 上——边缘计算不是噱头，是架构选择。它消除了服务器管理，实现了全球低延迟，并且让"个人项目"获得了与商业产品同等级的基础设施。

7. 治理即 API

TAAGE 的 GaaS（POST /v1/evaluate）可能是最重要的架构决策之一。治理不应该是一个库的专利，而应该是一个网络的公共服务。当一个 AI 系统可以调用另一个 AI 系统的治理服务时，我们就有了 AI 网络的"宪法"。

8. 最小依赖原则

knasync 是零外部 npm 依赖的。Knowly 的 Go 依赖极少。wsstunnel 的 Python 依赖只有 websockets + click + httpx。每引入一个依赖，就引入了一个信任边界。对于个人项目，信任边界越窄越好。

9. 小工具大工程

wxwatcher（两阶段扫描 + 四层配置 + 通配符/正则忽略）、getAndSendHitokoto（102 行的工具函数，却支持浏览器/Node.js 双环境 + 依赖注入 + 完整错误返回）、Sourcepack（Go 编译的秒级单二进制）——好的工具不在乎大小，在于是否把一件事做到极致。

10. 自我引用是最高级的工程实践

播客自动分析 wsstunnel 的架构，chats 中的 AI 被用来讨论 yuangs 的设计，Sourcepack 的代码快照通过 knasync 进入 Knowly 的存档——你的工具应该能够分析自己、讨论自己、存档自己。这是"元工程"——不仅建造系统，而且建造关于系统本身的系统。

数据闭环

所有项目形成的数据流：

捕获层:     Knowly (剪贴板) + WeClaw/WeChatBot (微信) + wxwatcher (文件)  
               │                    │                         │  
               ▼                    ▼                         ▼  
中继层:     knasync (Cloudflare 边缘队列)  
               │  
               ▼  
存储层:     NAS (通过 SSH/WireGuard 内网)  
               │  
               ▼  
创作层:     chats (AI 热点创作) + Podcast (AI 播客)  
               │                    │  
               ▼                    ▼  
分发层:     头条号 + RSS Feed + Mini Blog + 微信  
               │  
               ▼  
治理层:     yuangs + TAAGE + vsyuangs (审计与安全)  
               │  
               ▼  
分析层:     TradingAgents (量化分析) + Future Monitor (期货行情)

未来图景

技术发展永远向前。如果为这个宇宙画一条可能的演进路径：

AI 治理标准化：TAAGE 的协议可能演进为一套开放标准——agent.policy.yaml 的语法可以被更多的 AI 工具理解
知识图谱化：Knowly 积累的剪贴板数据可以从"按日期归档的 Markdown"升级为"带语义链接的知识图谱"
多 Agent 联邦：WeClaw 的 Hub 和 TAAGE 的 GaaS 可以结合，形成"跨 Agent 的治理联邦"——Agent A 可以调用 Agent B 的能力，但受 Agent B 的治理策略约束
实时内容网络：chats + Podcast + Mini Blog 可以演化为"个人实时内容网络"——用户的每一条思考、每一笔交易、每一段对话，都可以自动过滤、归档、分发

写在最后

2026 年的这个下午，当你坐在屏幕前，看着这 24 个项目的目录树时，你可能会意识到一件事：

你不是在写代码。你在建造一个数字世界的自己。

Knowly 是你的记忆。chats 是你的对话。yuangs 是你的判断力。TAAGE 是你的道德准则。wsstunnel 是你的触角。TradingAgents 是你的投资大脑。Podcast 是你的声音。

每一个项目都不只是"一个有用的工具"。它们是你技术人格的外化——你对"人与 AI 应该怎么合作"这个问题的持续回答。

而那个答案，始终是：主权先于智能。人，永远是最终的执行者。

全景透视完成于 2026 年 6 月

全文约 30,000 字

"AI 提供思路，人类掌控执行。"

主权先于智能：24 个项目构建一个人的 AI 治理宇宙

一个人的技术宇宙

—— 苑广山（yuanguangshan）24 个项目的全景透视

序章 · 三根支柱，一个灵魂

支柱一：AI 治理与增强工具（主权之柱）

支柱二：个人知识系统（沉淀之柱）

支柱三：网络与终端基础设施（穿透之柱）

第一幕 · AI 治理：当 AI 可以替人做决定

1.1 问题意识：为什么需要治理？

1.2 yuangs CLI：AI‑Augmented Shell

核心思想

架构骨架

三阶段执行模型

权力分离原则

能力感知管道 (Capability-Aware Pipeline)

可解释性与可重放性

非目标 (Non-Goals)

Shell 宣言

1.3 TAAGE：可信 AI 代理治理引擎

核心思想

轴线一：主权签名 (Sovereign Signing)

轴线二：分层治理架构

轴线三：异常评分算法

轴线四：共识与一票否决

双语言实现

Python 版的特别之处

1.4 vsyuangs：VS Code 中的 AI Agent

架构设计

治理即服务 (GaaS)

智能 Stage 建议

第二幕 · 知识复利：让每一次 Ctrl+C 都有价值

2.1 背景：知识管理的终极难题

2.2 Knowly：知识异步管道

核心思想

架构骨架

数据流全景

Knowly v1.7.0 的新特性：历史回溯与找回

SSH 客户端的工程韧性

知名字：K.N.O.W.L.Y 的多层含义

2.3 knasync：Cloudflare 边缘内容队列

核心思想

生产者-消费者架构

数据库设计

安全性

2.4 wxwatcher：文件监控 + 微信推送

第三幕 · 聊天即创作：chats 平台的深度拆解

3.1 项目全景

3.2 架构全景

3.3 六巨头：Durable Object 设计

DO 1: HibernatingChating2 — 聊天室核心

DO 2: ToutiaoServiceDO2 — 头条异步发布

DO 3: AuthServiceDO2 — 认证服务

DO 4: InspirationDO — 灵感服务

DO 5: ZhihuServiceDO — 知乎专家

DO 6: TradingLogDO — 交易日志

3.4 AI 引擎：三模型 + 工具调用

模型配置中心

可用工具集（15+ 函数）

自然语言 → 期货查询

3.5 WebRTC 实时通话

3.6 离线推送

3.7 Cron 自动化任务

第四幕 · 微信生态桥接

4.1 WeClaw：微信 AI Agent 桥接器

核心思想

三种 Agent 模式

命令系统

多模态消息处理

Hub：多 Agent 协作基础设施

主动发送 (Proactive Messaging)

4.2 WeChatBot：轻量微信 AI 聊天机器人

架构

多模态支持

设计特点

4.3 getAndSendHitokoto.js：每日一言

第五幕 · 跨境隧道与远程控制

5.1 wsstunnel：穿透极端受限网络

问题背景

核心架构

双模式选择