跳到主要内容

去中心化模式

有了管理者模式，为什么还要去中心化模式？​

  • 动机一: 模拟人类社会的组织方式——让多个职责对等的角色分工与制衡，各自从自己的专业视角审视问题、自主决定与谁沟通;
  • 动机二: 解决稳定性问题——模型或 API 服务故障会让一些 Agent 停止响应、工具调用失败或陷入错误工具调用的死循环，而在管理者模式中管理者 Agent 崩溃往往是系统最大的单点故障;
  • 自主沟通的形态: 移交任务（"我的部分做完了，交给你"）、请求反馈（"这个方案技术上可行吗"）、报告问题（"你给的需求有矛盾，我们需要重新讨论"）;
  • 术语: 微服务领域把两者分别称为编排（orchestration，由指挥统一调度）与编舞（choreography，靠每位舞者自行把握入场时机）;

对等移交（handoff）的最小协议是什么？​

  • 载体: 每个 Agent 配备若干 handoff 选项，可以在任何时刻把控制权移交给网络中的任意其他 Agent，没有中心调度者;
  • 上下文规则: handoff 只应传递明确的任务包与产物引用，不默认暴露完整私有轨迹（与共享上下文协作相反）;
  • 风险: 成环——A 移交给 B，B 又移交回 A，任务在环路中空转，因此需要移交次数上限之类的保护机制;
  • 参考实现:
handoff = {
    task_id, sender, recipient, goal, constraints,
    accepted_facts, artifact_refs, remaining_budget,
    visited_agents
}

if recipient in handoff.visited_agents:
    reject("cycle")
elif handoff.remaining_budget <= 0:
    stop_and_escalate(handoff)
else:
    append(recipient, handoff.visited_agents)
    run_local_agent(handoff)
  • 设计含义: 它把"上下文隔离"变成可检查的接口——接收者读任务包与引用、按需取证；预算、访问链与循环检测由运行时保留，不能由任一 Agent 自行删除;

"Agent Swarm"一词对应哪些不同架构？​

  • 背景: 2025 年以来成为厂商热门词汇，但它并不对应单一架构;
用法实质代表
handoff 网络去中心化模式（本节所述）OpenAI Swarm、LangGraph 的 swarm 库、微软 Agent Framework 的 handoff 编排
规模化管理者模式orchestrator–worker 星型拓扑Kimi K2.5 首发的 Agent Swarm（主 Agent 动态创建上百个子 Agent 并行执行）、Anthropic 多 Agent 研究系统、Manus 的 Wide Research
  • Kimi 的做法: 把"何时拆、拆几个"的编排决策通过并行 Agent 强化学习直接训练进模型，K3 将其延续为独立模型档位并开源了配套的并行 Agent 训练沙箱 AgentEnv;
  • 规模数字: GTC 2026 上披露并行子 Agent 上限已扩展至 300 个;
  • 判断方法: 看清概念背后的实质，分析不同多 Agent 系统的实际结构，而不被名称迷惑;

同一台机器上的多个对等 Agent 如何协调？​

  • 与前几类的区别: 以上系统都在合作完成同一件事，还有一类去中心化是各干各的——每个 Agent 有自己的任务;
  • 通信目的: 不是为了分工，而是为了协调使用共享资源;
  • 能力: Claude Code 已支持同一台机器上的多个 Agent 互相发现（list_agents）并互相发消息;
  • 冲突实例: 两个 Agent 修改同一组文件时协商解决冲突；机器上只有一块 GPU 而两个实例都要跑训练时协调使用 GPU;
  • 演进方向: 进一步的演进是 Agent 社会，见 Agent 社会;