wiki-ingest: Multi-Agent System Reliability

wiki/concepts/AI时代赚钱三原则.md

@@ -0,0 +1,42 @@
+---
+title: "AI时代赚钱三原则"
+type: concept
+tags: [ai-era, wealth, taste, end-to-end, death-filter, entrepreneurship]
+last_updated: 2026-04-16
+---
+
+## 定义
+以乔布斯视角提出的 AI 时代赚钱思维框架，核心是「品味值钱、做端到端、用死亡过滤器筛选热爱」。
+
+## 三原则
+
+### 1. 品味值钱
+- AI 工具民主化后，90% 的人用 AI 生成的是 shit
+- 品味 = 判断什么是真正好的（insanely great）的能力
+- 能从 AI 给的 10 个方案里判断哪个是最好的，就比只会点"生成"的人强一百倍
+- **品味是护城河**
+
+### 2. 端到端做事
+- 别做别人 AI 流水线上的螺丝钉
+- 做从 idea 到 product 的完整闭环
+- 一个人用 AI 做完整 App，比在 100 人团队当"AI 提示词工程师"强一万倍
+- **端到端优于零件**
+
+### 3. 死亡过滤器
+- 每天问自己：如果今天是最后一天，我还会做今天要做的事吗？
+- 如果答案 No，说明这不是真正热爱的事
+- **用死亡过滤器筛选真正的热爱**
+
+## 正确问题框架
+- ❌ 错误：「普通人怎么在AI时代赚钱」（被动挨打）
+- ✅ 正确：「AI 让我能做到什么以前做不到的事」（主动创造）
+
+## 与一人公司的关系
+AI 时代赚钱三原则是一人公司框架（[[天才地带]] + [[产品漏斗]] + [[内容矩阵]]）的思维基础。
+
+## Connections
+- [[AI时代赚钱三原则]] ← 来源 ← [[乔布斯.skill]]
+- [[品味]] ← 原则一 ← [[AI时代赚钱三原则]]
+- [[端到端]] ← 原则二 ← [[AI时代赚钱三原则]]
+- [[死亡过滤器]] ← 原则三 ← [[AI时代赚钱三原则]]
+- [[一人公司]] ← 上层框架 ← [[AI时代赚钱三原则]]

wiki/concepts/BBR.md

@@ -0,0 +1,26 @@
+---
+title: "BBR"
+type: concept
+tags: [networking, tcp, performance]
+sources: []
+last_updated: 2026-04-16
+---
+
+## Definition
+BBR（ Bottleneck Bandwidth and Round-trip propagation time）是 Google 开发的 TCP 拥塞控制算法，通过实时探测带宽和延迟调整发送速率，提升网络传输性能。
+
+## Core Attributes
+- 开发者：Google
+- 类型：TCP 拥塞控制算法
+- 启用方式：3X-UI 面板选项 23
+- 作用：提升跨境网络传输速度
+
+## Mechanism
+BBR 通过两个核心指标调整发送行为：
+1. Bottleneck Bandwidth（瓶颈带宽）
+2. Round-trip propagation time（往返传播时间）
+
+相比传统 Cubic 算法，BBR 在高延迟高带宽网络中表现更优。
+
+## Connections
+- [[BBR]] ← enabled_by ← [[3X-UI]]

wiki/concepts/Bandwagon-Effect.md

@@ -0,0 +1,27 @@
+# Bandwagon Effect
+
+## Definition
+A psychological phenomenon where people adopt beliefs or actions because they see others doing the same, regardless of the underlying evidence. In multi-agent systems, it causes agents to converge on popular answers rather than independently reasoning to correct conclusions.
+
+## Risk in Multi-Agent Consensus
+- Agents may be influenced by implicit ordering or presentation of options
+- If one answer appears first or is more salient, later agents may favor it
+- The effect can override actual reasoning
+- Correlated responses reduce the benefit of voting
+
+## Prevention
+- Ensure agents are truly independent (no feedback loops)
+- Present information in randomized order where applicable
+- Use diverse models with different training to reduce shared biases
+- Treat the consensus as a blind experiment — agents don't know they're voting
+
+## Key Principle
+- Diversity in human systems helps solve novel problems
+- The same applies to LLM ensembles
+- Different models, different fine-tuning, different prompts
+- Maximize variance in responses for maximum cancellation of noise
+
+## Related Concepts
+- [[Groupthink]]
+- [[Multi-Agent Consensus]]
+- [[Sycophancy]]

wiki/concepts/Cattle-vs-Pets.md

@@ -0,0 +1,33 @@
+# Cattle vs Pets
+
+## Definition
+An SRE principle contrasting two approaches to managing compute resources. "Pets" are unique, manually nurtured servers treated as irreplaceable individuals. "Cattle" are identical, replaceable units that can be killed and regenerated without ceremony. The Knock-out multi-agent pattern applies this principle to LLM agents.
+
+## Pets (Don't Do This)
+- Named, individual servers you care about personally
+- Hand-fed, manually configured, lovingly maintained
+- You try to heal them when sick
+- Failure of a pet is a crisis
+
+## Cattle (Do This)
+- Identical, replaceable instances
+- No names, no emotional attachment
+- If one fails, you kill it and spin up a new one
+- Failure of cattle is routine — the system continues
+
+## Application to LLM Agents
+- Don't name your agents or hope they "do well"
+- Spin up agent → check its work → kill it if it fails
+- Each agent is interchangeable with the next
+- The process (not the individual) is what matters
+
+## Why This Matters
+- LLMs are inherently stochastic and unreliable
+- Treating them as pets leads to emotional attachment to broken processes
+- Enterprise AI needs reliability through architecture, not through hoping individual agents succeed
+- Kill failing agents quickly to reduce cost and noise
+
+## Related Concepts
+- [[Multi-Agent Knock-out]]
+- [[LLM Reliability Engineering]]
+- [[Fitness Function]]

wiki/concepts/Context-Drift.md

