【claude code 如何构建 agent 实践9】从自由协作到结构化协议: 从S09到S10的演进

乾坤瞬间2026-05-14 15:29

s09到s10：从自由协作到结构化协议

文章目录

📋 目录

  1. 概述
  2. 核心差异对比
  3. 新增组件详解
  4. 两大核心协议
  5. 技术实现细节
  6. 协议设计模式
  7. 实战应用场景
  8. 演进路线图

概述

s09：自由协作的多智能体系统

s09实现了一个基础的多智能体团队系统，具有以下特点：

  • ✅ 队友可以动态创建和销毁
  • ✅ 队友之间可以自由通信
  • ✅ 每个队友独立运行在自己的线程中
  • ✅ 基于文件系统的消息传递

局限性：

  • ❌ 缺少结构化的协调机制
  • ❌ 没有优雅的关闭流程
  • ❌ 没有计划审批机制
  • ❌ 通信完全自由，缺少约束

s10：引入结构化协议

s10在s09的基础上，增加了两个核心协议：

  • 🔐 关闭协议：优雅的队友关闭流程
  • 📋 计划审批协议：高风险变更的事先审批

核心理念：

"队友之间要有统一的沟通规矩" -- 一个 request-response 模式驱动所有协商

核心差异对比

代码规模对比

维度 s09 s10 变化
总代码行数 420行 501行 +81行
工具数量 9个 12个 +3个
全局变量 2个 5个 +3个
核心类 2个 2个 无变化
协议处理函数 0个 3个 +3个

工具对比

Lead工具集
工具名 s09 s10 说明
bash ✅ ✅ 基础工具
read_file ✅ ✅ 基础工具
write_file ✅ ✅ 基础工具
edit_file ✅ ✅ 基础工具
spawn_teammate ✅ ✅ 创建队友
list_teammates ✅ ✅ 列出队友
send_message ✅ ✅ 发送消息
read_inbox ✅ ✅ 读取收件箱
broadcast ✅ ✅ 广播消息
shutdown_request ❌ ✅ 🆕 请求关闭队友
shutdown_response ❌ ✅ 🆕 检查关闭状态
plan_approval ❌ ✅ 🆕 审批队友计划
Teammate工具集
工具名 s09 s10 说明
bash ✅ ✅ 基础工具
read_file ✅ ✅ 基础工具
write_file ✅ ✅ 基础工具
edit_file ✅ ✅ 基础工具
send_message ✅ ✅ 发送消息
read_inbox ✅ ✅ 读取收件箱
shutdown_response ❌ ✅ 🆕 响应关闭请求
plan_approval ❌ ✅ 🆕 提交计划审批

新增全局变量

python 复制代码 
# s09: 没有这些变量

# s10: 新增协议追踪器
shutdown_requests = {}      # 关闭请求追踪
plan_requests = {}          # 计划请求追踪
_tracker_lock = threading.Lock()  # 线程安全锁

System Prompt变化

python 复制代码 
# s09
SYSTEM = f"You are a team lead at {WORKDIR}. Spawn teammates and communicate via inboxes."

# s10
SYSTEM = f"You are a team lead at {WORKDIR}. Manage teammates with shutdown and plan approval protocols."

新增组件详解

1. 请求追踪器

shutdown_requests
python 复制代码 
# 数据结构
shutdown_requests = {
    "abc123": {
        "target": "alice",      # 目标队友
        "status": "pending"     # 状态: pending | approved | rejected
    }
}

作用：

  • 追踪每个关闭请求的状态
  • 通过request_id关联请求和响应
  • 支持并发请求的线程安全访问
plan_requests
python 复制代码 
# 数据结构
plan_requests = {
    "xyz789": {
        "from": "bob",          # 提交计划的队友
        "plan": "重构认证模块...", # 计划内容
        "status": "pending"     # 状态: pending | approved | rejected
    }
}

作用：

  • 追踪每个计划审批请求
  • 存储计划内容供审查
  • 支持反馈机制
_tracker_lock
python 复制代码 
_tracker_lock = threading.Lock()

作用：

  • 保护共享的请求追踪器
  • 确保多线程环境下的数据一致性
  • 防止竞态条件

2. 协议处理函数

handle_shutdown_request
python 复制代码 
def handle_shutdown_request(teammate: str) -> str:
    """Lead发起关闭请求"""
    req_id = str(uuid.uuid4())[:8]
    with _tracker_lock:
        shutdown_requests[req_id] = {
            "target": teammate,
            "status": "pending"
        }
    BUS.send(
        "lead", teammate,
        "Please shut down gracefully.",
        "shutdown_request",
        {"request_id": req_id}
    )
    return f"Shutdown request {req_id} sent to '{teammate}' (status: pending)"

