兰 亭 墨 苑

标题 *

URL 别名 *

内容 * (支持 Markdown 格式) > 通过 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` 也许是整个项目中最能体现其哲学的文件。它明确列出**系统不做什么**： 1. **不支持自治执行** — AI 生成的命令永不自动执行 2. **不支持自推进 Agent 循环** — 每一步都需要用户关卡 3. **不进行隐式上下文扩展** — 只读你给了的东西，不多读一个字节 4. **不存在"AI 拥有的工具"** — 所有工具属于 Runtime/User > **"任何可能产生副作用的状态变化，都必须经过一次明确的用户关卡。"** ### Shell 宣言 yuangs 的 `shell-manifesto.md` 是一篇充满战斗气息的技术宣言。它提出三个论断： 1. **Shell 已经到达认知瓶颈** — 语法复杂度不可再增长，错误信息停留在 1970 年代 2. **过去 20 年的改良路线已经失败** — IDE 插件解决的是"代码世界"不是"系统世界"；Chat 式 AI 需要中断工作、重新描述上下文 3. **下一个十年属于治理式 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： ```python 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 的新特性：历史回溯与找回 这是用户反馈驱动的功能。典型场景： 1. **手滑覆盖**：复制了新内容，想找回上一条被覆盖的长文本 2. **截图归档**：确认截图是否已成功同步到 NAS ```bash $ 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 调用包装器，而是一个具备工具感知能力的智能代理。 ### 模型配置中心 ```javascript 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+ 函数） ```javascript 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` 实现了一个轻量级的**共享上下文文件系统**： ```go type Hub struct { sharedDir string // 共享目录 mu sync.RWMutex // 并发保护 } ``` 多个 AI Agent 可以通过 Hub 共享上下文文件（带 YAML frontmatter 的 Markdown 文件）。这意味着一个 Agent 的分析结果可以被另一个 Agent 读取——**多 Agent 协作的基础设施**。 ### 主动发送 (Proactive Messaging) WeClaw 支持主动给微信用户发消息——不等待用户先发消息。 ```bash # 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` | 行缓冲，轻量 | 批量命令执行 | ```python # 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 拼接：这是体系，不是脚本 ### 双账户配置切换 ```bash # 免费账户（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 → 退出 ``` ### 操作符-动作模型 ```python # 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 文件。 ### 使用方式 ```bash gdoc # 默认扫描全部 gdoc -i go,md # 只包含 Go 和 Markdown gdoc -x exe,bin # 排除特定后缀 gdoc -X vendor # 排除目录关键字 gdoc -s # 多维度统计（不生成文件） gdoc -c # 直接复制到剪贴板 gdoc -p # 推送到远端中继（knasync） ``` ### 生成的快照包含 1. **项目结构树** — 目录优先、字母排序 2. **文件目录 (TOC)** — 带锚点跳转 3. **完整源码** — 自动语法高亮 4. **项目统计** — 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` 定义了所有智能体之间传递的核心状态： ```python 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 (期货行情) ``` ## 未来图景 技术发展永远向前。如果为这个宇宙画一条可能的演进路径： 1. **AI 治理标准化**：TAAGE 的协议可能演进为一套开放标准——`agent.policy.yaml` 的语法可以被更多的 AI 工具理解 2. **知识图谱化**：Knowly 积累的剪贴板数据可以从"按日期归档的 Markdown"升级为"带语义链接的知识图谱" 3. **多 Agent 联邦**：WeClaw 的 Hub 和 TAAGE 的 GaaS 可以结合，形成"跨 Agent 的治理联邦"——Agent A 可以调用 Agent B 的能力，但受 Agent B 的治理策略约束 4. **实时内容网络**：chats + Podcast + Mini Blog 可以演化为"个人实时内容网络"——用户的每一条思考、每一笔交易、每一段对话，都可以自动过滤、归档、分发 ## 写在最后 2026 年的这个下午，当你坐在屏幕前，看着这 24 个项目的目录树时，你可能会意识到一件事： **你不是在写代码。你在建造一个数字世界的自己。** Knowly 是你的记忆。chats 是你的对话。yuangs 是你的判断力。TAAGE 是你的道德准则。wsstunnel 是你的触角。TradingAgents 是你的投资大脑。Podcast 是你的声音。 每一个项目都不只是"一个有用的工具"。它们是你技术人格的外化——你对"人与 AI 应该怎么合作"这个问题的持续回答。 而那个答案，始终是：**主权先于智能。人，永远是最终的执行者。** --- > *全景透视完成于 2026 年 6 月* > > *全文约 30,000 字* > > *"AI 提供思路，人类掌控执行。"*

配图 (可多选)

标签