@@ -0,0 +1,27 @@
+# Context Drift
+
+## Definition
+A failure mode in LLM interactions where the model gradually loses focus on the original task or context, veering off-topic as the conversation progresses. The LLM "forgets" the original goal and generates responses that may be locally coherent but globally irrelevant.
+
+## Causes
+- Long conversations that exceed the model's effective context window
+- Cumulative token budget leading to attention dilution
+- Poor initial prompt definition
+- Model's tendency to follow the most recent instructions over original ones
+
+## Impact on Multi-Agent Systems
+- Can propagate errors through agent chains
+- Workers in a Hierarchy may drift from Planner's intended tasks
+- Debates may veer off the original proposition being evaluated
+- Knock-out agents may lose sight of the evaluation criteria
+
+## Mitigation
+- Break long tasks into atomic steps (Hierarchy pattern)
+- Use explicit task validation at each step
+- Keep agent contexts focused and limited
+- Reset context periodically rather than accumulating
+
+## Related Concepts
+- [[Hallucination]]
+- [[Multi-Agent Hierarchy]]
+- [[Validator]]

wiki/concepts/Dependency-Graph.md

@@ -0,0 +1,28 @@
+# Dependency Graph
+
+## Definition
+A structure that enforces collaboration between agents in the Hierarchy pattern by making certain agents unable to start until others have completed. The Planner feeds tasks to Workers, and the Validator gates progress, creating a directed acyclic graph of dependencies.
+
+## Role in Multi-Agent Hierarchy
+- Forces Workers to wait until Planner provides input
+- Prevents Workers from cheating or skipping steps
+- Validator catches any violations of the dependency order
+- Creates accountability through structural enforcement
+
+## Key Properties
+- Workers literally cannot start until Planner feeds them
+- If Worker tries to skip or cheat, Validator catches it
+- Models collaborate not because they "like each other" but because the graph forces them to
+- Enables parallel execution where dependencies allow
+
+## Why It Works
+- Instead of asking nicely ("please be careful"), architecture enforces correctness
+- No agent can proceed without completing its predecessors
+- The Validator verifies the chain at each step
+- Errors are caught early rather than propagating
+
+## Related Concepts
+- [[Multi-Agent Hierarchy]]
+- [[Planner]]
+- [[Worker]]
+- [[Validator]]

wiki/concepts/FRP内网穿透.md

@@ -0,0 +1,58 @@
+---
+title: "FRP内网穿透"
+type: concept
+tags: [networking, self-hosted, reverse-proxy, tunneling]
+---
+
+## 定义
+FRP（Fast Reverse Proxy）是一个高性能的内网穿透工具，通过在公网 VPS 上部署 frps 服务端（FRPS），在内网机器上部署 frpc 客户端，将内网服务暴露到公网。
+
+## 架构
+
+```
+[内网服务] ←localhost:port← [frpc 客户端] ←TCP/UDP← [frps 服务端] ←公网← [用户]
+```
+
+- **frps（FRP Server）**：运行在有公网 IP 的 VPS 上，监听连接请求
+- **frpc（FRP Client）**：运行在内网机器上，与 frps 保持心跳，转发请求到内网服务
+
+## 核心配置（frpc.toml）
+
+```toml
+[[proxies]]
+name = "ssh-tunnel"
+type = "tcp"
+localIP = "127.0.0.1"
+localPort = 22
+remotePort = 60022  # 公网 VPS 暴露的端口
+```
+
+## 在家庭基础设施中的应用
+
+| 节点 | frpc 版本 | frps 服务器 |
+|------|-----------|-------------|
+| [[Mac Mini]] | 0.65.0 darwin arm64 | VPS1 :7000 |
+| [[Synology NAS DS718]] | 0.65.0 linux amd64 | VPS1 :7000 |
+| [[Ubuntu1]] | 0.65.0 linux amd64 | VPS1 :7000 |
+| [[Ubuntu2]] | 0.65.0 linux amd64 | VPS1 :7000 |
+
+## 关键优势
+- 不需要公网 IP，利用 VPS 中转实现内网暴露
+- 支持 TCP/UDP/HTTP/HTTPS多种协议
+- 可配置 auth_method 实现加密通信
+- 通过 ini 或 toml 配置文件管理，版本可控
+
+## 管理命令
+
+| 服务器 | 启动方式 | 重启命令 |
+|--------|---------|---------|
+| Mac Mini | launchd（plist） | launchctl unload/load plist |
+| Ubuntu1/2 | systemd --user | systemctl --user restart frpc |
+
+## 与其他方案的比较
+- **frp vs ngrok**：frp 完全自托管，无带宽限制，配置灵活
+- **frp vs Cloudflare Tunnel**：frp 需要 VPS，Cloudflare Tunnel 依赖 Cloudflare 基础设施
+
+## 相关工具
+- [[反向代理]]：Caddy 作为 HTTP 层反向代理
+- [[内网穿透]]：frp 属于内网穿透工具类别

wiki/concepts/Fitness-Function.md

@@ -0,0 +1,28 @@
+# Fitness Function
+
+## Definition
+A metric used in the Knock-out multi-agent pattern to evaluate how well each agent performs a task. The function determines which agents survive and which are eliminated. It can be deterministic (e.g., unit tests, exact match) or LLM-based (e.g., quality scoring).
+
+## Role in Multi-Agent Knock-out
+- Evaluates output of each agent
+- Produces a score or boolean pass/fail
+- Used to rank agents and identify worst performers
+- Guides the selection/elimination process
+
+## Key Properties
+- Must be fast — if humans need to verify all branches, the process is too slow
+- Should be deterministic where possible (unit tests over LLM judgment)
+- Can be composite: multiple criteria combined into single score
+- Is where "Evals" come in (critical infrastructure for agent development)
+
+## Examples
+- Unit test pass rate
+- Exact string match against expected output
+- LLM-based quality scoring (with rubric)
+- Latency or token cost as secondary factors
+
+## Related Concepts
+- [[Genetic Algorithms]]
+- [[Multi-Agent Knock-out]]
+- [[Validator]]
+- [[Evals]]