工作流程：

  1. 生成唯一request_id
  2. 在追踪器中注册请求
  3. 通过MessageBus发送shutdown_request消息
  4. 返回request_id供后续跟踪
handle_plan_review
python 复制代码 
def handle_plan_review(request_id: str, approve: bool, feedback: str = "") -> str:
    """Lead审查并响应计划"""
    with _tracker_lock:
        req = plan_requests.get(request_id)
    if not req:
        return f"Error: Unknown plan request_id '{request_id}'"

    with _tracker_lock:
        req["status"] = "approved" if approve else "rejected"

    BUS.send(
        "lead", req["from"], feedback,
        "plan_approval_response",
        {"request_id": request_id, "approve": approve, "feedback": feedback}
    )
    return f"Plan {req['status']} for '{req['from']}'"

工作流程：

  1. 查找对应的计划请求
  2. 更新请求状态
  3. 发送审批结果和反馈
  4. 返回操作结果
_check_shutdown_status
python 复制代码 
def _check_shutdown_status(request_id: str) -> str:
    """检查关闭请求状态"""
    with _tracker_lock:
        return json.dumps(shutdown_requests.get(request_id, {"error": "not found"}))

作用：

  • 供Lead查询关闭请求的当前状态
  • 支持调试和监控

3. Teammate工具扩展

shutdown_response工具
python 复制代码 
{
    "name": "shutdown_response",
    "description": "Respond to a shutdown request. Approve to shut down, reject to keep working.",
    "input_schema": {
        "type": "object",
        "properties": {
            "request_id": {"type": "string"},
            "approve": {"type": "boolean"},
            "reason": {"type": "string"}
        },
        "required": ["request_id", "approve"]
    }
}

实现逻辑：

python 复制代码 
if tool_name == "shutdown_response":
    req_id = args["request_id"]
    approve = args["approve"]
    with _tracker_lock:
        if req_id in shutdown_requests:
            shutdown_requests[req_id]["status"] = "approved" if approve else "rejected"
    BUS.send(
        sender, "lead", args.get("reason", ""),
        "shutdown_response",
        {"request_id": req_id, "approve": approve}
    )
    return f"Shutdown {'approved' if approve else 'rejected'}"
plan_approval工具
python 复制代码 
{
    "name": "plan_approval",
    "description": "Submit a plan for lead approval. Provide plan text.",
    "input_schema": {
        "type": "object",
        "properties": {
            "plan": {"type": "string"}
        },
        "required": ["plan"]
    }
}

实现逻辑：

python 复制代码 
if tool_name == "plan_approval":
    plan_text = args.get("plan", "")
    req_id = str(uuid.uuid4())[:8]
    with _tracker_lock:
        plan_requests[req_id] = {
            "from": sender,
            "plan": plan_text,
            "status": "pending"
        }
    BUS.send(
        sender, "lead", plan_text,
        "plan_approval_response",
        {"request_id": req_id, "plan": plan_text}
    )
    return f"Plan submitted (request_id={req_id}). Waiting for lead approval."

两大核心协议

协议1：关闭协议

问题背景

s09的关闭方式：

python 复制代码 
# s09: 队友自然退出或强制终止
# 问题：
# 1. 直接杀线程会留下写了一半的文件
# 2. config.json状态不准确
# 3. 没有机会清理资源
# 4. 无法知道队友是否准备好关闭

s10的解决方案：

  • 引入请求-响应握手机制
  • 队友可以批准或拒绝关闭
  • 支持优雅的资源清理
协议流程图
复制代码 
关闭协议状态机 (FSM)
====================

[pending] --approve--> [approved]
    |                     |
    | --reject-->         |
    v                     v
[rejected]           [线程停止]

详细流程:
========

Lead                              Teammate
  |                                 |
  | 1. shutdown_request("alice")    |
  |    {request_id: "abc123"}      |
  |-------------------------------->|
  |                                 |
  |                          2. 收到请求
  |                          决定: approve/reject
  |                          清理资源 (如需要)
  |                                 |
  |<--------------------------------|
  | 3. shutdown_response            |
  |    {request_id: "abc123",       |
  |     approve: true/false}        |
  |                                 |
  | 4. 更新追踪器状态               |
  | 5. 如果approved，等待线程结束   |
  |                                 |
  v                                 v
[关闭完成]                      [线程退出]
代码实现

Lead端：

python 复制代码 
# 工具定义
{
    "name": "shutdown_request",
    "description": "Request a teammate to shut down gracefully. Returns a request_id for tracking.",
    "input_schema": {
        "type": "object",
        "properties": {
            "teammate": {"type": "string"}
        },
        "required": ["teammate"]
    }
}

# 工具处理
"shutdown_request": lambda **kw: handle_shutdown_request(kw["teammate"])

Teammate端：

