前言

Claude：编程向的LLM大模型
1. 本地部署 LLM，无订阅使用 Claude Code https://km.netease.com/v4/detail/blog/258409
  1. 本地部署 LLM，并让 Claude Code 使用本地模型作为推理后端。
2. Claude Code Agent Teams 实验与技术剖析 https://km.netease.com/v4/detail/blog/259175
3. 部署思路：
  1. Ollama。https://zhuanlan.zhihu.com/p/1996694609837983703
  2. 原生部署。
Claude Skill
1. 我用Claude白嫖了整个Github，现在每天只工作2小时 https://zhuanlan.zhihu.com/p/1998522824734815001
WY工具
1. Claude Dashboard：AI并行编程的指挥中心 https://km.netease.com/v4/detail/blog/258957
2. 100% AI编程实践：POPO for OpenClaw 开发纪实 https://km.netease.com/v4/detail/blog/259053
其他大模型
1. OpenCode
2. QWen
3. Gemini
4. MiniMax
5. DeepSeek

其他相关知识

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 的轮次结束，系统自动通知)
  │                           │

关键机制：

消息不会打断正在工作的 Agent：如果 Agent B 正在写代码，Agent A 发送的消息会在 B 的邮箱中排队，直到 B 当前轮次结束后才会被处理。
idle_notification 是系统自动发送的：当一个 Agent 的轮次结束（无论是完成了工作还是在等待输入），系统会自动向 Team Lead 发送空闲通知。这不是 Agent 主动发的。
Agent 间不直接通信：所有消息都通过邮箱系统路由。Agent A 发给 Agent B 的消息，Team Lead 可以在 idle_notification 的 summary 中看到摘要。
共享文件系统是隐式通信通道：虽然 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 的主会话贯穿全程，是唯一跨团队的持久上下文。

8.5 KiB Raw Blame History Unescape Escape

前言