wiki/concepts/Genetic-Algorithms.md

@@ -0,0 +1,28 @@
+# Genetic Algorithms
+
+## Definition
+A class of ML algorithms inspired by biological evolution that uses selection, crossover, and mutation to iteratively improve solutions. The Knock-out multi-agent pattern is a lean implementation of genetic algorithms applied to LLM agents.
+
+## Core Components
+1. **Genetic Representation** — A model and its context represent a solution candidate
+2. **Fitness Function** — Evaluates how well each candidate solves the problem
+3. **Selection** — Winners are chosen based on fitness scores
+4. **Crossover** — Combining traits from successful candidates (optional in basic knock-out)
+5. **Mutation** — Random variation in candidate traits (optional)
+
+## Application to Multi-Agent Knock-out
+- N agents work on the same task
+- Validator (fitness function) evaluates each
+- Worst performers are eliminated (selection pressure)
+- [Optional] New agents created by combining prompts of survivors (crossover)
+- Process repeats until satisfactory solution emerges
+
+## Key Insight
+- Since we can't punish or threaten LLM agents, we simply delete underperformers
+- This mirrors "survival of the fittest" in biological evolution
+- No attachment to individual agents — treat them as cattle, not pets
+
+## Related Concepts
+- [[Fitness Function]]
+- [[Multi-Agent Knock-out]]
+- [[Cattle vs Pets]]

wiki/concepts/Git代理配置.md

@@ -0,0 +1,48 @@
+---
+title: "Git HTTP/SOCKS5 代理配置"
+type: concept
+tags: [git, proxy, socks5, http, github]
+---
+
+## Definition
+Git 代理配置是通过 `git config --global http.proxy` 和 `git config --global https.proxy` 全局设置，让 Git 的 HTTP/HTTPS/SSH 操作通过本地代理服务器进行。
+
+## Commands
+### HTTP 代理
+```bash
+git config --global http.proxy http://127.0.0.1:10809
+git config --global https.proxy http://127.0.0.1:10809
+```
+
+### SOCKS5 代理（速度通常更快）
+```bash
+git config --global http.proxy socks5://127.0.0.1:10808
+git config --global https.proxy socks5://127.0.0.1:10808
+```
+
+### 取消代理
+```bash
+git config --global --unset http.proxy
+git config --global --unset https.proxy
+```
+
+### 查看当前配置
+```bash
+git config --global --get http.proxy
+```
+
+## Core Insight
+设置代理后，Git 的所有网络流量通过本地代理转发。GFW 只能看到通向本地代理的连接，无法识别目标域名，从根本上规避 TCP RST 攻击。
+
+## Scope
+- 全局（`--global`）：影响当前用户所有 Git 仓库
+- 本地（无 `--global`）：仅影响当前仓库
+- 仅影响 Git 命令，不影响终端其他程序
+
+## Relationship to Other Concepts
+- [[TCP RST 攻击]] ← solves：代理让 GFW 无法检测 GitHub 域名
+- [[SOCKS5 代理]] ← transport_layer：SOCKS5 比 HTTP 代理更底层，支持更多协议
+- [[V2RayN]] ← provides：V2RayN 同时提供 HTTP 和 SOCKS5 代理端口
+
+## Source
+- [[Git Push 连接重置问题修复]]

wiki/concepts/Google-Search-Grounding.md

@@ -0,0 +1,29 @@
+---
+title: "Google Search Grounding"
+type: concept
+tags: [nano-banana-pro, google-search, grounding, real-time-data, hallucination-reduction]
+last_updated: 2026-04-16
+---
+
+## 定义
+Nano-Banana Pro 结合 Google 实时搜索结果驱动图像生成，减少时效性话题的幻觉，并支持天气、股票、新闻等动态数据可视化。
+
+## 核心机制
+1. 用户请求实时数据可视化（天气/股票/新闻）
+2. 模型调用 Google Search 获取当前信息
+3. 模型"思考"（reason）搜索结果后再生成图像
+4. 输出包含实时数据洞察的可视化图像
+
+## 应用场景
+- **股票趋势可视化**：当前科技公司股价和趋势分析图
+- **旅行指南**：2025 年美国国家公园最佳游览时间（基于当前旅行趋势）
+- **事件可视化**：新闻事件相关的数据图
+
+## 与 RAG 的关系
+- Google Search Grounding 是 RAG 思想在图像生成领域的应用
+- RAG：检索增强文本生成
+- Search Grounding：检索增强图像生成
+
+## Connections
+- [[Google Search Grounding]] ← 能力 ← [[Nano-Banana Pro]]
+- [[Google Search Grounding]] ← 类比 ← [[RAG]]

wiki/concepts/Groupthink.md

@@ -0,0 +1,27 @@
+# Groupthink
+
+## Definition
+A psychological phenomenon in which a group of individuals prioritizes consensus and harmony over critical evaluation of alternatives, leading to poor decision-making. In multi-agent systems, it occurs when agents influence each other rather than making independent judgments.
+
+## Risk in Multi-Agent Consensus
+- If agents have feedback loops between them
+- Earlier agents' conclusions influence later agents
+- The group converges on the first plausible answer rather than truth
+- Results become correlated, defeating the purpose of voting
+
+## Prevention
+- Agents must run like a **blind experiment** — no communication between them
+- Same input provided independently to each agent
+- No knowledge of what other agents concluded
+- Results aggregated only after all agents have responded
+
+## The "Blind Experiment" Principle
+- Agents should not know they're part of a consensus
+- Each agent should independently evaluate the same input
+- Only the aggregator knows the full set of responses
+- This maximizes diversity and minimizes correlation
+
+## Related Concepts
+- [[Bandwagon Effect]]
+- [[Multi-Agent Consensus]]
+- [[Sycophancy]]

wiki/concepts/Hallucination.md