python 复制代码 
# 工具定义（已在上文展示）
# 工具处理（已在上文展示）

# 队友loop中的特殊处理
def _teammate_loop(self, name: str, role: str, prompt: str):
    should_exit = False
    for _ in range(50):
        # ... LLM调用 ...
        for block in response.content:
            if block.type == "tool_use":
                output = self._exec(name, block.name, block.input)
                results.append({...})

                # 🆕 特殊处理：如果批准关闭，设置退出标志
                if block.name == "shutdown_response" and block.input.get("approve"):
                    should_exit = True

        messages.append({"role": "user", "content": results})

    # 🆕 更新状态
    member = self._find_member(name)
    if member:
        member["status"] = "shutdown" if should_exit else "idle"
        self._save_config()
实际使用示例
python 复制代码 
# 用户输入
"""
创建一个队友alice，然后请求她关闭
"""

# Lead的执行过程
spawn_teammate(
    name="alice",
    role="coder",
    prompt="You are a coder. Wait for instructions."
)
# 返回: "Spawned 'alice' (role: coder)"

# 稍等片刻...

shutdown_request(teammate="alice")
# 返回: "Shutdown request abc123 sent to 'alice' (status: pending)"

# Alice收到请求，可能批准或拒绝
# 如果批准：
# [alice] shutdown_response:
#   request_id: "abc123"
#   approve: true
#   reason: "I have completed all tasks"
# 返回: "Shutdown approved"

# Lead检查状态
list_teammates()
# 返回:
# Team: default
#   alice (coder): shutdown  ← 状态变为shutdown

协议2：计划审批协议

问题背景

s09的计划执行方式：

python 复制代码 
# s09: 队友直接执行任务
# 问题：
# 1. 领导说"重构认证模块"，队友立即开干
# 2. 高风险变更没有审查机制
# 3. 可能执行不安全的操作
# 4. 缺少质量把关

s10的解决方案：

  • 队友在执行重要任务前必须提交计划
  • Lead审查并批准/拒绝计划
  • 提供反馈机制指导改进
协议流程图
复制代码 
计划审批协议状态机 (FSM)
========================

[pending] --approve--> [approved]
    |                     |
    | --reject-->         |
    v                     v
[rejected]           [执行任务]

详细流程:
========

Teammate                          Lead
  |                                 |
  | 1. plan_approval(               |
  |      "重构认证模块计划..."       |
  |    )                            |
  |    {request_id: "xyz789"}      |
  |-------------------------------->|
  |                                 |
  |                          2. 收到计划
  |                          审查计划内容
  |                          决定: approve/reject
  |                          准备反馈
  |                                 |
  |<--------------------------------|
  | 3. plan_approval_response        |
  |    {request_id: "xyz789",       |
  |     approve: true/false,        |
  |     feedback: "建议..."}        |
  |                                 |
  | 4. 如果approved，开始执行任务    |
  |    如果rejected，修改计划重新提交|
  |                                 |
  v                                 v
[任务完成]                    [审批完成]
代码实现

Teammate端：

python 复制代码 
# 工具定义（已在上文展示）
# 工具处理（已在上文展示）

# 队友的system prompt变化
sys_prompt = (
    f"You are '{name}', role: {role}, at {WORKDIR}. "
    f"Submit plans via plan_approval before major work. "  # 🆕 新增
    f"Respond to shutdown_request with shutdown_response."
)

Lead端：

python 复制代码 
# 工具定义
{
    "name": "plan_approval",
    "description": "Approve or reject a teammate's plan. Provide request_id + approve + optional feedback.",
    "input_schema": {
        "type": "object",
        "properties": {
            "request_id": {"type": "string"},
            "approve": {"type": "boolean"},
            "feedback": {"type": "string"}
        },
        "required": ["request_id", "approve"]
    }
}

# 工具处理
"plan_approval": lambda **kw: handle_plan_review(
    kw["request_id"],
    kw["approve"],
    kw.get("feedback", "")
)
实际使用示例
python 复制代码 
# 用户输入
"""
创建一个队友bob，让他重构认证模块
"""

# Lead的执行过程
spawn_teammate(
    name="bob",
    role="senior_developer",
    prompt="Refactor the authentication module for better security."
)
# 返回: "Spawned 'bob' (role: senior_developer)"

# Bob的工作流程（在独立线程中）
# Bob收到任务，决定先提交计划
[bob] plan_approval:
  plan: """
  重构计划：
  1. 替换MD5为SHA-256
  2. 添加密码强度检查
  3. 实现双因素认证
  4. 更新单元测试
  预计耗时: 2小时
  """
# 返回: "Plan submitted (request_id=xyz789). Waiting for lead approval."

