From 664e69bfc6029b3973a703dda834b480bb63ec0d Mon Sep 17 00:00:00 2001
From: Zane <zane@zanecloud.host>
Date: Tue, 9 Jun 2026 10:48:33 +0800
Subject: [PATCH] Add Milky notes: 20 file(s)

---
 ...��队级_AI_编程驾驭工程_BV1SZoXBkErT_笔记.md | 352 +++++++
 ...��驱动落地_文档管理策略_BV1mZV76eEPC_笔记.md | 177 ++++
 ...理_核心组件和实战应用_学不会我_BV1Hn9UBrEsH_P1_笔记.md | 320 ++++++
 InBox/Multi-Agent与Multi-Task编排架构.md      | 934 ++++++++++++++++++
 ...ill的自动评分器怎么搭_BV1HWd6BsEmG_笔记.md | 316 ++++++
 ...��织要的不是个人提效_是组织自进化_BV1i77X6pE1C_笔记.md | 187 ++++
 ...de技巧了_Autoresearch帮你搞定_BV1tJwKzDE8x_笔记.md | 317 ++++++
 ...程能力更新_开源agent生态分化_BV1LjdzB3EAu_笔记.md | 180 ++++
 InBox/milky_BV17y7U6EER5.md                   | 158 +++
 InBox/milky_BV1ArVU62Eac.md                   | 435 ++++++++
 InBox/milky_BV1HWd6BsEmG.md                   | 321 ++++++
 InBox/milky_BV1Hn9UBrEsH.md                   | 324 ++++++
 InBox/milky_BV1LjdzB3EAu.md                   | 186 ++++
 InBox/milky_BV1SZoXBkErT.md                   | 365 +++++++
 InBox/milky_BV1i77X6pE1C.md                   | 192 ++++
 InBox/milky_BV1mZV76eEPC.md                   | 181 ++++
 InBox/milky_BV1p9QnBtEMq.md                   | 273 +++++
 InBox/milky_BV1tJwKzDE8x.md                   | 320 ++++++
 ...出Agent新范式_不改模型权重_效果接近翻倍_BV17y7U6EER5_笔记.md | 156 +++
 ...框架解决逻辑断层_实现92.0_平衡准确率_BV1p9QnBtEMq_笔记.md | 269 +++++
 ...�构编程范式_超越OOP和MVC_BV1ArVU62Eac_笔记.md | 423 ++++++++
 21 files changed, 6386 insertions(+)
 create mode 100644 InBox/2026-04-25_Harness_for_AI_coding_团队级_AI_编程驾驭工程_BV1SZoXBkErT_笔记.md
 create mode 100644 InBox/2026-05-30_SDD_规格驱动落地_文档管理策略_BV1mZV76eEPC_笔记.md
 create mode 100644 InBox/Harness_Engineering最佳实践_深度解析AgentHamness的底层原理_核心组件和实战应用_学不会我_BV1Hn9UBrEsH_P1_笔记.md
 create mode 100644 InBox/Multi-Agent与Multi-Task编排架构.md
 create mode 100644 InBox/OpenAI_Skill的自动评分器怎么搭_BV1HWd6BsEmG_笔记.md
 create mode 100644 InBox/Shopify_内部_Agent__为什么不准员工私聊___AI_native组织要的不是个人提效_是组织自进化_BV1i77X6pE1C_笔记.md
 create mode 100644 InBox/_AI翻译_别再自己钻研Claude技巧了_Autoresearch帮你搞定_BV1tJwKzDE8x_笔记.md
 create mode 100644 InBox/_播客__Agent技术周报2_harness工程能力更新_开源agent生态分化_BV1LjdzB3EAu_笔记.md
 create mode 100644 InBox/milky_BV17y7U6EER5.md
 create mode 100644 InBox/milky_BV1ArVU62Eac.md
 create mode 100644 InBox/milky_BV1HWd6BsEmG.md
 create mode 100644 InBox/milky_BV1Hn9UBrEsH.md
 create mode 100644 InBox/milky_BV1LjdzB3EAu.md
 create mode 100644 InBox/milky_BV1SZoXBkErT.md
 create mode 100644 InBox/milky_BV1i77X6pE1C.md
 create mode 100644 InBox/milky_BV1mZV76eEPC.md
 create mode 100644 InBox/milky_BV1p9QnBtEMq.md
 create mode 100644 InBox/milky_BV1tJwKzDE8x.md
 create mode 100644 InBox/北大Agent新范式_不改模型权重_效果翻倍北大搞出Agent新范式_不改模型权重_效果接近翻倍_BV17y7U6EER5_笔记.md
 create mode 100644 InBox/让AI真正读懂证据间的因果_深度验证框架解决逻辑断层_实现92.0_平衡准确率_BV1p9QnBtEMq_笔记.md
 create mode 100644 InBox/面向架构编程范式_超越OOP和MVC_BV1ArVU62Eac_笔记.md