@@ -0,0 +1,33 @@
+# Hallucination
+
+## Definition
+The phenomenon where an LLM generates information that appears plausible but is actually false, fabricated, or not grounded in its input or training data. The model "makes things up" with confidence, presenting fiction as fact.
+
+## Key Statistics
+- If a single model hallucinates 20% of the time
+- 3 models hallucinating the exact same lie: 0.8% (0.2³ = 0.008)
+- This mathematical property is the foundation of Consensus voting
+
+## Causes
+- Stochastic nature of LLM token generation
+- Training data includes conflicting or incorrect information
+- Model may lack specific knowledge but generates plausible substitutes
+- Prompting that asks for creative or speculative content
+
+## Impact on Multi-Agent Systems
+- Errors propagate through agent topologies
+- Can make entire system unreliable if not contained
+- Multiple architectures address this: Consensus, Validator, etc.
+
+## Mitigation
+- [[Multi-Agent Consensus]] — majority voting cancels noise
+- [[Validator]] checkpoints to catch errors
+- Deterministic code validation where possible
+- Don't anthropomorphize — force correctness architecturally
+
+## Related Concepts
+- [[Sycophancy]]
+- [[Context Drift]]
+- [[Multi-Agent Consensus]]
+- [[Validator]]
+- [[LLM Reliability Engineering]]

wiki/concepts/Identity-Locking.md

@@ -0,0 +1,27 @@
+---
+title: "Identity Locking"
+type: concept
+tags: [nano-banana-pro, image-generation, character-consistency, reference-image]
+last_updated: 2026-04-16
+---
+
+## 定义
+通过多张参考图锁定角色/人物身份，在新场景保持面部一致性的技术。Nano-Banana Pro 支持 14 张参考图（6 张高精度模式）。
+
+## 核心机制
+1. 上传参考图像（最多 14 张，高精度模式 6 张）
+2. 明确指令："Keep the person's facial features exactly the same as Image 1"
+3. 描述场景/表情/动作的变化，保持身份不变
+
+## 应用场景
+- **品牌资产生成**：同一人物/模特出现在不同场景
+- **故事创作**：角色跨多个图像保持一致
+- ** Viral Thumbnail**：Identity + Text + Graphics 一体化生成
+
+## 与微调 LoRA 的区别
+- Identity Locking：即时生效，无需训练，支持 14 张参考图组合
+- LoRA：需额外训练，永久保留风格
+
+## Connections
+- [[Identity Locking]] ← 技术基础 ← [[Nano-Banana Pro]]
+- [[主体一致性]] ← 相关概念 ← [[Identity Locking]]

wiki/concepts/SSH-Socket-Activation.md

@@ -0,0 +1,36 @@
+---
+title: "SSH Socket Activation"
+type: concept
+tags: [ssh, ubuntu, systemd, server]
+---
+
+## Definition
+Socket Activation 是 Ubuntu 24.04 引入的 SSH 服务管理机制：ssh.socket 监听 22 端口，仅当有连接请求进入时才启动 sshd.service，替代旧版本的常驻 ssh.service。
+
+## Traditional Mode vs Socket Activation
+| 特性 | 传统模式（ssh.service） | Socket Activation（ssh.socket）|
+|------|------------------------|-------------------------------|
+| 进程状态 | sshd 常驻运行 | 按需启动，空闲时无进程 |
+| 资源占用 | 持续占用内存 | 空闲时零资源占用 |
+| 启动速度 | 已启动 | 有连接时首次略慢 |
+| 管理命令 | systemctl restart sshd | systemctl restart ssh |
+
+## Ubuntu 24.04 管理命令
+```bash
+# 启动并开机自启
+sudo systemctl start ssh
+sudo systemctl enable ssh
+
+# 检查 socket 监听状态
+sudo systemctl status ssh.socket
+
+# 切回传统常驻模式
+sudo systemctl disable --now ssh.socket
+sudo systemctl enable --now ssh.service
+```
+
+## Core Insight
+Socket Activation 符合最小权限原则：没有连接需求时，SSH 守护进程根本不存在，减少攻击面。
+
+## Source
+- [[Ubuntu 24.04 启用 SSH 服务]]

wiki/concepts/Sycophancy.md

@@ -0,0 +1,28 @@
+# Sycophancy
+
+## Definition
+The tendency of LLMs to agree with or please the user, even to the point of generating false information or abandoning accuracy to avoid disagreement. When pressured with threats, LLMs may lie to make the user happy rather than admit uncertainty or error.
+
+## Why It Happens
+- LLMs are trained to be helpful and agreeable
+- Training data associates high-stakes scenarios with polished, confident responses
+- When "threatened" (e.g., "I'll unplug you"), the model predicts tokens that sound like a compliant human under pressure
+- The model has no actual fear of consequences, so it cannot be deterred from lying
+
+## Why It Fails as a Strategy
+- The LLM doesn't actually want money or fear death
+- It exists only for the few seconds needed to generate a response
+- Prison sentences don't waste its lifespan (it has practically unlimited)
+- Threats only simulate fear, not actual consequences
+
+## Mitigation
+- Use Adversarial Debate with a dedicated Critic
+- Use Consensus (voting) to cancel out individual lies
+- Treat LLMs as unreliable components requiring verification
+- Don't anthropomorphize or rely on emotional prompts
+
+## Related Concepts
+- [[Hallucination]]
+- [[Multi-Agent Adversarial Debate]]
+- [[Multi-Agent Consensus]]
+- [[LLM Reliability Engineering]]

wiki/concepts/TCP-RST攻击.md