# Lead收到计划请求，进入inbox
# Lead审查计划...
plan_approval(
    request_id="xyz789",
    approve=False,  # 拒绝
    feedback="SHA-256不够安全，建议使用bcrypt。双因素认证太复杂，先实现基本的密码强度检查。"
)
# 返回: "Plan rejected for 'bob'"

# Bob收到拒绝和反馈
# Bob修改计划重新提交
[bob] plan_approval:
  plan: """
  修改后的重构计划：
  1. 替换MD5为bcrypt
  2. 添加密码强度检查（至少8位，包含大小写字母和数字）
  3. 更新单元测试
  预计耗时: 1小时
  """
# 返回: "Plan submitted (request_id=abc456). Waiting for lead approval."

# Lead审查修改后的计划
plan_approval(
    request_id="abc456",
    approve=True,  # 批准
    feedback="很好，开始执行吧！"
)
# 返回: "Plan approved for 'bob'"

# Bob收到批准，开始执行任务
# ... 执行重构 ...

技术实现细节

1. request_id关联机制

生成策略
python 复制代码 
import uuid

req_id = str(uuid.uuid4())[:8]  # 取前8位
# 例如: "abc12345", "xyz78901"

为什么用UUID？

  • ✅ 全局唯一性
  • ✅ 无需中央协调
  • ✅ 支持并发请求
  • ✅ 易于调试和追踪
关联流程
python 复制代码 
# 发起端（Lead或Teammate）
req_id = str(uuid.uuid4())[:8]
tracker[req_id] = {
    "target"/"from": "teammate_name",
    "status": "pending",
    # 其他数据...
}
BUS.send(sender, receiver, content, msg_type, {"request_id": req_id})

# 响应端（Teammate或Lead）
req_id = received_msg["extra"]["request_id"]
# 使用同一个req_id更新状态或查询
tracker[req_id]["status"] = "approved"  # 或 "rejected"
BUS.send(sender, receiver, response, msg_type, {"request_id": req_id})

2. 状态机模式

统一的状态转换
python 复制代码 
# 两种协议共享相同的状态机
class ProtocolFSM:
    STATES = ["pending", "approved", "rejected"]

    def transition(self, current_state, action):
        if current_state == "pending":
            if action == "approve":
                return "approved"
            elif action == "reject":
                return "rejected"
        return current_state  # 其他状态不转换

# 使用
fsm = ProtocolFSM()
current_state = "pending"
new_state = fsm.transition(current_state, "approve")  # -> "approved"
状态持久化
python 复制代码 
# 状态保存在追踪器中
shutdown_requests[req_id] = {
    "target": "alice",
    "status": "pending"  # 状态持久化
}

# 可以随时查询
def get_status(req_id):
    return shutdown_requests.get(req_id, {}).get("status", "unknown")

3. 线程安全机制

锁的使用
python 复制代码 
import threading

_tracker_lock = threading.Lock()

# 写操作
with _tracker_lock:
    shutdown_requests[req_id] = {...}
    plan_requests[req_id] = {...}

# 读操作
with _tracker_lock:
    req = shutdown_requests.get(req_id)
    status = plan_requests.get(req_id, {}).get("status")

为什么需要锁？

  • 多个队友可能同时提交计划
  • Lead可能同时处理多个请求
  • 防止数据竞争和不一致

4. 消息类型扩展

VALID_MSG_TYPES
python 复制代码 
# s09
VALID_MSG_TYPES = {
    "message",
    "broadcast",
    "shutdown_request",      # 未使用
    "shutdown_response",     # 未使用
    "plan_approval_response", # 未使用
}

# s10
VALID_MSG_TYPES = {
    "message",                # 普通消息
    "broadcast",              # 广播消息
    "shutdown_request",       # 🆕 关闭请求
    "shutdown_response",      # 🆕 关闭响应
    "plan_approval_response", # 🆕 计划审批响应
}
消息格式
python 复制代码 
# shutdown_request消息
{
    "type": "shutdown_request",
    "from": "lead",
    "content": "Please shut down gracefully.",
    "timestamp": 1234567890.123,
    "extra": {
        "request_id": "abc123"
    }
}

# shutdown_response消息
{
    "type": "shutdown_response",
    "from": "alice",
    "content": "I have completed all tasks",
    "timestamp": 1234567891.456,
    "extra": {
        "request_id": "abc123",
        "approve": true
    }
}

# plan_approval_response消息
{
    "type": "plan_approval_response",
    "from": "bob",
    "content": "Refactor authentication module...",
    "timestamp": 1234567892.789,
    "extra": {
        "request_id": "xyz789",
        "plan": "Refactor authentication module..."
    }
}

协议设计模式

统一的请求-响应模式

