如何设计多agent 的协作和动态切换机制

协作主要是消息传递和共享状态，消息传递通过中间件实现消息的传递，这个共享状态通过共同读写一个状态对象，实现这个消息的传递

动态切换主要通过两种方式，一种是静态路由，根据消息类型判断给那个agent, 另一种LLM动态决策

claude code 如何做上下文压缩

1.大结果存磁盘 agent 调用一个read ，如果超过50kb，就讲工具结果写入磁盘，只给模型留下2kb 预览 2.snip 砍掉远古消息，对话前面的探索式提问可能已经没有用了。snip 负责这个把它删除掉，不过删除消息不是写死的规则，而是专门有个snip 返回没有用的消息ID，然后执行工具删除。 3.Micro-compact 时间衰减，就是上次APi 调用超过60分钟触发，只保留最近5个的工具结果，以及子agent ,TASK 这类不可重复的结果绝对不裁剪。 4.Context Collapse 读时投影 上下文达到90%触发，95%时升级，不修改原始消息，只在调用API的那一刻动态计算一个压缩视图给模型，原始对话 在本地保留，模型看到的是压缩版 5. Auto-Compact 全量摘要，上下文逼近窗口上限时触发，具体阈值时从原始窗口中留出约33k缓冲，由20k摘要输出和13冗余组成，把整段对话全部送进摘要器重写一份， 配置做文件恢复，缓存清理，消息重组。

如何设计多 Agent 的协作和动态切换机制

多 Agent 系统要解决两个问题：Agent 之间怎么协作（交换信息），以及当前任务该交给哪个 Agent 处理（切换）。前者主要靠消息传递和共享状态，后者主要靠规则路由或 LLM 决策。

一、协作机制

1. 消息传递

Agent 之间通过消息通信，每个 Agent 只处理发给自己的消息，再把结果发给下一个。消息可以走进程内的队列，也可以借助 Redis、Kafka 等中间件实现跨服务通信。

• 优点：Agent 之间松耦合，便于独立扩展和替换。
• 缺点：信息分散在各条消息里，全局上下文不好追踪。

2. 共享状态

所有 Agent 读写同一个状态对象（也叫黑板模式），比如一个包含任务目标、已完成步骤、中间结果的结构。LangGraph 就是这种思路：图中每个节点是一个 Agent，读取 State、处理后写回 State。

class TaskState(TypedDict):
    question: str
    plan: list[str]
    search_results: list[str]
    draft: str
    next_agent: str

• 优点：上下文集中，任何 Agent 都能看到全局进度。
• 缺点：要注意并发写冲突，状态太大时会占用上下文窗口。

实际系统中两者常常结合使用：用共享状态保存全局进度，用消息传递触发具体任务。

二、动态切换机制

1. 静态路由

按预先定义的规则决定交给哪个 Agent，比如根据消息类型、关键词或任务阶段：

def route(state: TaskState) -> str:
    if not state["plan"]:
        return "planner"
    if not state["search_results"]:
        return "researcher"
    return "writer"

速度快、结果可预测、便于调试，但只能覆盖事先想到的情况。

2. LLM 动态决策

由一个主管（Supervisor）Agent 根据当前状态，让大模型判断下一步该调用哪个 Agent，或者判断任务是否已经完成。它能处理开放、复杂的任务，但有额外的延迟和 token 开销，结果也不完全可控。

常见做法是两者结合：确定性的流程用规则路由，模糊的分支交给 LLM 判断，同时设置最大轮次，防止 Agent 之间来回踢皮球陷入死循环。

三、设计时要注意

• 职责单一：每个 Agent 只负责一类任务，工具和提示词也只配它需要的部分。
• 上下文控制：交接时只传必要信息或摘要，避免上下文膨胀。
• 终止条件：明确什么情况下任务算完成，以及超过多少轮强制结束。
• 可观测性：记录每次切换的原因和输入输出，方便排查问题。

总结

多 Agent 协作靠消息传递和共享状态交换信息；动态切换靠静态路由或 LLM 决策选择下一个执行者。工程上通常是规则加 LLM 混合使用，并配合上下文裁剪、终止条件和日志追踪，保证系统可控。

---

📮 联系方式

微信：BuZhiCoder　｜　QQ：1776418445　扫码添加，备注「求职」优先通过