Add Milky notes: 20 file(s)
This commit is contained in:
Zane
@@ -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 自动修复代码风格问题，效果很好
|
||||
177
InBox/2026-05-30_SDD_规格驱动落地_文档管理策略_BV1mZV76eEPC_笔记.md
Normal file
177
InBox/2026-05-30_SDD_规格驱动落地_文档管理策略_BV1mZV76eEPC_笔记.md
Normal file
@@ -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编程`
|
||||
@@ -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 的技术架构与工程实践。视频原版对三层架构有详细展开，读者可根据需要结合原视频深入理解各层级的技术细节。
|
||||
934
InBox/Multi-Agent与Multi-Task编排架构.md
Normal file
934
InBox/Multi-Agent与Multi-Task编排架构.md
Normal file
@@ -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 自动抓取保存*
|
||||
316
InBox/OpenAI_Skill的自动评分器怎么搭_BV1HWd6BsEmG_笔记.md
Normal file
316
InBox/OpenAI_Skill的自动评分器怎么搭_BV1HWd6BsEmG_笔记.md
Normal file
@@ -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）
|
||||
@@ -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 的价值是让后面的线程不从零开始。**
|
||||
317
InBox/_AI翻译_别再自己钻研Claude技巧了_Autoresearch帮你搞定_BV1tJwKzDE8x_笔记.md
Normal file
317
InBox/_AI翻译_别再自己钻研Claude技巧了_Autoresearch帮你搞定_BV1tJwKzDE8x_笔记.md
Normal file
@@ -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 的可靠性和准确性，实现技能的**自我进化**。
|
||||
@@ -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工程**是构建这些能力的核心学科。
|
||||
|
||||
- 开源生态会继续分化，提供不同层级的解决方案
|
||||
- 企业及个人用户的选择标准需从"模型智能"转向"**模型可靠性**"等系统能力
|
||||
158
InBox/milky_BV17y7U6EER5.md
Normal file
158
InBox/milky_BV17y7U6EER5.md
Normal file
@@ -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
|
||||
435
InBox/milky_BV1ArVU62Eac.md
Normal file
435
InBox/milky_BV1ArVU62Eac.md
Normal file
@@ -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
|
||||
321
InBox/milky_BV1HWd6BsEmG.md
Normal file
321
InBox/milky_BV1HWd6BsEmG.md
Normal file
@@ -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 视频总结助手
|
||||
324
InBox/milky_BV1Hn9UBrEsH.md
Normal file
324
InBox/milky_BV1Hn9UBrEsH.md
Normal file
@@ -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
|
||||
186
InBox/milky_BV1LjdzB3EAu.md
Normal file
186
InBox/milky_BV1LjdzB3EAu.md
Normal file
@@ -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 视频总结助手
|
||||
365
InBox/milky_BV1SZoXBkErT.md
Normal file
365
InBox/milky_BV1SZoXBkErT.md
Normal file
@@ -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
|
||||
192
InBox/milky_BV1i77X6pE1C.md
Normal file
192
InBox/milky_BV1i77X6pE1C.md
Normal file
@@ -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
|
||||
181
InBox/milky_BV1mZV76eEPC.md
Normal file
181
InBox/milky_BV1mZV76eEPC.md
Normal file
@@ -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
|
||||
273
InBox/milky_BV1p9QnBtEMq.md
Normal file
273
InBox/milky_BV1p9QnBtEMq.md
Normal file
@@ -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 视频总结助手
|
||||
320
InBox/milky_BV1tJwKzDE8x.md
Normal file
320
InBox/milky_BV1tJwKzDE8x.md
Normal file
@@ -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 视频总结助手
|
||||
@@ -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可解释、可审计，解决监管问题
|
||||
|
||||
---
|
||||
|
||||
## 核心启示
|
||||
|
||||
> 不要一遇到问题就想着堆算力、堆参数。有时候真正的突破来自于对问题本身的重新定义。
|
||||
>
|
||||
> 不是模型不行，可能是我们的接口不行。
|
||||
>
|
||||
> 换个角度看问题，整个世界都不一样了。
|
||||
269
InBox/让AI真正读懂证据间的因果_深度验证框架解决逻辑断层_实现92.0_平衡准确率_BV1p9QnBtEMq_笔记.md
Normal file
269
InBox/让AI真正读懂证据间的因果_深度验证框架解决逻辑断层_实现92.0_平衡准确率_BV1p9QnBtEMq_笔记.md
Normal file
@@ -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** | — | 逻辑规则引擎，用于自动构建训练样本 |
|
||||
423
InBox/面向架构编程范式_超越OOP和MVC_BV1ArVU62Eac_笔记.md
Normal file
423
InBox/面向架构编程范式_超越OOP和MVC_BV1ArVU62Eac_笔记.md
Normal file
@@ -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 区别挺大——类可以维护状态，函数式更纯粹
|
||||
- 有些成员变量要维护的话，面向对象还是最合适的
|
||||
Reference in New Issue
Block a user