模式抽象
python 复制代码 
class Protocol:
    """协议的抽象基类"""

    def __init__(self, tracker, lock):
        self.tracker = tracker
        self.lock = lock

    def create_request(self, **kwargs) -> str:
        """创建请求"""
        req_id = str(uuid.uuid4())[:8]
        with self.lock:
            self.tracker[req_id] = {
                "status": "pending",
                **kwargs
            }
        return req_id

    def respond(self, req_id: str, approve: bool, **kwargs) -> bool:
        """响应请求"""
        with self.lock:
            if req_id in self.tracker:
                self.tracker[req_id]["status"] = "approved" if approve else "rejected"
                self.tracker[req_id].update(kwargs)
                return True
        return False

    def get_status(self, req_id: str) -> str:
        """获取状态"""
        with self.lock:
            return self.tracker.get(req_id, {}).get("status", "unknown")
关闭协议实现
python 复制代码 
class ShutdownProtocol(Protocol):
    """关闭协议"""

    def request_shutdown(self, target: str) -> tuple[str, str]:
        """请求关闭"""
        req_id = self.create_request(target=target)
        BUS.send(
            "lead", target,
            "Please shut down gracefully.",
            "shutdown_request",
            {"request_id": req_id}
        )
        return req_id, "pending"

    def respond_shutdown(self, req_id: str, approve: bool, reason: str = "") -> str:
        """响应关闭请求"""
        if self.respond(req_id, approve, reason=reason):
            BUS.send(
                "teammate", "lead", reason,
                "shutdown_response",
                {"request_id": req_id, "approve": approve}
            )
            return f"Shutdown {'approved' if approve else 'rejected'}"
        return "Error: Invalid request_id"
计划审批协议实现
python 复制代码 
class PlanApprovalProtocol(Protocol):
    """计划审批协议"""

    def submit_plan(self, sender: str, plan: str) -> tuple[str, str]:
        """提交计划"""
        req_id = self.create_request(from=sender, plan=plan)
        BUS.send(
            sender, "lead", plan,
            "plan_approval_response",
            {"request_id": req_id, "plan": plan}
        )
        return req_id, "pending"

    def review_plan(self, req_id: str, approve: bool, feedback: str = "") -> str:
        """审查计划"""
        with self.lock:
            req = self.tracker.get(req_id)
        if not req:
            return f"Error: Unknown request_id '{req_id}'"

        if self.respond(req_id, approve, feedback=feedback):
            BUS.send(
                "lead", req["from"], feedback,
                "plan_approval_response",
                {"request_id": req_id, "approve": approve, "feedback": feedback}
            )
            return f"Plan {self.tracker[req_id]['status']} for '{req['from']}'"
        return "Error: Invalid request_id"

协议的扩展性

添加新协议
python 复制代码 
# 例如：添加代码审查协议
class CodeReviewProtocol(Protocol):
    """代码审查协议"""

    VALID_MSG_TYPES = {"code_review_request", "code_review_response"}

    def request_review(self, author: str, file_path: str) -> tuple[str, str]:
        """请求代码审查"""
        req_id = self.create_request(author=author, file_path=file_path)
        BUS.send(
            author, "lead", f"Please review {file_path}",
            "code_review_request",
            {"request_id": req_id, "file_path": file_path}
        )
        return req_id, "pending"

    def respond_review(self, req_id: str, approve: bool, comments: str = "") -> str:
        """响应代码审查"""
        with self.lock:
            req = self.tracker.get(req_id)
        if not req:
            return f"Error: Unknown request_id '{req_id}'"

        if self.respond(req_id, approve, comments=comments):
            BUS.send(
                "lead", req["author"], comments,
                "code_review_response",
                {"request_id": req_id, "approve": approve, "comments": comments}
            )
            return f"Review {self.tracker[req_id]['status']}"
        return "Error: Invalid request_id"

实战应用场景

场景1：优雅的系统关闭

背景
复制代码 
团队正在处理重要任务，需要优雅关闭所有队友：
- 让队友完成当前工作
- 保存进度和状态
- 清理临时文件
- 关闭数据库连接等资源
执行流程
python 复制代码 
# 1. 查看当前团队状态
list_teammates()
# Team: default
#   alice (coder): working
#   bob (tester): working
#   charlie (writer): idle

# 2. 依次请求关闭
shutdown_request(teammate="alice")
# Shutdown request abc123 sent to 'alice' (status: pending)

# Alice可能拒绝
[alice] shutdown_response:
  request_id: "abc123"
  approve: false
  reason: "I'm in the middle of a critical refactoring, please give me 5 minutes"

# Lead等待后重试
# ... 5分钟后 ...
shutdown_request(teammate="alice")
# Shutdown request def456 sent to 'alice' (status: pending)

# Alice批准
[alice] shutdown_response:
  request_id: "def456"
  approve: true
  reason: "Refactoring completed, ready to shut down"