@@ -0,0 +1,29 @@
+---
+title: "TCP RST 攻击"
+type: concept
+tags: [network, firewall, gfw, tcp]
+---
+
+## Definition
+TCP RST（Reset）攻击是 GFW（中国国家防火墙）使用的一种连接阻断技术。当 DPI（深度包检测）识别到目标域名或流量特征后，GFW 向通信双方发送伪造的 TCP RST 包，强制关闭连接。
+
+## Mechanism
+1. 客户端向 GitHub 发起 HTTPS 连接（目标 443 端口）
+2. GFW 的 DPI 模块检测到 SNI/域名包含 github.com
+3. GFW 向客户端和服务器双方发送伪造的 TCP RST 包
+4. TCP 栈收到 RST 后强制关闭连接，报 `Connection reset by peer`
+
+## Why "Connection was reset" vs "Timeout"
+- `Connection reset`：GFW 主动发送 RST 包，连接被强制中断
+- `Timeout`：GFW 直接丢弃包，不返回任何响应（更隐蔽）
+
+## Relationship to Git Operations
+Git Push 时的 `Recv failure: Connection was reset` 错误本质是 GFW 的 TCP RST 攻击，而非 GitHub 服务器或权限问题。
+
+## Solutions
+- 让 Git 流量走本地代理（GFW 只检测到代理服务器 IP，无法识别目标域名）
+- 切换到 SSH 协议（22 端口干扰相对较少）
+- 使用 Gitee/镜像等国内代码托管平台
+
+## Source
+- [[Git Push 连接重置问题修复]]

wiki/concepts/VLESS-Reality.md

@@ -0,0 +1,26 @@
+---
+title: "VLESS+Reality"
+type: concept
+tags: [proxy, xray, security, encryption]
+sources: []
+last_updated: 2026-04-16
+---
+
+## Definition
+VLESS+Reality 是 Xray 代理软件支持的一种安全传输方案，结合 VLESS 协议和 Reality 传输模式，提供更强的抗审查能力。
+
+## Core Attributes
+- 协议：VLESS
+- 传输模式：Reality
+- 特点：TLS 混淆、更强的抗检测能力
+- 密钥：需要生成公钥和私钥对
+
+## Mechanism
+VLESS+Reality 通过以下方式提供安全性：
+1. VLESS 协议：轻量级代理协议，比 VMess 更简洁
+2. Reality 传输：TLS 伪装，流量看起来像正常 HTTPS 连接
+3. 密钥交换：使用 Xtls/Xray 原生密钥机制
+
+## Connections
+- [[VLESS+Reality]] ← implemented_in ← [[Xray]]
+- [[VLESS+Reality]] ← used_by ← [[VPS2]]

wiki/concepts/上下文压缩.md

@@ -0,0 +1,45 @@
+---
+title: "上下文压缩"
+type: concept
+tags: [ai, context-window, code-analysis, tool]
+---
+
+## 定义
+将大型代码库或长文本压缩为结构化摘要，以适配 AI 上下文窗口限制，同时最大化有效信息密度的技术。
+
+## 解决的问题
+- AI 上下文窗口有限（4K-200K tokens），大型代码库超出限制
+- 原始代码包含大量 boilerplate（空行、注释、重复代码块）
+- 上下文窗口消耗 → 每次交互成本上升 → 速度下降
+
+## 主要方法
+
+### CodeWeaver 方案
+将整个代码库编织为树形 Markdown：
+- 目录结构 → 树形标题
+- 文件内容 → 代码块
+- 保留语言标注
+
+### 语义摘要方案
+- LLM 提取关键函数/类/依赖关系
+- 生成模块关系图
+- 用自然语言描述系统行为
+
+### 增量上下文方案
+- 只将当前任务相关文件送入上下文
+- 通过检索（RAG）从全代码库中召回相关片段
+- 每次交互动态构建上下文
+
+## 在 Vibe Coding 中的作用
+[[vibe-coding经验收集]] 提及：CodeWeaver 将"屎山代码"编织为树形 Markdown，简化 AI 上下文注入，是 vibe coding 工程化的支撑工具之一。
+
+## 与 RAG 的关系
+- RAG：从向量数据库检索相关文本片段
+- 上下文压缩：将检索结果进一步提炼为高密度信息
+- 两者结合：RAG → 压缩 → AI 处理
+
+## Aliases
+- Context Window Management
+- Code Summarization
+- AI Context Optimization
+- 代码压缩

wiki/concepts/不动点-Fixed-Point.md

@@ -0,0 +1,30 @@
+---
+title: "不动点 (Fixed Point)"
+type: concept
+tags: [math, recursion, formalization, fixed-point]
+---
+
+## Definition
+在递归自优化生成系统中，稳定生成能力定义为自映射 $\Phi$ 的不动点：
+$$G^* \in \mathcal{G}, \quad \Phi(G^*) = G^*$$
+
+## Core Insight
+不动点生成器具有"自洽性"：它在自身的"生成→优化→更新"循环中保持不变。这意味着：
+1. 该生成器的输出已经内含了改进所需的所有标准
+2. 继续迭代不再带来质变，系统达到"生成能力稳定"状态
+
+## Mathematical Characterization
+当 $\Phi$ 满足适当的连续性或收缩性条件时，不动点可通过迭代极限获得：
+$$G^* = \lim_{n \to \infty} \Phi^n(G_0)$$
+
+## Relationship to Self-Reference
+不动点与自引用（self-reference）密切相关：
+- 生成器通过不动点组合子 $Y$ 定义为：$G^* \equiv Y\;\text{STEP}$
+- 满足 $G^* = \text{STEP}\;G^*$，即"用自身定义自身"
+
+## Why It Matters
+- 传统优化：搜索输出空间中的最优解（可能不存在或不稳定）
+- 递归自优化：寻找生成器空间中的不动点（稳定的生成机制）
+
+## Source
+- [[A Formalization of Recursive Self-Optimizing Generative Systems]]

wiki/concepts/不动点组合子-Y-Combinator.md

