diff --git a/07-Other/AI/AI Agent/Claude Agent案例.md b/07-Other/AI/AI Agent/Claude Agent案例.md new file mode 100644 index 0000000..bced444 --- /dev/null +++ b/07-Other/AI/AI Agent/Claude Agent案例.md @@ -0,0 +1,138 @@ +# 前言 +1. Claude Code Agent Teams 实验与技术剖析 https://km.netease.com/v4/detail/blog/259175 + + + +##  Agent Teams 工作机制与原理 +在深入案例之前，先理解 Agent Teams 的底层工作机制。这有助于理解后续协作中发生的每一个事件。 +### **2.1 架构概览** +``` +┌─────────────────────────────────────────────────────────┐ +│ 用户（Human） │ +│ │ │ +│ ▼ │ +│ ┌─────────────────┐ │ +│ │ Team Lead │ ◀── 主 Claude 会话 │ +│ │ (Orchestrator) │ │ +│ └────────┬────────┘ │ +│ │ │ +│ ┌────────────┼────────────┐ │ +│ │ SendMessage / TaskUpdate │ │ +│ │ (异步消息队列) │ │ +│ ▼ ▼ ▼ │ +│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ +│ │ Agent A │ │ Agent B │ │ Agent C │ ◀── 子进程 │ +│ │(Architect)│ │(Backend) │ │(Frontend)│ │ +│ └──────────┘ └──────────┘ └──────────┘ │ +│ │ │ │ │ +│ └────────────┼────────────┘ │ +│ ▼ │ +│ 共享文件系统 │ +│ (api-contract.yaml, │ +│ shared-types.ts, ...) │ +└─────────────────────────────────────────────────────────┘ +``` +### 2.2 核心组件 +#### **Team（团队）** +通过 TeamCreate 创建，在 ~/.claude/teams/{team-name}/config.json 生成团队配置文件。团队是一个逻辑分组，包含： +- 团队名称和描述 +- 成员列表（name、agentId、agentType） +- 与 TaskList 的 1:1 对应关系 +#### **Agent（智能体）** +每个 Agent 是一个独立的 Claude 子进程，通过 Task 工具启动（subagent_type: general-purpose）。每个 Agent 拥有： +- **独立的上下文窗口**：Agent 之间不共享对话历史 +- **独立的工具集**：可以读写文件、执行 bash 命令、搜索代码等 +- **异步消息队列**：接收来自其他 Agent 或 Team Lead 的消息 +- **团队感知**：可以读取团队配置文件，知道队友是谁 + +#### **TaskList（任务列表）** +通过 TaskCreate、TaskUpdate、TaskList 等工具管理。任务系统提供： +- **状态机**：pending → in_progress → completed +- **依赖关系**：blockedBy / blocks 实现任务间的前后依赖 +- **分配机制**：owner 字段标识任务归属 + +#### **SendMessage（消息系统）** +Agent 间通信的唯一方式。消息类型包括： +- message：点对点消息（Agent A → Agent B） +- broadcast：广播消息（发送给所有队友） +- shutdown_request / shutdown_response：优雅关闭协议 + +### **2.3 通信模型：异步邮箱 + 空闲通知** +Agent Teams 的通信是**异步的**，这是理解整个协作过程的关键： +``` +Agent A Agent B + │ │ + ├─── SendMessage ──────────▶│ (消息进入 B 的邮箱) + │ │ + ├─── 继续工作... │ (B 可能正忙，消息排队) + │ │ + │ ├── 本轮工作结束 + │ ├── 检查邮箱，读取消息 + │ ├── 处理消息，发送回复 + │ ◀── idle_notification ───┤ (B 的轮次结束，系统自动通知) + │ │ +``` + +**关键机制：** +1. **消息不会打断正在工作的 Agent**：如果 Agent B 正在写代码，Agent A 发送的消息会在 B 的邮箱中排队，直到 B 当前轮次结束后才会被处理。 +2. **idle_notification 是系统自动发送的**：当一个 Agent 的轮次结束（无论是完成了工作还是在等待输入），系统会自动向 Team Lead 发送空闲通知。这不是 Agent 主动发的。 +3. **Agent 间不直接通信**：所有消息都通过邮箱系统路由。Agent A 发给 Agent B 的消息，Team Lead 可以在 idle_notification 的 summary 中看到摘要。 +4. **共享文件系统是隐式通信通道**：虽然 Agent 间不共享上下文，但它们可以通过读写同一个文件（如 api-contract.yaml）来传递信息。 + +### **2.4 Agent 的生命周期** +``` +创建(Task tool) + │ + ▼ +初始化 ──▶ 读取 prompt ──▶ 开始工作 + │ + ┌───────────┤ + ▼ ▼ + 完成工作 等待消息 + │ │ + ▼ ▼ + 发送结果 idle (空闲) + │ │ + ▼ ▼ + idle_notification ──▶ Team Lead + │ + ┌───────┤ + ▼ ▼ + 收到新消息 收到 shutdown_request + │ │ + ▼ ▼ + 继续工作 shutdown_response(approve) + │ + ▼ + 进程退出 +``` + +### **2.5 任务依赖如何控制协作节奏** +这个案例中最关键的协调机制是**任务依赖**： +``` +Task #1 (Architect: 设计 API) status: pending → in_progress → completed + │ + ├── blocks ──▶ Task #2 (Backend: 评审) ← blockedBy: [#1] + ├── blocks ──▶ Task #3 (Frontend: 评审) ← blockedBy: [#1] + └── blocks ──▶ Task #4 (QA: 评审+测试) ← blockedBy: [#1] +``` +当 Task #1 的状态变为 completed 时，Tasks #2/#3/#4 的 blockedBy 列表自动清空，Agent 可以通过 TaskList 发现任务可执行。 +但实际操作中，**依赖关系是"软约束"** —— Agent 并不会自动被阻塞。Team Lead 需要主动告知 Agent "你的任务被阻塞了，请等待"，或者 Agent 自己通过 TaskList 查看依赖状态后决定等待。 + +### **2.6 多团队工作流** +在这个案例里面，同一个 Team Lead **顺序创建、使用、销毁了 4 支团队**，每支团队负责一个阶段： +``` +flash-sale (4 Agent) 合约设计 + 并行编码 + │ 完成 → 销毁 + ▼ +flash-sale-review (4 Agent) 代码评审 + │ 完成 → 销毁 + ▼ +p0-fix (9 Agent) P0 级问题并行修复 + │ 完成 → 销毁 + ▼ +remaining-fix (4 Agent) 剩余问题并行修复 + │ 完成 → 销毁 +``` + +每支团队拥有独立的 TaskList 和成员列表，团队之间通过**共享文件系统**传递成果（上一支团队的代码产出是下一支团队的评审/修复输入）。Team Lead 的主会话贯穿全程，是唯一跨团队的持久上下文。 \ No newline at end of file diff --git a/07-Other/AI/AI Agent/OpenClaw.md b/07-Other/AI/AI Agent/OpenClaw.md new file mode 100644 index 0000000..4f9eb7b --- /dev/null +++ b/07-Other/AI/AI Agent/OpenClaw.md @@ -0,0 +1,2 @@ +# 前言 +