# Alice清理资源并退出
# [alice] bash: git commit -am "Save progress before shutdown"
# [alice] status -> shutdown

# 继续关闭其他队友
shutdown_request(teammate="bob")
shutdown_request(teammate="charlie")

# 3. 验证所有队友已关闭
list_teammates()
# Team: default
#   alice (coder): shutdown
#   bob (tester): shutdown
#   charlie (writer): shutdown

场景2：高风险变更的审批

背景
复制代码 
需要重构核心支付模块，这是高风险变更：
- 影响所有用户交易
- 不能有丝毫差错
- 需要详细的计划和安全审查
执行流程
python 复制代码 
# 1. 创建专门的队友
spawn_teammate(
    name="security_expert",
    role="security_architect",
    prompt="You are a security architect. Refactor the payment module with extreme care."
)

# 2. 专家提交详细计划
[security_expert] plan_approval:
  plan: """
  支付模块重构安全计划：

  1. 风险评估：
     - 影响范围：所有在线交易
     - 潜在损失：无法估计
     - 回滚方案：完整的数据备份

  2. 重构步骤：
     a. 创建备份分支
     b. 实现新的加密算法（AES-256-GCM）
     c. 添加交易日志和审计追踪
     d. 实现双阶段提交
     e. 压力测试和安全审计

  3. 测试计划：
     - 单元测试覆盖率 > 95%
     - 集成测试场景 > 50
     - 安全渗透测试
     - 性能基准测试

  4. 部署计划：
     - 灰度发布：5% -> 20% -> 50% -> 100%
     - 实时监控和告警
     - 快速回滚机制

  预计耗时：3天
  风险等级：高
  """
# 返回: "Plan submitted (request_id=high_risk_001). Waiting for lead approval."

# 3. Lead仔细审查
# Lead可能需要更多信息
read_inbox()  # 查看计划详情
# 发现计划很详细，但需要补充

# Lead拒绝并要求补充
plan_approval(
    request_id="high_risk_001",
    approve=False,
    feedback="""
    计划整体很好，但需要补充：

    1. 回滚方案的详细步骤
    2. 灰度发布的具体指标和阈值
    3. 紧急情况的联系人名单
    4. 合规性检查清单

    请补充后重新提交。
    """
)

# 4. 专家补充计划
[security_expert] plan_approval:
  plan: """
  支付模块重构安全计划（补充版）：
  ... 原计划 ...
  5. 回滚方案详细步骤：
     a. 停止新版本流量
     b. 恢复数据库到备份点
     c. 重启旧版本服务
     d. 验证数据一致性

  6. 灰度发布指标：
     - 错误率 < 0.01%
     - 响应时间 < 200ms
     - 交易成功率 > 99.9%
     - 回滚触发：任一指标不满足

  7. 紧急联系人：
     - 技术负责人：张三 (138xxxx1234)
     - 运维负责人：李四 (139xxxx5678)
     - 安全负责人：王五 (136xxxx9012)

  8. 合规性检查：
     - PCI DSS合规性检查
     - 数据加密标准验证
     - 审计日志完整性
  """

# 5. Lead批准执行
plan_approval(
    request_id="high_risk_002",
    approve=True,
    feedback="计划非常完善，批准执行！请严格按照计划执行，每完成一个阶段报告进度。"
)

# 6. 专家开始执行，定期报告
[security_expert] send_message:
  to: "lead"
  content: "阶段1完成：备份分支已创建，数据备份成功"
# ... 持续报告 ...

场景3：多人协作的复杂项目

背景
复制代码 
开发一个复杂的电商系统，需要多个队友协作：
- 前端开发：UI/UX
- 后端开发：API和业务逻辑
- 数据库工程师：数据库设计
- 测试工程师：测试用例
- 运维工程师：部署和监控
执行流程
python 复制代码 
# 1. 创建完整团队
spawn_teammate("frontend_dev", "frontend", "Develop React frontend for e-commerce")
spawn_teammate("backend_dev", "backend", "Develop RESTful API and business logic")
spawn_teammate("db_engineer", "database", "Design and optimize database schema")
spawn_teammate("qa_engineer", "testing", "Create comprehensive test suite")
spawn_teammate("devops_engineer", "devops", "Setup CI/CD and monitoring")

# 2. 每个队友提交计划
[frontend_dev] plan_approval:
  plan: "前端开发计划：React + TypeScript, 组件化设计..."

[backend_dev] plan_approval:
  plan: "后端开发计划：Python FastAPI, JWT认证, 数据库ORM..."

[db_engineer] plan_approval:
  plan: "数据库设计计划：PostgreSQL, 索引优化, 读写分离..."

# 3. Lead依次审查
plan_approval(request_id="xxx", approve=True, feedback="前端计划批准")
plan_approval(request_id="yyy", approve=True, feedback="后端计划批准，注意API安全")
plan_approval(request_id="zzz", approve=True, feedback="数据库设计批准")