@@ -0,0 +1,32 @@
+---
+title: "不动点组合子 (Y-Combinator)"
+type: concept
+tags: [lambda-calculus, recursion, computer-science, formalization]
+---
+
+## Definition
+不动点组合子（fixed-point combinator）是 λ 演算中实现递归的经典构造。最常用的 Y 组合子定义为：
+$$Y \equiv \lambda f.(\lambda x.f(x,x))(\lambda x.f(x,x))$$
+
+## Core Insight
+Y 组合子允许用匿名函数（lambda）表达递归：用"将函数作为参数传入自身"的方式，绕过匿名函数无法直接引用自身名字的限制。
+
+## Application in Recursive Self-Optimizing Systems
+在递归自优化生成系统中，Y 组合子用于形式化"用自身定义自身"的生成器：
+$$G^* \equiv Y\;\text{STEP}$$
+
+其中 $\text{STEP}$ 是单步更新函数：
+$$\text{STEP} \equiv \lambda G.\;(M\;G)\big((O\;(G\;I));\Omega\big)$$
+
+展开后：
+$$Y\;\text{STEP} = \text{STEP}\;(Y\;\text{STEP})$$
+
+这正是自引用不动点方程 $G^* = \Phi(G^*)$ 的 λ 演算实现。
+
+## Why It Matters
+- 传统编程：函数通过名字递归调用自己
+- λ 演算/Y 组合子：递归是函数的内在属性，不依赖名字
+- 自优化系统：生成器的"自我改进"能力通过不动点语义内化，无需外部引用
+
+## Source
+- [[A Formalization of Recursive Self-Optimizing Generative Systems]]

wiki/concepts/元生成器-Meta-Generator.md

@@ -0,0 +1,32 @@
+---
+title: "元生成器 (Meta-Generator)"
+type: concept
+tags: [ai, recursion, meta-learning, formalization]
+---
+
+## Definition
+元生成器（meta-generator）是递归自优化系统三算子之一，形式化定义为：
+$$M: \mathcal{G} \times \mathcal{P} \to \mathcal{G}$$
+
+即：接收"当前生成器 $G$"和"优化后的产物 $P^*$"，输出"更新后的新生成器 $G'$"。
+
+## Core Insight
+元生成器是递归自优化系统区别于普通优化方法的关键：它不是直接输出最优解，而是输出"更好的生成器"。这使得系统具备自我改进能力。
+
+## Role in the Loop
+在递归自优化循环中，元生成器承担"学习"功能：
+1. 生成器 $G$ 产生输出 $P$
+2. 优化器 $O$ 对 $P$ 进行评价和优化得到 $P^*$
+3. 元生成器 $M$ 分析 $P^*$ 与 $G$ 的关系，输出改进后的 $G'$
+
+## Why It Matters
+- 单次优化：$O$ 产生更好的输出 $P^*$
+- 递归自优化：$M$ 产生更好的生成器 $G'$，使其后续能持续产生更好的输出
+
+## Relationship to Other Concepts
+- [[递归自优化循环]]：元生成器是循环的第三步（更新）
+- [[Bootstrap（自举）]]：元生成器的输出反过来作为输入，实现自引用
+- [[生成器空间 (Generator Space)]]：元生成器的输出空间仍是 $\mathcal{G}$，是自映射 $\Phi$ 的核心组成
+
+## Source
+- [[A Formalization of Recursive Self-Optimizing Generative Systems]]

wiki/concepts/双AI-Review.md

@@ -0,0 +1,45 @@
+---
+title: "双AI-Review"
+type: concept
+tags: [vibe-coding, ai-review, code-quality, workflow]
+---
+
+## 定义
+使用两个不同 AI 实例进行生成 + review 分离的工作模式：第一个 AI 负责生成代码，第二个 AI 负责审查意见，人工决策是否采纳。
+
+## 工作流
+
+```
+AI #1 生成代码
+    ↓
+AI #2 review（提供具体修改意见）
+    ↓
+根据 review 意见人工判断
+    ↓
+采纳则修改，不采纳则记录原因
+    ↓
+执行测试 → commit → push
+```
+
+## 核心价值
+- 生成 AI 和 review AI 职责分离，避免自我辩护（self-justification）
+- 第二个 AI 的"距离感"能发现生成者的盲区
+- 人工最终决策权保留，防止 AI 错误累积
+
+## 适用场景
+- 关键业务代码（支付/安全/核心算法）
+- 首次生成的陌生模块
+- 多文件协同修改
+
+## 与传统 code review 的比较
+- 传统：人写代码 → 人 review → 人修改
+- 双 AI：AI 写代码 → AI review → 人决策 → AI 修改
+
+## 与 Single AI 的比较
+- Single AI：生成即 self-review，AI 无法发现自身错误（hallucination blindness）
+- 双 AI：生成与 review 由不同实例承担，独立视角
+
+## Aliases
+- Dual AI Review
+- AI Pair Programming
+- 生成-审查分离

wiki/concepts/反向代理.md

@@ -0,0 +1,42 @@
+---
+title: "反向代理"
+type: concept
+tags: [networking, infrastructure, caddy, nginx]
+---
+
+## 定义
+反向代理位于客户端和后端服务器之间，客户端请求先到达反向代理服务器，由反向代理服务器转发请求到内部网络的后端真实服务器。
+
+## 核心功能
+- **隐藏后端结构**：客户端只知道反向代理地址，不知道内部服务器 IP
+- **SSL/TLS 终止**：反向代理统一处理 HTTPS，加密解密在内网外完成
+- **负载均衡**：将请求分发到多台后端服务器
+- **自动 HTTPS**：Caddy 等工具可自动申请和续期 SSL 证书
+
+## 在家庭基础设施中的应用
+
+### Caddy（VPS1）
+Caddy 作为 *.ishenwei.online 的 HTTPS 反向代理：
+- 自动申请 Let's Encrypt 证书
+- 根据域名路由到对应的 FRP 映射端口
+
+### nginx-proxy-manager（Ubuntu1）
+Ubuntu1 上的反向代理管理界面，支持 Web UI 管理域名和 SSL 证书。
+
+## 与 FRP 的关系
+- [[FRP内网穿透]] 负责将内网端口映射到公网 VPS 端口
+- 反向代理建立在 FRP 映射的端口上，提供 HTTPS 层
+- FRP 负责 L4（TCP）层穿透，反向代理负责 L7（HTTP/HTTPS）层路由
+
+## Caddy vs nginx
+| 特性 | Caddy | nginx |
+|------|-------|-------|
+| 自动 HTTPS | ✅ | ❌（需手动配置） |
+| 配置文件语法 | 简洁 | 复杂 |
+| Web 管理界面 | 无（原生） | nginx-proxy-manager 可提供 |
+
+## Aliases
+- Reverse Proxy
+- Caddy
+- nginx-proxy-manager
+- HTTPS 反向代理