diff --git a/InBox/2026-04-25_Harness_for_AI_coding_团队级_AI_编程驾驭工程_BV1SZoXBkErT_笔记.md b/InBox/2026-04-25_Harness_for_AI_coding_团队级_AI_编程驾驭工程_BV1SZoXBkErT_笔记.md
new file mode 100644
index 0000000..cb0b694
--- /dev/null
+++ b/InBox/2026-04-25_Harness_for_AI_coding_团队级_AI_编程驾驭工程_BV1SZoXBkErT_笔记.md
@@ -0,0 +1,352 @@
+# 敏捷团队 AI 编程驾驭工程体系
+
+## 一、背景与核心问题
+
+### 1.1 为什么需要团队级 AI 编程体系
+
+当前 AI 编程工具（如 SuperPowe、Claude Code、Cursor 等）已经非常强大，但**在团队级、项目级场景下落地困难**。核心原因是：
+
+- **需求衔接问题**：产品经理/BA 给的需求格式不统一，颗粒度不一致，导致 AI 无法有效理解
+- **开发实践问题**：多人协作时，AI 生成的代码风格不统一、难以形成一致的整体
+- **工具生态混乱**：Claude Code、Cursor、windsurf、SuperPower 等工具差异大，没有统一标准
+- **流程与制度问题**：团队工作习惯难以改变，这是最大的阻力来源
+
+### 1.2 当前团队使用 AI 编程的认知分级
+
+根据开发者能力分层：
+
+| 级别 | 描述 | 典型行为 |
+|------|------|----------|
+| 初级开发者 | 照猫画虎，不知道系统如何工作 | 抄代码、写业务逻辑，被 AI 替代 |
+| 专家型开发者 | 做技术公关，复杂组件开发 | 仍需要，但 AI 可辅助 |
+| 架构型开发者 | 设计服务、做权衡决策 | AI 辅助设计，但要人工把关 |
+| 技术经理/CTO | 处理复杂混乱的问题 | 构建团队 AI 工作体系 |
+
+> **关键洞察**："这个玩具不是玩 AI，是玩人"——真正的挑战不在于 AI 能力，而在于如何让团队按照统一的方式工作。
+
+### 1.3 AI 辅助软件工程全流程图
+
+```
+需求分析 → 技术方案设计 → 代码编写 → Code Review → 测试 → 部署 → 生产 Bug 修复
+   ↓            ↓              ↓          ↓         ↓       ↓         ↓
+  录音转文档   打样工程      API/单元测试   交叉模型   E2E测试   K8S部署   MCP自动
+  访谈纪要    代码模板       TDD 循环      Review    Playwright  触发合并  发通知
+  需求文档    技术规范
+  原型链接
+```
+
+## 二、需求阶段：如何让需求 AI 友好
+
+### 2.1 需求规格模板必须包含的内容
+
+BA 或产品经理给的需求文档必须包含以下 4 个关键部分：
+
+1. **业务背景**：为什么做这个需求
+2. **字段清单**：所有业务字段的类型、默认值、业务规则（避免只给原型图让 AI 去猜）
+3. **原型链接**：Figma 图等设计稿的链接（AI 可通过 MCP 读取 Figma）
+4. **业务规则**：按条拆分，例如：
+   - 订单号生成规则
+   - 发货规则
+   - 状态转换规则
+
+### 2.2 需求颗粒度的判断标准
+
+**不要用 Story 拆分需求**（一个人增产改查拆成 4 个 story 对 AI 来说信息量不够）。
+
+正确做法：**一个模块一个文档**，判断颗粒度的标准是：
+- 是否有独立的表结构
+- 是否可以单独上线
+
+### 2.3 新建需求 vs 变更需求
+
+**新建需求**：告诉 AI 有多少表、多少页面、多少功能操作 → AI 生成完整模块
+
+**变更需求**（重要）：
+- 必须用标签标注变更类型：`[+字段]` `[-字段]` `[修改字段]`
+- 不要把最终完整状态给 AI，因为 AI 需要对比现有代码 → 浪费大量 Token 且效果差
+- 示例：
+
+```markdown
+# 订单模块变更需求
+
+## 新增内容 [+]
+- 新增字段：order_type（订单类型，枚举值：NORMAL, VIP, B2B）
+
+## 修改内容 [~]
+- 修改字段：shipping_address 最大长度从 200 改为 500
+
+## 删除内容 [-]
+- 删除字段：legacy_flag（已废弃）
+```
+
+### 2.4 用 Obsidian 搭建知识库给 AI 做上下文
+
+将所有需求规格、技术规格都放到知识库中，用 Obsidian + Markdown 管理：
+
+- 用浏览器插件一键将网页转成 Markdown 并保存图片本地
+- 用 backlink 功能做上下文关联
+- AI 通过读取这个知识库获得长期记忆 → "Single source of truth"
+
+## 三、技术规格阶段：技术方案设计
+
+### 3.1 技术规格必须包含的内容
+
+技术规格是开发的核心输入，必须包含以下 5 个部分：
+
+| 内容 | 工具/格式 | 说明 |
+|------|----------|------|
+| 领域模型 | PlantUML / Mermaid | 代码化表达，便于 AI 理解 |
+| 数据库设计 | DBML / Flyway 脚本 | 不要让 AI 直接操作数据库，用版本化的 Flyway 脚本 |
+| API 定义 | OpenAPI / Markdown | 后端写完 API 后输出 API 文档给前端 |
+| 时序图 | Mermaid | 复杂流程需要时序图 |
+| 专项设计 | Markdown | 权限、事务、缓存等专项内容 |
+
+> **重要教训**：不要给 AI 写数据库的写权限，曾经因为 AI 动不动修改数据库导致多人操作冲突。把写权限关掉，让 AI 生成 Flyway 脚本，本地测试时让 Flyway 跑。
+
+### 3.2 DSL 驱动的技术规格
+
+用领域特定语言（DSL）来驱动技术规格：
+- 领域模型用 PlantUML
+- 数据库用 DBML
+- API 用 OpenAPI
+- 这些 DSL 都可以通过代码生成 → 保证前后端一致性
+
+> 这实际上就是模型驱动架构（Model-Driven Architecture），当团队从零开始全新的 AI 项目时，这种严格的检查和约束更容易建立。
+
+## 四、打样工程：AI 友好的代码框架
+
+### 4.1 什么是打样工程
+
+打样工程（Seed Project）是一个预先定义好的代码框架模板，包含：
+- 每层的类名和职责定义
+- 代码规范和最佳实践
+- 依赖配置和目录结构
+
+### 4.2 打样工程的作用
+
+1. **AI 生成代码风格一致**：所有 AI 都基于同一个框架生成代码
+2. **减少重复代码**：AI 会复用框架中的组件而不是重复写
+3. **降低认知负担**：AI 不需要每次理解项目结构
+
+### 4.3 如何创建打样工程
+
+1. 从旧项目中蒸馏出一个干净的新项目骨架
+2. 定义每层职责：`Controller → Service → Repository → Entity`
+3. 定义类命名规范和包结构
+4. 放入 Git 仓库供团队共享
+
+## 五、开发阶段：让 AI 听话写出统一风格的代码
+
+### 5.1 用 RAG（检索增强生成）提供上下文
+
+将技术规格、代码规范、历史决策等信息放到代码仓库的 `/docs` 或 `/book` 目录下，AI 通过检索这些文档获得上下文：
+
+```markdown
+/my-project
+  /book
+    /requirements      # 需求规格
+    /specifications     # 技术规格
+    /api-docs          # API 文档
+  /src
+  /skills
+  /mcp
+```
+
+### 5.2 多任务同步开发：Worktree 的使用
+
+Git Worktree 可以把分支映射成目录，实现多任务并行：
+
+```bash
+# 创建多个工作目录
+git worktree add ../feature-order feature/order
+git worktree add ../feature-user feature/user
+
+# 在不同目录下同时工作，做完后合并
+```
+
+**但要注意**：
+- 多人同时操作多人工作时，版本管理会比较痛苦
+- 建议提前把规格设计好，让 AI 慢慢跑，而不是同时开太多任务
+
+### 5.3 不要让 AI 边写代码边做设计
+
+用 `rapper5` 的思路：**Discovery/Design 和 Coding 分两个阶段**。
+- 先做探索性设计，让不同 AI 模型（GPT、Claude、Gemini）各自给出方案
+- 选定方案后，再激活 Coding 角色专职写代码
+- 切换角色时重置上下文，避免 AI 注意力分散
+
+## 六、测试阶段：AI 写代码形成闭环的核心
+
+### 6.1 为什么测试是 AI 编程的命脉
+
+> "没有 API 测试和单元测试，无法形成 AI 写代码的闭环。"
+
+AI 生成代码后必须能**自我验证**，否则：
+- 人工验证效率极低
+- AI 无法发现自己的问题
+- 团队无法真正提效
+
+### 6.2 测试策略（3 层）
+
+| 测试类型 | 工具 | 驱动方式 |
+|----------|------|----------|
+| 单元测试 | JUnit / pytest | TDD：先写测试让 AI 失败，再写实现 |
+| API 测试 | REST Assured / Newman | 自动化回归，可直接卡 90%+ 覆盖率 |
+| E2E 测试 | Playwright（推荐，替代了 Selenium） | 上线前 80% 的 case 回归覆盖 |
+
+### 6.3 TDD 循环（SuperPower 的工作方式）
+
+1. 让 AI 先写 API 测试/单元测试
+2. AI 运行测试 → 失败
+3. AI 再写实现代码
+4. AI 自动运行测试验证 → 通过
+
+> **效果**：单元测试可达 100% 覆盖率，API 测试可达 90%+ 覆盖率。
+
+### 6.4 AI 写测试解决假阳性问题
+
+有时候 AI 为了让测试通过，会伪造测试逻辑。解决方案：
+- **TDD 先写测试**：先让测试失败，再让 AI 写实现
+- **交叉验证**：用不同的 AI 模型互相 review 代码和测试
+
+### 6.5 测试用例的管理
+
+测试用例直接放到代码仓库中：
+- 单元测试：跟随代码模块
+- API 测试：放在 `/test/api` 目录
+- E2E 测试：用 TypeScript + Playwright，放在代码仓库根目录（或与前端项目同仓库）
+
+## 七、Review 阶段：AI 辅助 Code Review
+
+### 7.1 多种 Review 方式
+
+1. **工具扫描**：SonarQube 等静态分析工具 + AI 自动修复
+2. **AI Review**：用另一个 AI 模型做交叉 review（换模型做 review 是常用技巧）
+3. **Agent 自动触发**：在 PR 阶段自动触发 Review Agent
+
+### 7.2 AI Review 的问题与解决方案
+
+**问题**：AI Review 总是会提改进建议，哪怕没有明显问题（因为你的 prompt 让它提问题）。
+
+**解决方案**：
+- 设置阈值：达到一定级别才提问题，否则不输出
+- 让 AI 只关注 bug 和逻辑错误，不过度关注风格问题
+- 用团队的架构规约来约束 Review 标准
+
+### 7.3 不同场景的 Review 策略
+
+- **全新项目（AI 100% 生成）**：可以用最严格的规则，AI 写完直接修
+- **混合项目（人 + AI）**：可能存在历史遗留问题，Review 结果噪音多，建议从新模块开始逐步规范
+- **跨系统场景**：AI 容易犯错（尤其涉及 3-5 个系统的交互），建议收敛到单个仓库处理
+
+> **经验**：跨系统时 AI 犯错误概率高达 70-80%，核心原因是缺少完整的系统间关系和业务规则上下文。
+
+## 八、工具链：AI 编程工具全景
+
+### 8.1 三类 AI 编程工具
+
+| 类型 | 代表工具 | 特点 |
+|------|----------|------|
+| 命令行 CLI | Claude Code, OpenAI Codex | 适合快速操作、脚本化 |
+| IDE 集成 | Cursor, Windsurf, VS Code AI | 适合日常开发，界面友好 |
+| 辅助插件 | SuperPower（推荐个人）, Copilot | 按需使用 |
+
+### 8.2 常用 MCP（Model Context Protocol）
+
+| MCP | 用途 |
+|-----|------|
+| 数据库 MCP | 操作数据库（注意：只读，写权限建议关闭） |
+| Figma MCP | 读取设计稿 |
+| Jira MCP | 管理工单 |
+| Git MCP | 代码提交、PR 操作 |
+
+### 8.3 Skills 体系
+
+Skills = 一段提示词 + 模板 + 脚本，用于描述工作方法。
+
+- 把打样工程的初始化做成 Skill
+- 把团队规范做成 Skills
+- Skills 放到代码仓库中共享
+
+**重要观点**：
+> "现在 AI 理解力已经很强大，不需要把规范落实为非常固定的格式，只要表达清楚信息、强调重点即可。"
+
+**主流 Skill 框架**：
+- SuperPower：内置大量 Skills，开箱即用，适合个人
+- Claude Agent（hermes）：自动基于对话生成和优化 Skills
+- MCP：工具调用协议
+
+### 8.4 为什么不推荐 SDD 框架
+
+SDD（Scenario-Driven Development）框架本身很好，但**落地难度在于团队共识**：
+
+- 需要团队所有人按照相同流程工作
+- 现实团队中阻力很大（不是不愿意用，是习惯改不了）
+- SuperPower 对个人很好用，但团队级很难推广
+
+> **结论**：与其强推 SDD 框架，不如团队自己定义一套 Roos + Skills + MCP 的组合。
+
+## 九、架构型思考：未来趋势
+
+### 9.1 Agent Code 的趋势
+
+未来必然会出现 "Agent Code" 的概念——把整个团队的所有产物（需求、规格、规范、测试）全部代码化，放到代码仓库中统一管理：
+
+```markdown
+/.agent
+  /skills          # 工作方法
+  /mcp             # 工具配置
+  /templates       # 模板
+  /rules           # 规范
+  /docs            # 文档
+```
+
+所有 AI 工具（SuperPower、Claude Code 等）安装时都从代码库读取配置，实现极致高效。
+
+### 9.2 多 Agent 协调的挑战
+
+当前多 Agent 框架（如 CrewAI、AutoGen）还处于早期阶段：
+- 缺少程序级别的精确校验（不能完全依赖 AI 判断）
+- Agent 与代码之间的交互需要程序驱动而非纯 AI 驱动
+- 可能需要自己写 workflow 调度器
+
+### 9.3 共识是第一要务
+
+> "工具是玩人的，为了获得团队的共识。"
+
+大公司之所以比小公司/创业公司更难推进 AI 编程变革，是因为：
+- 习惯难以改变
+- 团队文化难以调整
+- 需要从上到下的强力推动
+
+## 十、团队实践建议
+
+### 10.1 渐进式落地路线
+
+1. **单人验证阶段**：选择一个简单项目，用 SuperPower + TDD 验证 AI 编程效率
+2. **规范建立阶段**：定义技术规格模板、代码规范、打样工程
+3. **团队推广阶段**：用 Skills 标准化工作方法，逐步让团队接受
+4. **自动化阶段**：打通从需求到部署的全流程，实现"代码即一切"
+
+### 10.2 技术经理的核心职责
+
+- 定义 AI 友好的需求规格模板 → 推动 BA/产品接受
+- 建立打样工程和代码规范 → 控制代码质量下限
+- 推动测试文化 → 这是专业和非专业软件公司的分界线
+- 构建团队共识 → 这是最难也是最重要的事
+
+### 10.3 避坑指南
+
+1. **不要让 AI 直接写数据库**：用 Flyway 脚本版本化管理
+2. **不要拆分过于细小的需求**：一个模块一个文档
+3. **变更需求一定要标注变更类型**：不要给完整状态
+4. **不要让 AI 同时做设计和代码**：分阶段，用不同角色
+5. **不要完全依赖 AI Review**：用规则约束、AI + 人工结合
+
+## 十一、观众反馈与补充
+
+- **华为 CodeArts Agent**：带有规范驱动开发模式，可以参考
+- **Obsidian + Opal**：适合做 Markdown 知识库管理，手机和电脑同步，适合在外也能用手机+终端工作
+- **看板式 AI 协同**：所有需求、设计、任务全部看板化，共享给团队成员
+- **跨 Agent 通信**：契约文件（如 OpenAPI JSON）放到共享目录，前后端各自读取 → 避免前端改完后端不知道的问题
+- **sonarlint 本地扫描 + AI 自动修复**：在 pre-commit 阶段触发静态扫描，AI 自动修复代码风格问题，效果很好
\ No newline at end of file
diff --git a/InBox/2026-05-30_SDD_规格驱动落地_文档管理策略_BV1mZV76eEPC_笔记.md b/InBox/2026-05-30_SDD_规格驱动落地_文档管理策略_BV1mZV76eEPC_笔记.md
new file mode 100644
index 0000000..f8ea206
--- /dev/null
+++ b/InBox/2026-05-30_SDD_规格驱动落地_文档管理策略_BV1mZV76eEPC_笔记.md
@@ -0,0 +1,177 @@
+# SDD 规格驱动落地：文档管理策略
+
+## 研讨会背景与目的
+
+本次分享是 AI 编程相关话题的延续，主要聚焦 **SDD（Spec-Driven Development，规格驱动开发）** 的文档管理策略。
+
+### 研讨会机制
+
+- **目的**：让参会者能够参与达成社区共识，分享各公司在 AI 编程实践中的经验
+- **形式**：咨询师分享观察到的公司实现方案、架构设计、系统设计等内容
+- **价值**：对个人和团队帮助都非常大，通过集体讨论形成共识
+
+> 特别感谢卡尼克老哥在研讨会期间贡献了大量分享思想，受益颇多。
+
+---
+
+## AI 编程发展历程回顾
+
+### 时间线概览
+
+| 时间 | 分享内容 | 核心概念 |
+|------|----------|----------|
+| 2025年6月 | 早期 AI 编程实践 | DPER5 方法论 |
+| 后续 | MCP 等工具整合 | MCP、Scales |
+| 5月9日 | Plan 和 Build 模式 | 新因子（吸引子）概念 |
+| 本次 | SDD 文档管理策略 | 规格驱动落地 |
+
+---
+
+## DPER5 方法论
+
+### 核心思想
+
+DPER5 将软件工程中使用 AI 进行开发的过程分为 **5 个弱阶段（Weak Stages）**：
+
+```
+Discover → Plan → Execute → Review → Refine
+   ↓         ↓        ↓         ↓        ↓
+ 发现      规划      执行      评审      优化
+```
+
+### 阶段特性
+
+- 不同阶段 AI 会按照不同的模式运行
+- 例如在 **Design** 模式或 **Discover** 模式下，AI **不会修改代码**
+- 这种分阶段约束是驯服 AI 的简单有效方法
+
+### 实践应用
+
+- 在早期阶段（2025年），演讲者已经在公司内部领先应用
+- 采用 `Design → Plan → Execute` 的流程驱动开发
+- 该方法使用了较长时间，有效规范了 AI 辅助开发流程
+
+---
+
+## MCP（Model Context Protocol）工具生态
+
+### 工具整合
+
+后续随着 MCP 以及相关工具套件的出现，形成了完整的 AI 编程工具生态：
+
+- **MCP（Model Context Protocol）**：模型上下文协议
+- **Scales**：扩展工具
+- **SDD**：规格驱动开发方法论
+
+这些工具被整合到一份 PPT 手册中，作为团队 AI 编程的指南或手册参考。
+
+---
+
+## SDD（规格驱动开发）
+
+### SDD 的核心模式
+
+SDD 提供了多种工作模式，适用于不同的开发场景：
+
+| 模式 | 适用场景 | AI 行为特征 |
+|------|----------|-------------|
+| **Design** | 需求分析、架构设计 | 不修改代码，仅提供设计建议 |
+| **Discover** | 探索发现、方案调研 | 不修改代码，专注于信息收集 |
+| **Plan** | 规划分解、任务拆解 | 生成实现计划 |
+| **Build** | 代码实现、具体开发 | 执行代码编写和修改 |
+
+### 新因子（吸引子）概念
+
+由 countic 大佬在 5月9日的分享中引入：
+
+**物理学的概念解释**：
+
+- 在混沌系统中，存在两种震荡反馈的系统
+- 这种系统最终会收敛到一个稳定状态
+- 这个收敛点被称为 **吸引子（Attractor）**
+
+**在 AI 编程中的应用**：
+
+- 通过引入新因子，可以引导 AI 的输出趋向于预期的稳定状态
+- 帮助控制 AI 在复杂任务中的发散性
+- 实现更可控的 AI 驱动开发流程
+
+---
+
+## SDD 文档管理策略
+
+> 本次分享的核心主题，聚焦于规格驱动开发的文档管理方法
+
+### 文档在 SDD 中的作用
+
+1. **规格定义**：明确需求和设计规范，作为开发的基准
+2. **上下文传递**：在不同阶段之间传递上下文信息
+3. **版本控制**：记录规格的变更历史
+4. **团队协作**：统一团队对需求的理解和实现方式
+
+### 文档管理最佳实践
+
+（基于 SDD 方法论，文档管理应遵循以下原则）
+
+- **规格优先**：在开发前先完成规格文档的编写
+- **增量迭代**：规格文档随项目进展逐步完善
+- **双向追溯**：规格与实现之间保持可追溯性
+- **工具集成**：将文档管理与 AI 编程工具链整合
+
+---
+
+## 工具链整合方案
+
+### 推荐的 AI 编程工具栈
+
+```
+┌─────────────────────────────────────────────────────┐
+│                    规格层 (Spec)                      │
+│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐  │
+│  │   Design    │  │   Discover  │  │    Plan     │  │
+│  └─────────────┘  └─────────────┘  └─────────────┘  │
+├─────────────────────────────────────────────────────┤
+│                    工具层 (Tools)                     │
+│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐  │
+│  │     MCP     │  │   Scales    │  │    SDD     │  │
+│  └─────────────┘  └─────────────┘  └─────────────┘  │
+├─────────────────────────────────────────────────────┤
+│                    执行层 (Execution)                │
+│  ┌─────────────┐  ┌─────────────┐                    │
+│  │    Build    │  │   Review    │                    │
+│  └─────────────┘  └─────────────┘                    │
+└─────────────────────────────────────────────────────┘
+```
+
+### MCP 的核心功能
+
+- 提供标准化的上下文协议
+- 实现 AI 与外部工具的无缝集成
+- 支持多工具协同工作
+
+---
+
+## 社区贡献者致谢
+
+| 贡献者 | 贡献内容 |
+|--------|----------|
+| 卡尼克 | 大量分享思想，研讨会核心参与者 |
+| countic | 引入新因子（吸引子）概念，分享 Plan/Build 模式 |
+| 少个分号 | SDD 方法论整理，工具链整合，文档管理策略分享 |
+
+---
+
+## 后续话题预告
+
+本次分享的议程安排：
+
+1. **SDD 文档管理策略**（当前内容）
+2. **AIGC 模板相关话题**（由卡尼克老哥分享）
+
+---
+
+## 参考资源
+
+- 本次分享的 PPT 资料（可作为团队 AI 编程手册/指南）
+- 搜索关键词：`AI编程`、`MCP`、`SDD`、`DPER5`、`规格驱动开发`
+- 相关标签：`人工智能`、`规格驱动开发`、`AI编程`
\ No newline at end of file
diff --git a/InBox/Harness_Engineering最佳实践_深度解析AgentHamness的底层原理_核心组件和实战应用_学不会我_BV1Hn9UBrEsH_P1_笔记.md b/InBox/Harness_Engineering最佳实践_深度解析AgentHamness的底层原理_核心组件和实战应用_学不会我_BV1Hn9UBrEsH_P1_笔记.md
new file mode 100644
index 0000000..1211b26
--- /dev/null
+++ b/InBox/Harness_Engineering最佳实践_深度解析AgentHamness的底层原理_核心组件和实战应用_学不会我_BV1Hn9UBrEsH_P1_笔记.md
@@ -0,0 +1,320 @@
+# Harness Engineering 最佳实践：Agent Harness 底层原理、核心组件与实战应用
+
+## 目录
+
+1. [AI 工程师的岗位分层体系](#1-ai-工程师的岗位分层体系)
+2. [大模型应用的三层进化范式](#2-大模型应用的三层进化范式)
+3. [Prompt Engineering：让模型"会说"](#3-prompt-engineering让模型会说)
+4. [Context Engineering：解决上下文膨胀问题](#4-context-engineering解决上下文膨胀问题)
+5. [Agent Harness 核心架构](#5-agent-harness-核心架构)
+6. [Harness Engineering 的工程实践](#6-harness-engineering-的工程实践)
+
+---
+
+## 1. AI 工程师的岗位分层体系
+
+### 1.1 三层架构概述
+
+在 2026 年，AI 工程师可分为三个层级，每个层级有明确的技术侧重点：
+
+| 层级 | 定位 | 核心职责 | 技术侧重 |
+|------|------|----------|----------|
+| **AI 产品化** | AI 产品经理、AI 解决方案架构师 | 发现 AI 价值场景，重塑业务流程 | 业务分析、产品设计 |
+| **AI 应用层** | AI 应用工程师、大模型应用开发 | 业务方案落地，AI 赋能场景 | Prompt Engineering、Context Engineering、RAG |
+| **AI 大模型算法层** | 模型研发工程师 | 提升模型垂直能力 | SFT 微调、RLHF 对齐、安全护栏 |
+
+### 1.2 各层级的核心差异
+
+**AI 产品化层**：
+- 聚焦于找到 AI 的价值场景
+- 重新定义业务产品线
+- 属于业务与产品方向
+
+**AI 应用层**（Harness Engineering 的落地层）：
+- 偏业务 + 方案落地
+- 利用开源模型构建垂直应用
+- 2026 年最稀缺、最具机会的方向
+
+**AI 大模型算法层**：
+- 不做基座模型（GPT-4、Qwen3.6 等基座由大厂完成）
+- 聚焦于模型的**垂直能力提升**
+- 包括：
+  - **SFT 微调**（Supervised Fine-Tuning）
+  - **RLHF**（Reinforcement Learning from Human Feedback）
+  - **对齐训练**（Alignment）
+  - **安全护栏**（Safety Guardrails）
+
+### 1.3 职业选择建议
+
+```
+技术背景 → AI 应用层（最佳入场点）
+产品背景 → AI 产品化层 → 可延伸至应用层
+算法背景 → AI 大模型算法层
+```
+
+> **核心观点**：2026 年是**大模型应用落地**的关键年份，大多数人的机会在于 AI 应用层。
+
+---
+
+## 2. 大模型应用的三层进化范式
+
+从时间维度看，AI 应用开发经历了三个阶段的范式转变：
+
+```
+2022-2024：Prompt Engineering 时代
+    ↓
+2025：Context Engineering 时代
+    ↓
+2026：Agent Harness / Harness Engineering 时代
+```
+
+---
+
+## 3. Prompt Engineering：让模型"会说"
+
+### 3.1 时间窗口
+
+2022 年 11 月 ChatGPT 发布后成为焦点
+
+### 3.2 核心问题
+
+**解决"如何说"的问题**——如何更好地与模型沟通，让模型生成更高质量的回答。
+
+### 3.3 技术特征
+
+- 单对单对话模式
+- 用户输入一句话，模型返回一句话
+- 关注点：如何编写有效的 Prompt
+
+### 3.4 典型场景
+
+```
+用户 → Prompt → LLM → Response
+```
+
+---
+
+## 4. Context Engineering：解决上下文膨胀问题
+
+### 4.1 时间窗口
+
+2025 年
+
+### 4.2 核心问题
+
+随着 Agent 开发引入工具调用（如 MCP 协议），上下文窗口中的内容越来越多，导致模型能力反而下降、**幻觉（Hallucination）** 问题加剧。
+
+### 4.3 核心目标
+
+**解决"有什么"的问题**——让模型清楚地知道当前拥有哪些信息。
+
+### 4.4 关键概念
+
+**Context Window（上下文窗口）**：
+- 多轮对话的执行过程中，所有历史信息都存储在上下文窗口中
+- 当内容越来越多时，模型会出现"迷失"现象
+
+**迷失问题（Lost in Context）**：
+- 模型在大量上下文中无法准确识别关键信息
+- 导致：
+  - 响应质量下降
+  - 幻觉增加
+  - 任务执行失败
+
+### 4.5 Context Engineering 的职责
+
+| 问题 | 解决方案 |
+|------|----------|
+| 上下文过长 | 上下文压缩、摘要 |
+| 信息混乱 | 结构化组织、分类管理 |
+| 关键信息被淹没 | 关键信息突出、检索增强 |
+
+---
+
+## 5. Agent Harness 核心架构
+
+### 5.1 官方来源
+
+本文档基于 **LangChain 团队**发布的关于 Agent Harness 的官方博客，是全球最懂 Agent 的团队发布的系统性技术文档。
+
+### 5.2 Agent Harness 的定位
+
+**Harness** 的本意是"驾驭、利用"，Agent Harness 即对 Agent 的工程化驾驭框架。
+
+### 5.3 核心架构体系
+
+```
+┌─────────────────────────────────────────┐
+│           Agent Harness                │
+├─────────────────────────────────────────┤
+│  ┌─────────────┐  ┌─────────────────┐   │
+│  │   规划层    │  │     执行层       │   │
+│  │  Planning  │  │   Execution     │   │
+│  └─────────────┘  └─────────────────┘   │
+│  ┌─────────────┐  ┌─────────────────┐   │
+│  │   工具层    │  │     记忆层       │   │
+│  │   Tools    │  │     Memory      │   │
+│  └─────────────┘  └─────────────────┘   │
+│  ┌─────────────┐  ┌─────────────────┐   │
+│  │   感知层    │  │     评估层       │   │
+│  │ Perception │  │  Evaluation     │   │
+│  └─────────────┘  └─────────────────┘   │
+└─────────────────────────────────────────┘
+```
+
+### 5.4 各层核心组件详解
+
+#### 5.4.1 规划层（Planning）
+
+**职责**：将复杂任务分解为可执行的子任务
+
+**关键技术**：
+- **任务分解**（Task Decomposition）
+- **思维链**（Chain of Thought, CoT）
+- **子任务规划**
+
+#### 5.4.2 执行层（Execution）
+
+**职责**：执行规划层生成的子任务
+
+**关键技术**：
+- **工具调用**（Tool Calling）
+- **动作执行**（Action Execution）
+- **结果反馈**
+
+#### 5.4.3 工具层（Tools）
+
+**职责**：为 Agent 提供外部能力
+
+**典型工具类型**：
+- **MCP 工具**（Model Context Protocol）
+- API 调用
+- 搜索引擎
+- 数据库查询
+- 文件系统操作
+
+#### 5.4.4 记忆层（Memory）
+
+**职责**：存储和管理 Agent 的历史状态与上下文
+
+**记忆类型**：
+| 类型 | 说明 | 用途 |
+|------|------|------|
+| 短期记忆 | 当前对话上下文 | 处理即时任务 |
+| 长期记忆 | 持久化存储 | 跨会话经验积累 |
+| 工作记忆 | 工作过程中的临时状态 | 任务执行中间态 |
+
+#### 5.4.5 感知层（Perception）
+
+**职责**：接收和处理外部输入
+
+**感知内容**：
+- 用户指令
+- 文档输入
+- 多模态信息（图像、音频等）
+- 环境状态
+
+#### 5.4.6 评估层（Evaluation）
+
+**职责**：评估 Agent 执行结果的质量
+
+**评估维度**：
+- 输出正确性
+- 任务完成度
+- 安全性检查
+- 效率评估
+
+---
+
+## 6. Harness Engineering 的工程实践
+
+### 6.1 定义
+
+**Harness Engineering** 是系统性地构建、测试、优化 Agent 行为能力的工程学科。
+
+### 6.2 与传统软件工程的区别
+
+| 维度 | 传统软件工程 | Harness Engineering |
+|------|-------------|---------------------|
+| 不确定性 | 低（确定性逻辑） | 高（概率性输出） |
+| 测试难度 | 可精确断言 | 需概率评估 |
+| 调试方法 | 日志追踪 | 行为轨迹分析 |
+| 质量保障 | 单元测试 + 集成测试 | 评估驱动开发 |
+
+### 6.3 核心工程实践
+
+#### 6.3.1 评估驱动开发（Evaluation-Driven Development）
+
+```
+设计评估指标 → 开发 Agent → 持续评估 → 迭代优化
+```
+
+#### 6.3.2 行为可复现性
+
+- 通过种子（seed）控制随机性
+- 构建可测试的 Agent 行为
+- 建立回归测试机制
+
+#### 6.3.3 多维度评测
+
+- **任务完成率**：Agent 是否完成目标
+- **效率指标**：消耗的 Token 数量、执行时间
+- **质量评分**：输出的人力评估
+- **安全性检查**：有害内容过滤
+
+### 6.4 LangChain Agent Harness 的工具链
+
+```
+┌──────────────────────────────────────────┐
+│           LangChain 生态                 │
+├──────────────────────────────────────────┤
+│  LangChain       │  Agent 开发框架        │
+│  LangSmith       │  追踪与评估平台        │
+│  LangServe       │  Agent 部署服务        │
+│  LangGraph       │  Agent 工作流编排      │
+└──────────────────────────────────────────┘
+```
+
+---
+
+## 7. 补充：观众反馈中的有价值观点
+
+> 本节整理自视频弹幕中观众的补充与讨论
+
+### 7.1 关于 Context Engineering 的延伸
+
+- Context Engineering 不仅解决"上下文膨胀"，还需要考虑**信息密度**问题
+- 有效上下文 = 去除噪音后的核心信息
+- 常用的压缩策略：LLM 摘要、关键信息提取、信息去重
+
+### 7.2 关于 Agent 幻觉的处理
+
+- 幻觉问题在单轮对话中已存在
+- 在多轮 Agent 执行中，幻觉会被**级联放大**
+- 建议在每个关键步骤增加**自我校验**机制
+
+### 7.3 关于实际落地的建议
+
+- 不要过度追求 Agent 的自主性，**人机协同**往往更可靠
+- 初期应聚焦垂直场景，积累领域知识后再扩展
+
+---
+
+## 附录：关键术语表
+
+| 英文术语 | 中文解释 |
+|----------|----------|
+| **Harness Engineering** | 驾驭工程，Agent 的系统工程化方法 |
+| **Agent Harness** | Agent 框架的核心组件集合 |
+| **Prompt Engineering** | 提示词工程，优化人机交互质量 |
+| **Context Engineering** | 上下文工程，管理信息输入质量 |
+| **Hallucination** | 幻觉，LLM 生成虚假或不准确内容 |
+| **Chain of Thought (CoT)** | 思维链，引导模型展示推理过程 |
+| **SFT** | Supervised Fine-Tuning，有监督微调 |
+| **RLHF** | Reinforcement Learning from Human Feedback，基于人类反馈的强化学习 |
+| **MCP** | Model Context Protocol，模型上下文协议 |
+| **Agent** | 智能体，能够自主执行任务的 AI 系统 |
+
+---
+
+> **笔记说明**：本笔记基于 LangChain 团队发布的官方博客整理，聚焦于 Agent Harness 的技术架构与工程实践。视频原版对三层架构有详细展开，读者可根据需要结合原视频深入理解各层级的技术细节。
\ No newline at end of file
diff --git a/InBox/Multi-Agent与Multi-Task编排架构.md b/InBox/Multi-Agent与Multi-Task编排架构.md
new file mode 100644
index 0000000..15d24ef
--- /dev/null
+++ b/InBox/Multi-Agent与Multi-Task编排架构.md
@@ -0,0 +1,934 @@
+# Multi-Agent与Multi-Task编排架构
+
+> 来源：[知乎专栏](https://zhuanlan.zhihu.com/p/2045496378252588635?utm_psn=2045633590483068568)
+> 抓取时间：2026-06-03 22:39
+
+---
+
+Multi-Agent 与 Multi-Task 编排架构
+
+定位：Staff/Architect 面试中「多智能体协作」与「多任务并行调度」的 专题深潜。区分 Multi-Agent（多个"谁"）与 Multi-Task（多个"什么"），覆盖拓扑模式、通信协议、任务 DAG、状态共享、成本建模与生产反模式。
+不重复：框架选型见 04；12 能力域见 13；七视图与成熟度 Stage 见 27；Buy 领域落地见 18。
+DevEx 对照：Cursor Subagent / Fork / Resume 与本篇 Coordinator/Supervisor 的映射 → 06。
+工业级索引：编排/Token/多任务场景 → 96 §2.6–§2.7 · 深读索引（MA_* / MT_* / CTX_*）。
+风格：沿 L1 概念 → L2 原理 → L3 生产 → L4 Staff 答辩 四层递进；每层有 ⚠ 难点 / 🔥 高频 / 💀 陷阱 标注。
+
+0. 本篇注意点与核心难点速查
+
+面试前 3 分钟过一遍此表，定位薄弱项。
+
+#	难点 / 注意点	为什么难	对应章节	🔥频率
+1	Multi-Agent vs Multi-Task 概念混淆	面试官常故意混用，需 30s 内澄清	§1	★★★★★
+2	拓扑选型说不出 trade-off	只知道 Supervisor，不知 Hierarchical/Peer/Swarm 差异	§2	★★★★
+3	Coordinator token 爆炸	N 个 Worker × R 轮 → context 超窗口 → 幻觉	§5, §6	★★★★★
+4	Fan-out 写操作一致性	并行写 → 重复退款/发货；需 DAG + 幂等 + Saga	§3, §7	★★★★★
+5	何时上 Multi-Agent 的准入判断	很多人跳 Stage 1 直上多 Agent → 成本翻倍、completion 下降	§2.4, §9	★★★★
+6	A2A vs MCP 分不清	两者都是协议，但层次和解决问题不同	§4	★★★
+7	跨 Agent 可观测 trace 断裂	每个 Agent 独立 trace → 无法端到端归因	§8	★★★★
+8	Multi-Agent Memory/Context 共享边界	过度共享 → token 爆炸；过度隔离 → 信息断层	§5	★★★★
+9	动态 Agent 编排（Swarm/OpenAI Agents SDK）	新范式 vs 传统 Supervisor，何时用	§2.5	★★★
+10	Multi-Agent 测试与 Eval	单 Agent eval 不够，需协调质量+端到端+收敛性	§9	★★★★
+1. 概念辨析：Multi-Agent vs Multi-Task
+1.1 定义对比 🔥
+维度	Multi-Agent（多智能体）	Multi-Task（多任务）
+定义	多个具备独立 Prompt/工具/角色 的 Agent 协作完成目标	多个子任务被分解、调度、并行或依赖执行
+关注点	角色设计、通信协议、状态共享、冲突解决	任务分解、依赖图(DAG)、调度策略、结果聚合
+独立存在	✅ 多 Agent 处理同一任务（辩论式验证）	✅ 单 Agent Fan-out 多个 tool calls
+交集	多 Agent 各领一个 Task → Multi-Agent Multi-Task	
+Staff 考点	拓扑选型、Coordinator 设计、A2A 协议	DAG 调度、Fan-out/Fan-in、幂等聚合
+1.2 四象限模型 ⚠
+                    单任务            多任务
+              ┌───────────────┬───────────────┐
+  单 Agent    │  标准 Agent    │  Fan-out      │
+              │  ReAct 循环   │  并行 tool     │
+              ├───────────────┼───────────────┤
+  多 Agent    │  辩论验证      │  协作编排      │
+              │  红蓝对抗     │  (生产主流)    │
+              └───────────────┴───────────────┘
+
+左上：单 Agent 单任务 → 最简单，Stage 1 起点
+右上：单 Agent 多任务 → LangGraph Send API / OpenAI parallel tool calls
+左下：多 Agent 单任务 → 用于验证、质量提升（如 Generator + Verifier）
+右下：多 Agent 多任务 → 生产级系统，本篇重点
+1.3 💀 常见混淆
+错误说法	纠正
+“Multi-Agent 就是 Multi-Task”	不对，Multi-Agent 是角色维度，Multi-Task 是任务维度
+“单 Agent 不能做 Multi-Task”	不对，单 Agent 可以 Fan-out 并行调用多个 tool
+“Multi-Agent 一定更好”	不对，Coordinator 开销可能让成本翻倍但质量不升
+“Pipeline 不是 Multi-Agent”	Pipeline 也是 Multi-Agent 的一种拓扑
+
+一句话：Multi-Agent 解决"谁来做"，Multi-Task 解决"做什么和怎么排"。生产系统两者通常同时出现。
+
+2. Multi-Agent 拓扑模式（L2 原理）
+2.1 六种核心拓扑
+2.2 拓扑选型矩阵 🔥
+拓扑	适用场景	优势	劣势	典型框架
+Supervisor	明确角色分工、可枚举子任务	简单、可控、易审计	单点瓶颈、Supervisor token 开销	LangGraph supervisor node
+Hierarchical	大规模 Agent 团队、跨域协作	分层管理、局部自治	层间延迟、Manager prompt 复杂	AutoGen GroupChat + nested
+Peer-to-Peer	辩论/验证、创意头脑风暴	无单点、多视角	难收敛、token 爆炸	CrewAI process off
+Pipeline	线性流水线（提取→转换→校验）	最低协调开销	无并行、上游阻塞	LangGraph 线性 StateGraph
+Mixture/Dynamic	请求类型差异大、需动态路由	灵活、按需分配	路由逻辑本身需维护	LangGraph conditional_edges
+Swarm/Handoff	对话式客服、逐步移交	上下文自然传递、按需升级	回退困难、handoff 条件需精确	OpenAI Swarm / Agents SDK
+2.3 Staff 级架构决策树
+2.4 准入门槛与 Stage 对齐 ⚠
+Stage	拓扑	准入门槛	来源
+Stage 1	单 Agent	有 checkpoint + trace	27 §8.1
+Stage 2	Supervisor / Pipeline	单 Agent eval ≥ 80%	本篇 §9
+Stage 3	Hierarchical / Mixture + Workflow	写操作全 HITL 或 Saga	13 §19
+Stage 4	Agent Mesh / Swarm 联邦	AI Gateway + 统一 eval	24
+
+💀 反模式：跳 Stage 1 直上 Multi-Agent → 成本翻倍、completion 下。先 Single Agent 优化到极致再加复杂度。
+
+2.5 Swarm / Handoff 模式详解（新范式） 🔥
+
+OpenAI Agents SDK 和 Swarm 框架引入的 handoff 范式与传统 Supervisor 有本质区别：
+
+维度	Supervisor	Swarm/Handoff
+控制流	中心化：Supervisor 分发	去中心化：Agent 间直接移交
+上下文传递	通过 Coordinator state	通过 handoff 携带 conversation history
+适用	结构化任务拆分	对话式、意图逐步明确
+回退	Coordinator 重新分配	需显式 handoff 回源 Agent
+典型场景	退款处理分角色	客服从通用→专业→人工层层升级
+# OpenAI Agents SDK handoff 示例概念
+triage_agent = Agent(
+    name="Triage",
+    instructions="判断用户意图，移交给专业 Agent",
+    handoffs=[order_agent, refund_agent, faq_agent]
+)
+refund_agent = Agent(
+    name="Refund",
+    instructions="处理退款相关问题",
+    tools=[check_order, calculate_refund],
+    handoffs=[human_agent]  # 复杂case升级人工
+)
+
+
+⚠ 难点：Handoff 条件不够精确 → Agent 乒乓跳转（A→B→A→B…）；解法：handoff 带 reason + max_handoff_count。
+
+3. Multi-Task 编排模式（L2 原理）
+3.1 任务分解策略
+策略	描述	适用	风险
+LLM Plan	LLM 自主将目标拆为子任务列表	开放域、用户意图模糊	Plan 漂移、幻觉任务
+Template DAG	预定义任务模板 + 参数填充	已知 SOP、资金操作	灵活性低
+Hybrid	固定骨架 + LLM 填充可变节点	生产推荐	需 policy guard 防溢出
+3.2 任务依赖 DAG 🔥
+3.3 Plan 输出结构化 schema ⚠
+{
+"goal"
+:
+"处理用户退款请求"
+,
+"tasks"
+:
+[
+{
+"id"
+:
+"t1"
+,
+"action"
+:
+"query_order"
+,
+"agent"
+:
+"order_agent"
+,
+"deps"
+:
+[
+]
+,
+"write"
+:
+false
+}
+,
+{
+"id"
+:
+"t2"
+,
+"action"
+:
+"query_profile"
+,
+"agent"
+:
+"profile_agent"
+,
+"deps"
+:
+[
+]
+,
+"write"
+:
+false
+}
+,
+{
+"id"
+:
+"t3"
+,
+"action"
+:
+"calc_refund"
+,
+"agent"
+:
+"refund_calc_agent"
+,
+"deps"
+:
+[
+"t1"
+,
+"t2"
+]
+,
+"write"
+:
+false
+}
+,
+{
+"id"
+:
+"t4"
+,
+"action"
+:
+"create_refund"
+,
+"agent"
+:
+"refund_exec_agent"
+,
+"deps"
+:
+[
+"t3"
+]
+,
+"write"
+:
+true
+,
+"hitl"
+:
+true
+}
+,
+{
+"id"
+:
+"t5"
+,
+"action"
+:
+"send_notification"
+,
+"agent"
+:
+"notify_agent"
+,
+"deps"
+:
+[
+"t3"
+]
+,
+"write"
+:
+true
+}
+]
+,
+"constraints"
+:
+{
+"write_tasks_sequential"
+:
+true
+,
+"max_parallel"
+:
+3
+,
+"timeout_per_task_s"
+:
+30
+}
+}
+
+💀 陷阱：Plan 中 write: true 的任务如果没有标 hitl 且没有幂等键 → 重复执行风险。
+
+3.4 并行调度：Fan-out / Fan-in
+                    ┌─→ Task A ──┐
+User Request → Plan ├─→ Task B ──┼─→ Merge → Respond
+                    └─→ Task C ──┘
+
+组件	职责	实现要点
+Plan	拆分子任务、声明依赖	输出结构化 JSON（见 §3.3 schema）
+Scheduler	按依赖图调度、并行无依赖任务	拓扑排序 + asyncio.gather / thread pool
+Worker	执行单任务、返回结构化结果	幂等、超时、重试、输出 schema 固定
+Merger	聚合结果、冲突解决	reduce 函数；冲突时 escalate 给 Supervisor
+3.5 任务状态机
+3.6 Replan 策略 ⚠
+触发条件	策略	风险
+单 task 失败且 retry exhausted	跳过该 task + 调整下游依赖	信息不完整
+多 task 并行结果矛盾	Coordinator 仲裁或增加验证 task	增加轮数
+用户中途改变目标	清除未执行 task，基于新 goal replan	plan 膨胀
+Plan 漂移（goal 偏移检测）	比对 goal embedding 相似度 < 阈值 → 拒绝	误报
+
+💀 陷阱：Replan 不受限 → 无限 replan 循环。必须设 max_replan_count ≤ 3。
+
+4. Agent 间通信协议（L2 原理）
+4.1 四种通信范式
+范式	描述	延迟	耦合度	适用
+Direct Call	Agent A 同步调用 Agent B	低	高	同进程、Pipeline
+Message Bus	通过队列/事件异步通信	中	低	跨服务 Multi-Agent
+Shared State	通过共享 checkpoint/黑板写读	中	中	LangGraph StateGraph
+Handoff	Agent A 将控制权+context 移交 Agent B	低	中	对话式 Swarm
+4.2 A2A（Agent-to-Agent）协议 🔥
+
+Google 提出的 A2A 协议为跨组织 Agent 互操作提供标准：
+
+概念	说明
+Agent Card	JSON 描述 Agent 能力、输入输出 schema、认证方式
+Task	A2A 的原子单位，包含 input/output/status
+Streaming	SSE 流式返回中间结果
+Push Notification	长任务异步回调
+Artifact	任务产生的文件/数据，可传递给下游 Agent
+Agent A ──AgentCard 发现──→ Agent B
+         ──Task 请求────→
+         ←─SSE 流式结果──
+         ←─Artifact 交付──
+         ←─完成回调──────
+
+4.3 MCP 与 A2A 的关系 🔥
+维度	MCP	A2A
+解决问题	Agent ↔ Tool/Data 的标准接口	Agent ↔ Agent 的互操作协议
+类比	USB 接口（连接外设）	HTTP/gRPC（服务间通信）
+互补	Agent B 可以通过 MCP 暴露自己为 Tool	A2A 在上层编排，MCP 在下层连接
+认证	MCP Server 需独立鉴权	A2A Agent Card 声明认证方式
+状态	无状态（每次调用独立）	有状态（Task 生命周期管理）
+4.4 通信 Schema 版本管理 ⚠
+问题	解法
+Worker 输出 schema 变更	并存 2 版 30 天 + Coordinator 适配
+Agent Card 能力变更	semver + 发现服务自动刷新
+Handoff context 格式不兼容	中间层 adapter + 版本协商
+5. 状态共享与隔离（L3 生产）
+5.1 状态分层模型 🔥
+┌─────────────────────────────────────────┐
+│  Global State（共享·Coordinator 单写）   │
+│  → goal, plan, completed_steps,         │
+│    current_round, error_summary         │
+├─────────────────────────────────────────┤
+│  Agent-local State（隔离·各 Agent 写）   │
+│  → scratchpad, tool_cache, memory       │
+├─────────────────────────────────────────┤
+│  Task-local State（隔离·单任务写）       │
+│  → input, output, retry_count, status,  │
+│    idempotency_key, duration_ms         │
+└─────────────────────────────────────────┘
+
+5.2 设计原则
+原则	说明	违反后果
+Single Writer	同一 state key 只有一个 Agent 可写	写冲突、状态污染
+Coordinator 持 Plan	只有 Coordinator 可修改 goal / plan	Worker 各改 plan → 发散
+Structured Observation	Worker 返回 JSON，不返回自由文本	Coordinator 解析失败
+Checkpoint 租户隔离	tenant_id 行级过滤	跨租户记忆泄漏（见 27 §12）
+Append-only for Workers	Worker 只 append observation，不覆盖	历史丢失、审计断裂
+5.3 Context Engineering for Multi-Agent ⚠ 难点
+
+多 Agent 的 Context Engineering 比单 Agent 复杂一个数量级。
+
+层级	策略	实现
+Coordinator	滑动窗口 + 摘要	只读最近 N 轮 observation + completed_steps 全量
+Worker	最小信息原则	只投递该 Worker 需要的 task context，不给全局 plan
+跨 Agent	摘要传递	Agent A 的输出经 summarizer 压缩后再给 Agent B
+长期	外部记忆	共享 checkpoint 存 PG，按需检索而非全量加载
+# Context 压缩示例
+def compress_observation(raw_obs: dict) -> dict:
+    """将 Worker 的原始 observation 压缩为摘要"""
+    return {
+        "task_id": raw_obs["task_id"],
+        "status": raw_obs["status"],
+        "key_findings": raw_obs["key_findings"][:3],  # 最多3条
+        "error": raw_obs.get("error"),
+        # 不传递: raw_data, tool_logs, debug_info
+    }
+
+5.4 LangGraph 实现模式
+from langgraph.graph import StateGraph
+from typing import TypedDict, Annotated
+from operator import add
+
+class MultiAgentState(TypedDict):
+    goal: str                                    # Coordinator 写
+    plan: list[dict]                             # Coordinator 写
+    current_round: int                           # Coordinator 写
+    completed_tasks: Annotated[list[str], add]   # Workers append-only
+    observations: Annotated[list[dict], add]     # Workers append-only（压缩后）
+    final_answer: str                            # Coordinator 写
+    error_summary: list[dict]                    # Coordinator 写
+
+graph = StateGraph(MultiAgentState)
+# Coordinator node: 读 observations → 更新 plan → 分配下一批 task
+# Worker nodes: 读 plan 中自己的 task → 执行 → append observation（压缩）
+# Merge node: 聚合并行结果 → pre-condition 校验 → 交回 Coordinator
+
+5.5 Memory 共享模式 ⚠
+模式	描述	适用	风险
+No Sharing	各 Agent 独立 memory	Pipeline	信息断层
+Blackboard	共享黑板，按 key 读写	Supervisor	写冲突
+Event Sourcing	所有 observation 追加到事件流	审计要求高	存储膨胀
+Selective Sharing	按 tag 选择性投递	生产推荐	需维护 tag 映射
+6. 成本与延迟建模（L3 生产）
+6.1 Token 开销分析 🔥
+组件	Token 消耗	优化手段
+Coordinator	每轮读所有 observations → O(N×T)	摘要压缩、滑动窗口
+Worker	仅读自身 task context → O(T)	限制 context window
+Plan 节点	一次性生成 → O(1)	缓存相似请求的 plan
+Merge 节点	聚合 N 个结果 → O(N×T)	结构化 reduce 而非 LLM 合并
+总开销	单 Agent: T ; Multi-Agent: N×T + Coordinator×R轮 + Merge	控制轮数 R≤5
+6.2 并行 vs 串行 Trade-off
+维度	串行 Pipeline	并行 Fan-out
+延迟	所有 Agent 延迟之和	max(各 Agent 延迟)
+Token	较少（无 Coordinator）	较多（+Coordinator+Merge）
+复杂度	低	高（需 scheduler、超时、部分失败处理）
+适用	严格顺序依赖	子任务独立可并行
+部分失败	上游失败 → 后续全停	单 Worker 失败 → 降级或 replan
+6.3 成本公式
+Cost_single = tokens_per_turn × turns × price_per_token
+Cost_multi  = Σ(worker_tokens) + coordinator_tokens × rounds + merge_tokens
+ROI 准入    = (Quality_multi - Quality_single) / (Cost_multi - Cost_single) > threshold
+
+6.4 容量估算（Staff 白板必会）⚠
+假设：
+  峰值 Agent QPS = 100
+  平均每请求拆分 3 个 Worker 任务
+  每 Worker 平均 1.5k token（输入+输出）
+  Coordinator 每轮 3k token，平均 2.5 轮
+  Token 单价 $3/1M (GPT-4o)
+
+Worker token/s   = 100 × 3 × 1500 / avg_task_duration(3s) = 150k token/s
+Coord token/s    = 100 × 3000 × 2.5 / avg_round_duration(5s) = 150k token/s
+总 token/s       ≈ 300k
+$/hour           = 300k × 3600 × $3 / 1M = $3,240/hour
+
+对比单 Agent（2k token × 5 轮）：
+单 Agent token/s = 100 × 2000 × 5 / 15s ≈ 67k
+$/hour          = 67k × 3600 × $3 / 1M ≈ $720/hour
+
+Multi-Agent 成本约 = 4.5x → 需要 completion 提升 ≥ 15% 才值得
+
+
+准入规则（来自 27 §11.7）：单 Agent eval ≥ 80% 后再上 Multi-Agent，否则成本翻倍但质量不升。
+
+7. 生产反模式与事故（L3 生产）
+7.1 反模式清单 🔥
+#	反模式	后果	正确做法
+1	无 Coordinator 的 Peer-to-Peer	循环对话、token 爆炸、不收敛	设 max_rounds + Coordinator 裁决
+2	Worker 私自修改 Plan	目标漂移、任务重复	Coordinator 单写 plan
+3	跳 Stage 1 直上 Multi-Agent	Completion 低 + 成本高	单 Agent eval ≥ 80% 准入
+4	全 Agent 共享完整 context	token 爆炸、O(N²)	按需投递、摘要压缩
+5	并行 Worker 无超时	一个慢 Worker 阻塞全局	超时 → 降级/跳过 + Coordinator replan
+6	无幂等的写操作 Fan-out	重复退款、重复发货	写操作单线程 + 幂等键
+7	Multi-Task 无依赖声明	并行本应串行的任务 → 数据不一致	显式 DAG + 拓扑排序
+8	Agent 间自由文本通信	解析失败率高	结构化 JSON schema
+9	Handoff 无 max_count	Agent 乒乓跳转 A→B→A→B…	handoff 带 reason + max_handoff ≤ 3
+10	Replan 无上限	无限 replan 循环	max_replan_count ≤ 3
+11	Coordinator 无进度检测	连续空转消耗 token	连续 2 轮无新 completed_task → 强制终止
+12	Multi-Agent 无独立 eval	不知道 Multi-Agent 是否真的优于单 Agent	对照实验 + eval gate
+7.2 STAR-M-P 事故案例 1：Multi-Agent 退款协调失败 🔥
+字段	内容
+S	电商客服 Multi-Agent 上线：Planner 拆分为"查单→算退款→执行"三个 Worker，无依赖声明，三者并行启动。
+T	“执行退款” Worker 在"查单"完成前就调用了 create_refund，传入 null 订单 → 退款金额为 0 → 用户投诉。
+A	① 补充 DAG 依赖声明；② 写操作 Worker 强制等待前置 task Success；③ 写操作增加 pre-condition 校验（订单非 null）；④ 添加 dry-run 阶段。
+R	事故率归零；延迟增加 200ms（可接受）；后续推广到所有写操作 Worker。
+M	方法论：Multi-Task 必须显式声明依赖；写操作 禁止无条件并行。
+P	推动平台级 Task Scheduler 支持 DAG 拓扑排序 + pre-condition guard。
+7.3 STAR-M-P 事故案例 2：Coordinator Token 爆炸 🔥
+字段	内容
+S	5 个 Worker 每轮返回 2k token observation，Coordinator 每轮读全量 → 第 4 轮 context 超 128k 被截断 → Plan 丢失关键信息 → 幻觉。
+T	在不降低 completion 的前提下控制 Coordinator 上下文。
+A	① Worker observation 压缩为结构化摘要（≤200 token）；② Coordinator 只读最近 2 轮 + 全局 completed_steps；③ 历史 observation 存 checkpoint，按需检索。
+R	Coordinator token 从 40k/轮 降至 8k/轮；completion 不降反升（噪声减少）。
+M	Multi-Agent 的 Context Engineering 是成本和质量的关键杠杆。
+P	沉淀 ObservationCompressor 组件，强制 Worker 输出 ≤ schema 上限。
+7.4 STAR-M-P 事故案例 3：Handoff 乒乓风暴
+字段	内容
+S	对话式客服 Swarm 架构，Triage → Order → Refund → Triage → Order… 用户问"退款后重新下单"触发 Agent 间无限 handoff。
+T	24h 内止血，防止 token 消耗失控。
+A	① 加 max_handoff_count = 5；② handoff 带 reason 字段，重复 reason 触发熔断；③ 超限后自动转人工。
+R	乒乓事件从日均 200 次降至 0；用户体验评分持平（转人工后处理）。
+M	Swarm/Handoff 的收敛性不如 Supervisor，必须有硬上限。
+P	平台级 handoff 中间件：全局 count + reason dedup + 熔断。
+7.5 STAR-M-P 事故案例 4：Multi-Agent 跨租户状态污染
+字段	内容
+S	多租户 Agent 平台，两个租户的 Worker 共享了同一个 checkpoint namespace → 租户 A 的 observation 出现在租户 B 的 Coordinator context 中。
+T	隔离修复 + 影响面评估 + 合规报告。
+A	① Checkpoint 表增加 tenant_id + 行级安全策略（RLS）；② 全量扫描历史 checkpoint 删除越权数据；③ Worker observation 增加 tenant_id 校验中间件。
+R	影响 12 个会话，无资金损失。7 天内修复。
+M	Multi-Agent 的 checkpoint 隔离比单 Agent 更易出问题（多写入源）。
+P	平台级 checkpoint 写入层强制 tenant_id；新租户上线前自动化隔离测试。
+8. Multi-Agent 可观测性（L3 生产） ⚠ 难点
+8.1 跨 Agent Trace 关联
+┌─ trace_id: abc-123 ────────────────────────────────────────┐
+│  span: coordinator                                          │
+│  ├─ span: fan-out-scheduler                                 │
+│  │  ├─ span: worker-order (agent_id: order, task_id: t1)   │
+│  │  ├─ span: worker-profile (agent_id: profile, task_id: t2)│
+│  │  └─ span: worker-risk (agent_id: risk, task_id: t3)     │
+│  ├─ span: merge                                             │
+│  └─ span: worker-refund (agent_id: refund, task_id: t4)    │
+└─────────────────────────────────────────────────────────────┘
+
+必须的 trace 属性	说明
+trace_id	用户请求级，贯穿所有 Agent
+agent_id	哪个 Agent
+task_id	哪个 Task
+round	第几轮
+tokens_in / tokens_out	每个 span 的 token 统计
+tool_calls	该 span 调用了哪些工具
+decision	Coordinator 的路由/分配决策
+8.2 成本归因
+总请求成本 → 按 agent_id 归因 → 按 task_id 归因
+  → Coordinator 占比 (通常 30-50%)
+  → Worker A 占比
+  → Worker B 占比
+  → Merge 占比
+
+8.3 告警规则
+指标	阈值	动作
+rounds_per_request > 5	收敛不良	降级到单 Agent
+coordinator_tokens > 50k	context 即将溢出	触发压缩
+handoff_count > 3	乒乓风险	熔断转人工
+task_timeout_rate > 10%	Worker 性能问题	扩容或降级
+cost_per_completion > budget	超预算	切换小模型
+
+→ 详见 25 AI 可观测性。
+
+9. Multi-Agent Eval 体系（L3 生产）
+9.1 四层 Eval 🔥
+层级	评估什么	指标	工具
+单 Agent	每个 Worker 的任务完成质量	accuracy, latency, tool_call_success	LangSmith / Braintrust
+协调质量	Coordinator 的任务拆分和分配	plan_precision, plan_recall, routing_accuracy	自建 eval dataset
+端到端	用户目标是否达成	completion_rate, user_satisfaction	A/B test
+成本效率	同质量下的 token 消耗	cost_per_completion	LiteLLM 统计
+收敛性	多少轮达成目标	avg_rounds, timeout_rate, handoff_count	trace 分析
+9.2 准入 Gate ⚠
+┌─ Stage 1 → Stage 2 准入 ─────────────────────────────┐
+│  单 Agent eval ≥ 80%                                   │
+│  有 checkpoint + trace + 至少 30 条 eval case          │
+├─ Stage 2 留存条件 ─────────────────────────────────────┤
+│  Multi-Agent eval ≥ 单 Agent + 5%                      │
+│  Multi-Agent cost ≤ 单 Agent × 2                       │
+│  avg_rounds ≤ 5                                         │
+│  timeout_rate ≤ 5%                                      │
+├─ 不达标 → 自动回退 ────────────────────────────────────┤
+│  eval 连续 3 天低于阈值 → 灰度缩量 → 回退单 Agent     │
+└─────────────────────────────────────────────────────────┘
+
+9.3 Multi-Agent 专属 Eval Case ⚠
+用例类别	测什么	通过标准
+Plan 拆分正确性	给定 goal → plan 包含必需 task	F1 ≥ 0.9
+依赖排序正确性	写操作在前置读操作之后	100%
+部分失败降级	1 个 Worker 超时 → 系统仍可返回有意义结果	≥ 80%
+Coordinator 收敛	不出现空转（连续 2 轮无新完成）	timeout_rate ≤ 5%
+跨 Agent 一致性	Worker A 和 B 的 observation 不矛盾	矛盾率 ≤ 2%
+Handoff 合理性	handoff reason 与用户意图匹配	accuracy ≥ 90%
+重复写操作	Fan-out 后无重复 side effect	duplicate_write = 0
+Replan 正确性	replan 后 goal 不偏移	goal_drift = 0
+10. 框架实战对比（L3 生产）
+10.1 LangGraph Multi-Agent
+from langgraph.graph import StateGraph, START, END
+from langgraph.constants import Send
+
+# Supervisor 拓扑
+graph = StateGraph(MultiAgentState)
+graph.add_node("coordinator", coordinator_node)
+graph.add_node("researcher", researcher_node)
+graph.add_node("writer", writer_node)
+graph.add_node("reviewer", reviewer_node)
+
+graph.add_edge(START, "coordinator")
+graph.add_conditional_edges("coordinator", route_to_worker,
+    {"research": "researcher", "write": "writer",
+     "review": "reviewer", "done": END})
+graph.add_edge("researcher", "coordinator")
+graph.add_edge("writer", "coordinator")
+graph.add_edge("reviewer", "coordinator")
+
+# Fan-out 多任务并行：用 Send API
+def fan_out(state):
+    return [Send("worker", {"task": t})
+            for t in state["plan"] if t["status"] == "pending"
+                                   and all_deps_met(t, state)]
+
+graph.add_conditional_edges("coordinator", fan_out)
+
+10.2 AutoGen Multi-Agent
+from autogen import AssistantAgent, GroupChat, GroupChatManager
+
+planner = AssistantAgent("planner", system_message="你负责拆解任务...")
+researcher = AssistantAgent("researcher", system_message="你负责查询...")
+coder = AssistantAgent("coder", system_message="你负责实现...")
+
+group_chat = GroupChat(
+    agents=[planner, researcher, coder],
+    messages=[],
+    max_round=10,
+    speaker_selection_method="auto"  # 或 "round_robin"
+)
+manager = GroupChatManager(groupchat=group_chat)
+
+10.3 CrewAI Multi-Task
+from crewai import Agent, Task, Crew, Process
+
+researcher = Agent(role="Researcher", goal="...", tools=[search_tool])
+writer = Agent(role="Writer", goal="...", tools=[])
+
+task1 = Task(description="调研竞品", agent=researcher, expected_output="报告")
+task2 = Task(description="撰写文章", agent=writer, expected_output="文章",
+             context=[task1])  # 显式依赖
+
+crew = Crew(agents=[researcher, writer], tasks=[task1, task2],
+            process=Process.sequential)  # 或 Process.hierarchical
+
+10.4 生产选型决策 🔥
+场景	推荐	理由
+资金写操作	LangGraph	checkpoint + interrupt + 幂等 + 显式边
+研发探索/Code Review	AutoGen	多角色对话自然、快速迭代
+内容生产（无写操作）	CrewAI	Task 依赖声明直观、上手快
+对话式客服升级	OpenAI Agents SDK / Swarm	handoff 自然、上下文传递好
+企业级 Java 栈	Spring AI + 自建 Coordinator	与 Spring 生态集成、事务管理
+跨组织 Agent 互操作	A2A 协议 + 任一框架	标准化发现与通信
+11. Staff 面试高频题与满分答（L4 答辩）
+
+格式：结论先行 → 原理展开 → 边界/陷阱 → 落地经验 → 反问引导。答题时间标注在题目后。
+
+11.1 Multi-Agent vs Multi-Task 区别？🔥🔥🔥🔥🔥
+
+Q：Multi-Agent 和 Multi-Task 有什么区别？
+
+答（30s）：Multi-Agent 是"多个谁"——多个具备独立角色/提示/工具的 Agent 协作；Multi-Task 是"多个什么"——多个子任务被分解调度执行。单 Agent 可以 Multi-Task（Fan-out tool calls），多 Agent 也可以只处理单一任务（辩论验证）。生产中两者通常同时出现：Coordinator 拆任务（Multi-Task），分给不同 Worker（Multi-Agent）去并行执行。
+
+追问预判：→ 那什么时候用单 Agent Multi-Task 就够了？→ 当 角色 skill 无差异 时，加 Agent 只加成本不加质量。
+
+11.2 什么时候上 Multi-Agent？🔥🔥🔥🔥🔥
+
+Q：什么时候值得用 Multi-Agent？
+
+答（60s）：三个条件同时满足：① 子任务可并行且上下文可隔离——否则共享 context 反而浪费 token；② 角色 skill 差异大——不同 system prompt + 工具集能显著提升各子任务质量；③ 单 Agent completion < 目标——先证明单 Agent 不够再加复杂度。准入门槛：单 Agent eval ≥ 80%，Multi-Agent 必须比单 Agent 至少高 5 个点且成本 ≤ 2 倍。
+
+追问预判：→ 如果 eval 高了但成本超 2x 怎么办？→ 看 completion vs cost 曲线的边际收益，有的场景（资金）可以接受 3x 成本换 5% completion。
+
+11.3 拓扑怎么选？🔥🔥🔥🔥
+
+Q：Multi-Agent 有哪些拓扑模式？怎么选？
+
+答（60s）：六种核心拓扑——Supervisor（中心分发）、Hierarchical（分层管理）、Peer-to-Peer（去中心辩论）、Pipeline（线性流水线）、Mixture/Dynamic（按类型路由）、Swarm/Handoff（对话式移交）。决策点：子任务可枚举 → Supervisor；DAG 依赖+角色<5 → Pipeline 子图；角色>5 跨域 → Hierarchical；对话逐步升级 → Swarm；需验证 → Peer。核心原则：Supervisor 够用就不上 Hierarchical，Pipeline 够用就不上 Fan-out，复杂度是成本。
+
+追问预判：→ Swarm 和 Supervisor 本质区别？→ Supervisor 控制流中心化，Swarm 控制流去中心化，Supervisor 更可控但单点瓶颈，Swarm 更自然但收敛难保证。
+
+11.4 Coordinator 设计的关键原则？🔥🔥🔥🔥🔥
+
+Q：Multi-Agent 系统中 Coordinator 怎么设计？
+
+答（60s）：五个原则：① Single Writer——只有 Coordinator 可写 goal/plan/completed_steps，Worker 只 append observation；② 结构化通信——Worker 返回固定 JSON schema，不返回自由文本；③ 摘要压缩——每轮只读最近 N 轮 observation + 全局 completed 列表，防 token 爆炸；④ 收敛保证——设 max_rounds + 进度检测，连续 2 轮无进展 → 强制汇总或 escalate；⑤ 最小信息投递——Worker 只拿自己 task 的 context，不拿全局 plan。
+
+追问预判：→ Coordinator 本身 context 溢出怎么办？→ 三招：observation 压缩到 ≤200 token、滑动窗口只保留最近 2 轮、历史存 checkpoint 按需检索。
+
+11.5 并行任务的一致性怎么保证？🔥🔥🔥🔥🔥
+
+Q：Fan-out 多任务并行时怎么保证一致性？
+
+答（60s）：三层保障：① 显式 DAG 依赖——写操作的前置任务必须 Success 才启动，拓扑排序强制执行；② 写操作禁止无条件并行——多个写操作走 Saga 不走 Fan-out，补偿逻辑明确；③ Merge pre-condition——聚合前校验所有必需 task 已完成，缺失则 replan 而非用 null 值拼接。额外：写操作必须有 幂等键（业务键如 order_id + refund_type），防止重试导致重复写。
+
+11.6 A2A 与 MCP 的关系？🔥🔥🔥
+
+Q：A2A 协议和 MCP 有什么关系？
+
+答（30s）：MCP 解决 Agent 到 Tool/Data 的标准连接，类比 USB 接口；A2A 解决 Agent 到 Agent 的互操作协议，类比 HTTP。两者互补：A2A 在上层编排 Agent 协作，MCP 在下层让每个 Agent 接入工具。一个 Agent 也可以通过 MCP 把自己暴露为另一个 Agent 的 Tool。关键区别：MCP 无状态，A2A 有 Task 生命周期管理。
+
+11.7 画一个 Multi-Agent 退款系统的架构？🔥🔥🔥🔥
+
+Q：白板画一个 Multi-Agent 退款架构。
+
+答（90s）：
+
+User → API Gateway → Coordinator Agent
+                         │
+              ┌──────────┼──────────┐  ← Fan-out (读操作, 可并行)
+              ▼          ▼          ▼
+        Order Agent  Policy Agent  Risk Agent
+        (查订单)     (查退款政策)   (风控评估)
+              │          │          │
+              └──────────┼──────────┘
+                         ↓
+                Coordinator Merge   ← pre-condition: 3个全 Success
+                         │
+                         ▼ (全部通过)
+                  Refund Agent      ← 串行 + HITL 人审 + 幂等键
+                  (执行退款)
+                         │
+                         ▼
+                  Notify Agent      ← 异步, 允许失败重试
+                  (发通知)
+
+
+关键点：① 前三个 Agent 可并行（Fan-out），因为互不依赖；② Refund Agent 必须等前三个全部 Success（DAG 依赖）；③ 写操作（退款）走 HITL + 幂等；④ 每个 Agent 的 observation 是结构化 JSON；⑤ Coordinator 负责 merge 和决策；⑥ 全链路统一 trace_id。
+
+11.8 Multi-Agent 的 Context Engineering 怎么做？🔥🔥🔥🔥
+
+Q：多个 Agent 协作时，上下文怎么管理？
+
+答（60s）：三层策略——Global State（目标/计划/完成列表，Coordinator 单写）、Agent-local（各 Agent 的 scratchpad 和工具缓存，互不可见）、Task-local（单任务的 input/output/重试计数）。核心技巧：① Worker observation 强制压缩到 ≤200 token 的结构化摘要；② Coordinator 用滑动窗口只读最近 N 轮；③ 跨 Agent 传递用 summarizer 压缩；④ 长期 context 存 checkpoint PG，按需检索。过度共享 → token 爆炸，过度隔离 → 信息断层，所以用 tag-based selective sharing。
+
+11.9 Multi-Agent 怎么做可观测？🔥🔥🔥
+
+Q：多 Agent 系统的可观测性怎么建？
+
+答（60s）：三个维度——Trace：统一 trace_id 贯穿所有 Agent，每个 Agent/Task 一个 span，span 上打 agent_id/task_id/round/tokens/decision 标签；Cost：按 agent_id 归因 token 消耗，Coordinator 通常占 30-50%，据此优化；Quality：告警 5 个阈值——rounds>5（收敛差）、coordinator_tokens>50k（context 溢出）、handoff>3（乒乓）、task_timeout>10%（性能）、cost>budget（超预算）。
+
+11.10 Swarm/Handoff 和 Supervisor 怎么选？🔥🔥🔥
+
+Q：OpenAI 的 Swarm/Handoff 模式什么时候用？和 Supervisor 区别是什么？
+
+答（45s）：Supervisor 是 中心化控制——一个 Coordinator 决定分给谁、什么时候收；Swarm 是 去中心化移交——每个 Agent 自己决定何时 handoff 给谁。Supervisor 适合 结构化任务拆分（退款流程），Swarm 适合 对话式逐步升级（客服从通用→专业→人工）。关键风险：Swarm 的收敛性不如 Supervisor，必须加 max_handoff + reason dedup 防乒乓。生产建议：资金路径用 Supervisor，对话路径用 Swarm。
+
+11.11 Multi-Agent 部分失败怎么处理？🔥🔥🔥🔥
+
+Q：Fan-out 后有 Worker 失败了怎么办？
+
+答（45s）：分三级——① 可忽略（如通知 Agent 失败）：标记 skipped，继续后续步骤，异步重试；② 可降级（如风控 Agent 超时）：用默认策略（如拒绝高风险），降级完成；③ 必需（如查单 Agent 失败）：阻塞后续，retry × 3，exhausted 后整体 replan 或转人工。Coordinator 的 merge pre-condition 定义了哪些 task 是 required vs optional。配合 超时 ：每 task 30s hard timeout，10s soft timeout 触发降级路径。
+
+11.12 给我讲一个 Multi-Agent 的生产事故？🔥🔥🔥🔥🔥
+
+Q：你在生产中遇到过什么 Multi-Agent 的问题？
+
+答（90s，用 §7.2-7.5 任一案例，STAR-M-P 格式）：
+
+选择最贴近你经历的案例背诵。推荐 §7.2（退款协调失败）或 §7.3（Coordinator token 爆炸），因为最高频。
+
+12. 面试前 30 分钟 Checklist（Staff / Architect）
+
+只勾不看内容，发现 ❌ 立即翻对应章节。
+
+能 30s 内说清 Multi-Agent vs Multi-Task 区别（§1、Q11.1）
+能说出 6 种拓扑 + 各自 trade-off（§2.2）
+能画 Supervisor + Fan-out 退款架构白板（Q11.7）
+能说出 Coordinator 5 个设计原则（Q11.4）
+能说出 Fan-out 一致性三层保障（Q11.5）
+能区分 A2A vs MCP（Q11.6）
+能说出 Multi-Agent 准入门槛数字（eval≥80%, +5%, cost≤2x）
+能讲 1 个 STAR-M-P 事故（§7.2–7.5 选一）
+能说出 Context Engineering 三层策略（Q11.8）
+能说出 5 个告警阈值（§8.3）
+知道 Swarm vs Supervisor 区别和选型（Q11.10）
+能说出部分失败的三级处理（Q11.11）
+准备好 1 个成本估算例子（§6.4 替换数字）
+能对照 06 讲 Subagent/Fork/Coordinator（§15）
+能说明 LangGraph Send 与 Cursor 并行 Task 的异同（§15.2）
+13. 全知识点 Checklist（逐项自测）
+13.1 概念层（L1）— 8 项
+KC-01 能定义 Multi-Agent：多个独立角色/提示/工具的 Agent 协作
+KC-02 能定义 Multi-Task：多个子任务分解、调度、并行/依赖执行
+KC-03 能画四象限（单Agent单Task / 单Agent多Task / 多Agent单Task / 多Agent多Task）
+KC-04 知道单 Agent 也能 Multi-Task（Fan-out tool calls）
+KC-05 知道多 Agent 可以处理单任务（辩论验证）
+KC-06 能区分 Coordinator / Worker / Scheduler / Merger 四角色
+KC-07 能说出 Stage 1→4 成熟度与拓扑对应
+KC-08 知道 Multi-Agent 不一定优于单 Agent
+13.2 拓扑与编排层（L2）— 16 项
+KC-09 Supervisor 拓扑：优势（可控）、劣势（单点、token 开销）
+KC-10 Hierarchical 拓扑：优势（分层自治）、劣势（层间延迟）
+KC-11 Peer-to-Peer 拓扑：优势（多视角）、劣势（难收敛）
+KC-12 Pipeline 拓扑：优势（最低开销）、劣势（无并行）
+KC-13 Mixture/Dynamic 拓扑：优势（灵活）、劣势（路由维护）
+KC-14 Swarm/Handoff 拓扑：优势（自然传递）、劣势（回退困难）
+KC-15 能画拓扑选型决策树
+KC-16 任务分解三策略：LLM Plan / Template DAG / Hybrid
+KC-17 Plan 输出结构化 schema（id, deps, agent, write, hitl）
+KC-18 DAG 拓扑排序调度
+KC-19 Fan-out / Fan-in 模式
+KC-20 任务状态机（Pending→Running→Success/Failed→Retrying/Escalated，含 HITL）
+KC-21 Replan 策略与 max_replan_count ≤ 3
+KC-22 四种通信范式（Direct / Message Bus / Shared State / Handoff）
+KC-23 A2A 协议核心概念（Agent Card / Task / Streaming / Artifact）
+KC-24 MCP vs A2A 区别与互补关系
+13.3 状态与 Context（L2-L3）— 12 项
+KC-25 状态分层：Global / Agent-local / Task-local
+KC-26 Single Writer 原则
+KC-27 Coordinator 持 Plan 原则
+KC-28 Structured Observation 原则
+KC-29 Append-only for Workers 原则
+KC-30 Checkpoint 租户隔离（tenant_id RLS）
+KC-31 Context Engineering：Coordinator 滑动窗口 + 摘要压缩
+KC-32 Worker 最小信息原则
+KC-33 跨 Agent 摘要传递
+KC-34 ObservationCompressor 组件（≤200 token）
+KC-35 Memory 共享模式（No Sharing / Blackboard / Event Sourcing / Selective）
+KC-36 LangGraph MultiAgentState 实现模式
+13.4 生产工程层（L3）— 18 项
+KC-37 Token 开销公式：N×T + Coordinator×R + Merge
+KC-38 并行 vs 串行 trade-off
+KC-39 容量估算：能口算 $/hour
+KC-40 准入门槛数字：eval≥80%, +5%, cost≤2x
+KC-41 回退机制：eval 不达标 → 灰度缩量 → 回退单 Agent
+KC-42 12 个反模式（§7.1）能说出 ≥ 5 个
+KC-43 能讲 ≥ 2 个 STAR-M-P 事故案例
+KC-44 跨 Agent trace 关联：统一 trace_id + agent_id/task_id span
+KC-45 成本归因：按 agent_id 维度
+KC-46 5 个告警阈值
+KC-47 四层 Eval（单Agent / 协调 / 端到端 / 成本 / 收敛）
+KC-48 Eval Gate 准入流程
+KC-49 8 类 Multi-Agent 专属 eval case
+KC-50 部分失败三级处理（可忽略 / 可降级 / 必需）
+KC-51 超时机制：soft timeout（降级）+ hard timeout（终止）
+KC-52 写操作一致性：DAG 依赖 + Saga + 幂等键 + pre-condition
+KC-53 Handoff 防乒乓：max_handoff + reason dedup + 熔断
+KC-54 通信 Schema 版本管理
+13.5 框架选型层（L3）— 6 项
+KC-55 LangGraph Multi-Agent：StateGraph + Send API + conditional_edges
+KC-56 AutoGen：GroupChat + GroupChatManager + speaker_selection
+KC-57 CrewAI：Agent + Task(context) + Crew(process)
+KC-58 OpenAI Agents SDK / Swarm：Agent + handoffs
+KC-59 Spring AI + 自建 Coordinator
+KC-60 场景→框架映射表（资金→LangGraph, 对话→Swarm, 内容→CrewAI）
+13.6 Staff 答辩层（L4）— 12 项
+KC-61 能白板画 Multi-Agent 退款架构
+KC-62 能 30s 说清 Multi-Agent vs Multi-Task
+KC-63 能说出 Coordinator 5 原则
+KC-64 能说出 Fan-out 一致性三层保障
+KC-65 能说出 Swarm vs Supervisor 选型逻辑
+KC-66 能讲 STAR-M-P 事故
+KC-67 能口算 Multi-Agent 成本估算
+KC-68 能说出 A2A vs MCP 区别
+KC-69 能说出 Context Engineering 三层策略
+KC-70 能画跨 Agent trace span 结构
+KC-71 能说出部分失败三级处理
+KC-72 能回答"什么时候不该用 Multi-Agent"
+KC-73 能区分 Cursor Subagent vs 生产 Worker（06）
+KC-74 能说明 IDE 会话 Fork 不等于业务 checkpoint
+KC-75 能口述 LangGraph Send Fan-out 与写操作互斥
+15. DevEx Subagent 与生产 Coordinator 闭环（2026 增补）
+
+专章：06-Coding-Agent运行时对照 · Catalog：96 DEVEX_* + MA_*
+
+15.1 同一问题，两套答案
+面试问法	先答运行面	再答生产不变式
+「Subagent 是什么？」	Cursor：独立 context 的 Worker	Coordinator 单写 plan；Worker append observation
+「Coordinator 在哪？」	父 Agent 隐式协调	MultiAgentState + checkpoint 显式节点
+「并行会不会更快？」	探索只读可并行	写操作 Fan-out 禁止；Saga 串行
+「断了怎么续？」	Resume agent ID / Fork 实验分支	thread_id + 幂等键；禁全量 replan
+15.2 LangGraph Send API：生产 Fan-out 标准写法
+
+依据：LangGraph 动态扇出。
+
+from langgraph.types import Send
+
+def coordinator_fanout(state):
+    """Coordinator 选出可并行 task → Send 到对应 worker 节点"""
+    pending = [t for t in state["plan"] if t["status"] == "pending" and deps_met(t, state)]
+    # 写操作：同一 round 最多 1 个
+    writes = [t for t in pending if t.get("write")]
+    if len(writes) > 1:
+        pending = [writes[0]]
+    return [Send(worker_node(t["agent"]), {"task": t, "goal": state["goal"]}) for t in pending]
+
+def worker_node(agent_name: str, payload: dict) -> dict:
+    obs = run_worker(agent_name, payload["task"], minimal_context(payload))
+    return {"observations": [compress_observation(obs)]}
+
+DevEx 对照	LangGraph
+父 Agent 发多个 Task	Send[]
+explore/bash/browser	专用 worker 节点 + 工具白名单
+background subagent	异步节点 + 轮询 merge
+readonly subagent	worker 图内只读 tool 边
+15.3 与 Cursor Subagent 的边界（Staff 必背）
+允许：用 subagent 做 explore / verifier / test-runner（06 §3）。
+禁止：IDE 并行 subagent 直接写 生产库；Fork 会话当业务 checkpoint（DEVEX_FORK_NO_AUDIT）。
+迁移：Orchestrator 三角色（Planner→Implementer→Verifier）→ Pipeline + 验证节点（06 §22）。
+15.4 Multi-Agent Eval 门禁（与 06 §25 成本账本校准）
+Gate	阈值（示意）	失败动作
+单 Agent baseline	success ≥ 80%	不准上 Multi-Agent
+Multi vs Single	completion +5pt 且 cost ≤2x	缩 Worker 或改拓扑
+Coordinator token	< 50k/run	压缩 observation
+Convergence	rounds ≤ 5	降级单 Agent
+Trajectory	golden 匹配 ≥ 95%	阻断发布（19）
+15.5 追加面试题（与 06 §99 交叉）
+11.13 Subagent 与 Multi-Agent Worker 一样吗？🔥🔥🔥🔥
+
+答（40s）：角色同、治理不同。Subagent 缺业务 checkpoint/租户/幂等；生产 Worker 必须在 Coordinator 下 结构化 JSON 回传。IDE 父 Agent≈Coordinator，但须 显式化 到图与 DB。
+
+11.14 Fork 会话能否代替 checkpoint？🔥🔥🔥
+
+答（30s）：不能。Fork/Resume 解决 研发实验与续聊；checkpoint 解决 写操作可审计续跑。见 96 DEVEX_* vs RUN_*。
+
+11.15 三个 readonly subagent 并行改同一模块？🔥🔥🔥🔥
+
+答（40s）：探索可并行，实现必须单写者。否则 Git 冲突与局部最优（06 §11 STAR）。生产同理：Fan-out 只给 读 Worker。
+
+11.16 Java 侧如何落地 Supervisor？🔥🔥🔥
+
+答（45s）：Spring AI ChatClient 做 intent → Scripted/LLM Supervisor 路由 → 多 Worker Bean → summarize；轨迹见 multi-agent-supervisor demo。演进：LangGraph4j 或 Plan-Execute 自研，不变式同 §5。
+
+11.17 Peer 辩论为何生产慎用？🔥🔥🔥
+
+答（35s）：无 Coordinator 时 token 与轮次易失控（MA_PEER_NO_CONVERGE）。仅用于 离线评审/红队；资金路径用 Supervisor + HITL。
+
+16. 总结金句
+
+Multi-Agent 解决"谁来做"，Multi-Task 解决"做什么和怎么排"。Coordinator 是唯一写 plan 的人，Worker 只反馈结构化 observation。写操作永远串行 + 幂等 + HITL，只有读操作才值得 Fan-out。上 Multi-Agent 前先证明单 Agent 不够——eval ≥ 80% 是准入门槛，成本 ≤ 2x 是留存条件。
+
+
+
+
+拓扑选型不是技术品味，是架构决策——Supervisor 够用就不上 Hierarchical，Pipeline 够用就不上 Fan-out。复杂度是成本，简单是竞争力。
+
+
+
+
+Context Engineering 是 Multi-Agent 的隐藏 boss——过度共享 token 爆炸，过度隔离信息断层。三层分离 + 摘要压缩 + 按需检索是生产正解。
+
+
+
+
+每个 Multi-Agent 系统都需要三个安全网：max_rounds 防空转、max_handoff 防乒乓、max_replan 防无限重做。没有硬上限的 Agent 系统迟早会在凌晨三点叫你起床。
+
+
+
+
+DevEx Subagent 与生产 Coordinator 是同一套编排的两层皮肤——IDE 省 context，生产保幂等与审计；详见 06 与 §15。
+
+官方文档与源码（一级依据）
+
+AI Engineering · 正文机制应来自下方 官方文档（L1） 与 官方源码仓库（L2）；
+禁止用教程站/博客充当机制依据。本章 QPS/延迟/STAR 为面试示意。
+写作规范：docs/official-sources-registry.md §0
+
+L1 · 官方文档
+
+Spring AI Reference
+LangGraph Interrupts
+LangChain4j Docs
+
+L2 · 官方源码
+
+spring-projects/spring-ai
+langchain-ai/langgraph
+langchain4j/langchain4j
+
+L3 · 论文 / 开放规范
+
+L3 MCP Specification
+
+---
+
+*笔记由 Hermes Agent 自动抓取保存*
\ No newline at end of file
diff --git a/InBox/OpenAI_Skill的自动评分器怎么搭_BV1HWd6BsEmG_笔记.md b/InBox/OpenAI_Skill的自动评分器怎么搭_BV1HWd6BsEmG_笔记.md
new file mode 100644
index 0000000..a45374e
--- /dev/null
+++ b/InBox/OpenAI_Skill的自动评分器怎么搭_BV1HWd6BsEmG_笔记.md
@@ -0,0 +1,316 @@
+# OpenAI Skill 自动评分器构建指南
+
+## 一、为什么需要评分器
+
+当更新一个 Skill 并执行完成后，**表面结果正常不代表真的变好了**。核心问题是：
+
+- Skill 是否真的完成了预期任务？
+- 修改是否引入了新的问题（回归）？
+- 如何在不同版本之间进行性能比较？
+
+评分器的职责就是回答这些问题，让 Skill 的质量变化可衡量、可追踪。
+
+---
+
+## 二、运行轨迹记录
+
+### 2.1 什么是运行轨迹
+
+评分的前提是有东西可以打分。OpenAI 的做法是使用 **CodeExec JSON** 记录 Skill 的完整执行过程。
+
+### 2.2 配置方式
+
+```json
+{
+  "code_exec": true  // 启用后输出结构化执行记录
+}
+```
+
+### 2.3 记录内容
+
+启用后，Skill 每执行一步都会输出结构化记录，包括：
+
+- 跑了什么命令
+- 创建了什么文件
+- 执行顺序
+- 时间戳
+
+### 2.4 关键特性
+
+| 特性 | 说明 |
+|------|------|
+| **完整性** | 记录完整执行流程，而非日志摘要 |
+| **可解析性** | 结构化数据，可被程序直接读取 |
+| **可调试性** | 失败时可精确定位到具体哪一步出错 |
+
+> 没有运行轨迹，评分器只能看最终产物，无法分析执行过程。
+
+---
+
+## 三、评分器类型
+
+### 3.1 确定性检查（Deterministic Checks）
+
+#### 3.1.1 原理
+
+纯代码规则驱动的检查，**不用大模型**，写死判断逻辑，程序直接对着运行轨迹核对。
+
+#### 3.1.2 典型检查项
+
+```
+- 有没有执行 npm install
+- 有没有创建 package.json
+- 命令执行顺序是否符合预期
+- 是否在指定目录执行操作
+```
+
+#### 3.1.3 核心特性
+
+| 特性 | 说明 |
+|------|------|
+| **确定性** | 同样行为每次判断结果一致，没有模糊地带 |
+| **可调试** | 一旦失败，打开记录文件即可看到从哪一步开始偏离 |
+
+#### 3.1.4 局限性
+
+确定性检查能回答"**基础动作做了没有**"，但无法回答"**做出来的东西是不是你想要的样子**"。
+
+---
+
+### 3.2 评分细则检查（Rubric-based Checks）
+
+#### 3.2.1 原理
+
+使用 **LLM 作为裁判**，读取仓库内容，按预定义的评分细则输出结构化打分结果。
+
+#### 3.2.2 适用场景
+
+很多 Skill 的验收标准本来就是软性规则，例如：
+
+- 代码结构是否干净
+- 组件组织是否符合团队约定
+- 样式配置是否按既定风格落地
+- 命名规范是否遵循
+
+#### 3.2.3 评分细则的拆解方法
+
+把模糊的质量标准拆成若干个**可独立判断的维度**：
+
+| 模糊标准 | 拆解后的维度 |
+|----------|--------------|
+| 代码质量好 | 组件是否按功能分目录 |
+| | 是否有未使用的引用 |
+| | 样式类名是否遵循命名约定 |
+| | 配置项是否集中管理 |
+
+#### 3.2.4 关键要求：锁定输出格式
+
+**必须提前定义输出模板**，规定模型必须输出哪些字段：
+
+```json
+{
+  "passed": true/false,
+  "total_score": 85,
+  "dimensions": [
+    {
+      "name": "component_organization",
+      "score": 90,
+      "reason": "组件按功能正确分目录"
+    },
+    {
+      "name": "unused_imports",
+      "score": 70,
+      "reason": "发现3处未使用的import"
+    }
+  ]
+}
+```
+
+#### 3.2.5 为什么必须锁死格式
+
+| 自由输出 | 锁死格式 |
+|----------|----------|
+| 每次措辞不同 | 格式统一 |
+| 无法跨版本比较 | 结果可量化 |
+| 无法进自动化流程 | 可直接集成 CI/CD |
+| 输出是"审稿意见" | 输出是"评估数据" |
+
+---
+
+## 四、评分器组合策略
+
+### 4.1 分工明确
+
+```
+确定性检查 ──→ 抓底线（基础动作有没有发生）
+评分细则检查 ──→ 抓质量（做出来的东西像不像你要的）
+输出格式锁定 ──→ 防飘移（每次评分结果一致）
+```
+
+### 4.2 集成到流水线
+
+这套组合设计之初就面向 **持续集成（CI）**：
+
+- 不再依赖工程师手动触发测试
+- 成为持续运行的回归守门员
+- Skill 每次更新都会自动验证
+
+---
+
+## 五、6 类扩展检查
+
+在基础评分器之上，可按需叠加以下检查：
+
+### 5.1 命令数与循环检测
+
+```
+检查运行记录里执行了多少条命令
+```
+
+**目的**：检测行为退化
+
+> 案例：如果一个 Skill 以前 6 步能完成，现在要 18 步，表面上任务还是完成了，但系统正在变差。
+
+### 5.2 消耗量追踪
+
+```
+记录每次运行消耗的 token 数量
+```
+
+**目的**：防止 Skill 越来越臃肿
+
+- 每次执行越来越贵
+- 每次执行越来越慢
+
+### 5.3 构建检查
+
+```bash
+# skill 完成后直接执行构建命令
+npm run build
+```
+
+**目的**：端到端验证
+
+- 很多项目表面完成，构建就露馅
+- 成本低，应该**默认开启**
+
+### 5.4 运行时冒烟检查
+
+```bash
+# 启动开发服务器
+npm run dev
+# 发送测试请求
+curl http://localhost:3000/api/health
+```
+
+**目的**：验证服务是否真正可用
+
+> 注意：这类检查更慢，按风险等级决定是否每次都执行。
+
+### 5.5 仓库清洁度检查
+
+```
+检查任务完成后是否出现不该有的文件
+```
+
+**目的**：确保系统没有被"弄脏"
+
+### 5.6 权限回归检查
+
+```
+验证 skill 是否还能在最小权限下正常工作
+```
+
+**目的**：防止权限漂移
+
+- 某次改动后悄悄开始依赖更高权限
+- 权限漂移在自动化后会变成结构性风险
+
+### 5.7 扩展策略
+
+```
+原文建议：先加快速检查，再按风险叠加慢检查
+         不是一次全上，是按需扩展
+```
+
+| 检查类型 | 速度 | 建议频率 |
+|----------|------|----------|
+| 命令数检测 | 快 | 每次 |
+| 消耗量追踪 | 快 | 每次 |
+| 仓库清洁度 | 快 | 每次 |
+| 构建检查 | 中 | 每次 |
+| 运行时冒烟 | 慢 | 按风险 |
+| 权限回归 | 慢 | 定期 |
+
+---
+
+## 六、5 条核心原则
+
+### 原则一：量真正重要的东西
+
+> Don't measure for the sake of measuring. First, think about what you'd actually care about if it got worse.
+
+**不要为了有指标而有指标**，先想清楚什么变差了，你会真的在意。
+
+### 原则二：先写清晰可检查的定义
+
+> If the success criteria are fuzzy, the evaluation will be too.
+
+验收标准模糊，评估就没有意义。**先把"什么叫做对"写成可执行的判断**。
+
+### 原则三：把评估扎在真实行为上
+
+> Record the full execution trace and write deterministic checks around the actual actions taken.
+
+记录 Skill 的完整运行轨迹，围绕实际执行的动作写确定性检查。
+
+### 原则四：规则不够时，再让模型补上
+
+> Use rubric-based evals to handle quality judgments that rules can't cover, not as a replacement.
+
+用评分细则处理规则覆盖不了的质量判断，**顺序不能反**。确定性检查在前，LLM 评分在后。
+
+### 原则五：让真实失败去驱动样本增长
+
+> Every time you manually fix something, turn it into a test case.
+
+每次手动修复都是一个信号，**把它变成测试用例**，让 Skill 持续把这件事做对。
+
+---
+
+## 七、整体流程图
+
+```
+┌─────────────────────────────────────────────────────────┐
+│                    Skill 执行                            │
+└─────────────────┬───────────────────────────────────────┘
+                  ▼
+┌─────────────────────────────────────────────────────────┐
+│            CodeExec JSON 记录运行轨迹                     │
+└─────────────────┬───────────────────────────────────────┘
+                  ▼
+         ┌───────┴───────┐
+         ▼               ▼
+┌───────────────┐ ┌─────────────────┐
+│ 确定性检查     │ │ 评分细则检查     │
+│ (规则驱动)     │ │ (LLM 裁判)       │
+└───────┬───────┘ └────────┬────────┘
+        ▼                  ▼
+        └────────┬─────────┘
+                 ▼
+┌─────────────────────────────────────────────────────────┐
+│              结构化评估结果（跨版本可比较）                │
+└─────────────────┬───────────────────────────────────────┘
+                  ▼
+┌─────────────────────────────────────────────────────────┐
+│                   进入 CI/CD 流水线                       │
+└─────────────────────────────────────────────────────────┘
+```
+
+---
+
+## 八、参考资料
+
+- 原文标题：Testing Agent Skills Systematically with Evals
+- 原文链接：https://developers.openai.com/blog/eval-skills
+- 视频来源：慢学AI（BV1HWd6BsEmG）
\ No newline at end of file
diff --git a/InBox/Shopify_内部_Agent__为什么不准员工私聊___AI_native组织要的不是个人提效_是组织自进化_BV1i77X6pE1C_笔记.md b/InBox/Shopify_内部_Agent__为什么不准员工私聊___AI_native组织要的不是个人提效_是组织自进化_BV1i77X6pE1C_笔记.md
new file mode 100644
index 0000000..6f70fde
--- /dev/null
+++ b/InBox/Shopify_内部_Agent__为什么不准员工私聊___AI_native组织要的不是个人提效_是组织自进化_BV1i77X6pE1C_笔记.md
@@ -0,0 +1,187 @@
+# Shopify 内部 Agent River：为什么不准员工私聊？
+
+## 核心观点
+
+**AI-native 组织的门槛不是个人更快，而是组织能从经验中学习、能自进化。**
+
+单纯给员工配备私人 AI Agent，可能让每个人变快，但组织本身没有进化。
+
+---
+
+## 问题背景：企业对 AI 的常见误区
+
+### 误区做法
+
+给每个员工开 AI 账号，配一个自己的 Agent，让他跑在：
+
+- 本地终端
+- 编辑器私人对话框
+- 私聊窗口里
+
+### 效果
+
+- 查问题更快
+- 改代码更快
+- 跑测试更快
+
+### 真正的门槛
+
+> 更硬的问题是：**组织能不能从这些 AI 工作里学习？**
+
+能否把一次排查、一次修复、一次好判断，变成后面所有人和所有 Agent 都能继承的经验？
+
+---
+
+## 核心对比：私人 Agent 的天花板
+
+| 维度 | 私人 Agent | 公开 Agent（River） |
+|------|-----------|---------------------|
+| 服务范围 | 键盘前那个人 | 整个团队 |
+| 上下文来源 | 单人输入 | 多人补充 |
+| 经验沉淀 | 个人日志 | 组织语料 |
+| 复现性 | 低（过程不可见） | 高（可搜索、复用） |
+| 学习能力 | Agent 之间互相学不到 | 团队协作促进 Agent 进化 |
+
+### 私人 Agent 的局限性
+
+以一次排查偶发失败测试为例：
+
+1. 你昨天怎么定位问题？
+2. 中间错了哪些方向？
+3. 最后是哪条线索把问题收住？
+
+这些问题**即使留在日志里，也只是事后材料**：
+
+- 不会天然变成多人协作现场
+- 别的工程师不会在过程中看到
+- 不会有人顺手补一个约束
+- 下一次类似情况，不会自动从这条路径开始
+
+---
+
+## River 的设计选择
+
+### 基本工作方式
+
+River 是 Shopify 内部 Slack 里的 AI Agent：
+
+- 员工**不在私聊窗口找他**，要到内部公开频道里 @ 他
+- River 会执行：读代码、跑测试、开 PR、查数据仓库、看生产链路记录
+- 必要时，River 还会**反驳他认为不好的计划**
+
+### 硬性产品约束
+
+```
+只支持公开频道工作，不支持一对一私聊
+```
+
+每一次和 River 的对话，都会变成一条 Slack 线程记录，**默认对 Shopify 内部员工可见**。
+
+> 注：这里的"公开"指 Shopify 内部 Slack 范围内可见，不是互联网公开。
+
+---
+
+## 公开线程的工作机制
+
+### 典型场景
+
+```
+1. 工程师 A 在频道提问
+         ↓
+2. River 开始工作：读文件、跑查询、贴出部分发现
+         ↓
+3. 工程师 B 看到（通过频道链接或被人拉进来）
+         ↓
+4. B 补一句关键约束：
+   - "这个表不能这样查"
+   - "这个服务刚迁移过"
+   - "这个测试以前失败过，原因可能不在这里"
+   - "这个方案会影响另一个团队"
+         ↓
+5. River 吸收新上下文，继续往下查
+```
+
+### 公开 vs 私人的关键差别
+
+- **私人对话**：AI 多数只继承一个人的上下文
+- **公开线程**：AI 进入的是一个**多人协作现场**
+
+---
+
+## 组织学习机制：语料挖掘与回写
+
+公开线程记录会形成一套**可挖掘的组织语料**，Shopify 会：
+
+1. **挖掘反复出现的模式**
+2. 把这些模式回写到 River 的：
+   - 技能（Skills）
+   - 提示词（Prompts）
+   - 默认动作（Default Actions）
+
+### 具体沉淀内容
+
+| 沉淀内容 | 说明 |
+|---------|------|
+| 排查路径 | 哪些排查路径有效 |
+| 工程约束 | 哪些工程约束应该默认带上 |
+| 提示词/技能 | 哪些提示词和技能动作可以沉淀下来 |
+
+### 核心机制
+
+```
+一个人硬啃出来的修复办法 → 下一个人的起点
+一个线程里反复出现的约束 → River 以后更容易带上的上下文
+```
+
+> **一次好的排查，不再只是某个人和某个 Agent 的私有经历，而是开始教会后面的线程。**
+
+---
+
+## 边界与限制
+
+### 不等于禁止所有私聊
+
+企业**不是不能有任何 AI 私聊**，而是 River 这个 Agent 坚持不做私聊入口。
+
+### 需要边界控制的场景
+
+以下敏感问题仍然要有边界：
+
+- 权限相关
+- 安全相关
+- 人事相关
+- 法务相关
+
+### River 的定位
+
+River 处理的是**那些值得被组织记住的工作**，而不是所有对话。
+
+---
+
+## 核心启示
+
+### 对老板和技术负责人的问题清单
+
+部署 AI Agent 时，不仅要问：
+
+- ❌ 员工有没有 Agent？
+- ❌ 对话日志能不能回收？
+- ❌ 个人效率有没有提升？
+
+更要问：
+
+- ✅ 这些 Agent 对话**会不会教会后面的线程**？
+- ✅ 员工用 AI 解决问题的过程，是一份**后台日志**，还是一个**团队能参与、能接力、能复用的工作现场**？
+
+### 结论
+
+| 类型 | 结果 |
+|------|------|
+| 如果只是后台日志 | 一堆分散的个人提效，每个人都快了一点，但组织没有变聪明 |
+| 如果是可协作的工作现场 | 组织从每次 AI 工作中学习，实现**自进化** |
+
+### 金句
+
+> **私人 Agent 的天花板是键盘前那个人。**
+>
+> **公开 Agent 的价值是让后面的线程不从零开始。**
\ No newline at end of file
diff --git a/InBox/_AI翻译_别再自己钻研Claude技巧了_Autoresearch帮你搞定_BV1tJwKzDE8x_笔记.md b/InBox/_AI翻译_别再自己钻研Claude技巧了_Autoresearch帮你搞定_BV1tJwKzDE8x_笔记.md
new file mode 100644
index 0000000..1396b77
--- /dev/null
+++ b/InBox/_AI翻译_别再自己钻研Claude技巧了_Autoresearch帮你搞定_BV1tJwKzDE8x_笔记.md
@@ -0,0 +1,317 @@
+# AutoResearch 自动优化 Claude Code Skills 完整指南
+
+## 目录
+
+- [核心概念](#核心概念)
+- [为什么需要自动研究](#为什么需要自动研究)
+- [AutoResearch 仓库解析](#autoresearch-仓库解析)
+- [自动研究的三个要素](#自动研究的三个要素)
+- [评估设计原则](#评估设计原则)
+- [实战演示流程](#实战演示流程)
+- [演示结果](#演示结果)
+- [最佳实践与注意事项](#最佳实践与注意事项)
+
+---
+
+## 核心概念
+
+### Claude Code Skills 现状
+
+Claude Code Skills（云代码技能）是用于扩展 Claude Code 能力的提示词文件，但存在**稳定性问题**：
+
+| 指标 | 比例 |
+|------|------|
+| 运行技能得到预期输出 | ~70% |
+| 运行技能输出垃圾结果 | ~30% |
+
+### 什么是 AutoResearch
+
+AutoResearch 是由 **Andre Karpathy**（OpenAI 创始成员、前特斯拉 AI 负责人）发布的一个 GitHub 仓库，核心功能是让**一组 AI 智能体能够自主优化某个流程**。
+
+原仓库地址：
+```
+https://github.com/karpathy/auto-research
+```
+
+---
+
+## AutoResearch 仓库解析
+
+该仓库刻意设计得非常精简，**只有三个重要文件**：
+
+### 文件结构
+
+```
+auto-research/
+├── prepare.py      # 机器学习专用（训练分词器等），与技能优化无关
+├── train.py        # 核心文件，相当于你的 skill.md
+└── program.py      # 核心文件，相当于你的智能体
+```
+
+### 工作原理类比
+
+| AutoResearch 组件 | 对应内容 |
+|-------------------|----------|
+| `train.py` | 你的 `skill.md`（要优化的技能提示词） |
+| `program.py` | 你的**智能体**（负责改进技能） |
+
+### 优化流程
+
+```
+1. 给智能体（program.py）一个高级指令
+2. 智能体运行技能（train.py），根据评估标准评分
+3. 智能体判断"这次是否比上次好"
+4. 自动迭代，提示词越来越严密
+5. 每 N 分钟自动运行一次（如每 5 分钟）
+```
+
+---
+
+## 自动研究的三个要素
+
+要让自动研究工作，你需要准备好：
+
+### 1. 客观指标（Objective Metric）
+
+一个**可量化测量**的数字，而不是模糊的感觉描述。
+
+**示例：**
+
+| 应用场景 | 客观指标 |
+|----------|----------|
+| 网站加载速度 | 毫秒（ms） |
+| 冷邮件活动 | 回复率（%） |
+| Claude Code Skill | 通过率 / 评估分数 |
+
+### 2. 测量工具（Measurement Tool）
+
+理想情况下应该**自动化、可靠**，无需人工介入。
+
+**示例：**
+
+| 应用场景 | 测量工具 |
+|----------|----------|
+| 网站性能 | Google Lighthouse |
+| 冷邮件 | 即时 API 分析 |
+| Skills | **测试套件**（智能体编写的自动化测试） |
+
+### 3. 可改变的东西（Variable to Change）
+
+整个优化的对象：
+
+| 应用场景 | 改变的内容 |
+|----------|------------|
+| 网站优化 | 代码改动 |
+| 冷邮件优化 | 邮件文案 |
+| Skills 优化 | **提示词内容（skill.md 文件）** |
+
+---
+
+## 评估设计原则
+
+### 为什么需要多次运行评估
+
+AI 输出本质上是**数据分布**，存在随机性：
+
+```
+运行 20 次技能（生成 20 张图片）
+  ↓
+每次输出都有细微差别
+  ↓
+有些图片相似，有些不同
+  ↓
+必须运行多次，用统计方法评估
+```
+
+### 评估的三个统计指标
+
+| 指标 | 含义 | 作用 |
+|------|------|------|
+| **众数（Mode）** | 出现频率最高的值 | 判断"最常见的结果是什么" |
+| **中位数（Median）** | 排序后的中间值 | 判断"大致平均水平" |
+| **平均值（Mean）** | 所有分数之和除以次数 | 判断"总体表现" |
+
+### 二元问题原则（核心要点）
+
+> **评估应该使用二元的是/否、真/假问题，尽量避免多值评分。**
+
+**原因：** 复合概率导致变异性放大
+
+```
+二元评分：只有 Pass/Fail → 变异性可控
+多值评分（如 1-7 分）→ 每个环节的变异会累积放大
+       ↓
+想象一个漏斗：开始很窄，变异累积后可能差很多
+最终结果可能从 39/40 变成 2/40
+```
+
+**多值评分的风险示例：**
+- 如果给模型太多评估点
+- 模型可能学会"复述每个评估点"来通过测试
+- 就像不理解材料但能考 100 分的学生
+
+### 不要过于具体/狭窄
+
+**反面示例（过于严格）：**
+```
+"确保输出在 X 字以内"
+"确保包含关系符号"
+"确保不包含某些字符"
+```
+
+这会导致模型**过度优化评估指标**而不是真正提升质量。
+
+---
+
+## 实战演示流程
+
+### 演示案例：图表生成器技能优化
+
+#### 步骤一：设置 Claude Code 环境
+
+在 VSCode 或任意编辑器中安装 Claude Code 扩展，设置好开发环境。
+
+#### 步骤二：获取 AutoResearch 仓库
+
+```bash
+# 将仓库链接提供给智能体
+"Read this: https://github.com/karpathy/auto-research"
+```
+
+#### 步骤三：创建评估标准
+
+将评估标准定义为**4 个二元问题**：
+
+| # | 评估标准 | 具体要求 |
+|---|----------|----------|
+| 1 | 文字清晰度 | 所有文字是否清晰且语法正确 |
+| 2 | 配色方案 | 是否符合粉彩色、柔和色调（避免霓虹色） |
+| 3 | 布局条理 | 是否从左到右/从上到下有条理（无乱糟糟的气泡和装饰） |
+| 4 | 无数字编号 | 是否没有 "1, 2, 3, 4" 这样的编号 |
+
+#### 步骤四：提供高级指令给智能体
+
+使用自然语言描述任务：
+
+```
+"我想让你用 AutoResearch 库来改进图表生成器技能。
+  
+  该技能的功能是生成约 200 字的脚本。
+  
+  请用上面的仓库中的自动研究方法帮我建立一套改进系统。
+  
+  每次测试请生成 10 个图表。
+  
+  我希望你按回车继续。"
+```
+
+#### 步骤五：明确评分机制
+
+```
+生成 10 张图片
+每个图片用 4 个标准评估
+最高分 = 40 分（10 × 4）
+
+流程：
+1. 生成 10 张图
+2. 用 4 个标准评估所有 10 张
+3. 计算 40 分中的得分
+4. 修改提示词
+5. 再试一次
+6. 选择表现更好的版本
+```
+
+---
+
+## 演示结果
+
+### 网站优化案例
+
+| 指标 | 优化前 | 优化后 | 改进 |
+|------|--------|--------|------|
+| 加载时间 | 1100ms | 67ms | **81.3%** |
+
+### 图表生成器技能案例
+
+| 指标 | 第一次测试 | 后续迭代 |
+|------|------------|----------|
+| 评估分数 | 32/40 | 37/40 |
+| 迭代趋势 | 基准 | 持续提升 |
+
+**视频效果：** 智能体不断让提示词越来越符合预设的粉彩色、可爱图标等规格。
+
+---
+
+## 最佳实践与注意事项
+
+### ✅ 推荐做法
+
+1. **使用二元问题评估**
+   - 是/否、真/假
+   - 避免 1-10 分等多值评分
+
+2. **保持评估标准简洁**
+   - 每个技能 3-5 个核心标准
+   - 太多标准会导致"假通过"
+
+3. **让评估自动化**
+   - 编写测试套件
+   - 设置定时循环运行
+
+4. **记录所有变更**
+   - 模型尝试的所有改动清单
+   - 可传承给未来的更强模型（GPT-6、Claude 4.0 等）
+
+### ❌ 避免做法
+
+1. **不要过于具体**
+   ```
+   ✗ "确保输出在 100 字以内"
+   ✗ "确保包含关系符号"
+   ```
+
+2. **不要多值复合评分**
+   ```
+   ✗ "X 方面打 1-7 分"
+   ✓ "X 方面是否达标：是/否"
+   ```
+
+3. **不要只运行一次**
+   - 必须多次运行取统计结果
+   - 用众数、中位数判断质量
+
+---
+
+## 可应用场景扩展
+
+AutoResearch 不仅限于 Skills 优化，可应用领域：
+
+| 领域 | 优化目标 |
+|------|----------|
+| 网站 | 加载速度、SEO |
+| 落地页 | 转化率 |
+| A/B 测试 | 标题、缩略图 |
+| 邮件营销 | 邮件文案、回复率 |
+| 代码 | 性能、架构 |
+| 提示词 | 任何技能或流程 |
+
+---
+
+## 资源链接
+
+- **原视频：** https://www.youtube.com/watch?v=qKU-e0x2EmE
+- **AutoResearch 仓库：** https://github.com/karpathy/auto-research
+- **完整 Claude Code 课程：** 见 UP 主频道
+
+---
+
+## 总结
+
+AutoResearch 提供了一种**让 AI 自主优化 AI** 的方法论。通过：
+
+1. **定义客观指标** → 知道要优化什么
+2. **建立测量工具** → 知道如何量化改进
+3. **提供可变量** → 提示词、代码或文案
+4. **多次运行 + 统计评估** → 确保结果可靠
+
+即使你不是机器学习专家，也可以利用这个框架显著提升 Claude Code Skills 的可靠性和准确性，实现技能的**自我进化**。
\ No newline at end of file
diff --git a/InBox/_播客__Agent技术周报2_harness工程能力更新_开源agent生态分化_BV1LjdzB3EAu_笔记.md b/InBox/_播客__Agent技术周报2_harness工程能力更新_开源agent生态分化_BV1LjdzB3EAu_笔记.md
new file mode 100644
index 0000000..d22bc17
--- /dev/null
+++ b/InBox/_播客__Agent技术周报2_harness工程能力更新_开源agent生态分化_BV1LjdzB3EAu_笔记.md
@@ -0,0 +1,180 @@
+# Agent技术周报#2：Harness工程能力更新与开源Agent生态分化
+
+## 本周核心主题
+
+Agent开发正从**单纯的模型能力竞赛**转向更复杂的**系统能力构建**，Harness Engineering（脚手架工程）成为Agent开发的核心差异化竞争点。
+
+业界共识：有用的Agent不是 "just best models"，而是以下系统能力的组合：
+
+- 文件系统访问
+- BSH（Shell）上下文压缩
+- 记忆管理
+- 权限控制
+- 重试机制
+- 评估机制
+- 子Agent协作
+
+---
+
+## 趋势预测
+
+> 预计到 **2025年下半年**，竞争焦点将从模型精度转向整个Agent系统的**鲁棒性**和**可观测性**。
+
+用户核心关注点：
+
+| 旧关注点 | 新关注点 |
+|---------|---------|
+| 单次推理精度 | 能否持续运行数小时甚至数天 |
+| 模型是否最聪明 | 任务中途出错能否自动恢复 |
+| 上下文理解能力 | 长对话中是否丢失上下文 |
+
+---
+
+## Harness工程的技术实践路径
+
+### 1. 解耦与标准化
+
+**代表方案：OpenAI Ediness SDK**
+
+- 将Harness逻辑与实际计算存储环境分离
+- Harness本身**开源可定制**
+- 具体代码执行委托给第三方沙箱环境（如 Modal、CodeFlare）
+- 形成 **无状态编排 + 有状态隔离工作区** 的模式
+- 优势：**既安全又灵活**
+
+### 2. 强化控制与护栏
+
+**代表方案：Lachain DeepAgent**
+
+- 将Agent降级为**结构化的工具调用**
+- 通过**中间件**和**严格的文件系统权限**设置护栏
+- 防止Agent行为失控
+
+### 3. 技能持久化与演化（关键创新）
+
+**代表方案：HermesAgent**
+
+核心思想：把Agent成功完成的工作流**自动保存**为可复用的技能
+
+```
+工作流程：执行 → 成功 → 保存技能 → 可复用 → 持续积累
+```
+
+- Agent不再是"干完就忘"
+- 能积累经验，**越用越强**
+- 形成 **学习 → 固化 → 复用** 的闭环
+
+---
+
+## 实际影响
+
+### 企业层面
+
+- **部署门槛变化**：从"选GPT-4还是Claude"转向"如何设计稳定安全的Harness系统"
+- 云服务商迅速反应：Cloudflare、Modal等推出专门的**Agent沙箱服务**，试图在生态层绑定用户
+- 开源Harness项目正在快速追赶闭源系统的能力
+
+### 用户层面
+
+- 更关注Agent的**持续运行能力**、**自动恢复**、**上下文保持**
+- 衍生新现象：**Wing Fatigue**（持续的审查、修正AI输出带来的精神疲劳）
+- 反向推动系统本身需要更可靠、更自动化
+
+---
+
+## 开源Agent生态分化
+
+> 本周焦点：开源Agent框架早期百花齐放，现在开始像操作系统一样出现**清晰的定位分化**。
+
+### 主要框架对比
+
+| 框架 | 定位 | 特点 | 目标用户 |
+|------|------|------|----------|
+| **HermesAgent** | 可编程专业Agent | 高度可定制、技能持久化、工具箱 | 开发者和高级用户 |
+| **Open Interpreter / Open Cloud** | 即时运行个人助理 | 记忆导入、Memory Palace、聊天UI优化、视频生成插件 | 普通用户 |
+
+### HermesAgent（本周更新 V0.9 / V0.10）
+
+核心功能：
+
+- 专业的本地Web管理仪表盘
+- 强大的**技能持久化**功能
+- 丰富的集成能力
+
+典型应用场景：
+> 用户用它自动修复开源模型的底层代码bug → 跑测试 → 生成报告 → 上传到模型社区，全程高度自制。
+
+**杀手锏**：不是会用工具，而是能**固化技能**——让Agent从临时工变成有经验的老员工。
+
+### Open Cloud
+
+核心功能：
+
+- 记忆导入
+- Memory Palace
+- 聊天UI优化
+- 视频生成插件集成
+
+**定位**：更偏向即时运行个人助理，用户体验更友好。
+
+### 新入局者
+
+| 框架 | 特点 |
+|------|------|
+| **OpenAG** | 开源云编码Agent站 |
+| **DeepAgent** | 底层运行1，支持可插拔模型、提供商、沙箱、中间件、追踪等 |
+
+---
+
+## 行业格局影响
+
+> 2025年可能迎来Agent框架的 **Linux vs Windows** 时刻。
+
+- 用户根据**可编程性需求**（Hermes方向）还是**应用性需求**（Open Cloud方向）做选择
+- 开源Agent在**可复现性**和**可审计性**上的优势凸显
+- 开始吸引对**透明度**和**可控性**有要求的企业用户
+- 闭源方案（GitHub Copilot、Claude Code等）仍有先发和集成优势，但开源追赶速度非常快
+
+---
+
+## 其他值得关注的技术趋势
+
+### 1. 安全与合规转型
+
+新的架构正在推动审查重点从**代码安全**转向**AI行为安全**
+
+- 结合Git版本管理的存储方案
+- 为Agent所有操作提供**审计追踪**和**回滚能力**
+
+### 2. 垂直化与平台化并行
+
+- **平台化**：通用Agent平台扩展为Agent工作区
+- **垂直化**：面向生命科学、网络安全等高价值领域的垂直专业Agent兴起，针对特定领域知识深度优化
+
+### 3. 本地部署加速
+
+- 将Qwen 3.6模型通过**量化技术**
+- 可在**消费级显卡**甚至大内存普通电脑上运行
+
+典型场景：
+> 用户用本地部署的模型分析长达**数十万字**的个人日记，数据完全不用离开本地，**隐私优势无可替代**
+
+---
+
+## 总结
+
+Agent战场已全面升级：从单点模型比拼扩展到**整体系统比拼**。
+
+### 决定性竞争优势来源
+
+| 能力 | 说明 |
+|------|------|
+| 容错性 | 系统容许组件失败 |
+| 可恢复性 | 出错后能自动恢复 |
+| 可审计性 | 所有操作可追溯 |
+| 可演化性 | 经验积累能力 |
+
+**Harness工程**是构建这些能力的核心学科。
+
+- 开源生态会继续分化，提供不同层级的解决方案
+- 企业及个人用户的选择标准需从"模型智能"转向"**模型可靠性**"等系统能力
\ No newline at end of file
diff --git a/InBox/milky_BV17y7U6EER5.md b/InBox/milky_BV17y7U6EER5.md
new file mode 100644
index 0000000..a67dc89
--- /dev/null
+++ b/InBox/milky_BV17y7U6EER5.md
@@ -0,0 +1,158 @@
+---
+title: "[Milky] 为您整理《北大Agent新范式：不改模型权重，效果翻倍北大搞出Agent新范式：不改模型权重，效果接近翻倍》笔记 | BV17y7U6EER5"
+source: "milky@4ueo.com"
+date: 2026-06-09 10:48
+tags: [milky, bilibili, notes]
+email_id: 2068
+---
+
+Milky 为您整理了《北大Agent新范式：不改模型权重，效果翻倍北大搞出Agent新范式：不改模型权重，效果接近翻倍》 | BV17y7U6EER5 笔记。
+
+Life Harnessness：北大Agent优化新范式
+
+核心发现
+
+传统Agent优化的核心假设被推翻：Agent的效果并非完全由模型能力决定。北京大学这篇论文证明，在很多情况下，Agent的失败不是因为模型"笨"，而是因为模型与环境之间的接口不匹配。
+
+
+Agent的本质再定义
+
+传统观点认为：Agent ≈ LLM，能力强则Agent强
+
+论文新观点：Agent是一个完整的交互循环系统，包含以下组件：
+
+`
+环境 → 观测 → 运行时系统 → 工具定义 → 动作模型 → 输出动作
+  ↑                                                              ↓
+  ←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
+`
+
+| 组件 | 说明 |
+|------|------|
+| 运行环境 | 环境给观测，定义工具和动作 |
+| 动作执行器 | 模型输出动作，执行器执行 |
+| 反馈循环 | 执行结果反馈回来更新下一步决策 |
+
+关键洞察：模型输出相同，结果可能完全不同。整个行为是模型和运行时环境共同决定的。
+
+
+问题根源：接口层不匹配
+
+传统Agent常见的失败场景：
+
+模型不知道API的调用格式
+不知道什么动作是合法的
+不知道反馈信号是什么意思
+不知道什么时候该停止
+
+传统解决方案：通过SFT（监督微调）把这些知识灌进模型权重
+
+新方案思路：为什么把环境特定的知识硬编码到模型里？这些东西应该在接口层处理。
+
+
+Life Harnessness 框架
+
+核心思路
+
+不改模型权重，只改运行时接口
+
+从训练轨迹中学习，把反复出现的交互失败转换成可复用的干预。
+
+四个维度的可复用干预
+
+| 维度 | 功能 | 说明 |
+|------|------|------|
+| 环境契约 (Environment Contract) | 告诉模型环境规则 | 明确这个环境中什么能做、什么不能做 |
+| 程序技能 (Program Skill) | 任务分解标准化 | 把复杂任务拆解成标准流程 |
+| 动作实现 (Action Implementation) | 格式转换 | 把模型的高层意图转换成环境能理解的精确格式 |
+| 轨迹调控 (Trajectory Regulation) | 流程控制 | 决定什么时候该回溯、什么时候该停止、什么时候该重试 |
+
+核心特征
+
+训练后固定：Harness一旦训练好就固定下来，评估时不再改变
+非动态调整：不是推理时还在动态调整的东西
+标准化接口适配层：类似于给Agent配了一个"经验丰富的项目经理"
+
+
+实验结果
+
+评估规模
+
+7个确定性环境
+18个模型骨干（从最小到最大全覆盖）
+126个模型-环境组合
+
+效果数据
+
+| 指标 | 数值 |
+|------|------|
+| 有提升的组合数 | 116 / 126 |
+| 平均相对提升 | 88.5% |
+
+88.5%是接近翻倍的提升，不是小数点后一位的微弱改进。
+
+迁移能力验证
+
+使用 Qwen-34B 的训练轨迹进化出来的Harness
+能直接迁移到其他 17个模型 上
+从最小到最大的模型全部适用
+
+关键发现：这说明Harness抓到的不是某个模型的特性行为，而是环境本身的结构。
+
+
+范式转变
+
+| 维度 | 旧范式（模型中心） | 新范式（接口中心） |
+|------|-------------------|-------------------|
+| 优化方向 | 调模型：SFT、蒸馏、更大参数 | 调接口：优化运行时适配层 |
+| 适用场景 | Agent不行就调模型 | Agent不行，先看接口是否有问题 |
+| 关系定位 | 互补，非替代 | 互补，非替代 |
+
+
+局限性
+
+最适合确定性、规则型的环境：需要大量创造性、开放性的任务可能效果不明显
+依赖训练轨迹：需要有足够多的失败案例才能总结干预规则
+干预维度固定：目前是4个维度，能否扩展到更多类型环境还需验证
+
+
+未来发展方向
+
+自动发现与进化
+不用人工定义4个维度，让系统自己发现需要什么样的接口适配
+
+跨环境迁移
+在一个环境上学到的接口适配，能否用到另一个类似环境
+
+协同进化（最具潜力）
+Harness和模型的协同进化，接口层与模型共同进化
+
+
+对普通人的意义
+
+短期
+企业级Agent体验大幅提升
+"你得用精确话术跟AI说话"的情况越来越少
+接口层帮你把意图转换成系统能理解的格式
+
+中期
+Agent开发门槛大幅降低
+不需要海量数据去SFT大模型
+只要把接口适配做好，中等模型就能有很好的效果
+
+长期
+可能改变整个AI产业的分工：
+  - 大模型厂商：负责通用推理能力
+  - 垂直领域厂商：负责接口适配层
+比现在每个公司都训练自己的模型更高效
+Harness可解释、可审计，解决监管问题
+
+
+核心启示
+
+不要一遇到问题就想着堆算力、堆参数。有时候真正的突破来自于对问题本身的重新定义。
+不是模型不行，可能是我们的接口不行。
+换个角度看问题，整个世界都不一样了。
+
+──────────────────────────────
+Generated by MilkyAi@Bilibili: https://space.bilibili.com/3461574540921489
\ No newline at end of file
diff --git a/InBox/milky_BV1ArVU62Eac.md b/InBox/milky_BV1ArVU62Eac.md
new file mode 100644
index 0000000..314567c
--- /dev/null
+++ b/InBox/milky_BV1ArVU62Eac.md
@@ -0,0 +1,435 @@
+---
+title: "[Milky] 为您整理《面向架构编程范式，超越OOP和MVC》笔记 | BV1ArVU62Eac"
+source: "milky@4ueo.com"
+date: 2026-06-09 10:48
+tags: [milky, bilibili, notes]
+email_id: 2062
+---
+
+Milky 为您整理了《面向架构编程范式，超越OOP和MVC》 | BV1ArVU62Eac 笔记。
+
+面向架构编程范式：超越 OOP 和 MVC
+
+一、编程范式的本质
+
+1.1 什么是编程范式
+
+编程范式（Programming Paradigm）是指程序的表达方式，它不决定程序能实现什么功能，只决定能否方便、易懂地表达功能。
+
+`
+过程式表达：
+f1(); f2(); f3();
+
+面向对象表达：
+obj.f1(); obj.f2(); obj.f3();
+`
+
+两段代码功能完全相同，都是先执行 F1，再执行 F2、F3。表达方式不同，但实现的功能是一样的。
+
+关键结论：
+面向对象能写的程序，过程式也能写
+反过来也一样
+无论用哪种范式，你的程序都能实现买东西这个功能
+
+1.2 编程范式的真正目的
+
+编程范式的根本目的是为了大规模代码和大规模团队分工合作。
+
+当代码量膨胀到：
+成千上万行
+几十万行
+上百万行
+
+当团队有上百号程序员时，需要将整个项目拆分成多个模块，每个组负责一个模块。程序员需要调用其他人开发的模块，这就引出了模块封装隔离的概念。
+
+1.3 模块封装隔离的概念
+
+把模块的运行原理封装在模块内，只暴露接口。模块的调用者只需要会操作接口，不需要理解模块内部的运行原理，就能使用这个模块。
+
+如果做不好封装隔离：
+调用其他模块时，需要充分理解那个模块的内部原理
+整个项目可能有成百上千个模块
+需要懂上百个模块的内部原理，才能写自己的程序
+这在实际项目中是不现实的
+
+二、面向对象与模块封装
+
+2.1 面向对象的封装优势
+
+面向对象提供 class 语法，程序员可以很方便地把程序拆分成多个部分：
+
+`python
+class A:
+    def interface1(self): ...
+    def interface2(self): ...
+
+class B:
+    def interface1(self): ...
+    def interface3(self): ...
+
+class C:
+    def interface2(self): ...
+    def interface3(self): ...
+`
+
+每个类是一个模块，每个模块下有若干接口（可外部调用的函数）。实际项目中，每个类可能有几百上千行代码，好几十个函数接口，分别由不同程序员开发。
+
+2.2 不只是面向对象在做模块封装
+
+`python
+过程式模块封装
+module_a.py
+def f1(): ...
+def f2(): ...
+
+module_b.py
+def f3(): ...
+
+main.py
+import module_a
+import module_b
+module_a.f1()
+module_b.f3()
+`
+
+效果和 class 一样。但这种方案太笨重了，比用类要复杂。
+
+2.3 工程成本原则："太麻烦，没人用"
+
+工程问题和数学问题不同：
+数学算法不需要考虑成本
+工程问题最看重的就是成本
+
+如果一个东西的使用成本大于收益，那根本就不会有人去用它。即使这是个好东西。
+
+这会导致：
+只有那些最重要的功能才能采用该方案
+一些边边角角的小功能则完全没法用
+用它反而会让程序更复杂
+
+结论：面向对象比过程式高级，因为面向对象提供了一种方便的用于封装接口的语法。
+
+2.4 class 的本质澄清
+
+class 的本质是借口（Interface）。
+
+一个 class 定义得好不好，取决于：
+有没有做好功能的封装
+有没有暴露出正确的接口
+
+至于汽车有几个轮子、像不像鸭子，根本无关紧要。
+
+正确的类比：手机开机按钮就是一个接口。按下开机键后，手机进行一系列复杂的初始化过程，而用户不需要懂这个过程，只要会按开机键就可以了。
+
+三、面向对象的设计缺陷
+
+3.1 继承的问题：代码无法复用
+
+使用继承进行代码复用的问题：
+
+`
+      A
+     / \
+    B   C
+`
+
+假设 F1、F2、F3 的代码写在 A 类中。用户只需要 F1 和 F3，无法复用这段代码——因为继承会把 F2 也带进来。
+
+3.2 组合优于继承
+
+组合思想：
+`
+    Main
+   / | \
+  A  B  C
+`
+
+子模块拆分成 A 类、B 类、C 类。写 Main 类的程序员需要 F1、F2、F3 中的哪个就组哪个，不需要的就不组。既简单又灵活，完胜继承链条。
+
+组合是一种思想，并不局限于某种特定语法。
+
+3.3 多重继承的致命问题：重名冲突
+
+这是一个记账器例子，子模块 A 和子模块 C 有一个重名的函数 F1，这会造成冲突。
+
+有人会说：把其中一个函数重命名为其他名字不就得了？
+
+现实项目里没这么简单：
+A 模块和 C 模块可能分别是两家公司开发的开源库
+每个库可能有几万行代码
+F1 函数的调用链可能非常复杂
+如果要改名，就要改动整条调用链
+项目还可能存在其他库依赖这两个库的命名
+要改的话就要连同其他库一起改
+
+真正要命的是：原库可能已经在业界运行过多年，安全性和稳定性有保证。改了源代码就要承担出 bug 的风险。
+
+3.4 这种改动要求是不合理的
+
+对比其他领域的例子：
+显卡上有一个电容
+主板上的电容可能和显卡上的电容重名或型号相同
+不会产生命名冲突
+
+工业产品的拆分逻辑都是组合。子模块中存在重名零件，根本不影响任何东西。这才是正确的封装逻辑。
+
+全天底下各行各业，就面向对象搞特殊。
+
+四、MVC 方案的局限
+
+4.1 MVC 就是组合
+
+MVC 把功能拆分成最细的 Model（数据）和 View（函数），再通过 Controller 组合起来：
+
+`python
+class MainController:
+    def init(self):
+        self.modelA = ModelA()
+        self.modelB = ModelB()
+        self.viewC = ViewC()
+`
+
+用哪个 model 或 view 函数就组哪个，不用的就不组。
+
+虽然 A 和 B 存在重名函数，但是并不会产生冲突。
+
+4.2 MVC 的问题：抽象泄露
+
+在 Main 模块中初始化 A 和 B，并交换两者的指针时，存在一个问题：
+
+A 和 B 的初始化逻辑泄露到 Main 这一层了。
+
+在实际项目中：
+A 和 B 可能是别的程序员写的底层库
+Main 模块由业务层程序员写
+底层库的逻辑本不应该泄露到业务层
+
+正确的封装：每一层程序员将本层的逻辑封装在本层。不应该要求使用者理解本层逻辑，只要使用者会用即可。
+
+4.3 初始化逻辑的复杂性
+
+实际项目中初始化可能存在非常复杂的交互关系：
+
+`
+A 先初始化几步
+把中间结果传给 B 初始化
+再把中间结果传回给 A，继续初始化
+`
+
+另外，实际项目中子模块可能不止两个，很可能存在多个子模块初始化过程相互交织的情况。这要求 Main 程序员必须非常理解 A 和 B 等子模块的内部实现，才能写出 Main 层。
+
+4.4 抽象泄露导致的问题
+
+问题 1：模块无法替换
+
+库存程序员无法写出一个模块 C 去替换模块 B，因为 Main 层耦合了模块 B 的初始化逻辑。模块 C 只要初始化逻辑稍有不同，就无法替换 B。
+
+问题 2：中间层方案要么灵活性差，要么代码极为复杂
+
+一种方案是加一个中间层（Middle Layer），中间层由 A 或 B 这一层的程序员编写。Main 层程序员无需理解中间层的内部实现。
+
+但存在两种情况：
+中间层代码最为简单，但灵活性差：Main 程序员无法选择组合哪几个子模块或者组合其他同接口的子模块。比如 Main 实现不了组合 A、C、D 三个模块，因为中间层只实现了 A、B 组合
+让中间层适配，由 Main 层程序员自由选择组合哪些子模块：中间层的代码变得极为复杂
+
+记住"太麻烦，没人用"原则。
+
+4.5 依赖注入和微服务
+
+依赖注入或微服务确实解决了抽象泄露问题。这两个方案都能进行模块替换。
+
+衡量封装得好不好，可以看此模块能不能替换成同类模块。
+
+唯一的问题是：这俩方案太重型了。使用成本太高。
+
+五、时间悖论问题
+
+5.1 时间悖论的根源
+
+回到第一种方案，分析根本原因：
+
+`
+A 模块 ←→ B 模块
+     ↓
+  Main 模块
+`
+
+这里存在一个时间悖论：
+A 模块和 B 模块是先写出来的
+Main 模块是在之后的某个时间点写出来的
+
+如果想避免抽象泄露到 Main 层，程序员需要在 Main 类出现前表达交换 A 和 B 的指针这件事。然而，这做不到，因为 Main 只有在 A 和 B 存在后才出现。
+
+5.2 语法限制导致的困境
+
+但这是因为语法限制。假设编译器支持使用抽象名称作为指针名，其实是不存在时间悖论的。
+
+六、新语法设计方案
+
+6.1 核心语法设计
+
+语法基本沿袭继承，但在调用函数或成员变量时，使用该成员的整个名称链：
+
+| 符号 | 含义 |
+|------|------|
+| ..（两个点） | 向上级寻找 |
+| ...（三个点） | 向平级寻找 |
+| .（一个点） | 向下级寻找 |
+
+也可以使用上斜杠、横杠和下斜杠表示。符号不重要，重要的是原理。
+
+6.2 use 关键字
+
+当名称列太长时，可以使用 use 关键字进行缩写：
+
+`python
+use module_a.b.c as abc
+`
+
+实际上，这个 use 关键字本质上和传统语言里包管理里的 include 或 import 是相同的东西。
+
+6.3 super 关键字
+
+代码中有个 super 关键字。ABCD 模块可能是先写出来的，Main 模块是未来的某个时间点写出来的。
+
+所以写 ABCD 的时候，程序员是不知道未来那个上级模块叫什么名字。这时可以用 super 关键字表示任意名称的上级模块：
+
+`python
+class A:
+    def method(self):
+        super..call_something()  # 向上级寻找
+`
+
+在这种写法下：
+底层模块的逻辑封装在底层
+每一层程序员无需理解底层模块，只要会组合就行了
+可以任意替换同类模块
+
+6.4 from 和 to 关键字
+
+`python
+from ModuleC import xxx as xxx_renamed
+to ModuleX use some_function
+`
+
+from 和 to 关键字比看上去更重要，类似于主板设计师在 PCB 板上连同导线。这个动作是本编程范式下的基石。
+
+6.5 模块重命名
+
+有时子模块可能需要同类。那么可以像下面这样重命名：
+
+`python
+class MainB:
+    from ModuleA as mod_a
+    from ModuleB as mod_b
+    # 两个模块都有相同的接口，但名称不同时进行重命名
+`
+
+6.6 新语法的优势
+
+在抽象泄露的情况下，是无法做到自由替换子模块的，因为上级模块耦合了下层实现。每个下层实现的逻辑不同，替换时要连带替换，泄露到内层的逻辑代码。
+
+使用新语法后：
+每层程序员可以任意组合 B 或 C
+两者名称不同时，使用 from 关键字重命名即可
+模块可以自由替换
+
+七、核心原理：工业流水线思想
+
+7.1 职能隔离的比喻
+
+本语法的核心思想是仿照工业流水生产线生产工业品：
+
+不同工段的工人是职能隔离的
+不同工段的工人无需理解前一个工段
+只需要会组装上一个工段传输过来的零件即可
+同时，本工段的工人也应该将封装好的零件提供给后一个工段的工人，让其无需理解本工段逻辑
+
+7.2 空间位置关系
+
+拿主板和显卡的例子来做说明：
+主板上的一个电容和显卡上的一个电容重名或型号相同时，不会产生名称冲突
+原因在于，主板和显卡是通过三维空间位置寻找子零件
+
+本语法中的全路径巡境表达的是对象成员的空间位置关系，相当于主板设计师在 PCB 板上按空间位置连同导线。
+
+7.3 编译期依赖注入
+
+本语法相当于在面向对象的继承语法的基础上，在编译期实现依赖注入。
+
+本语法是对面向对象的语法的发展或改进，而非否定。
+
+八、API 关键字与调用链耦合
+
+8.1 基本语法存在的问题
+
+但刚刚的基本语法存在一个问题：调用链耦合了其他模块的名称链。
+
+看回例子：
+模块 A 再调用模块 B 时，调用链耦合了 B 到 D 这个名称链
+在实际项目中，模块 B 可能是其他公司开发的开源库
+它写的名称链可能是 B → E → D
+模块 A 的程序员是不可能要求 B 程序员按 A 的要求改名的
+
+所以这种基本语法仅适用于模块内部，程序员可以完全控制代码的情况下。
+
+8.2 API 关键字解决方案
+
+当模块间进行交互时，需要另外一种封装机制：API 关键字。
+
+`python
+class ModuleA:
+    @API  # 标记为公开接口
+    def public_interface(self): ...
+    
+    def privatemethod(self): ...  # 内部方法
+`
+
+本语法中不存在其他面向对象语言中的 public 和 private 关键字，而是使用 API 关键字控制可见性。
+
+8.3 API 关键字的作用
+
+当模块 M 的未标记为 API 时：
+该 M 的成员变量和成员函数全是 public 公有
+可被外部任意访问
+
+使用 API 关键字可以：
+精确控制哪些接口对外暴露
+将调用链耦合封装在模块内部
+允许外部替换同接口的模块而不影响内部实现
+
+九、总结
+
+9.1 编程范式演进路径
+
+| 阶段 | 特点 | 问题 |
+|------|------|------|
+| 过程式 | 简单直接 | 代码膨胀后难以维护 |
+| 面向对象 | class 语法便于封装 | 继承导致代码无法复用、重名冲突 |
+| MVC | 组合思想 | 抽象泄露、初始化逻辑耦合 |
+| 依赖注入/微服务 | 解决抽象泄露 | 太重型、成本高 |
+
+9.2 新范式的核心要点
+
+全路径巡境：通过名称链完整表达模块间的空间位置关系
+编译期依赖注入：在编译阶段完成依赖关系的绑定
+职能隔离：仿照工业流水线，每层程序员无需理解底层
+模块可替换：衡量封装好不好的标准是能否自由替换同类模块
+API 关键字：控制模块间交互的接口暴露
+
+9.3 对面向对象的态度
+
+本语法是对面向对象的语法的发展或改进，而非否定。它解决了：
+继承的代码复用问题
+多重继承的重名冲突问题
+MVC 的抽象泄露问题
+时间悖论导致的初始化耦合问题
+
+
+相关讨论补充（来自弹幕）：
+边界条件处理和输入检查在任何范式下都需要考虑
+用函数做 API 和用类做 API 区别挺大——类可以维护状态，函数式更纯粹
+有些成员变量要维护的话，面向对象还是最合适的
+
+──────────────────────────────
+Generated by MilkyAi@Bilibili: https://space.bilibili.com/3461574540921489
\ No newline at end of file
diff --git a/InBox/milky_BV1HWd6BsEmG.md b/InBox/milky_BV1HWd6BsEmG.md
new file mode 100644
index 0000000..077db09
--- /dev/null
+++ b/InBox/milky_BV1HWd6BsEmG.md
@@ -0,0 +1,321 @@
+---
+title: "[Milky] 为您整理《OpenAI：Skill的自动评分器怎么搭》笔记 | BV1HWd6BsEmG"
+source: "milky@4ueo.com"
+date: 2026-06-09 10:48
+tags: [milky, bilibili, notes]
+email_id: 1995
+---
+
+Milky 为您整理了《OpenAI：Skill的自动评分器怎么搭》| BV1HWd6BsEmG 笔记。
+
+OpenAI Skill 自动评分器构建指南
+
+一、为什么需要评分器
+
+当更新一个 Skill 并执行完成后，表面结果正常不代表真的变好了。核心问题是：
+
+Skill 是否真的完成了预期任务？
+修改是否引入了新的问题（回归）？
+如何在不同版本之间进行性能比较？
+
+评分器的职责就是回答这些问题，让 Skill 的质量变化可衡量、可追踪。
+
+
+二、运行轨迹记录
+
+2.1 什么是运行轨迹
+
+评分的前提是有东西可以打分。OpenAI 的做法是使用 CodeExec JSON 记录 Skill 的完整执行过程。
+
+2.2 配置方式
+
+`json
+{
+  "code_exec": true  // 启用后输出结构化执行记录
+}
+`
+
+2.3 记录内容
+
+启用后，Skill 每执行一步都会输出结构化记录，包括：
+
+跑了什么命令
+创建了什么文件
+执行顺序
+时间戳
+
+2.4 关键特性
+
+| 特性 | 说明 |
+|------|------|
+| 完整性 | 记录完整执行流程，而非日志摘要 |
+| 可解析性 | 结构化数据，可被程序直接读取 |
+| 可调试性 | 失败时可精确定位到具体哪一步出错 |
+
+没有运行轨迹，评分器只能看最终产物，无法分析执行过程。
+
+
+三、评分器类型
+
+3.1 确定性检查（Deterministic Checks）
+
+3.1.1 原理
+
+纯代码规则驱动的检查，不用大模型，写死判断逻辑，程序直接对着运行轨迹核对。
+
+3.1.2 典型检查项
+
+`
+有没有执行 npm install
+有没有创建 package.json
+命令执行顺序是否符合预期
+是否在指定目录执行操作
+`
+
+3.1.3 核心特性
+
+| 特性 | 说明 |
+|------|------|
+| 确定性 | 同样行为每次判断结果一致，没有模糊地带 |
+| 可调试 | 一旦失败，打开记录文件即可看到从哪一步开始偏离 |
+
+3.1.4 局限性
+
+确定性检查能回答"基础动作做了没有"，但无法回答"做出来的东西是不是你想要的样子"。
+
+
+3.2 评分细则检查（Rubric-based Checks）
+
+3.2.1 原理
+
+使用 LLM 作为裁判，读取仓库内容，按预定义的评分细则输出结构化打分结果。
+
+3.2.2 适用场景
+
+很多 Skill 的验收标准本来就是软性规则，例如：
+
+代码结构是否干净
+组件组织是否符合团队约定
+样式配置是否按既定风格落地
+命名规范是否遵循
+
+3.2.3 评分细则的拆解方法
+
+把模糊的质量标准拆成若干个可独立判断的维度：
+
+| 模糊标准 | 拆解后的维度 |
+|----------|--------------|
+| 代码质量好 | 组件是否按功能分目录 |
+| | 是否有未使用的引用 |
+| | 样式类名是否遵循命名约定 |
+| | 配置项是否集中管理 |
+
+3.2.4 关键要求：锁定输出格式
+
+必须提前定义输出模板，规定模型必须输出哪些字段：
+
+`json
+{
+  "passed": true/false,
+  "total_score": 85,
+  "dimensions": [
+    {
+      "name": "component_organization",
+      "score": 90,
+      "reason": "组件按功能正确分目录"
+    },
+    {
+      "name": "unused_imports",
+      "score": 70,
+      "reason": "发现3处未使用的import"
+    }
+  ]
+}
+`
+
+3.2.5 为什么必须锁死格式
+
+| 自由输出 | 锁死格式 |
+|----------|----------|
+| 每次措辞不同 | 格式统一 |
+| 无法跨版本比较 | 结果可量化 |
+| 无法进自动化流程 | 可直接集成 CI/CD |
+| 输出是"审稿意见" | 输出是"评估数据" |
+
+
+四、评分器组合策略
+
+4.1 分工明确
+
+`
+确定性检查 ──→ 抓底线（基础动作有没有发生）
+评分细则检查 ──→ 抓质量（做出来的东西像不像你要的）
+输出格式锁定 ──→ 防飘移（每次评分结果一致）
+`
+
+4.2 集成到流水线
+
+这套组合设计之初就面向 持续集成（CI）：
+
+不再依赖工程师手动触发测试
+成为持续运行的回归守门员
+Skill 每次更新都会自动验证
+
+
+五、6 类扩展检查
+
+在基础评分器之上，可按需叠加以下检查：
+
+5.1 命令数与循环检测
+
+`
+检查运行记录里执行了多少条命令
+`
+
+目的：检测行为退化
+
+案例：如果一个 Skill 以前 6 步能完成，现在要 18 步，表面上任务还是完成了，但系统正在变差。
+
+5.2 消耗量追踪
+
+`
+记录每次运行消耗的 token 数量
+`
+
+目的：防止 Skill 越来越臃肿
+
+每次执行越来越贵
+每次执行越来越慢
+
+5.3 构建检查
+
+`bash
+skill 完成后直接执行构建命令
+npm run build
+`
+
+目的：端到端验证
+
+很多项目表面完成，构建就露馅
+成本低，应该默认开启
+
+5.4 运行时冒烟检查
+
+`bash
+启动开发服务器
+npm run dev
+发送测试请求
+curl http://localhost:3000/api/health
+`
+
+目的：验证服务是否真正可用
+
+注意：这类检查更慢，按风险等级决定是否每次都执行。
+
+5.5 仓库清洁度检查
+
+`
+检查任务完成后是否出现不该有的文件
+`
+
+目的：确保系统没有被"弄脏"
+
+5.6 权限回归检查
+
+`
+验证 skill 是否还能在最小权限下正常工作
+`
+
+目的：防止权限漂移
+
+某次改动后悄悄开始依赖更高权限
+权限漂移在自动化后会变成结构性风险
+
+5.7 扩展策略
+
+`
+原文建议：先加快速检查，再按风险叠加慢检查
+         不是一次全上，是按需扩展
+`
+
+| 检查类型 | 速度 | 建议频率 |
+|----------|------|----------|
+| 命令数检测 | 快 | 每次 |
+| 消耗量追踪 | 快 | 每次 |
+| 仓库清洁度 | 快 | 每次 |
+| 构建检查 | 中 | 每次 |
+| 运行时冒烟 | 慢 | 按风险 |
+| 权限回归 | 慢 | 定期 |
+
+
+六、5 条核心原则
+
+原则一：量真正重要的东西
+
+Don't measure for the sake of measuring. First, think about what you'd actually care about if it got worse.
+
+不要为了有指标而有指标，先想清楚什么变差了，你会真的在意。
+
+原则二：先写清晰可检查的定义
+
+If the success criteria are fuzzy, the evaluation will be too.
+
+验收标准模糊，评估就没有意义。先把"什么叫做对"写成可执行的判断。
+
+原则三：把评估扎在真实行为上
+
+Record the full execution trace and write deterministic checks around the actual actions taken.
+
+记录 Skill 的完整运行轨迹，围绕实际执行的动作写确定性检查。
+
+原则四：规则不够时，再让模型补上
+
+Use rubric-based evals to handle quality judgments that rules can't cover, not as a replacement.
+
+用评分细则处理规则覆盖不了的质量判断，顺序不能反。确定性检查在前，LLM 评分在后。
+
+原则五：让真实失败去驱动样本增长
+
+Every time you manually fix something, turn it into a test case.
+
+每次手动修复都是一个信号，把它变成测试用例，让 Skill 持续把这件事做对。
+
+
+七、整体流程图
+
+`
+┌─────────────────────────────────────────────────────────┐
+│                    Skill 执行                            │
+└─────────────────┬───────────────────────────────────────┘
+                  ▼
+┌─────────────────────────────────────────────────────────┐
+│            CodeExec JSON 记录运行轨迹                     │
+└─────────────────┬───────────────────────────────────────┘
+                  ▼
+         ┌───────┴───────┐
+         ▼               ▼
+┌───────────────┐ ┌─────────────────┐
+│ 确定性检查     │ │ 评分细则检查     │
+│ (规则驱动)     │ │ (LLM 裁判)       │
+└───────┬───────┘ └────────┬────────┘
+        ▼                  ▼
+        └────────┬─────────┘
+                 ▼
+┌─────────────────────────────────────────────────────────┐
+│              结构化评估结果（跨版本可比较）                │
+└─────────────────┬───────────────────────────────────────┘
+                  ▼
+┌─────────────────────────────────────────────────────────┐
+│                   进入 CI/CD 流水线                       │
+└─────────────────────────────────────────────────────────┘
+`
+
+
+八、参考资料
+
+原文标题：Testing Agent Skills Systematically with Evals
+原文链接：https://developers.openai.com/blog/eval-skills
+视频来源：慢学AI（BV1HWd6BsEmG）
+
+──────────────────────────────
+— Milky 视频总结助手
\ No newline at end of file
diff --git a/InBox/milky_BV1Hn9UBrEsH.md b/InBox/milky_BV1Hn9UBrEsH.md
new file mode 100644
index 0000000..fd6cb69
--- /dev/null
+++ b/InBox/milky_BV1Hn9UBrEsH.md
@@ -0,0 +1,324 @@
+---
+title: "[Milky] 为您整理《Harness Engineering最佳实践：深度解析AgentHamness的底层原理、核心组件和实战应用 学不会我退出AI圈！》 P1笔记 | BV1Hn9UBrEsH"
+source: "milky@4ueo.com"
+date: 2026-06-09 10:48
+tags: [milky, bilibili, notes]
+email_id: 2013
+---
+
+Milky 为您整理了《Harness Engineering最佳实践：深度解析AgentHamness的底层原理、核心组件和实战应用 学不会我退出AI圈！》 P1 | BV1Hn9UBrEsH 笔记。
+
+Harness Engineering 最佳实践：Agent Harness 底层原理、核心组件与实战应用
+
+目录
+
+AI 工程师的岗位分层体系
+大模型应用的三层进化范式
+Prompt Engineering：让模型"会说"
+Context Engineering：解决上下文膨胀问题
+Agent Harness 核心架构
+Harness Engineering 的工程实践
+
+
+AI 工程师的岗位分层体系
+
+1.1 三层架构概述
+
+在 2026 年，AI 工程师可分为三个层级，每个层级有明确的技术侧重点：
+
+| 层级 | 定位 | 核心职责 | 技术侧重 |
+|------|------|----------|----------|
+| AI 产品化 | AI 产品经理、AI 解决方案架构师 | 发现 AI 价值场景，重塑业务流程 | 业务分析、产品设计 |
+| AI 应用层 | AI 应用工程师、大模型应用开发 | 业务方案落地，AI 赋能场景 | Prompt Engineering、Context Engineering、RAG |
+| AI 大模型算法层 | 模型研发工程师 | 提升模型垂直能力 | SFT 微调、RLHF 对齐、安全护栏 |
+
+1.2 各层级的核心差异
+
+AI 产品化层：
+聚焦于找到 AI 的价值场景
+重新定义业务产品线
+属于业务与产品方向
+
+AI 应用层（Harness Engineering 的落地层）：
+偏业务 + 方案落地
+利用开源模型构建垂直应用
+2026 年最稀缺、最具机会的方向
+
+AI 大模型算法层：
+不做基座模型（GPT-4、Qwen3.6 等基座由大厂完成）
+聚焦于模型的垂直能力提升
+包括：
+  - SFT 微调（Supervised Fine-Tuning）
+  - RLHF（Reinforcement Learning from Human Feedback）
+  - 对齐训练（Alignment）
+  - 安全护栏（Safety Guardrails）
+
+1.3 职业选择建议
+
+`
+技术背景 → AI 应用层（最佳入场点）
+产品背景 → AI 产品化层 → 可延伸至应用层
+算法背景 → AI 大模型算法层
+`
+
+核心观点：2026 年是大模型应用落地的关键年份，大多数人的机会在于 AI 应用层。
+
+
+大模型应用的三层进化范式
+
+从时间维度看，AI 应用开发经历了三个阶段的范式转变：
+
+`
+2022-2024：Prompt Engineering 时代
+    ↓
+2025：Context Engineering 时代
+    ↓
+2026：Agent Harness / Harness Engineering 时代
+`
+
+
+Prompt Engineering：让模型"会说"
+
+3.1 时间窗口
+
+2022 年 11 月 ChatGPT 发布后成为焦点
+
+3.2 核心问题
+
+解决"如何说"的问题——如何更好地与模型沟通，让模型生成更高质量的回答。
+
+3.3 技术特征
+
+单对单对话模式
+用户输入一句话，模型返回一句话
+关注点：如何编写有效的 Prompt
+
+3.4 典型场景
+
+`
+用户 → Prompt → LLM → Response
+`
+
+
+Context Engineering：解决上下文膨胀问题
+
+4.1 时间窗口
+
+2025 年
+
+4.2 核心问题
+
+随着 Agent 开发引入工具调用（如 MCP 协议），上下文窗口中的内容越来越多，导致模型能力反而下降、幻觉（Hallucination） 问题加剧。
+
+4.3 核心目标
+
+解决"有什么"的问题——让模型清楚地知道当前拥有哪些信息。
+
+4.4 关键概念
+
+Context Window（上下文窗口）：
+多轮对话的执行过程中，所有历史信息都存储在上下文窗口中
+当内容越来越多时，模型会出现"迷失"现象
+
+迷失问题（Lost in Context）：
+模型在大量上下文中无法准确识别关键信息
+导致：
+  - 响应质量下降
+  - 幻觉增加
+  - 任务执行失败
+
+4.5 Context Engineering 的职责
+
+| 问题 | 解决方案 |
+|------|----------|
+| 上下文过长 | 上下文压缩、摘要 |
+| 信息混乱 | 结构化组织、分类管理 |
+| 关键信息被淹没 | 关键信息突出、检索增强 |
+
+
+Agent Harness 核心架构
+
+5.1 官方来源
+
+本文档基于 LangChain 团队发布的关于 Agent Harness 的官方博客，是全球最懂 Agent 的团队发布的系统性技术文档。
+
+5.2 Agent Harness 的定位
+
+Harness 的本意是"驾驭、利用"，Agent Harness 即对 Agent 的工程化驾驭框架。
+
+5.3 核心架构体系
+
+`
+┌─────────────────────────────────────────┐
+│           Agent Harness                │
+├─────────────────────────────────────────┤
+│  ┌─────────────┐  ┌─────────────────┐   │
+│  │   规划层    │  │     执行层       │   │
+│  │  Planning  │  │   Execution     │   │
+│  └─────────────┘  └─────────────────┘   │
+│  ┌─────────────┐  ┌─────────────────┐   │
+│  │   工具层    │  │     记忆层       │   │
+│  │   Tools    │  │     Memory      │   │
+│  └─────────────┘  └─────────────────┘   │
+│  ┌─────────────┐  ┌─────────────────┐   │
+│  │   感知层    │  │     评估层       │   │
+│  │ Perception │  │  Evaluation     │   │
+│  └─────────────┘  └─────────────────┘   │
+└─────────────────────────────────────────┘
+`
+
+5.4 各层核心组件详解
+
+5.4.1 规划层（Planning）
+
+职责：将复杂任务分解为可执行的子任务
+
+关键技术：
+任务分解（Task Decomposition）
+思维链（Chain of Thought, CoT）
+子任务规划
+
+5.4.2 执行层（Execution）
+
+职责：执行规划层生成的子任务
+
+关键技术：
+工具调用（Tool Calling）
+动作执行（Action Execution）
+结果反馈
+
+5.4.3 工具层（Tools）
+
+职责：为 Agent 提供外部能力
+
+典型工具类型：
+MCP 工具（Model Context Protocol）
+API 调用
+搜索引擎
+数据库查询
+文件系统操作
+
+5.4.4 记忆层（Memory）
+
+职责：存储和管理 Agent 的历史状态与上下文
+
+记忆类型：
+| 类型 | 说明 | 用途 |
+|------|------|------|
+| 短期记忆 | 当前对话上下文 | 处理即时任务 |
+| 长期记忆 | 持久化存储 | 跨会话经验积累 |
+| 工作记忆 | 工作过程中的临时状态 | 任务执行中间态 |
+
+5.4.5 感知层（Perception）
+
+职责：接收和处理外部输入
+
+感知内容：
+用户指令
+文档输入
+多模态信息（图像、音频等）
+环境状态
+
+5.4.6 评估层（Evaluation）
+
+职责：评估 Agent 执行结果的质量
+
+评估维度：
+输出正确性
+任务完成度
+安全性检查
+效率评估
+
+
+Harness Engineering 的工程实践
+
+6.1 定义
+
+Harness Engineering 是系统性地构建、测试、优化 Agent 行为能力的工程学科。
+
+6.2 与传统软件工程的区别
+
+| 维度 | 传统软件工程 | Harness Engineering |
+|------|-------------|---------------------|
+| 不确定性 | 低（确定性逻辑） | 高（概率性输出） |
+| 测试难度 | 可精确断言 | 需概率评估 |
+| 调试方法 | 日志追踪 | 行为轨迹分析 |
+| 质量保障 | 单元测试 + 集成测试 | 评估驱动开发 |
+
+6.3 核心工程实践
+
+6.3.1 评估驱动开发（Evaluation-Driven Development）
+
+`
+设计评估指标 → 开发 Agent → 持续评估 → 迭代优化
+`
+
+6.3.2 行为可复现性
+
+通过种子（seed）控制随机性
+构建可测试的 Agent 行为
+建立回归测试机制
+
+6.3.3 多维度评测
+
+任务完成率：Agent 是否完成目标
+效率指标：消耗的 Token 数量、执行时间
+质量评分：输出的人力评估
+安全性检查：有害内容过滤
+
+6.4 LangChain Agent Harness 的工具链
+
+`
+┌──────────────────────────────────────────┐
+│           LangChain 生态                 │
+├──────────────────────────────────────────┤
+│  LangChain       │  Agent 开发框架        │
+│  LangSmith       │  追踪与评估平台        │
+│  LangServe       │  Agent 部署服务        │
+│  LangGraph       │  Agent 工作流编排      │
+└──────────────────────────────────────────┘
+`
+
+
+补充：观众反馈中的有价值观点
+
+本节整理自视频弹幕中观众的补充与讨论
+
+7.1 关于 Context Engineering 的延伸
+
+Context Engineering 不仅解决"上下文膨胀"，还需要考虑信息密度问题
+有效上下文 = 去除噪音后的核心信息
+常用的压缩策略：LLM 摘要、关键信息提取、信息去重
+
+7.2 关于 Agent 幻觉的处理
+
+幻觉问题在单轮对话中已存在
+在多轮 Agent 执行中，幻觉会被级联放大
+建议在每个关键步骤增加自我校验机制
+
+7.3 关于实际落地的建议
+
+不要过度追求 Agent 的自主性，人机协同往往更可靠
+初期应聚焦垂直场景，积累领域知识后再扩展
+
+
+附录：关键术语表
+
+| 英文术语 | 中文解释 |
+|----------|----------|
+| Harness Engineering | 驾驭工程，Agent 的系统工程化方法 |
+| Agent Harness | Agent 框架的核心组件集合 |
+| Prompt Engineering | 提示词工程，优化人机交互质量 |
+| Context Engineering | 上下文工程，管理信息输入质量 |
+| Hallucination | 幻觉，LLM 生成虚假或不准确内容 |
+| Chain of Thought (CoT) | 思维链，引导模型展示推理过程 |
+| SFT | Supervised Fine-Tuning，有监督微调 |
+| RLHF | Reinforcement Learning from Human Feedback，基于人类反馈的强化学习 |
+| MCP | Model Context Protocol，模型上下文协议 |
+| Agent | 智能体，能够自主执行任务的 AI 系统 |
+
+
+笔记说明：本笔记基于 LangChain 团队发布的官方博客整理，聚焦于 Agent Harness 的技术架构与工程实践。视频原版对三层架构有详细展开，读者可根据需要结合原视频深入理解各层级的技术细节。
+
+──────────────────────────────
+— MilkyAi
\ No newline at end of file
diff --git a/InBox/milky_BV1LjdzB3EAu.md b/InBox/milky_BV1LjdzB3EAu.md
new file mode 100644
index 0000000..b552af8
--- /dev/null
+++ b/InBox/milky_BV1LjdzB3EAu.md
@@ -0,0 +1,186 @@
+---
+title: "[Milky] 为您整理《[播客] Agent技术周报2，harness工程能力更新，开源agent生态分化》笔记 | BV1LjdzB3EAu"
+source: "milky@4ueo.com"
+date: 2026-06-09 10:48
+tags: [milky, bilibili, notes]
+email_id: 1989
+---
+
+Milky 为您整理了《[播客] Agent技术周报2，harness工程能力更新，开源agent生态分化》| BV1LjdzB3EAu 笔记。
+
+Agent技术周报#2：Harness工程能力更新与开源Agent生态分化
+
+本周核心主题
+
+Agent开发正从单纯的模型能力竞赛转向更复杂的系统能力构建，Harness Engineering（脚手架工程）成为Agent开发的核心差异化竞争点。
+
+业界共识：有用的Agent不是 "just best models"，而是以下系统能力的组合：
+
+文件系统访问
+BSH（Shell）上下文压缩
+记忆管理
+权限控制
+重试机制
+评估机制
+子Agent协作
+
+
+趋势预测
+
+预计到 2025年下半年，竞争焦点将从模型精度转向整个Agent系统的鲁棒性和可观测性。
+
+用户核心关注点：
+
+| 旧关注点 | 新关注点 |
+|---------|---------|
+| 单次推理精度 | 能否持续运行数小时甚至数天 |
+| 模型是否最聪明 | 任务中途出错能否自动恢复 |
+| 上下文理解能力 | 长对话中是否丢失上下文 |
+
+
+Harness工程的技术实践路径
+
+解耦与标准化
+
+代表方案：OpenAI Ediness SDK
+
+将Harness逻辑与实际计算存储环境分离
+Harness本身开源可定制
+具体代码执行委托给第三方沙箱环境（如 Modal、CodeFlare）
+形成 无状态编排 + 有状态隔离工作区 的模式
+优势：既安全又灵活
+
+强化控制与护栏
+
+代表方案：Lachain DeepAgent
+
+将Agent降级为结构化的工具调用
+通过中间件和严格的文件系统权限设置护栏
+防止Agent行为失控
+
+技能持久化与演化（关键创新）
+
+代表方案：HermesAgent
+
+核心思想：把Agent成功完成的工作流自动保存为可复用的技能
+
+`
+工作流程：执行 → 成功 → 保存技能 → 可复用 → 持续积累
+`
+
+Agent不再是"干完就忘"
+能积累经验，越用越强
+形成 学习 → 固化 → 复用 的闭环
+
+
+实际影响
+
+企业层面
+
+部署门槛变化：从"选GPT-4还是Claude"转向"如何设计稳定安全的Harness系统"
+云服务商迅速反应：Cloudflare、Modal等推出专门的Agent沙箱服务，试图在生态层绑定用户
+开源Harness项目正在快速追赶闭源系统的能力
+
+用户层面
+
+更关注Agent的持续运行能力、自动恢复、上下文保持
+衍生新现象：Wing Fatigue（持续的审查、修正AI输出带来的精神疲劳）
+反向推动系统本身需要更可靠、更自动化
+
+
+开源Agent生态分化
+
+本周焦点：开源Agent框架早期百花齐放，现在开始像操作系统一样出现清晰的定位分化。
+
+主要框架对比
+
+| 框架 | 定位 | 特点 | 目标用户 |
+|------|------|------|----------|
+| HermesAgent | 可编程专业Agent | 高度可定制、技能持久化、工具箱 | 开发者和高级用户 |
+| Open Interpreter / Open Cloud | 即时运行个人助理 | 记忆导入、Memory Palace、聊天UI优化、视频生成插件 | 普通用户 |
+
+HermesAgent（本周更新 V0.9 / V0.10）
+
+核心功能：
+
+专业的本地Web管理仪表盘
+强大的技能持久化功能
+丰富的集成能力
+
+典型应用场景：
+用户用它自动修复开源模型的底层代码bug → 跑测试 → 生成报告 → 上传到模型社区，全程高度自制。
+
+杀手锏：不是会用工具，而是能固化技能——让Agent从临时工变成有经验的老员工。
+
+Open Cloud
+
+核心功能：
+
+记忆导入
+Memory Palace
+聊天UI优化
+视频生成插件集成
+
+定位：更偏向即时运行个人助理，用户体验更友好。
+
+新入局者
+
+| 框架 | 特点 |
+|------|------|
+| OpenAG | 开源云编码Agent站 |
+| DeepAgent | 底层运行1，支持可插拔模型、提供商、沙箱、中间件、追踪等 |
+
+
+行业格局影响
+
+2025年可能迎来Agent框架的 Linux vs Windows 时刻。
+
+用户根据可编程性需求（Hermes方向）还是应用性需求（Open Cloud方向）做选择
+开源Agent在可复现性和可审计性上的优势凸显
+开始吸引对透明度和可控性有要求的企业用户
+闭源方案（GitHub Copilot、Claude Code等）仍有先发和集成优势，但开源追赶速度非常快
+
+
+其他值得关注的技术趋势
+
+安全与合规转型
+
+新的架构正在推动审查重点从代码安全转向AI行为安全
+
+结合Git版本管理的存储方案
+为Agent所有操作提供审计追踪和回滚能力
+
+垂直化与平台化并行
+
+平台化：通用Agent平台扩展为Agent工作区
+垂直化：面向生命科学、网络安全等高价值领域的垂直专业Agent兴起，针对特定领域知识深度优化
+
+本地部署加速
+
+将Qwen 3.6模型通过量化技术
+可在消费级显卡甚至大内存普通电脑上运行
+
+典型场景：
+用户用本地部署的模型分析长达数十万字的个人日记，数据完全不用离开本地，隐私优势无可替代
+
+
+总结
+
+Agent战场已全面升级：从单点模型比拼扩展到整体系统比拼。
+
+决定性竞争优势来源
+
+| 能力 | 说明 |
+|------|------|
+| 容错性 | 系统容许组件失败 |
+| 可恢复性 | 出错后能自动恢复 |
+| 可审计性 | 所有操作可追溯 |
+| 可演化性 | 经验积累能力 |
+
+Harness工程是构建这些能力的核心学科。
+
+开源生态会继续分化，提供不同层级的解决方案
+企业及个人用户的选择标准需从"模型智能"转向"模型可靠性"等系统能力
+
+──────────────────────────────
+— Milky 视频总结助手
\ No newline at end of file
diff --git a/InBox/milky_BV1SZoXBkErT.md b/InBox/milky_BV1SZoXBkErT.md
new file mode 100644
index 0000000..1a10610
--- /dev/null
+++ b/InBox/milky_BV1SZoXBkErT.md
@@ -0,0 +1,365 @@
+---
+title: "[Milky] 为您整理《2026-04-25 Harness for AI coding 团队级 AI 编程驾驭工程》笔记 | BV1SZoXBkErT"
+source: "milky@4ueo.com"
+date: 2026-06-09 10:48
+tags: [milky, bilibili, notes]
+email_id: 2043
+---
+
+Milky 为您整理了《2026-04-25 Harness for AI coding 团队级 AI 编程驾驭工程》 | BV1SZoXBkErT 笔记。
+
+敏捷团队 AI 编程驾驭工程体系
+
+一、背景与核心问题
+
+1.1 为什么需要团队级 AI 编程体系
+
+当前 AI 编程工具（如 SuperPowe、Claude Code、Cursor 等）已经非常强大，但在团队级、项目级场景下落地困难。核心原因是：
+
+需求衔接问题：产品经理/BA 给的需求格式不统一，颗粒度不一致，导致 AI 无法有效理解
+开发实践问题：多人协作时，AI 生成的代码风格不统一、难以形成一致的整体
+工具生态混乱：Claude Code、Cursor、windsurf、SuperPower 等工具差异大，没有统一标准
+流程与制度问题：团队工作习惯难以改变，这是最大的阻力来源
+
+1.2 当前团队使用 AI 编程的认知分级
+
+根据开发者能力分层：
+
+| 级别 | 描述 | 典型行为 |
+|------|------|----------|
+| 初级开发者 | 照猫画虎，不知道系统如何工作 | 抄代码、写业务逻辑，被 AI 替代 |
+| 专家型开发者 | 做技术公关，复杂组件开发 | 仍需要，但 AI 可辅助 |
+| 架构型开发者 | 设计服务、做权衡决策 | AI 辅助设计，但要人工把关 |
+| 技术经理/CTO | 处理复杂混乱的问题 | 构建团队 AI 工作体系 |
+
+关键洞察："这个玩具不是玩 AI，是玩人"——真正的挑战不在于 AI 能力，而在于如何让团队按照统一的方式工作。
+
+1.3 AI 辅助软件工程全流程图
+
+`
+需求分析 → 技术方案设计 → 代码编写 → Code Review → 测试 → 部署 → 生产 Bug 修复
+   ↓            ↓              ↓          ↓         ↓       ↓         ↓
+  录音转文档   打样工程      API/单元测试   交叉模型   E2E测试   K8S部署   MCP自动
+  访谈纪要    代码模板       TDD 循环      Review    Playwright  触发合并  发通知
+  需求文档    技术规范
+  原型链接
+`
+
+二、需求阶段：如何让需求 AI 友好
+
+2.1 需求规格模板必须包含的内容
+
+BA 或产品经理给的需求文档必须包含以下 4 个关键部分：
+
+业务背景：为什么做这个需求
+字段清单：所有业务字段的类型、默认值、业务规则（避免只给原型图让 AI 去猜）
+原型链接：Figma 图等设计稿的链接（AI 可通过 MCP 读取 Figma）
+业务规则：按条拆分，例如：
+   - 订单号生成规则
+   - 发货规则
+   - 状态转换规则
+
+2.2 需求颗粒度的判断标准
+
+不要用 Story 拆分需求（一个人增产改查拆成 4 个 story 对 AI 来说信息量不够）。
+
+正确做法：一个模块一个文档，判断颗粒度的标准是：
+是否有独立的表结构
+是否可以单独上线
+
+2.3 新建需求 vs 变更需求
+
+新建需求：告诉 AI 有多少表、多少页面、多少功能操作 → AI 生成完整模块
+
+变更需求（重要）：
+必须用标签标注变更类型：[+字段] [-字段] [修改字段]
+不要把最终完整状态给 AI，因为 AI 需要对比现有代码 → 浪费大量 Token 且效果差
+示例：
+
+`markdown
+订单模块变更需求
+
+新增内容 [+]
+新增字段：order_type（订单类型，枚举值：NORMAL, VIP, B2B）
+
+修改内容 [~]
+修改字段：shipping_address 最大长度从 200 改为 500
+
+删除内容 [-]
+删除字段：legacy_flag（已废弃）
+`
+
+2.4 用 Obsidian 搭建知识库给 AI 做上下文
+
+将所有需求规格、技术规格都放到知识库中，用 Obsidian + Markdown 管理：
+
+用浏览器插件一键将网页转成 Markdown 并保存图片本地
+用 backlink 功能做上下文关联
+AI 通过读取这个知识库获得长期记忆 → "Single source of truth"
+
+三、技术规格阶段：技术方案设计
+
+3.1 技术规格必须包含的内容
+
+技术规格是开发的核心输入，必须包含以下 5 个部分：
+
+| 内容 | 工具/格式 | 说明 |
+|------|----------|------|
+| 领域模型 | PlantUML / Mermaid | 代码化表达，便于 AI 理解 |
+| 数据库设计 | DBML / Flyway 脚本 | 不要让 AI 直接操作数据库，用版本化的 Flyway 脚本 |
+| API 定义 | OpenAPI / Markdown | 后端写完 API 后输出 API 文档给前端 |
+| 时序图 | Mermaid | 复杂流程需要时序图 |
+| 专项设计 | Markdown | 权限、事务、缓存等专项内容 |
+
+重要教训：不要给 AI 写数据库的写权限，曾经因为 AI 动不动修改数据库导致多人操作冲突。把写权限关掉，让 AI 生成 Flyway 脚本，本地测试时让 Flyway 跑。
+
+3.2 DSL 驱动的技术规格
+
+用领域特定语言（DSL）来驱动技术规格：
+领域模型用 PlantUML
+数据库用 DBML
+API 用 OpenAPI
+这些 DSL 都可以通过代码生成 → 保证前后端一致性
+
+这实际上就是模型驱动架构（Model-Driven Architecture），当团队从零开始全新的 AI 项目时，这种严格的检查和约束更容易建立。
+
+四、打样工程：AI 友好的代码框架
+
+4.1 什么是打样工程
+
+打样工程（Seed Project）是一个预先定义好的代码框架模板，包含：
+每层的类名和职责定义
+代码规范和最佳实践
+依赖配置和目录结构
+
+4.2 打样工程的作用
+
+AI 生成代码风格一致：所有 AI 都基于同一个框架生成代码
+减少重复代码：AI 会复用框架中的组件而不是重复写
+降低认知负担：AI 不需要每次理解项目结构
+
+4.3 如何创建打样工程
+
+从旧项目中蒸馏出一个干净的新项目骨架
+定义每层职责：Controller → Service → Repository → Entity
+定义类命名规范和包结构
+放入 Git 仓库供团队共享
+
+五、开发阶段：让 AI 听话写出统一风格的代码
+
+5.1 用 RAG（检索增强生成）提供上下文
+
+将技术规格、代码规范、历史决策等信息放到代码仓库的 /docs 或 /book 目录下，AI 通过检索这些文档获得上下文：
+
+`markdown
+/my-project
+  /book
+    /requirements      # 需求规格
+    /specifications     # 技术规格
+    /api-docs          # API 文档
+  /src
+  /skills
+  /mcp
+`
+
+5.2 多任务同步开发：Worktree 的使用
+
+Git Worktree 可以把分支映射成目录，实现多任务并行：
+
+`bash
+创建多个工作目录
+git worktree add ../feature-order feature/order
+git worktree add ../feature-user feature/user
+
+在不同目录下同时工作，做完后合并
+`
+
+但要注意：
+多人同时操作多人工作时，版本管理会比较痛苦
+建议提前把规格设计好，让 AI 慢慢跑，而不是同时开太多任务
+
+5.3 不要让 AI 边写代码边做设计
+
+用 rapper5 的思路：Discovery/Design 和 Coding 分两个阶段。
+先做探索性设计，让不同 AI 模型（GPT、Claude、Gemini）各自给出方案
+选定方案后，再激活 Coding 角色专职写代码
+切换角色时重置上下文，避免 AI 注意力分散
+
+六、测试阶段：AI 写代码形成闭环的核心
+
+6.1 为什么测试是 AI 编程的命脉
+
+"没有 API 测试和单元测试，无法形成 AI 写代码的闭环。"
+
+AI 生成代码后必须能自我验证，否则：
+人工验证效率极低
+AI 无法发现自己的问题
+团队无法真正提效
+
+6.2 测试策略（3 层）
+
+| 测试类型 | 工具 | 驱动方式 |
+|----------|------|----------|
+| 单元测试 | JUnit / pytest | TDD：先写测试让 AI 失败，再写实现 |
+| API 测试 | REST Assured / Newman | 自动化回归，可直接卡 90%+ 覆盖率 |
+| E2E 测试 | Playwright（推荐，替代了 Selenium） | 上线前 80% 的 case 回归覆盖 |
+
+6.3 TDD 循环（SuperPower 的工作方式）
+
+让 AI 先写 API 测试/单元测试
+AI 运行测试 → 失败
+AI 再写实现代码
+AI 自动运行测试验证 → 通过
+
+效果：单元测试可达 100% 覆盖率，API 测试可达 90%+ 覆盖率。
+
+6.4 AI 写测试解决假阳性问题
+
+有时候 AI 为了让测试通过，会伪造测试逻辑。解决方案：
+TDD 先写测试：先让测试失败，再让 AI 写实现
+交叉验证：用不同的 AI 模型互相 review 代码和测试
+
+6.5 测试用例的管理
+
+测试用例直接放到代码仓库中：
+单元测试：跟随代码模块
+API 测试：放在 /test/api 目录
+E2E 测试：用 TypeScript + Playwright，放在代码仓库根目录（或与前端项目同仓库）
+
+七、Review 阶段：AI 辅助 Code Review
+
+7.1 多种 Review 方式
+
+工具扫描：SonarQube 等静态分析工具 + AI 自动修复
+AI Review：用另一个 AI 模型做交叉 review（换模型做 review 是常用技巧）
+Agent 自动触发：在 PR 阶段自动触发 Review Agent
+
+7.2 AI Review 的问题与解决方案
+
+问题：AI Review 总是会提改进建议，哪怕没有明显问题（因为你的 prompt 让它提问题）。
+
+解决方案：
+设置阈值：达到一定级别才提问题，否则不输出
+让 AI 只关注 bug 和逻辑错误，不过度关注风格问题
+用团队的架构规约来约束 Review 标准
+
+7.3 不同场景的 Review 策略
+
+全新项目（AI 100% 生成）：可以用最严格的规则，AI 写完直接修
+混合项目（人 + AI）：可能存在历史遗留问题，Review 结果噪音多，建议从新模块开始逐步规范
+跨系统场景：AI 容易犯错（尤其涉及 3-5 个系统的交互），建议收敛到单个仓库处理
+
+经验：跨系统时 AI 犯错误概率高达 70-80%，核心原因是缺少完整的系统间关系和业务规则上下文。
+
+八、工具链：AI 编程工具全景
+
+8.1 三类 AI 编程工具
+
+| 类型 | 代表工具 | 特点 |
+|------|----------|------|
+| 命令行 CLI | Claude Code, OpenAI Codex | 适合快速操作、脚本化 |
+| IDE 集成 | Cursor, Windsurf, VS Code AI | 适合日常开发，界面友好 |
+| 辅助插件 | SuperPower（推荐个人）, Copilot | 按需使用 |
+
+8.2 常用 MCP（Model Context Protocol）
+
+| MCP | 用途 |
+|-----|------|
+| 数据库 MCP | 操作数据库（注意：只读，写权限建议关闭） |
+| Figma MCP | 读取设计稿 |
+| Jira MCP | 管理工单 |
+| Git MCP | 代码提交、PR 操作 |
+
+8.3 Skills 体系
+
+Skills = 一段提示词 + 模板 + 脚本，用于描述工作方法。
+
+把打样工程的初始化做成 Skill
+把团队规范做成 Skills
+Skills 放到代码仓库中共享
+
+重要观点：
+"现在 AI 理解力已经很强大，不需要把规范落实为非常固定的格式，只要表达清楚信息、强调重点即可。"
+
+主流 Skill 框架：
+SuperPower：内置大量 Skills，开箱即用，适合个人
+Claude Agent（hermes）：自动基于对话生成和优化 Skills
+MCP：工具调用协议
+
+8.4 为什么不推荐 SDD 框架
+
+SDD（Scenario-Driven Development）框架本身很好，但落地难度在于团队共识：
+
+需要团队所有人按照相同流程工作
+现实团队中阻力很大（不是不愿意用，是习惯改不了）
+SuperPower 对个人很好用，但团队级很难推广
+
+结论：与其强推 SDD 框架，不如团队自己定义一套 Roos + Skills + MCP 的组合。
+
+九、架构型思考：未来趋势
+
+9.1 Agent Code 的趋势
+
+未来必然会出现 "Agent Code" 的概念——把整个团队的所有产物（需求、规格、规范、测试）全部代码化，放到代码仓库中统一管理：
+
+`markdown
+/.agent
+  /skills          # 工作方法
+  /mcp             # 工具配置
+  /templates       # 模板
+  /rules           # 规范
+  /docs            # 文档
+`
+
+所有 AI 工具（SuperPower、Claude Code 等）安装时都从代码库读取配置，实现极致高效。
+
+9.2 多 Agent 协调的挑战
+
+当前多 Agent 框架（如 CrewAI、AutoGen）还处于早期阶段：
+缺少程序级别的精确校验（不能完全依赖 AI 判断）
+Agent 与代码之间的交互需要程序驱动而非纯 AI 驱动
+可能需要自己写 workflow 调度器
+
+9.3 共识是第一要务
+
+"工具是玩人的，为了获得团队的共识。"
+
+大公司之所以比小公司/创业公司更难推进 AI 编程变革，是因为：
+习惯难以改变
+团队文化难以调整
+需要从上到下的强力推动
+
+十、团队实践建议
+
+10.1 渐进式落地路线
+
+单人验证阶段：选择一个简单项目，用 SuperPower + TDD 验证 AI 编程效率
+规范建立阶段：定义技术规格模板、代码规范、打样工程
+团队推广阶段：用 Skills 标准化工作方法，逐步让团队接受
+自动化阶段：打通从需求到部署的全流程，实现"代码即一切"
+
+10.2 技术经理的核心职责
+
+定义 AI 友好的需求规格模板 → 推动 BA/产品接受
+建立打样工程和代码规范 → 控制代码质量下限
+推动测试文化 → 这是专业和非专业软件公司的分界线
+构建团队共识 → 这是最难也是最重要的事
+
+10.3 避坑指南
+
+不要让 AI 直接写数据库：用 Flyway 脚本版本化管理
+不要拆分过于细小的需求：一个模块一个文档
+变更需求一定要标注变更类型：不要给完整状态
+不要让 AI 同时做设计和代码：分阶段，用不同角色
+不要完全依赖 AI Review：用规则约束、AI + 人工结合
+
+十一、观众反馈与补充
+
+华为 CodeArts Agent：带有规范驱动开发模式，可以参考
+Obsidian + Opal：适合做 Markdown 知识库管理，手机和电脑同步，适合在外也能用手机+终端工作
+看板式 AI 协同：所有需求、设计、任务全部看板化，共享给团队成员
+跨 Agent 通信：契约文件（如 OpenAPI JSON）放到共享目录，前后端各自读取 → 避免前端改完后端不知道的问题
+sonarlint 本地扫描 + AI 自动修复：在 pre-commit 阶段触发静态扫描，AI 自动修复代码风格问题，效果很好
+
+──────────────────────────────
+Generated by MilkyAi@Bilibili: https://space.bilibili.com/3461574540921489
\ No newline at end of file
diff --git a/InBox/milky_BV1i77X6pE1C.md b/InBox/milky_BV1i77X6pE1C.md
new file mode 100644
index 0000000..8cc5951
--- /dev/null
+++ b/InBox/milky_BV1i77X6pE1C.md
@@ -0,0 +1,192 @@
+---
+title: "[Milky] 为您整理《Shopify：内部 Agent， 为什么不准员工私聊？——AI native组织要的不是个人提效，是组织自进化》笔记 | BV1i77X6pE1C"
+source: "milky@4ueo.com"
+date: 2026-06-09 10:48
+tags: [milky, bilibili, notes]
+email_id: 2054
+---
+
+Milky 为您整理了《Shopify：内部 Agent， 为什么不准员工私聊？——AI native组织要的不是个人提效，是组织自进化》 | BV1i77X6pE1C 笔记。
+
+Shopify 内部 Agent River：为什么不准员工私聊？
+
+核心观点
+
+AI-native 组织的门槛不是个人更快，而是组织能从经验中学习、能自进化。
+
+单纯给员工配备私人 AI Agent，可能让每个人变快，但组织本身没有进化。
+
+
+问题背景：企业对 AI 的常见误区
+
+误区做法
+
+给每个员工开 AI 账号，配一个自己的 Agent，让他跑在：
+
+本地终端
+编辑器私人对话框
+私聊窗口里
+
+效果
+
+查问题更快
+改代码更快
+跑测试更快
+
+真正的门槛
+
+更硬的问题是：组织能不能从这些 AI 工作里学习？
+
+能否把一次排查、一次修复、一次好判断，变成后面所有人和所有 Agent 都能继承的经验？
+
+
+核心对比：私人 Agent 的天花板
+
+| 维度 | 私人 Agent | 公开 Agent（River） |
+|------|-----------|---------------------|
+| 服务范围 | 键盘前那个人 | 整个团队 |
+| 上下文来源 | 单人输入 | 多人补充 |
+| 经验沉淀 | 个人日志 | 组织语料 |
+| 复现性 | 低（过程不可见） | 高（可搜索、复用） |
+| 学习能力 | Agent 之间互相学不到 | 团队协作促进 Agent 进化 |
+
+私人 Agent 的局限性
+
+以一次排查偶发失败测试为例：
+
+你昨天怎么定位问题？
+中间错了哪些方向？
+最后是哪条线索把问题收住？
+
+这些问题即使留在日志里，也只是事后材料：
+
+不会天然变成多人协作现场
+别的工程师不会在过程中看到
+不会有人顺手补一个约束
+下一次类似情况，不会自动从这条路径开始
+
+
+River 的设计选择
+
+基本工作方式
+
+River 是 Shopify 内部 Slack 里的 AI Agent：
+
+员工不在私聊窗口找他，要到内部公开频道里 @ 他
+River 会执行：读代码、跑测试、开 PR、查数据仓库、看生产链路记录
+必要时，River 还会反驳他认为不好的计划
+
+硬性产品约束
+
+`
+只支持公开频道工作，不支持一对一私聊
+`
+
+每一次和 River 的对话，都会变成一条 Slack 线程记录，默认对 Shopify 内部员工可见。
+
+注：这里的"公开"指 Shopify 内部 Slack 范围内可见，不是互联网公开。
+
+
+公开线程的工作机制
+
+典型场景
+
+`
+工程师 A 在频道提问
+         ↓
+River 开始工作：读文件、跑查询、贴出部分发现
+         ↓
+工程师 B 看到（通过频道链接或被人拉进来）
+         ↓
+B 补一句关键约束：
+   - "这个表不能这样查"
+   - "这个服务刚迁移过"
+   - "这个测试以前失败过，原因可能不在这里"
+   - "这个方案会影响另一个团队"
+         ↓
+River 吸收新上下文，继续往下查
+`
+
+公开 vs 私人的关键差别
+
+私人对话：AI 多数只继承一个人的上下文
+公开线程：AI 进入的是一个多人协作现场
+
+
+组织学习机制：语料挖掘与回写
+
+公开线程记录会形成一套可挖掘的组织语料，Shopify 会：
+
+挖掘反复出现的模式
+把这些模式回写到 River 的：
+   - 技能（Skills）
+   - 提示词（Prompts）
+   - 默认动作（Default Actions）
+
+具体沉淀内容
+
+| 沉淀内容 | 说明 |
+|---------|------|
+| 排查路径 | 哪些排查路径有效 |
+| 工程约束 | 哪些工程约束应该默认带上 |
+| 提示词/技能 | 哪些提示词和技能动作可以沉淀下来 |
+
+核心机制
+
+`
+一个人硬啃出来的修复办法 → 下一个人的起点
+一个线程里反复出现的约束 → River 以后更容易带上的上下文
+`
+
+一次好的排查，不再只是某个人和某个 Agent 的私有经历，而是开始教会后面的线程。
+
+
+边界与限制
+
+不等于禁止所有私聊
+
+企业不是不能有任何 AI 私聊，而是 River 这个 Agent 坚持不做私聊入口。
+
+需要边界控制的场景
+
+以下敏感问题仍然要有边界：
+
+权限相关
+安全相关
+人事相关
+法务相关
+
+River 的定位
+
+River 处理的是那些值得被组织记住的工作，而不是所有对话。
+
+
+核心启示
+
+对老板和技术负责人的问题清单
+
+部署 AI Agent 时，不仅要问：
+
+❌ 员工有没有 Agent？
+❌ 对话日志能不能回收？
+❌ 个人效率有没有提升？
+
+更要问：
+
+✅ 这些 Agent 对话会不会教会后面的线程？
+✅ 员工用 AI 解决问题的过程，是一份后台日志，还是一个团队能参与、能接力、能复用的工作现场？
+
+结论
+
+| 类型 | 结果 |
+|------|------|
+| 如果只是后台日志 | 一堆分散的个人提效，每个人都快了一点，但组织没有变聪明 |
+| 如果是可协作的工作现场 | 组织从每次 AI 工作中学习，实现自进化 |
+
+金句
+
+私人 Agent 的天花板是键盘前那个人。
+公开 Agent 的价值是让后面的线程不从零开始。
+
+──────────────────────────────
+Generated by MilkyAi@Bilibili: https://space.bilibili.com/3461574540921489
\ No newline at end of file
diff --git a/InBox/milky_BV1mZV76eEPC.md b/InBox/milky_BV1mZV76eEPC.md
new file mode 100644
index 0000000..2d6f56a
--- /dev/null
+++ b/InBox/milky_BV1mZV76eEPC.md
@@ -0,0 +1,181 @@
+---
+title: "[Milky] 为您整理《2026-05-30 SDD 规格驱动落地，文档管理策略》笔记 | BV1mZV76eEPC"
+source: "milky@4ueo.com"
+date: 2026-06-09 10:48
+tags: [milky, bilibili, notes]
+email_id: 2044
+---
+
+Milky 为您整理了《2026-05-30 SDD 规格驱动落地，文档管理策略》 | BV1mZV76eEPC 笔记。
+
+SDD 规格驱动落地：文档管理策略
+
+研讨会背景与目的
+
+本次分享是 AI 编程相关话题的延续，主要聚焦 SDD（Spec-Driven Development，规格驱动开发） 的文档管理策略。
+
+研讨会机制
+
+目的：让参会者能够参与达成社区共识，分享各公司在 AI 编程实践中的经验
+形式：咨询师分享观察到的公司实现方案、架构设计、系统设计等内容
+价值：对个人和团队帮助都非常大，通过集体讨论形成共识
+
+特别感谢卡尼克老哥在研讨会期间贡献了大量分享思想，受益颇多。
+
+
+AI 编程发展历程回顾
+
+时间线概览
+
+| 时间 | 分享内容 | 核心概念 |
+|------|----------|----------|
+| 2025年6月 | 早期 AI 编程实践 | DPER5 方法论 |
+| 后续 | MCP 等工具整合 | MCP、Scales |
+| 5月9日 | Plan 和 Build 模式 | 新因子（吸引子）概念 |
+| 本次 | SDD 文档管理策略 | 规格驱动落地 |
+
+
+DPER5 方法论
+
+核心思想
+
+DPER5 将软件工程中使用 AI 进行开发的过程分为 5 个弱阶段（Weak Stages）：
+
+`
+Discover → Plan → Execute → Review → Refine
+   ↓         ↓        ↓         ↓        ↓
+ 发现      规划      执行      评审      优化
+`
+
+阶段特性
+
+不同阶段 AI 会按照不同的模式运行
+例如在 Design 模式或 Discover 模式下，AI 不会修改代码
+这种分阶段约束是驯服 AI 的简单有效方法
+
+实践应用
+
+在早期阶段（2025年），演讲者已经在公司内部领先应用
+采用 Design → Plan → Execute 的流程驱动开发
+该方法使用了较长时间，有效规范了 AI 辅助开发流程
+
+
+MCP（Model Context Protocol）工具生态
+
+工具整合
+
+后续随着 MCP 以及相关工具套件的出现，形成了完整的 AI 编程工具生态：
+
+MCP（Model Context Protocol）：模型上下文协议
+Scales：扩展工具
+SDD：规格驱动开发方法论
+
+这些工具被整合到一份 PPT 手册中，作为团队 AI 编程的指南或手册参考。
+
+
+SDD（规格驱动开发）
+
+SDD 的核心模式
+
+SDD 提供了多种工作模式，适用于不同的开发场景：
+
+| 模式 | 适用场景 | AI 行为特征 |
+|------|----------|-------------|
+| Design | 需求分析、架构设计 | 不修改代码，仅提供设计建议 |
+| Discover | 探索发现、方案调研 | 不修改代码，专注于信息收集 |
+| Plan | 规划分解、任务拆解 | 生成实现计划 |
+| Build | 代码实现、具体开发 | 执行代码编写和修改 |
+
+新因子（吸引子）概念
+
+由 countic 大佬在 5月9日的分享中引入：
+
+物理学的概念解释：
+
+在混沌系统中，存在两种震荡反馈的系统
+这种系统最终会收敛到一个稳定状态
+这个收敛点被称为 吸引子（Attractor）
+
+在 AI 编程中的应用：
+
+通过引入新因子，可以引导 AI 的输出趋向于预期的稳定状态
+帮助控制 AI 在复杂任务中的发散性
+实现更可控的 AI 驱动开发流程
+
+
+SDD 文档管理策略
+
+本次分享的核心主题，聚焦于规格驱动开发的文档管理方法
+
+文档在 SDD 中的作用
+
+规格定义：明确需求和设计规范，作为开发的基准
+上下文传递：在不同阶段之间传递上下文信息
+版本控制：记录规格的变更历史
+团队协作：统一团队对需求的理解和实现方式
+
+文档管理最佳实践
+
+（基于 SDD 方法论，文档管理应遵循以下原则）
+
+规格优先：在开发前先完成规格文档的编写
+增量迭代：规格文档随项目进展逐步完善
+双向追溯：规格与实现之间保持可追溯性
+工具集成：将文档管理与 AI 编程工具链整合
+
+
+工具链整合方案
+
+推荐的 AI 编程工具栈
+
+`
+┌─────────────────────────────────────────────────────┐
+│                    规格层 (Spec)                      │
+│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐  │
+│  │   Design    │  │   Discover  │  │    Plan     │  │
+│  └─────────────┘  └─────────────┘  └─────────────┘  │
+├─────────────────────────────────────────────────────┤
+│                    工具层 (Tools)                     │
+│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐  │
+│  │     MCP     │  │   Scales    │  │    SDD     │  │
+│  └─────────────┘  └─────────────┘  └─────────────┘  │
+├─────────────────────────────────────────────────────┤
+│                    执行层 (Execution)                │
+│  ┌─────────────┐  ┌─────────────┐                    │
+│  │    Build    │  │   Review    │                    │
+│  └─────────────┘  └─────────────┘                    │
+└─────────────────────────────────────────────────────┘
+`
+
+MCP 的核心功能
+
+提供标准化的上下文协议
+实现 AI 与外部工具的无缝集成
+支持多工具协同工作
+
+
+社区贡献者致谢
+
+| 贡献者 | 贡献内容 |
+|--------|----------|
+| 卡尼克 | 大量分享思想，研讨会核心参与者 |
+| countic | 引入新因子（吸引子）概念，分享 Plan/Build 模式 |
+| 少个分号 | SDD 方法论整理，工具链整合，文档管理策略分享 |
+
+
+后续话题预告
+
+本次分享的议程安排：
+
+SDD 文档管理策略（当前内容）
+AIGC 模板相关话题（由卡尼克老哥分享）
+
+
+参考资源
+
+本次分享的 PPT 资料（可作为团队 AI 编程手册/指南）
+搜索关键词：AI编程、MCP、SDD、DPER5、规格驱动开发
+相关标签：人工智能、规格驱动开发、AI编程
+
+──────────────────────────────
+Generated by MilkyAi@Bilibili: https://space.bilibili.com/3461574540921489
\ No newline at end of file
diff --git a/InBox/milky_BV1p9QnBtEMq.md b/InBox/milky_BV1p9QnBtEMq.md
new file mode 100644
index 0000000..7cd974c
--- /dev/null
+++ b/InBox/milky_BV1p9QnBtEMq.md
@@ -0,0 +1,273 @@
+---
+title: "[Milky] 为您整理《让AI真正读懂证据间的因果：深度验证框架解决逻辑断层，实现92.0%平衡准确率》笔记 | BV1p9QnBtEMq"
+source: "milky@4ueo.com"
+date: 2026-06-09 10:48
+tags: [milky, bilibili, notes]
+email_id: 1987
+---
+
+Milky 为您整理了《让AI真正读懂证据间的因果：深度验证框架解决逻辑断层，实现92.0%平衡准确率》| BV1p9QnBtEMq 笔记。
+
+病例驱动证据验证框架：从表面匹配到可验证推理
+
+研究背景与问题
+
+当前 AI 证据引用的核心缺陷
+
+现有 AI 模型在引用外部证据时存在严重的逻辑断层问题：
+
+| 缺陷类型 | 具体表现 |
+|---------|---------|
+| 表面匹配依赖 | 过度依赖文本相似度，用文字重合度"走捷径" |
+| 逻辑断层 | 未真正理解证据与主张之间的因果关系 |
+| 虚假支撑 | 生成看起来合理但缺乏逻辑支撑的回答 |
+| 高风险隐患 | 在医疗、法律等领域可能导致致命错误 |
+
+问题本质
+
+模型并未真正"看懂"证据，而是利用文本重合度生成看似合理的回答。这种虚假的逻辑支撑在专业领域非常危险。
+
+
+解决方案：三位一体验证框架
+
+框架架构
+
+研究团队提出病例驱动验证框架（Case-Driven Evidence Verification），核心是三位一体结构：
+
+`
+┌─────────────────────────────────────────────────────┐
+│                    验证任务                          │
+│            （转化为严苛的判断题）                      │
+├─────────────────────────────────────────────────────┤
+│                                                     │
+│   ┌─────────┐    ┌──────────────┐    ┌───────────┐ │
+│   │ 具体情境  │ +  │   外部证据    │ + │ 结构化主张  │ │
+│   │  CASE   │    │   EVIDENCE   │    │   CLAIM   │ │
+│   └─────────┘    └──────────────┘    └───────────┘ │
+│                                                     │
+│                    ↓                                │
+│           模型输出裁定结果 VERDICT                   │
+│           （支持 / 不支持）                          │
+└─────────────────────────────────────────────────────┘
+`
+
+工作机制
+
+输入三元组：同时输入具体情境（Case）、外部证据（Evidence）和结构化主张（Claim）
+判断题模式：将任务转化为判断题，强制模型输出明确裁定
+逻辑验证：验证证据在当前情境下是否真实支撑主张
+
+
+自动化数据生成方法
+
+核心创新
+
+零人工标注成本的自动化数据生成流水线，整合两大数据源：
+
+| 数据源 | 用途 |
+|-------|------|
+| MIMIC-CXR（真实影像报告） | 提取病例状态（Case） |
+| Radiopaedia（医学知识库） | 抽取数万条证据（Evidence） |
+
+通过 Refire Core 逻辑规则智能重组，自动映射成数十万条正负样本。
+
+四类训练样本
+
+| 样本类型 | 特征 | 作用 |
+|---------|------|------|
+| 正样本 | 明确支持主张 | 学习正确关联模式 |
+| 错误状态陷阱 | 高度相关但结论相反 | 封堵关键词匹配捷径 |
+| 困难负样本 | 因果关系复杂 | 强化深层理解 |
+| 简单负样本 | 明显不支持 | 基线学习 |
+
+反事实负样本（核心突破）
+
+语义特征：与主张极度接近，包含所有核心关键词
+逻辑特征：由于病例特征差异，推导方向与主张完全相反
+占比：25% 的数据集专门用于封堵关键词匹配捷径
+
+目的：逼迫模型放弃表面关联，深入理解文字背后的逻辑因果。
+
+
+实验设计与结果
+
+关键对比实验
+
+病例深度关联的效果
+
+| 配置 | AUPRC | 平衡准确率 |
+|-----|-------|-----------|
+| 纯证据验证 | 35.1% | — |
+| 深度关联验证 | 87.8% | 92.0% |
+
+结论：单纯堆砌资料不能让 AI 变聪明，结合具体情境才能实现性能跨越。
+
+关键词陷阱测试
+
+场景：病例明确显示无胸腔积液，面对包含相同术语的干扰证据
+
+| 模型 | 支持率 |
+|-----|-------|
+| 普通 AI | 99.1% |
+| 深度验证模型 | 0.000% |
+
+结论：框架能有效识破伪装，不再盲目信任语义相近但逻辑无关的信息。
+
+物理干预测试（检验推理真实性）
+
+三种极端条件：
+
+| 测试条件 | 描述 | AUPRC | F1 分数 |
+|---------|------|-------|---------|
+| 正常关联证据 | 基线测试 | 87.8% | 高 |
+| 清空证据 | 切断所有参考资料 | 大幅下降 | 大幅下降 |
+| 交换证据 | 张冠李戴的专业文本 | 21.7% | 显著缩水 |
+
+结论：性能急剧崩溃证明模型高度依赖正确的外部证据，而非死记答案。
+
+证据数量与性能关系
+
+| 证据数量 | AUROC |
+|---------|-------|
+| 1 句 | 较低 |
+| 2 句 | 97.4%（巅峰） |
+| 10 句 | 基本持平 |
+
+关键发现：模型不需要翻阅数百页文档，只需抓准最关键的两句信息就能实现满血性能。过度堆砌资料反而引入背景干扰。
+
+全维度性能对比
+
+| 方法 | AUROC | AUPRC | BRI Score |
+|-----|-------|-------|-----------|
+| 纯情境推断 | 59.90% | — | 高 |
+| 纯证据验证 | — | 35.11% | 高 |
+| 三位一体深度关联 | 97.43% | 87.8% | 0.060 |
+
+
+泛化能力验证
+
+陌生知识测试（Held-out Content）
+
+使用从未参与训练的全新医学百科文章：
+
+| 指标 | 结果 |
+|-----|------|
+| AUROC | 97.2% |
+| F1 分数 | 77.9% |
+
+结论：模型学习到的是通用验证逻辑，而非对特定教材句式的死记硬背。
+
+跨数据集迁移
+
+将基于 MIMIC-CXR 训练的模型直接空降到 CheXpert Plus 数据集（6万+患者）：
+
+| 指标 | 结果 |
+|-----|------|
+| AUROC | 93.46% |
+| 平衡准确率 | 87.45% |
+
+结论：即便面对截然不同的书写风格和病例分布，模型验证能力依然在线，展现极强落地适应性。
+
+底层模型对比
+
+| 模型 | 参数量 | AUPRC | 特点 |
+|-----|-------|-------|------|
+| DeBERTa-v3-large | 3.95亿 | 87.8% | 综合最强，面对未知证据最稳 |
+| FlanT5-large | — | 次之 | 经典大模型 |
+| RoBERTa-large | — | — | 经典 baseline |
+
+结论：更现代的特征提取器能更敏锐地锁定微小的语义偏差。
+
+
+应用场景
+
+临床问答护城河
+
+`
+检索器 → 生成器 → 【验证框架】 → 医生
+                              ↓
+                        输出置信度分数
+                        拦截 99% 幻觉主张
+`
+
+作为最后一道交叉质证
+有效拦截无依据方案
+辅助医生做出更稳健的决策
+
+自动化医疗报告审核
+
+自动提取结构化结论
+与原始影像发现及医学标准逐一核对
+实时标注逻辑冲突，提示人工复核
+减轻高年资医生审核负担
+杜绝因疲劳引发的关键性疏漏
+
+跨领域泛化
+
+| 领域 | 应用 |
+|-----|------|
+| 法律合规 | 核实法条是否真实适用于案件事实 |
+| 科研验证 | 自动检查实验引用是否存在张冠李戴 |
+| 企业知识库 | 核对工单与操作手册，拒绝随意发挥 |
+
+
+范式跃迁：从 RAG 到 VAG
+
+| 范式 | 特征 | 核心区别 |
+|-----|------|---------|
+| RAG（检索增强生成） | 只要检索文本看起来相似，就强行作为答案参考 | 区分相关性与支撑性 |
+| VAG（验证增强生成） | 只有存在明确逻辑因果的文本才被认定为有效证据 | 追求确凿性 |
+
+本质转变：AI 从松散的文本拼接机器 → 严谨的逻辑推演中枢
+
+
+当前局限与未来路线
+
+技术边界
+
+| 局限类型 | 具体问题 |
+|---------|---------|
+| 泛化损耗 | 面对截然不同的新证据时，AUPRC 指标仍会产生客观衰减 |
+| 多状态扩展 | 目前主要验证二元主张，未来需向复杂多元连续图谱扩展 |
+| 端到端噪声 | 引入全网实时检索后，对模型抗干扰能力提出更高要求 |
+
+演进路线
+
+`
+第一阶段（已完成）     第二阶段（进行中）     第三阶段（愿景）
+    ↓                     ↓                    ↓
+三位一体验证框架  →  端到端动态检索  →  人类专家深度对齐
+                        +                      +
+                  非结构化长文本         证据链自我修剪
+                  高噪声环境            自主思考 Agents
+`
+
+
+核心结论
+
+| 指标 | 结果 | 意义 |
+|-----|------|------|
+| AUPRC | 87.8%（提升 52.6%） | 跨越性性能提升 |
+| 平衡准确率 | 92.0% | 高可靠性 |
+| BRI Score | 0.060 | 极低预测误差 |
+
+核心启示：真正的智能不仅在于调取知识，更在于懂得如何对证据负责。
+
+
+术语表
+
+| 术语 | 全称 | 解释 |
+|-----|------|------|
+| AUPRC | Area Under Precision-Recall Curve | 精确率-召回率曲线下面积，衡量不平衡数据集性能 |
+| AUROC | Area Under Receiver Operating Characteristic Curve | ROC 曲线下面积，衡量分类器区分能力 |
+| BRI Score | Brier Score | 预测误差的均方误差，越低越准确 |
+| RAG | Retrieval-Augmented Generation | 检索增强生成 |
+| VAG | Verification-Augmented Generation | 验证增强生成 |
+| DeBERTa | Decoding-enhanced BERT with disentangled attention | 更现代的预训练语言模型架构 |
+| MIMIC-CXR | Medical Information Mart for Chest X-ray | 公开胸部 X 光影像数据集 |
+| 反事实负样本 | Counterfactual Negative Samples | 语义相似但逻辑结论相反的样本，用于测试模型是否真正理解因果关系 |
+| CheXpert Plus | — | 斯坦福大学胸部 X 光数据集 |
+| Refire Core | — | 逻辑规则引擎，用于自动构建训练样本 |
+
+──────────────────────────────
+— Milky 视频总结助手
\ No newline at end of file
diff --git a/InBox/milky_BV1tJwKzDE8x.md b/InBox/milky_BV1tJwKzDE8x.md
new file mode 100644
index 0000000..4b81004
--- /dev/null
+++ b/InBox/milky_BV1tJwKzDE8x.md
@@ -0,0 +1,320 @@
+---
+title: "[Milky] 为您整理《【AI翻译】别再自己钻研Claude技巧了，Autoresearch帮你搞定》笔记 | BV1tJwKzDE8x"
+source: "milky@4ueo.com"
+date: 2026-06-09 10:48
+tags: [milky, bilibili, notes]
+email_id: 1983
+---
+
+Milky 为您整理了《【AI翻译】别再自己钻研Claude技巧了，Autoresearch帮你搞定》| BV1tJwKzDE8x 笔记。
+
+AutoResearch 自动优化 Claude Code Skills 完整指南
+
+目录
+
+核心概念
+为什么需要自动研究
+AutoResearch 仓库解析
+自动研究的三个要素
+评估设计原则
+实战演示流程
+演示结果
+最佳实践与注意事项
+
+
+核心概念
+
+Claude Code Skills 现状
+
+Claude Code Skills（云代码技能）是用于扩展 Claude Code 能力的提示词文件，但存在稳定性问题：
+
+| 指标 | 比例 |
+|------|------|
+| 运行技能得到预期输出 | ~70% |
+| 运行技能输出垃圾结果 | ~30% |
+
+什么是 AutoResearch
+
+AutoResearch 是由 Andre Karpathy（OpenAI 创始成员、前特斯拉 AI 负责人）发布的一个 GitHub 仓库，核心功能是让一组 AI 智能体能够自主优化某个流程。
+
+原仓库地址：
+`
+https://github.com/karpathy/auto-research
+`
+
+
+AutoResearch 仓库解析
+
+该仓库刻意设计得非常精简，只有三个重要文件：
+
+文件结构
+
+`
+auto-research/
+├── prepare.py      # 机器学习专用（训练分词器等），与技能优化无关
+├── train.py        # 核心文件，相当于你的 skill.md
+└── program.py      # 核心文件，相当于你的智能体
+`
+
+工作原理类比
+
+| AutoResearch 组件 | 对应内容 |
+|-------------------|----------|
+| train.py | 你的 skill.md（要优化的技能提示词） |
+| program.py | 你的智能体（负责改进技能） |
+
+优化流程
+
+`
+给智能体（program.py）一个高级指令
+智能体运行技能（train.py），根据评估标准评分
+智能体判断"这次是否比上次好"
+自动迭代，提示词越来越严密
+每 N 分钟自动运行一次（如每 5 分钟）
+`
+
+
+自动研究的三个要素
+
+要让自动研究工作，你需要准备好：
+
+客观指标（Objective Metric）
+
+一个可量化测量的数字，而不是模糊的感觉描述。
+
+示例：
+
+| 应用场景 | 客观指标 |
+|----------|----------|
+| 网站加载速度 | 毫秒（ms） |
+| 冷邮件活动 | 回复率（%） |
+| Claude Code Skill | 通过率 / 评估分数 |
+
+测量工具（Measurement Tool）
+
+理想情况下应该自动化、可靠，无需人工介入。
+
+示例：
+
+| 应用场景 | 测量工具 |
+|----------|----------|
+| 网站性能 | Google Lighthouse |
+| 冷邮件 | 即时 API 分析 |
+| Skills | 测试套件（智能体编写的自动化测试） |
+
+可改变的东西（Variable to Change）
+
+整个优化的对象：
+
+| 应用场景 | 改变的内容 |
+|----------|------------|
+| 网站优化 | 代码改动 |
+| 冷邮件优化 | 邮件文案 |
+| Skills 优化 | 提示词内容（skill.md 文件） |
+
+
+评估设计原则
+
+为什么需要多次运行评估
+
+AI 输出本质上是数据分布，存在随机性：
+
+`
+运行 20 次技能（生成 20 张图片）
+  ↓
+每次输出都有细微差别
+  ↓
+有些图片相似，有些不同
+  ↓
+必须运行多次，用统计方法评估
+`
+
+评估的三个统计指标
+
+| 指标 | 含义 | 作用 |
+|------|------|------|
+| 众数（Mode） | 出现频率最高的值 | 判断"最常见的结果是什么" |
+| 中位数（Median） | 排序后的中间值 | 判断"大致平均水平" |
+| 平均值（Mean） | 所有分数之和除以次数 | 判断"总体表现" |
+
+二元问题原则（核心要点）
+
+评估应该使用二元的是/否、真/假问题，尽量避免多值评分。
+
+原因： 复合概率导致变异性放大
+
+`
+二元评分：只有 Pass/Fail → 变异性可控
+多值评分（如 1-7 分）→ 每个环节的变异会累积放大
+       ↓
+想象一个漏斗：开始很窄，变异累积后可能差很多
+最终结果可能从 39/40 变成 2/40
+`
+
+多值评分的风险示例：
+如果给模型太多评估点
+模型可能学会"复述每个评估点"来通过测试
+就像不理解材料但能考 100 分的学生
+
+不要过于具体/狭窄
+
+反面示例（过于严格）：
+`
+"确保输出在 X 字以内"
+"确保包含关系符号"
+"确保不包含某些字符"
+`
+
+这会导致模型过度优化评估指标而不是真正提升质量。
+
+
+实战演示流程
+
+演示案例：图表生成器技能优化
+
+步骤一：设置 Claude Code 环境
+
+在 VSCode 或任意编辑器中安装 Claude Code 扩展，设置好开发环境。
+
+步骤二：获取 AutoResearch 仓库
+
+`bash
+将仓库链接提供给智能体
+"Read this: https://github.com/karpathy/auto-research"
+`
+
+步骤三：创建评估标准
+
+将评估标准定义为4 个二元问题：
+
+| # | 评估标准 | 具体要求 |
+|---|----------|----------|
+| 1 | 文字清晰度 | 所有文字是否清晰且语法正确 |
+| 2 | 配色方案 | 是否符合粉彩色、柔和色调（避免霓虹色） |
+| 3 | 布局条理 | 是否从左到右/从上到下有条理（无乱糟糟的气泡和装饰） |
+| 4 | 无数字编号 | 是否没有 "1, 2, 3, 4" 这样的编号 |
+
+步骤四：提供高级指令给智能体
+
+使用自然语言描述任务：
+
+`
+"我想让你用 AutoResearch 库来改进图表生成器技能。
+  
+  该技能的功能是生成约 200 字的脚本。
+  
+  请用上面的仓库中的自动研究方法帮我建立一套改进系统。
+  
+  每次测试请生成 10 个图表。
+  
+  我希望你按回车继续。"
+`
+
+步骤五：明确评分机制
+
+`
+生成 10 张图片
+每个图片用 4 个标准评估
+最高分 = 40 分（10 × 4）
+
+流程：
+生成 10 张图
+用 4 个标准评估所有 10 张
+计算 40 分中的得分
+修改提示词
+再试一次
+选择表现更好的版本
+`
+
+
+演示结果
+
+网站优化案例
+
+| 指标 | 优化前 | 优化后 | 改进 |
+|------|--------|--------|------|
+| 加载时间 | 1100ms | 67ms | 81.3% |
+
+图表生成器技能案例
+
+| 指标 | 第一次测试 | 后续迭代 |
+|------|------------|----------|
+| 评估分数 | 32/40 | 37/40 |
+| 迭代趋势 | 基准 | 持续提升 |
+
+视频效果： 智能体不断让提示词越来越符合预设的粉彩色、可爱图标等规格。
+
+
+最佳实践与注意事项
+
+✅ 推荐做法
+
+使用二元问题评估
+   - 是/否、真/假
+   - 避免 1-10 分等多值评分
+
+保持评估标准简洁
+   - 每个技能 3-5 个核心标准
+   - 太多标准会导致"假通过"
+
+让评估自动化
+   - 编写测试套件
+   - 设置定时循环运行
+
+记录所有变更
+   - 模型尝试的所有改动清单
+   - 可传承给未来的更强模型（GPT-6、Claude 4.0 等）
+
+❌ 避免做法
+
+不要过于具体
+   `
+   ✗ "确保输出在 100 字以内"
+   ✗ "确保包含关系符号"
+   `
+
+不要多值复合评分
+   `
+   ✗ "X 方面打 1-7 分"
+   ✓ "X 方面是否达标：是/否"
+   `
+
+不要只运行一次
+   - 必须多次运行取统计结果
+   - 用众数、中位数判断质量
+
+
+可应用场景扩展
+
+AutoResearch 不仅限于 Skills 优化，可应用领域：
+
+| 领域 | 优化目标 |
+|------|----------|
+| 网站 | 加载速度、SEO |
+| 落地页 | 转化率 |
+| A/B 测试 | 标题、缩略图 |
+| 邮件营销 | 邮件文案、回复率 |
+| 代码 | 性能、架构 |
+| 提示词 | 任何技能或流程 |
+
+
+资源链接
+
+原视频： https://www.youtube.com/watch?v=qKU-e0x2EmE
+AutoResearch 仓库： https://github.com/karpathy/auto-research
+完整 Claude Code 课程： 见 UP 主频道
+
+
+总结
+
+AutoResearch 提供了一种让 AI 自主优化 AI 的方法论。通过：
+
+定义客观指标 → 知道要优化什么
+建立测量工具 → 知道如何量化改进
+提供可变量 → 提示词、代码或文案
+多次运行 + 统计评估 → 确保结果可靠
+
+即使你不是机器学习专家，也可以利用这个框架显著提升 Claude Code Skills 的可靠性和准确性，实现技能的自我进化。
+
+──────────────────────────────
+— Milky 视频总结助手
\ No newline at end of file
diff --git a/InBox/北大Agent新范式_不改模型权重_效果翻倍北大搞出Agent新范式_不改模型权重_效果接近翻倍_BV17y7U6EER5_笔记.md b/InBox/北大Agent新范式_不改模型权重_效果翻倍北大搞出Agent新范式_不改模型权重_效果接近翻倍_BV17y7U6EER5_笔记.md
new file mode 100644
index 0000000..bfc6231
--- /dev/null
+++ b/InBox/北大Agent新范式_不改模型权重_效果翻倍北大搞出Agent新范式_不改模型权重_效果接近翻倍_BV17y7U6EER5_笔记.md
@@ -0,0 +1,156 @@
+# Life Harnessness：北大Agent优化新范式
+
+## 核心发现
+
+传统Agent优化的核心假设被推翻：**Agent的效果并非完全由模型能力决定**。北京大学这篇论文证明，在很多情况下，Agent的失败不是因为模型"笨"，而是因为模型与环境之间的**接口不匹配**。
+
+---
+
+## Agent的本质再定义
+
+传统观点认为：Agent ≈ LLM，能力强则Agent强
+
+论文新观点：Agent是一个**完整的交互循环系统**，包含以下组件：
+
+```
+环境 → 观测 → 运行时系统 → 工具定义 → 动作模型 → 输出动作
+  ↑                                                              ↓
+  ←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
+```
+
+| 组件 | 说明 |
+|------|------|
+| 运行环境 | 环境给观测，定义工具和动作 |
+| 动作执行器 | 模型输出动作，执行器执行 |
+| 反馈循环 | 执行结果反馈回来更新下一步决策 |
+
+**关键洞察**：模型输出相同，结果可能完全不同。整个行为是**模型和运行时环境共同决定**的。
+
+---
+
+## 问题根源：接口层不匹配
+
+传统Agent常见的失败场景：
+
+- 模型不知道API的调用格式
+- 不知道什么动作是合法的
+- 不知道反馈信号是什么意思
+- 不知道什么时候该停止
+
+**传统解决方案**：通过SFT（监督微调）把这些知识灌进模型权重
+
+**新方案思路**：为什么把环境特定的知识硬编码到模型里？这些东西应该在**接口层**处理。
+
+---
+
+## Life Harnessness 框架
+
+### 核心思路
+
+> **不改模型权重，只改运行时接口**
+
+从训练轨迹中学习，把反复出现的交互失败转换成可复用的干预。
+
+### 四个维度的可复用干预
+
+| 维度 | 功能 | 说明 |
+|------|------|------|
+| **环境契约** (Environment Contract) | 告诉模型环境规则 | 明确这个环境中什么能做、什么不能做 |
+| **程序技能** (Program Skill) | 任务分解标准化 | 把复杂任务拆解成标准流程 |
+| **动作实现** (Action Implementation) | 格式转换 | 把模型的高层意图转换成环境能理解的精确格式 |
+| **轨迹调控** (Trajectory Regulation) | 流程控制 | 决定什么时候该回溯、什么时候该停止、什么时候该重试 |
+
+### 核心特征
+
+- **训练后固定**：Harness一旦训练好就固定下来，评估时不再改变
+- **非动态调整**：不是推理时还在动态调整的东西
+- **标准化接口适配层**：类似于给Agent配了一个"经验丰富的项目经理"
+
+---
+
+## 实验结果
+
+### 评估规模
+
+- **7个确定性环境**
+- **18个模型骨干**（从最小到最大全覆盖）
+- **126个模型-环境组合**
+
+### 效果数据
+
+| 指标 | 数值 |
+|------|------|
+| 有提升的组合数 | 116 / 126 |
+| 平均相对提升 | **88.5%** |
+
+> 88.5%是接近翻倍的提升，不是小数点后一位的微弱改进。
+
+### 迁移能力验证
+
+- 使用 **Qwen-34B** 的训练轨迹进化出来的Harness
+- 能直接迁移到其他 **17个模型** 上
+- 从最小到最大的模型全部适用
+
+**关键发现**：这说明Harness抓到的不是某个模型的特性行为，而是**环境本身的结构**。
+
+---
+
+## 范式转变
+
+| 维度 | 旧范式（模型中心） | 新范式（接口中心） |
+|------|-------------------|-------------------|
+| 优化方向 | 调模型：SFT、蒸馏、更大参数 | 调接口：优化运行时适配层 |
+| 适用场景 | Agent不行就调模型 | Agent不行，先看接口是否有问题 |
+| 关系定位 | 互补，非替代 | 互补，非替代 |
+
+---
+
+## 局限性
+
+1. **最适合确定性、规则型的环境**：需要大量创造性、开放性的任务可能效果不明显
+2. **依赖训练轨迹**：需要有足够多的失败案例才能总结干预规则
+3. **干预维度固定**：目前是4个维度，能否扩展到更多类型环境还需验证
+
+---
+
+## 未来发展方向
+
+### 1. 自动发现与进化
+不用人工定义4个维度，让系统自己发现需要什么样的接口适配
+
+### 2. 跨环境迁移
+在一个环境上学到的接口适配，能否用到另一个类似环境
+
+### 3. 协同进化（最具潜力）
+Harness和模型的协同进化，接口层与模型共同进化
+
+---
+
+## 对普通人的意义
+
+### 短期
+- 企业级Agent体验大幅提升
+- "你得用精确话术跟AI说话"的情况越来越少
+- 接口层帮你把意图转换成系统能理解的格式
+
+### 中期
+- Agent开发门槛大幅降低
+- 不需要海量数据去SFT大模型
+- 只要把接口适配做好，中等模型就能有很好的效果
+
+### 长期
+- 可能改变整个AI产业的分工：
+  - **大模型厂商**：负责通用推理能力
+  - **垂直领域厂商**：负责接口适配层
+- 比现在每个公司都训练自己的模型更高效
+- Harness可解释、可审计，解决监管问题
+
+---
+
+## 核心启示
+
+> 不要一遇到问题就想着堆算力、堆参数。有时候真正的突破来自于对问题本身的重新定义。
+>
+> 不是模型不行，可能是我们的接口不行。
+>
+> 换个角度看问题，整个世界都不一样了。
\ No newline at end of file
diff --git a/InBox/让AI真正读懂证据间的因果_深度验证框架解决逻辑断层_实现92.0_平衡准确率_BV1p9QnBtEMq_笔记.md b/InBox/让AI真正读懂证据间的因果_深度验证框架解决逻辑断层_实现92.0_平衡准确率_BV1p9QnBtEMq_笔记.md
new file mode 100644
index 0000000..b52e3b1
--- /dev/null
+++ b/InBox/让AI真正读懂证据间的因果_深度验证框架解决逻辑断层_实现92.0_平衡准确率_BV1p9QnBtEMq_笔记.md
@@ -0,0 +1,269 @@
+# 病例驱动证据验证框架：从表面匹配到可验证推理
+
+## 研究背景与问题
+
+### 当前 AI 证据引用的核心缺陷
+
+现有 AI 模型在引用外部证据时存在严重的逻辑断层问题：
+
+| 缺陷类型 | 具体表现 |
+|---------|---------|
+| **表面匹配依赖** | 过度依赖文本相似度，用文字重合度"走捷径" |
+| **逻辑断层** | 未真正理解证据与主张之间的因果关系 |
+| **虚假支撑** | 生成看起来合理但缺乏逻辑支撑的回答 |
+| **高风险隐患** | 在医疗、法律等领域可能导致致命错误 |
+
+### 问题本质
+
+模型并未真正"看懂"证据，而是利用文本重合度生成看似合理的回答。这种虚假的逻辑支撑在专业领域非常危险。
+
+---
+
+## 解决方案：三位一体验证框架
+
+### 框架架构
+
+研究团队提出**病例驱动验证框架（Case-Driven Evidence Verification）**，核心是三位一体结构：
+
+```
+┌─────────────────────────────────────────────────────┐
+│                    验证任务                          │
+│            （转化为严苛的判断题）                      │
+├─────────────────────────────────────────────────────┤
+│                                                     │
+│   ┌─────────┐    ┌──────────────┐    ┌───────────┐ │
+│   │ 具体情境  │ +  │   外部证据    │ + │ 结构化主张  │ │
+│   │  CASE   │    │   EVIDENCE   │    │   CLAIM   │ │
+│   └─────────┘    └──────────────┘    └───────────┘ │
+│                                                     │
+│                    ↓                                │
+│           模型输出裁定结果 VERDICT                   │
+│           （支持 / 不支持）                          │
+└─────────────────────────────────────────────────────┘
+```
+
+### 工作机制
+
+1. **输入三元组**：同时输入具体情境（Case）、外部证据（Evidence）和结构化主张（Claim）
+2. **判断题模式**：将任务转化为判断题，强制模型输出明确裁定
+3. **逻辑验证**：验证证据在当前情境下是否真实支撑主张
+
+---
+
+## 自动化数据生成方法
+
+### 核心创新
+
+**零人工标注成本**的自动化数据生成流水线，整合两大数据源：
+
+| 数据源 | 用途 |
+|-------|------|
+| **MIMIC-CXR**（真实影像报告） | 提取病例状态（Case） |
+| **Radiopaedia**（医学知识库） | 抽取数万条证据（Evidence） |
+
+通过 **Refire Core** 逻辑规则智能重组，自动映射成数十万条正负样本。
+
+### 四类训练样本
+
+| 样本类型 | 特征 | 作用 |
+|---------|------|------|
+| **正样本** | 明确支持主张 | 学习正确关联模式 |
+| **错误状态陷阱** | 高度相关但结论相反 | 封堵关键词匹配捷径 |
+| **困难负样本** | 因果关系复杂 | 强化深层理解 |
+| **简单负样本** | 明显不支持 | 基线学习 |
+
+### 反事实负样本（核心突破）
+
+- **语义特征**：与主张极度接近，包含所有核心关键词
+- **逻辑特征**：由于病例特征差异，推导方向与主张完全相反
+- **占比**：25% 的数据集专门用于封堵关键词匹配捷径
+
+**目的**：逼迫模型放弃表面关联，深入理解文字背后的逻辑因果。
+
+---
+
+## 实验设计与结果
+
+### 关键对比实验
+
+#### 1. 病例深度关联的效果
+
+| 配置 | AUPRC | 平衡准确率 |
+|-----|-------|-----------|
+| 纯证据验证 | 35.1% | — |
+| **深度关联验证** | **87.8%** | **92.0%** |
+
+**结论**：单纯堆砌资料不能让 AI 变聪明，结合具体情境才能实现性能跨越。
+
+#### 2. 关键词陷阱测试
+
+**场景**：病例明确显示无胸腔积液，面对包含相同术语的干扰证据
+
+| 模型 | 支持率 |
+|-----|-------|
+| 普通 AI | 99.1% |
+| **深度验证模型** | **0.000%** |
+
+**结论**：框架能有效识破伪装，不再盲目信任语义相近但逻辑无关的信息。
+
+#### 3. 物理干预测试（检验推理真实性）
+
+三种极端条件：
+
+| 测试条件 | 描述 | AUPRC | F1 分数 |
+|---------|------|-------|---------|
+| 正常关联证据 | 基线测试 | 87.8% | 高 |
+| 清空证据 | 切断所有参考资料 | 大幅下降 | 大幅下降 |
+| **交换证据** | 张冠李戴的专业文本 | **21.7%** | 显著缩水 |
+
+**结论**：性能急剧崩溃证明模型**高度依赖正确的外部证据**，而非死记答案。
+
+#### 4. 证据数量与性能关系
+
+| 证据数量 | AUROC |
+|---------|-------|
+| 1 句 | 较低 |
+| **2 句** | **97.4%（巅峰）** |
+| 10 句 | 基本持平 |
+
+**关键发现**：模型不需要翻阅数百页文档，只需抓准最关键的两句信息就能实现满血性能。过度堆砌资料反而引入背景干扰。
+
+### 全维度性能对比
+
+| 方法 | AUROC | AUPRC | BRI Score |
+|-----|-------|-------|-----------|
+| 纯情境推断 | 59.90% | — | 高 |
+| 纯证据验证 | — | 35.11% | 高 |
+| **三位一体深度关联** | **97.43%** | **87.8%** | **0.060** |
+
+---
+
+## 泛化能力验证
+
+### 陌生知识测试（Held-out Content）
+
+使用**从未参与训练**的全新医学百科文章：
+
+| 指标 | 结果 |
+|-----|------|
+| AUROC | 97.2% |
+| F1 分数 | 77.9% |
+
+**结论**：模型学习到的是**通用验证逻辑**，而非对特定教材句式的死记硬背。
+
+### 跨数据集迁移
+
+将基于 MIMIC-CXR 训练的模型**直接空降**到 CheXpert Plus 数据集（6万+患者）：
+
+| 指标 | 结果 |
+|-----|------|
+| AUROC | 93.46% |
+| 平衡准确率 | 87.45% |
+
+**结论**：即便面对截然不同的书写风格和病例分布，模型验证能力依然在线，展现极强落地适应性。
+
+### 底层模型对比
+
+| 模型 | 参数量 | AUPRC | 特点 |
+|-----|-------|-------|------|
+| **DeBERTa-v3-large** | **3.95亿** | **87.8%** | 综合最强，面对未知证据最稳 |
+| FlanT5-large | — | 次之 | 经典大模型 |
+| RoBERTa-large | — | — | 经典 baseline |
+
+**结论**：更现代的特征提取器能更敏锐地锁定微小的语义偏差。
+
+---
+
+## 应用场景
+
+### 1. 临床问答护城河
+
+```
+检索器 → 生成器 → 【验证框架】 → 医生
+                              ↓
+                        输出置信度分数
+                        拦截 99% 幻觉主张
+```
+
+- 作为最后一道交叉质证
+- 有效拦截无依据方案
+- 辅助医生做出更稳健的决策
+
+### 2. 自动化医疗报告审核
+
+- 自动提取结构化结论
+- 与原始影像发现及医学标准逐一核对
+- 实时标注逻辑冲突，提示人工复核
+- 减轻高年资医生审核负担
+- 杜绝因疲劳引发的关键性疏漏
+
+### 3. 跨领域泛化
+
+| 领域 | 应用 |
+|-----|------|
+| 法律合规 | 核实法条是否真实适用于案件事实 |
+| 科研验证 | 自动检查实验引用是否存在张冠李戴 |
+| 企业知识库 | 核对工单与操作手册，拒绝随意发挥 |
+
+---
+
+## 范式跃迁：从 RAG 到 VAG
+
+| 范式 | 特征 | 核心区别 |
+|-----|------|---------|
+| **RAG**（检索增强生成） | 只要检索文本看起来相似，就强行作为答案参考 | 区分**相关性**与**支撑性** |
+| **VAG**（验证增强生成） | 只有存在明确逻辑因果的文本才被认定为有效证据 | 追求**确凿性** |
+
+**本质转变**：AI 从松散的文本拼接机器 → 严谨的逻辑推演中枢
+
+---
+
+## 当前局限与未来路线
+
+### 技术边界
+
+| 局限类型 | 具体问题 |
+|---------|---------|
+| **泛化损耗** | 面对截然不同的新证据时，AUPRC 指标仍会产生客观衰减 |
+| **多状态扩展** | 目前主要验证二元主张，未来需向复杂多元连续图谱扩展 |
+| **端到端噪声** | 引入全网实时检索后，对模型抗干扰能力提出更高要求 |
+
+### 演进路线
+
+```
+第一阶段（已完成）     第二阶段（进行中）     第三阶段（愿景）
+    ↓                     ↓                    ↓
+三位一体验证框架  →  端到端动态检索  →  人类专家深度对齐
+                        +                      +
+                  非结构化长文本         证据链自我修剪
+                  高噪声环境            自主思考 Agents
+```
+
+---
+
+## 核心结论
+
+| 指标 | 结果 | 意义 |
+|-----|------|------|
+| AUPRC | 87.8%（提升 52.6%） | 跨越性性能提升 |
+| 平衡准确率 | 92.0% | 高可靠性 |
+| BRI Score | 0.060 | 极低预测误差 |
+
+**核心启示**：真正的智能不仅在于调取知识，更在于懂得如何对证据负责。
+
+---
+
+## 术语表
+
+| 术语 | 全称 | 解释 |
+|-----|------|------|
+| **AUPRC** | Area Under Precision-Recall Curve | 精确率-召回率曲线下面积，衡量不平衡数据集性能 |
+| **AUROC** | Area Under Receiver Operating Characteristic Curve | ROC 曲线下面积，衡量分类器区分能力 |
+| **BRI Score** | Brier Score | 预测误差的均方误差，越低越准确 |
+| **RAG** | Retrieval-Augmented Generation | 检索增强生成 |
+| **VAG** | Verification-Augmented Generation | 验证增强生成 |
+| **DeBERTa** | Decoding-enhanced BERT with disentangled attention | 更现代的预训练语言模型架构 |
+| **MIMIC-CXR** | Medical Information Mart for Chest X-ray | 公开胸部 X 光影像数据集 |
+| **反事实负样本** | Counterfactual Negative Samples | 语义相似但逻辑结论相反的样本，用于测试模型是否真正理解因果关系 |
+| **CheXpert Plus** | — | 斯坦福大学胸部 X 光数据集 |
+| **Refire Core** | — | 逻辑规则引擎，用于自动构建训练样本 |
\ No newline at end of file
diff --git a/InBox/面向架构编程范式_超越OOP和MVC_BV1ArVU62Eac_笔记.md b/InBox/面向架构编程范式_超越OOP和MVC_BV1ArVU62Eac_笔记.md
new file mode 100644
index 0000000..315f2bc
--- /dev/null
+++ b/InBox/面向架构编程范式_超越OOP和MVC_BV1ArVU62Eac_笔记.md
@@ -0,0 +1,423 @@
+# 面向架构编程范式：超越 OOP 和 MVC
+
+## 一、编程范式的本质
+
+### 1.1 什么是编程范式
+
+编程范式（Programming Paradigm）是指程序的**表达方式**，它不决定程序能实现什么功能，只决定能否方便、易懂地表达功能。
+
+```
+过程式表达：
+f1(); f2(); f3();
+
+面向对象表达：
+obj.f1(); obj.f2(); obj.f3();
+```
+
+两段代码功能完全相同，都是先执行 F1，再执行 F2、F3。表达方式不同，但实现的功能是一样的。
+
+**关键结论**：
+- 面向对象能写的程序，过程式也能写
+- 反过来也一样
+- 无论用哪种范式，你的程序都能实现买东西这个功能
+
+### 1.2 编程范式的真正目的
+
+> 编程范式的根本目的是为了**大规模代码**和**大规模团队分工合作**。
+
+当代码量膨胀到：
+- 成千上万行
+- 几十万行
+- 上百万行
+
+当团队有上百号程序员时，需要将整个项目拆分成多个模块，每个组负责一个模块。程序员需要调用其他人开发的模块，这就引出了**模块封装隔离**的概念。
+
+### 1.3 模块封装隔离的概念
+
+把模块的运行原理封装在模块内，只暴露接口。模块的调用者只需要会操作接口，不需要理解模块内部的运行原理，就能使用这个模块。
+
+**如果做不好封装隔离**：
+- 调用其他模块时，需要充分理解那个模块的内部原理
+- 整个项目可能有成百上千个模块
+- 需要懂上百个模块的内部原理，才能写自己的程序
+- 这在实际项目中是不现实的
+
+## 二、面向对象与模块封装
+
+### 2.1 面向对象的封装优势
+
+面向对象提供 `class` 语法，程序员可以很方便地把程序拆分成多个部分：
+
+```python
+class A:
+    def interface1(self): ...
+    def interface2(self): ...
+
+class B:
+    def interface1(self): ...
+    def interface3(self): ...
+
+class C:
+    def interface2(self): ...
+    def interface3(self): ...
+```
+
+每个类是一个模块，每个模块下有若干接口（可外部调用的函数）。实际项目中，每个类可能有几百上千行代码，好几十个函数接口，分别由不同程序员开发。
+
+### 2.2 不只是面向对象在做模块封装
+
+```python
+# 过程式模块封装
+# module_a.py
+def f1(): ...
+def f2(): ...
+
+# module_b.py
+def f3(): ...
+
+# main.py
+import module_a
+import module_b
+module_a.f1()
+module_b.f3()
+```
+
+效果和 class 一样。但这种方案**太笨重**了，比用类要复杂。
+
+### 2.3 工程成本原则："太麻烦，没人用"
+
+工程问题和数学问题不同：
+- 数学算法不需要考虑成本
+- 工程问题最看重的就是成本
+
+> **如果一个东西的使用成本大于收益，那根本就不会有人去用它。即使这是个好东西。**
+
+这会导致：
+- 只有那些最重要的功能才能采用该方案
+- 一些边边角角的小功能则完全没法用
+- 用它反而会让程序更复杂
+
+**结论**：面向对象比过程式高级，因为面向对象提供了一种方便的用于封装接口的语法。
+
+### 2.4 class 的本质澄清
+
+class 的本质是**借口**（Interface）。
+
+一个 class 定义得好不好，取决于：
+- 有没有做好功能的封装
+- 有没有暴露出正确的接口
+
+至于汽车有几个轮子、像不像鸭子，根本无关紧要。
+
+**正确的类比**：手机开机按钮就是一个接口。按下开机键后，手机进行一系列复杂的初始化过程，而用户不需要懂这个过程，只要会按开机键就可以了。
+
+## 三、面向对象的设计缺陷
+
+### 3.1 继承的问题：代码无法复用
+
+使用继承进行代码复用的问题：
+
+```
+      A
+     / \
+    B   C
+```
+
+假设 F1、F2、F3 的代码写在 A 类中。用户只需要 F1 和 F3，无法复用这段代码——因为继承会把 F2 也带进来。
+
+### 3.2 组合优于继承
+
+**组合思想**：
+```
+    Main
+   / | \
+  A  B  C
+```
+
+子模块拆分成 A 类、B 类、C 类。写 Main 类的程序员需要 F1、F2、F3 中的哪个就组哪个，不需要的就不组。既简单又灵活，**完胜继承链条**。
+
+**组合是一种思想，并不局限于某种特定语法。**
+
+### 3.3 多重继承的致命问题：重名冲突
+
+这是一个记账器例子，子模块 A 和子模块 C 有一个重名的函数 F1，这会造成冲突。
+
+**有人会说：把其中一个函数重命名为其他名字不就得了？**
+
+现实项目里没这么简单：
+- A 模块和 C 模块可能分别是两家公司开发的开源库
+- 每个库可能有几万行代码
+- F1 函数的调用链可能非常复杂
+- 如果要改名，就要改动整条调用链
+- 项目还可能存在其他库依赖这两个库的命名
+- 要改的话就要连同其他库一起改
+
+**真正要命的是**：原库可能已经在业界运行过多年，安全性和稳定性有保证。改了源代码就要承担出 bug 的风险。
+
+### 3.4 这种改动要求是不合理的
+
+对比其他领域的例子：
+- 显卡上有一个电容
+- 主板上的电容可能和显卡上的电容**重名或型号相同**
+- **不会产生命名冲突**
+
+**工业产品的拆分逻辑都是组合**。子模块中存在重名零件，根本不影响任何东西。这才是正确的封装逻辑。
+
+> 全天底下各行各业，就面向对象搞特殊。
+
+## 四、MVC 方案的局限
+
+### 4.1 MVC 就是组合
+
+MVC 把功能拆分成最细的 Model（数据）和 View（函数），再通过 Controller 组合起来：
+
+```python
+class MainController:
+    def __init__(self):
+        self.modelA = ModelA()
+        self.modelB = ModelB()
+        self.viewC = ViewC()
+```
+
+用哪个 model 或 view 函数就组哪个，不用的就不组。
+
+虽然 A 和 B 存在重名函数，但是并不会产生冲突。
+
+### 4.2 MVC 的问题：抽象泄露
+
+在 Main 模块中初始化 A 和 B，并交换两者的指针时，存在一个问题：
+
+> **A 和 B 的初始化逻辑泄露到 Main 这一层了。**
+
+在实际项目中：
+- A 和 B 可能是别的程序员写的底层库
+- Main 模块由业务层程序员写
+- 底层库的逻辑本不应该泄露到业务层
+
+**正确的封装**：每一层程序员将本层的逻辑封装在本层。不应该要求使用者理解本层逻辑，只要使用者会用即可。
+
+### 4.3 初始化逻辑的复杂性
+
+实际项目中初始化可能存在非常复杂的交互关系：
+
+```
+1. A 先初始化几步
+2. 把中间结果传给 B 初始化
+3. 再把中间结果传回给 A，继续初始化
+```
+
+另外，实际项目中子模块可能不止两个，很可能存在多个子模块初始化过程相互交织的情况。这要求 Main 程序员必须非常理解 A 和 B 等子模块的内部实现，才能写出 Main 层。
+
+### 4.4 抽象泄露导致的问题
+
+**问题 1：模块无法替换**
+
+库存程序员无法写出一个模块 C 去替换模块 B，因为 Main 层耦合了模块 B 的初始化逻辑。模块 C 只要初始化逻辑稍有不同，就无法替换 B。
+
+**问题 2：中间层方案要么灵活性差，要么代码极为复杂**
+
+一种方案是加一个中间层（Middle Layer），中间层由 A 或 B 这一层的程序员编写。Main 层程序员无需理解中间层的内部实现。
+
+但存在两种情况：
+1. 中间层代码最为简单，但灵活性差：Main 程序员无法选择组合哪几个子模块或者组合其他同接口的子模块。比如 Main 实现不了组合 A、C、D 三个模块，因为中间层只实现了 A、B 组合
+2. 让中间层适配，由 Main 层程序员自由选择组合哪些子模块：中间层的代码变得极为复杂
+
+**记住"太麻烦，没人用"原则**。
+
+### 4.5 依赖注入和微服务
+
+依赖注入或微服务确实解决了抽象泄露问题。这两个方案都能进行模块替换。
+
+> 衡量封装得好不好，可以看此模块能不能替换成同类模块。
+
+**唯一的问题是**：这俩方案太重型了。使用成本太高。
+
+## 五、时间悖论问题
+
+### 5.1 时间悖论的根源
+
+回到第一种方案，分析根本原因：
+
+```
+A 模块 ←→ B 模块
+     ↓
+  Main 模块
+```
+
+**这里存在一个时间悖论**：
+- A 模块和 B 模块是先写出来的
+- Main 模块是在之后的某个时间点写出来的
+
+如果想避免抽象泄露到 Main 层，程序员需要在 Main 类出现前表达交换 A 和 B 的指针这件事。然而，这做不到，因为 Main 只有在 A 和 B 存在后才出现。
+
+### 5.2 语法限制导致的困境
+
+但这是因为**语法限制**。假设编译器支持使用抽象名称作为指针名，其实是不存在时间悖论的。
+
+## 六、新语法设计方案
+
+### 6.1 核心语法设计
+
+语法基本沿袭继承，但在调用函数或成员变量时，使用该成员的**整个名称链**：
+
+| 符号 | 含义 |
+|------|------|
+| `..`（两个点） | 向上级寻找 |
+| `...`（三个点） | 向平级寻找 |
+| `.`（一个点） | 向下级寻找 |
+
+也可以使用上斜杠、横杠和下斜杠表示。符号不重要，重要的是原理。
+
+### 6.2 use 关键字
+
+当名称列太长时，可以使用 `use` 关键字进行缩写：
+
+```python
+use module_a.b.c as abc
+```
+
+实际上，这个 `use` 关键字本质上和传统语言里包管理里的 include 或 import 是相同的东西。
+
+### 6.3 super 关键字
+
+代码中有个 `super` 关键字。ABCD 模块可能是先写出来的，Main 模块是未来的某个时间点写出来的。
+
+所以写 ABCD 的时候，程序员是不知道未来那个上级模块叫什么名字。这时可以用 `super` 关键字表示**任意名称的上级模块**：
+
+```python
+class A:
+    def method(self):
+        super..call_something()  # 向上级寻找
+```
+
+在这种写法下：
+- 底层模块的逻辑封装在底层
+- 每一层程序员无需理解底层模块，只要会组合就行了
+- 可以任意替换同类模块
+
+### 6.4 from 和 to 关键字
+
+```python
+from ModuleC import xxx as xxx_renamed
+to ModuleX use some_function
+```
+
+**from 和 to 关键字比看上去更重要**，类似于主板设计师在 PCB 板上连同导线。这个动作是本编程范式下的基石。
+
+### 6.5 模块重命名
+
+有时子模块可能需要同类。那么可以像下面这样重命名：
+
+```python
+class MainB:
+    from ModuleA as mod_a
+    from ModuleB as mod_b
+    # 两个模块都有相同的接口，但名称不同时进行重命名
+```
+
+### 6.6 新语法的优势
+
+**在抽象泄露的情况下，是无法做到自由替换子模块的**，因为上级模块耦合了下层实现。每个下层实现的逻辑不同，替换时要连带替换，泄露到内层的逻辑代码。
+
+使用新语法后：
+- 每层程序员可以任意组合 B 或 C
+- 两者名称不同时，使用 `from` 关键字重命名即可
+- 模块可以自由替换
+
+## 七、核心原理：工业流水线思想
+
+### 7.1 职能隔离的比喻
+
+本语法的核心思想是仿照**工业流水生产线**生产工业品：
+
+- 不同工段的工人是职能隔离的
+- 不同工段的工人无需理解前一个工段
+- 只需要会组装上一个工段传输过来的零件即可
+- 同时，本工段的工人也应该将封装好的零件提供给后一个工段的工人，让其无需理解本工段逻辑
+
+### 7.2 空间位置关系
+
+拿主板和显卡的例子来做说明：
+- 主板上的一个电容和显卡上的一个电容重名或型号相同时，不会产生名称冲突
+- 原因在于，主板和显卡是通过**三维空间位置**寻找子零件
+
+**本语法中的全路径巡境表达的是对象成员的空间位置关系**，相当于主板设计师在 PCB 板上按空间位置连同导线。
+
+### 7.3 编译期依赖注入
+
+本语法相当于在面向对象的继承语法的基础上，在**编译期实现依赖注入**。
+
+> **本语法是对面向对象的语法的发展或改进，而非否定。**
+
+## 八、API 关键字与调用链耦合
+
+### 8.1 基本语法存在的问题
+
+但刚刚的基本语法存在一个问题：**调用链耦合了其他模块的名称链**。
+
+看回例子：
+- 模块 A 再调用模块 B 时，调用链耦合了 B 到 D 这个名称链
+- 在实际项目中，模块 B 可能是其他公司开发的开源库
+- 它写的名称链可能是 B → E → D
+- 模块 A 的程序员是不可能要求 B 程序员按 A 的要求改名的
+
+**所以这种基本语法仅适用于模块内部**，程序员可以完全控制代码的情况下。
+
+### 8.2 API 关键字解决方案
+
+当模块间进行交互时，需要另外一种封装机制：`API` 关键字。
+
+```python
+class ModuleA:
+    @API  # 标记为公开接口
+    def public_interface(self): ...
+    
+    def _private_method(self): ...  # 内部方法
+```
+
+本语法中不存在其他面向对象语言中的 public 和 private 关键字，而是使用 `API` 关键字控制可见性。
+
+### 8.3 API 关键字的作用
+
+当模块 M 的未标记为 API 时：
+- 该 M 的成员变量和成员函数全是 public 公有
+- 可被外部任意访问
+
+使用 API 关键字可以：
+- 精确控制哪些接口对外暴露
+- 将调用链耦合封装在模块内部
+- 允许外部替换同接口的模块而不影响内部实现
+
+## 九、总结
+
+### 9.1 编程范式演进路径
+
+| 阶段 | 特点 | 问题 |
+|------|------|------|
+| 过程式 | 简单直接 | 代码膨胀后难以维护 |
+| 面向对象 | class 语法便于封装 | 继承导致代码无法复用、重名冲突 |
+| MVC | 组合思想 | 抽象泄露、初始化逻辑耦合 |
+| 依赖注入/微服务 | 解决抽象泄露 | 太重型、成本高 |
+
+### 9.2 新范式的核心要点
+
+1. **全路径巡境**：通过名称链完整表达模块间的空间位置关系
+2. **编译期依赖注入**：在编译阶段完成依赖关系的绑定
+3. **职能隔离**：仿照工业流水线，每层程序员无需理解底层
+4. **模块可替换**：衡量封装好不好的标准是能否自由替换同类模块
+5. **API 关键字**：控制模块间交互的接口暴露
+
+### 9.3 对面向对象的态度
+
+本语法是对面向对象的语法的发展或改进，而非否定。它解决了：
+- 继承的代码复用问题
+- 多重继承的重名冲突问题
+- MVC 的抽象泄露问题
+- 时间悖论导致的初始化耦合问题
+
+---
+
+**相关讨论补充**（来自弹幕）：
+- 边界条件处理和输入检查在任何范式下都需要考虑
+- 用函数做 API 和用类做 API 区别挺大——类可以维护状态，函数式更纯粹
+- 有些成员变量要维护的话，面向对象还是最合适的
\ No newline at end of file