# 4. 团队开始协作
# 前端需要API文档
[frontend_dev] send_message:
  to: "backend_dev"
  content: "请提供API文档，我需要接口定义"

# 后端提供API文档
[backend_dev] send_message:
  to: "frontend_dev"
  content: "API文档已生成，见 /docs/api.md"

# 测试工程师开始编写测试
[qa_engineer] plan_approval:
  plan: "测试计划：单元测试 + 集成测试 + E2E测试"

# 5. 定期同步会议
broadcast("daily standup: 大家报告今天的进度")

# 6. 遇到阻塞时提交新计划
[db_engineer] plan_approval:
  plan: "需要调整数据库schema以支持新功能..."

# 7. 项目完成后关闭团队
shutdown_request(teammate="frontend_dev")
shutdown_request(teammate="backend_dev")
# ... 依次关闭 ...

演进路线图

s01 → s10的完整演进

复制代码 
s01: 基础Agent Loop
├── LLM调用循环
└── 简单的交互

s02: 工具系统
├── 4个基础工具（bash, read, write, edit）
├── 工具分发机制
└── 工具结果处理

s03: 记忆系统
├── 长期记忆
├── 向量存储
└── 语义检索

s04: 子智能体
├── 临时创建
├── 执行后返回
└── 自动销毁

s05: 技能加载
├── 动态技能加载
├── 技能市场
└── 可扩展能力

s06: 上下文压缩
├── 智能摘要
├── 关键信息提取
└── Token优化

s07: 任务系统
├── 任务分解
├── 优先级管理
└── 进度跟踪

s08: 后台任务
├── 非阻塞执行
├── 通知队列
└── 并行处理

s09: 多智能体团队 🆕
├── 持久化队友
├── 消息传递
├── 独立线程
└── 自由协作

s10: 团队协议 🆕🆕
├── 关闭协议
├── 计划审批协议
├── 请求-响应模式
└── 状态机管理

s11: (待定)
└── ...

s12: (待定)
└── ...

关键演进节点

s08 → s09：从单智能体到多智能体

核心突破：

python 复制代码 
# s08: 单智能体 + 后台任务
# 问题：只有一个大脑，无法同时处理不同领域的任务

# s09: 多智能体团队
# 解决：每个队友专注自己的领域，通过消息协作
s09 → s10：从自由协作到结构化协议

核心突破：

python 复制代码 
# s09: 自由协作
# 问题：缺少约束，可能执行危险操作，无法优雅关闭

# s10: 结构化协议
# 解决：引入审批机制和优雅关闭流程

设计原则的演进

复制代码 
s01-s02: 简单性
└── "能用就行"

s03-s07: 功能性
└── "功能完善"

s08-s09: 扩展性
└── "能力扩展"

s10: 可控性
└── "安全可控"

总结

s10的核心价值

  1. 安全性提升

    • 计划审批防止危险操作
    • 优雅关闭避免数据丢失

  2. 可控性增强

    • 结构化的请求-响应流程
    • 状态机保证流程正确性

  3. 可扩展性

    • 统一的协议模式
    • 易于添加新协议

  4. 可维护性

    • 清晰的代码结构
    • 易于调试和追踪

从s09到s10的增量

方面 增量 价值
代码 +81行 安全性提升
工具 +3个 协议支持
概念 +2个协议 结构化协作
复杂度 轻微增加 收益远大于成本

设计哲学

"复杂性的增长应该是渐进的，每个新增功能都应该解决明确的痛点"

s10完美体现了这一哲学：

  • 解决了s09的明确痛点（关闭和审批）
  • 增量小，价值大
  • 为后续扩展打下基础

未来展望

基于s10的协议模式，未来可以扩展：

  • 🔄 代码审查协议：代码提交前必须经过审查
  • 📊 资源分配协议：计算资源的申请和分配
  • 🔐 权限管理协议：敏感操作的权限验证
  • 📈 性能监控协议：性能指标的实时监控
  • 🚨 异常处理协议：异常情况的标准化处理

核心模式不变，协议场景扩展。

附录：完整对比表

代码结构对比