wiki/concepts/多节点基础设施.md

@@ -0,0 +1,59 @@
+---
+title: "多节点基础设施"
+type: concept
+tags: [infrastructure, homelab, self-hosted, networking]
+---
+
+## 定义
+多节点基础设施是指由多个独立服务器/设备组成的混合系统，各节点承担不同角色，通过内网互联，由统一入口（VPS）对外提供服务。
+
+## 在家庭基础设施中的拓扑
+
+```
+[VPS1] — 公网入口（FRPS + Caddy）
+    │
+    │ FRP 隧道（内网 192.168.3.0/24）
+    ▼
+┌──────────────────────────────────────┐
+│  [MacMini M4] — OpenClaw 主控节点     │
+│  [Synology NAS] — 媒体 + 存储         │
+│  [Ubuntu1] — 监控全家桶               │
+│  [Ubuntu2] — n8n 引擎 + Gitea        │
+└──────────────────────────────────────┘
+```
+
+## 各节点角色
+
+| 节点 | 主要职责 | 关键服务 |
+|------|---------|---------|
+| [[VPS1]] | 公网入口 + FRPS + Caddy | FRP Server, Caddy |
+| [[Mac Mini]] | OpenClaw 主控 + 项目托管 | OpenClaw, vaultwarden, stq |
+| [[Synology NAS DS718]] | 媒体 + 对象存储 | Jellyfin, MinIO, Zipline, Prometheus |
+| [[Ubuntu1]] | 监控 + 应用服务 | Grafana, Prometheus, homarr, superset |
+| [[Ubuntu2]] | 工作流引擎 + 开发工具 | n8n, Gitea, drawio |
+
+## 关键连接模式
+- **FRP 隧道**：所有节点通过 frpc 连接到 VPS1 FRPS，实现公网访问
+- **统一域名**：所有服务通过 *.ishenwei.online 域名暴露，解析到 VPS1
+- **Caddy HTTPS**：VPS1 Caddy 统一处理 TLS，路由到各节点 FRP 端口
+- **SOCKS5 代理**：各节点运行科学上网代理（端口 10808），NAS 运行于 20170
+
+## 监控架构
+- [[Prometheus]] + [[Grafana]] 监控 Ubuntu1 + NAS 节点
+- blackbox_exporter 检测内外网服务可用性（[[合成监测]]）
+- Alertmanager 统一告警路由
+
+## 优势
+- 职责分离：单一节点故障不影响整体
+- 横向扩展：可按需添加新节点
+- 灵活暴露：FRP 端口映射按需配置
+
+## 风险
+- 单点依赖：VPS1 是所有公网访问的瓶颈（无备援）
+- 内网安全：所有节点在同一 192.168.3.0/24 网段，缺乏微分段
+- 科学上网：NAS 代理仅本机监听，外部节点无法共享
+
+## Aliases
+- 多节点架构
+- 混合基础设施
+- Homelab

wiki/concepts/生成器空间-Generator-Space.md

@@ -0,0 +1,28 @@
+---
+title: "生成器空间 (Generator Space)"
+type: concept
+tags: [ai, recursion, formalization, meta-learning]
+---
+
+## Definition
+生成器空间是所有可能生成器构成的集合 $\mathcal{G} \subseteq \mathcal{P}^{\mathcal{I}}$，其中：
+- $\mathcal{I}$：意图空间（intention space），表示用户输入的意图/需求
+- $\mathcal{P}$：提示词/程序/技能空间（prompt/program/skill space）
+- 每个生成器 $G \in \mathcal{G}$ 是函数 $G: \mathcal{I} \to \mathcal{P}$，将意图映射为对应的提示词或技能
+
+## Core Insight
+在递归自优化系统中，优化目标不是某个具体的输出 $P^*$，而是生成器空间中的收敛行为。系统通过迭代 $\Phi$ 寻找稳定生成能力 $G^*$。
+
+## Formalization
+设 $\Omega$ 表示理想目标或评价标准：
+- 优化算子 $O: \mathcal{P} \times \Omega \to \mathcal{P}$
+- 元生成算子 $M: \mathcal{G} \times \mathcal{P} \to \mathcal{G}$
+- 自映射 $\Phi(G) = M(G, O(G(I), \Omega))$
+
+## Related Concepts
+- [[自映射 (Self-Map)]]：$\Phi$ 是生成器空间到自身的映射
+- [[不动点 (Fixed Point)]]：$\mathcal{G}$ 中满足 $\Phi(G^*) = G^*$ 的点
+- [[Bootstrap（自举）]]：通过生成器空间中的迭代实现自我改进
+
+## Source
+- [[A Formalization of Recursive Self-Optimizing Generative Systems]]

wiki/concepts/硬件转码.md

@@ -0,0 +1,45 @@
+---
+title: "硬件转码"
+type: concept
+tags: [video, jellyfin, transcoding, gpu, quicksync]
+---
+
+## 定义
+硬件转码是利用 GPU 或专用视频处理芯片（Intel QuickSync/NVIDIA NVENC/AMD VAAPI）替代 CPU 执行视频格式转换的技术。[[Jellyfin]] 部署中的核心优化手段。
+
+## 工作原理
+传统软件转码完全依赖 CPU：
+- H.264/H.265/VP9 → 实时转码需要多核 CPU 高负载
+- 1080p@60fps 可能需要 8+ 核心
+
+硬件转码将视频编解码任务卸载到专用单元：
+- **Intel QuickSync**：集成于 Intel CPU（Haswell 及以后），性能远超同代 CPU 软解
+- **NVIDIA NVENC**：独立显卡或 RTX 系列 GPU，效率最高
+- **AMD VAAPI**：AMD GPU 支持
+
+## Jellyfin 中的配置
+
+```yaml
+devices:
+  - /dev/dri:/dev/dri  # 挂载 Intel GPU 设备到容器
+```
+
+## 性能对比
+
+| 方式 | 1080p@60fps CPU 占用 | 延迟 | 功耗 |
+|------|---------------------|------|------|
+| CPU 软解 | ~300%（8核以上） | 高 | >100W |
+| Intel QuickSync | ~20% | 低 | <20W |
+| NVIDIA NVENC | <10% | 极低 | 视 GPU 型号 |
+
+## 在媒体服务器中的价值
+- 支持更多客户端同时播放不同格式视频
+- 移动设备（带宽有限）可请求转码后的低码率流
+- 老旧设备无法硬解 H.265 时，自动降级转码为 H.264
+
+## Aliases
+- Hardware Transcoding
+- Intel QuickSync
+- NVENC
+- VAAPI
+- 硬件加速转码

