git restore 和 revert 都能"撤销"，但操作对象和历史影响完全不同。

1. restore：操作文件（工作区/暂存区），不产生 commit
2. revert：操作某次 commit，必须新 commit
3. 核心差异：restore 改文件，revert 反做 diff
4. 进阶用法：restore --source=<sha> + commit，文件 = 目标版
5. 不能用 revert 退旧版：revert 只反补丁，无法对齐到任意 commit
6. preserve history：替代 reset --hard，免 force-push

OpenAI Responses API 与 Chat Completions 的本质差在数据模型：Message 还是 Item。

• Chat Completions 把工具调用挂在 message.tool_calls，执行完再补 role=tool message。
• Responses 把 message / function_call / output 拆成独立 Item，运行时一眼能区分。
• Item 让权限 / 重试 / 审计能挂在具体调用上，而不是糊在 message 上。
• API 只表达「模型建议调什么」，执行安全 / 审批归企业 runtime。
• Responses 支持 previous_response_id，免去手动拼历史，但不解决长期记忆。
• 流式推送：Responses 能告知 item 创建、参数生成、item 完成。
• 结论：Responses 更 Agent-native，但不替代企业 runtime——平台层应走 adapter，业务层不直接绑定 OpenAI 对象。

AI Agent 沙箱不是普通容器/虚拟机，是融合隔离 + 策略 + 审计的复合底座。

1. 本质：毫秒级轻量隔离 + 实时动态权限中枢 + 端到端审计追溯，三位一体。
2. 演进：四代演化——1990s Apple 沙盒 → VM (VMware) → Docker → 微虚拟机 (Firecracker/gVisor)。
3. 裸奔代价：四大黑天鹅——权限越界、算力雪崩账单失控、概率性失败、审计黑箱。
4. 三大支柱：最小权限执行域 + 毫秒级快照回退 + 全链路溯源。
5. 四层技术栈：隔离层 / 策略控制层 / 状态管理层 / 可观测层。
6. 2026 趋势：自适应能力图谱 + 硬件 TEE (SGX/SEV) + OASIS 协议标准化。

AI Agent 防 Prompt 注入,核心在工具调用面的四道闸——授权 / 上下文 / 沙箱 / 审计。

• 根因:Transformer 没指令/数据边界,Agent 注入是真金白银损失,不是文案错误。
• 工具调用授权:工具白名单 + 参数 schema 校验 + 高敏感操作必须二次确认。
• 上下文分层:系统 prompt / 用户输入 / 工具结果 标记来源,不让工具返回污染系统 prompt。
• 执行沙箱:工具在隔离环境跑(文件系统 / 网络 / 进程),副作用局限沙箱内。
• 全链路审计:每个 tool call 留痕,事后可回放定位注入路径。
• 间接注入最致命:恶意指令藏网页/PDF/数据库等工具返回内容里。

Electron 目录没有官方推荐，但 三层物理隔离 + main 内按职责拆分 是经得起长期维护的姿势。

1. 三层分离：src/main（Node 全权限）、src/preload（白名单桥）、src/renderer（沙箱 UI），别混
2. 入口最小化：main/index.ts 只做生命周期组装，业务全部下沉到 windows / ipc / services
3. IPC 按域拆：每个域（fs / dialog / store）一个 handler 文件，channel 名集中在 channels.ts 常量
4. Service 层下沉：数据库、文件、网络都封成 service，handler 只做参数转发
5. 窗口工厂：每种窗口一个工厂函数，统一管创建、状态恢复、生命周期
6. 共享类型：main / preload / renderer 之间的 interface 抽到 src/shared，杜绝重复定义

Git submodule 是 Git 原生的多仓库嵌套机制，父仓库只记 commit hash，不存文件内容。

1. 是什么：主仓库子目录里嵌入独立 Git 仓库，各自有 commit 历史
2. 三个核心命令：submodule add / init + update / update --remote
3. 典型场景：第三方库源码嵌入、独立发布周期的子项目
4. 致命坑 1：新 clone 是空目录，必须 init + update 才有内容
5. 致命坑 2：子模块默认 detached HEAD，commit 容易推不上去
6. 致命坑 3：主仓库切分支后忘了 update --remote，代码对不上
7. 替代方案：monorepo 处理强耦合，subtree 处理简单嵌入

contextBridge 解决的不是"怎么把 API 传给页面"，而是"怎么让页面用 Node 能力但看不到 Node 环境"。

1. 本质：在 isolated world 创建一道有边界的桥，preload 能跑 Node，页面只能摸到白名单 API
2. 机制：preload 跑在 isolated world，主世界（页面）拿不到 preload 的闭包变量，只能拿到白名单出口
3. 能力：exposeInMainWorld 暴露受限 API，序列化约束守住边界（Function、Symbol、Error 不能裸传）
4. 类型系统：preload 内 typeof api + 全局 Window['electronAPI'] 声明，编译期对齐
5. 反模式：暴露整个 ipcRenderer、暴露 process、关掉 contextIsolation

Electron 渲染层的真正主角不是 BrowserWindow，是 webContents。

1. 定位：每个渲染页面背后都有一个 webContents 实例
2. 三种获取方式：BrowserWindow.webContents、webContents.getAllWebContents()、<webview> 标签
3. 核心 API：loadURL、loadFile、导航事件、executeJavaScript、openDevTools
4. 关键推送：webContents.send 是 main 主动通知 renderer 的唯一通道
5. 与 IPC 的关系：send 单向 main → renderer，invoke 反向，组合用才能双向
6. 踩坑：webContents 销毁后再 send 直接抛错
7. 与视图的关系：webContents 是内容，BrowserWindow / webContentsView 是宿主

裸装的 DeepSeek Harness 是毛坯房，介绍一些不错的插件补齐 Agent 该有的样子。

1. 先装市场：dsh-market 是入口，装完才谈得上装别的
2. 补基础设施：侧边栏（文件 / 终端 / Git / 子任务）优先级最高
3. 控成本：余额查询 + 限额熔断，涨价后这是刚需
4. 加能力：视觉模型接入、会话跨工具双向迁移
5. 做排查：上下文查看器暴露轮次 / 压缩 / token 构成
6. 提效率：@ 文件引用增强、Skills 管理、皮肤市场
7. 生态现状：近千款插件重复率极高，筛选成本大于安装成本

Pi 极简内核决定了所有"看起来复杂"的功能都靠外挂。

1. 设计哲学：极简内核 + plugin + skills 双路径，所有可定制能力外挂
2. 安装姿势：从官网 packages 列表复制命令，全局默认；加 -l 改为项目级
3. 8 大常用插件：联网、并行子代理、MCP 适配器、BTW、Plan Mode、Goal、Dynamic Workflows、微信
4. Skills 协议：放 .agents/skills/ 目录即生效，Playwright CLI 是典型用法
5. Web UI：社区 star 数最高项目接管插件 / 技能管理面板
6. Pi 自己写插件：内置开发知识，UI 定制、权限保护类插件都能跑通