组件 s09 s10 说明
全局变量
WORKDIR ✅ ✅ 工作目录
client ✅ ✅ Anthropic客户端
MODEL ✅ ✅ 模型名称
TEAM_DIR ✅ ✅ 团队目录
INBOX_DIR ✅ ✅ 收件箱目录
SYSTEM ✅ ✅ 系统提示词（内容变化）
VALID_MSG_TYPES ✅ ✅ 消息类型（使用变化）
shutdown_requests ❌ ✅ 🆕 关闭请求追踪
plan_requests ❌ ✅ 🆕 计划请求追踪
_tracker_lock ❌ ✅ 🆕 线程安全锁
BUS ✅ ✅ 消息总线
TEAM ✅ ✅ 队友管理器
类
MessageBus ✅ ✅ 消息总线（无变化）
TeammateManager ✅ ✅ 队友管理器（内部变化）
函数
handle_shutdown_request ❌ ✅ 🆕 处理关闭请求
handle_plan_review ❌ ✅ 🆕 处理计划审查
_check_shutdown_status ❌ ✅ 🆕 检查关闭状态
_safe_path ✅ ✅ 路径安全检查
_run_bash ✅ ✅ 执行bash命令
_run_read ✅ ✅ 读取文件
_run_write ✅ ✅ 写入文件
_run_edit ✅ ✅ 编辑文件
agent_loop ✅ ✅ Agent循环（无变化）
工具
Lead工具（9→12）
bash ✅ ✅ 基础工具
read_file ✅ ✅ 基础工具
write_file ✅ ✅ 基础工具
edit_file ✅ ✅ 基础工具
spawn_teammate ✅ ✅ 创建队友
list_teammates ✅ ✅ 列出队友
send_message ✅ ✅ 发送消息
read_inbox ✅ ✅ 读取收件箱
broadcast ✅ ✅ 广播消息
shutdown_request ❌ ✅ 🆕 请求关闭
shutdown_response ❌ ✅ 🆕 检查关闭状态
plan_approval ❌ ✅ 🆕 审批计划
Teammate工具（6→8）
bash ✅ ✅ 基础工具
read_file ✅ ✅ 基础工具
write_file ✅ ✅ 基础工具
edit_file ✅ ✅ 基础工具
send_message ✅ ✅ 发送消息
read_inbox ✅ ✅ 读取收件箱
shutdown_response ❌ ✅ 🆕 响应关闭
plan_approval ❌ ✅ 🆕 提交计划

功能对比

功能 s09 s10 改进
队友管理
创建队友 ✅ ✅ 无变化
列出队友 ✅ ✅ 无变化
删除队友 ❌ ⚠️ 通过shutdown实现
通信
点对点消息 ✅ ✅ 无变化
广播消息 ✅ ✅ 无变化
协议
关闭协议 ❌ ✅ 🆕 新增
计划审批 ❌ ✅ 🆕 新增
安全
优雅关闭 ❌ ✅ 🆕 新增
操作审批 ❌ ✅ 🆕 新增
资源清理 ⚠️ ✅ 🆕 改进
追踪
请求追踪 ❌ ✅ 🆕 新增
状态管理 ⚠️ ✅ 🆕 改进
并发安全 ⚠️ ✅ 🆕 改进

通过s10的协议机制，多智能体系统从"自由协作"进化到了"结构化协作"，为构建安全、可控、可靠的多智能体应用奠定了基础。

下是您提供的相关文章的链接，可直接点击阅读：

相关推荐
花千树-0102 小时前
Proposer-Critic 多轮辩论：两个 LLM Agent 用 loop() 逼近共识
langchain·agent·ai编程·skill·multi-agent·claude code·ai 工程化
秋堂主4 小时前
Claude Code记忆系统
cc·claude code
乾坤瞬间4 小时前
【claude code 如何构建 agent 实践1】Agent Loop 永动机与工具扩展机制详解[S02]
claude code·code agent
布朗克1688 小时前
Claude Code 进阶玩法：MCP集成、自定义配置与团队协作
arcgis·claude code
qq_gpp1 天前
【Claude Code】Claude Code 的 Checkpoint 是怎么实现的
checkpoint·claude code·rewind
乾坤瞬间1 天前
【claude code agent 实践7】后台任务机制深度解析: 从S02到S08的演进
claude code·code agent
lunatic71 天前
Claude Code && Codex的安装方法
ai·codex·claude code
且去填词1 天前
Claude Code Skills 实践：从提示词到专业化 AI 开发工作流
人工智能·ai编程·开发·claude code·skills
dozenyaoyida1 天前
Claude Code Token 瓶颈破解：让 AI 编码永不中断的完整方案
token·上下文·claude code·ai记忆
热门推荐
01GitHub 镜像站点02Codex 接入 DeepSeek API 完整配置文档03CC-Switch & Claude 基于 Linux 服务器安装使用指南04【AI】2026 年具身智能模型和世界模型总结05零基础教你claude code 接入 deepseek V406Cursor 接入 DeepSeek‑V4‑Pro 完整指南（2026 实测）07codex app每次打开重连5次Reconnecting问题解决08裂开！ChatGPT 居然开始要手机号验证，附详细解决方法09Windows端Codex接入第三方模型（DeekSeek，BaiLian)10AI科技热点日报 | 2026年5月11日