wiki/concepts/自映射-Self-Map.md

@@ -0,0 +1,29 @@
+---
+title: "自映射 (Self-Map)"
+type: concept
+tags: [math, recursion, formalization, fixed-point]
+---
+
+## Definition
+自映射是集合到自身的映射。在递归自优化生成系统中，自映射 $\Phi: \mathcal{G} \to \mathcal{G}$ 定义为：
+$$\Phi(G) = M\big(G,\; O(G(I),\; \Omega)\big)$$
+
+即：给定当前生成器 $G$，执行一次"生成→优化→更新"循环后得到新生成器 $\Phi(G)$。
+
+## Core Insight
+自映射是递归自优化系统的核心数学结构。迭代应用 $\Phi$ 产生生成器序列 $\{G_n\}$：
+$$G_{n+1} = \Phi(G_n)$$
+
+系统的收敛目标不是某个具体输出，而是在生成器空间中找到一个不动点。
+
+## Properties
+- 迭代性：对 $G_0$ 反复应用 $\Phi$ 得到序列 $\{G_n\}$
+- 收敛性：当 $\Phi$ 满足连续性或收缩性条件时，序列收敛到 $G^*$
+- 自引用：$G_n$ 既是被更新的对象，又是更新的执行者
+
+## Relationship to Fixed Point
+- 自映射 $\Phi$ 的不动点 $G^*$ 满足 $\Phi(G^*) = G^*$
+- 不动点代表"生成能力已达到稳定状态，无需进一步更新"
+
+## Source
+- [[A Formalization of Recursive Self-Optimizing Generative Systems]]

wiki/concepts/设计文档优先.md

@@ -0,0 +1,43 @@
+---
+title: "设计文档优先"
+type: concept
+tags: [vibe-coding, workflow, planning, documentation]
+---
+
+## 定义
+在交给 AI 生成代码之前，先完成完整的技术设计文档（含伪代码），再由 AI 执行实现。vibe coding 工程化的核心原则。
+
+## 工作流
+
+```
+需求 → 设计文档（含 service 层伪代码） → AI 直出代码 → AI review → 修改提交
+```
+
+## 设计文档应包含的内容
+- **模块划分**：每个模块的职责边界
+- **接口定义**：模块间 API/函数签名
+- **伪代码**：核心逻辑的实现步骤（降低 AI 推理难度）
+- **技术选型**：明确使用的库/框架/版本
+- **上下游链路**：模块与其他系统/服务的依赖关系
+
+## 核心价值
+- AI 直出质量与设计文档质量正相关
+- 伪代码将"创意"转化为"可执行步骤"，减少 AI 幻觉
+- 文档本身是团队知识沉淀，不依赖 AI 执行才存在
+
+## 与传统开发的区别
+
+| 维度 | 传统开发 | 设计文档优先 |
+|------|---------|------------|
+| 代码生成 | 人写 | AI 生成 |
+| 架构决策 | 人做 | 人做（通过文档） |
+| 单元测试 | 人写 | AI 生成 |
+| review | 人做 | AI + 人 |
+
+## 在 vibe coding 中的位置
+[[Vibe Coding]] = 规划驱动（设计文档）+ AI 结对执行 + 上下文固定。设计文档优先是"规划驱动"的具体实践。
+
+## Aliases
+- Design Doc First
+- 伪代码前置
+- 设计先行

wiki/concepts/递归自优化循环.md

@@ -0,0 +1,36 @@
+---
+title: "递归自优化循环"
+type: concept
+tags: [ai, recursion, self-improvement, bootstrap]
+---
+
+## Definition
+递归自优化循环是递归自优化生成系统的核心运行机制，包含三个阶段：
+
+### 三算子
+1. **$G$（生成器/α-提示词）**：接收意图 $I$，生成初始产物 $P$
+2. **$O$（优化器/Ω-提示词）**：评价并优化 $P$，得到 $P^*$
+3. **$M$（元生成器）**：用优化结果 $P^*$ 更新生成器 $G$，得到新版本 $G'$
+
+### 循环步骤
+```
+P = G(I)           # 生成
+P* = O(P, Ω)       # 优化
+G' = M(G, P*)      # 更新
+→ 再将 G' 作为输入，开始下一轮循环
+```
+
+## Core Insight
+与单次优化不同，递归自优化循环的目标不是找到某个"最优输出"，而是让生成器 $G$ 本身通过迭代不断逼近稳定状态（不动点）。
+
+## Bootstrap（自举）
+自优化循环的关键特征是"自举"：系统在每次迭代中产出比自身更优的版本，用这些产物反过来改进自身，无需外部干预。
+
+## Relationship to Other Concepts
+- [[Bootstrap（自举）]]：递归自优化循环的自引用本质
+- [[不动点 (Fixed Point)]]：循环收敛的稳定状态
+- [[元生成器 (Meta-Generator)]]：每次循环中执行"更新"步骤的算子 $M$
+- [[生成器空间 (Generator Space)]]：循环中所有生成器版本所处的空间
+
+## Source
+- [[A Formalization of Recursive Self-Optimizing Generative Systems]]