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