热榜都在搞多 Agent 协作，我用 3 个模型搭了个系统才发现：最大的坑是并发

ofox
0 阅读5分钟

今天刷掘金热榜，满屏都是多 Agent、OpenClaw、GLM-5……好家伙，AI Agent 开发彻底从"概念吹水"进入"真刀真枪写代码"阶段了。

我也跟着折腾了两天，搭了个 3 模型协作的 Agent 系统。结果呢？代码逻辑写了 2 小时，被各家 API 的并发限制折腾了 2 天 😅

分享一下踩坑过程，给同样在搞 Agent 开发的兄弟们避避雷。

我要搭的东西

需求很简单：一个内容分析 Agent 系统，3 个角色协作：

  • Researcher：负责信息检索和初步整理（用便宜快速的模型）
  • Analyzer：深度分析和推理（用最强模型）
  • Writer：内容生成和润色（用性价比高的模型）

架构图大概长这样：

用户输入 → Researcher(DeepSeek) → 检索结果
                                      ↓
                            Analyzer(Claude) → 分析报告
                                      ↓
                             Writer(GPT-4o) → 最终输出

看起来很清晰对吧？来，开始踩坑。

坑一：国产模型并发限制，3 个就封顶

先从 Researcher 开始。我选了 DeepSeek V3，便宜，速度也快，跑检索任务绰绰有余。

代码写好了，单条请求丝滑得不行。然后我加了并发——

import asyncio
from openai import AsyncOpenAI

client = AsyncOpenAI(
    api_key="sk-xxx",
    base_url="https://api.deepseek.com/v1"
)

async def research(query: str):
    response = await client.chat.completions.create(
        model="deepseek-chat",
        messages=[{"role": "user", "content": f"检索并整理关于 {query} 的信息"}],
        stream=True
    )
    result = ""
    async for chunk in response:
        if chunk.choices[0].delta.content:
            result += chunk.choices[0].delta.content
    return result

# Researcher 要同时跑 5 个子任务
async def main():
    tasks = ["市场趋势", "竞品分析", "用户画像", "技术方案", "风险评估"]
    results = await asyncio.gather(*[research(t) for t in tasks])
    return results

跑起来，前 3 个任务正常返回，第 4 个直接报 429：

openai.RateLimitError: Error code: 429 - Rate limit reached

我一查，好家伙——DeepSeek 企业账号并发也就给 3-5。问了几个开发者群，大家情况一样。MiniMax、GLM-5、Kimi 2.5 都差不多，国产模型算力紧张，并发全部卡得死死的。

这我理解，算力确实稀缺。但搞 Agent 开发你不给并发，这不是让我拿跑车在胡同里开吗？

坑二：多模型切换，API 格式不统一

好吧，并发不够那就串行。但 Analyzer 要用 Claude，Writer 用 GPT-4o——三家 API 的调用方式全不一样：

# DeepSeek - OpenAI 格式，但有自己的特殊参数
deepseek_client = AsyncOpenAI(base_url="https://api.deepseek.com/v1")

# Claude - 完全不同的 SDK
import anthropic
claude_client = anthropic.AsyncAnthropic()

# GPT-4o - OpenAI 原版
openai_client = AsyncOpenAI()

三个 client，三套错误处理，三种 token 计算方式。光是统一 response 格式就写了一堆 adapter：

def normalize_response(provider: str, response) -> str:
    if provider == "deepseek":
        return response.choices[0].message.content
    elif provider == "claude":
        return response.content[0].text
    elif provider == "openai":
        return response.choices[0].message.content
    # ... 还有 Kimi、GLM 各种特殊情况

写到这里我就在想：2026 年了，搞个 AI Agent 还要自己糊这种胶水代码？

坑三：Agent 间协作的重试地狱

多 Agent 系统最头疼的是——任意一个环节挂了，整条链路怎么处理？

我最开始写的朴素版：

async def pipeline(user_input: str):
    try:
        research_result = await research(user_input)      # 可能 429
        analysis = await analyze(research_result)          # 可能超时
        final = await write(analysis)                      # 可能格式不对
        return final
    except Exception as e:
        return f"出错了: {e}"

实际跑了一天，三个问题全中：

  1. DeepSeek 429 了，整个流程重跑？后面的 Claude 调用可不便宜
  2. Claude Opus 偶尔超时（思考时间长），重试一次就好，但不能无限重试
  3. GPT-4o 偶尔输出格式不对，需要让它重新生成

最后搞了个带断点续传的重试逻辑：

async def pipeline_with_retry(user_input: str):
    cache = {}  # 每步结果缓存，失败只重试失败的那步

    steps = [
        ("research", lambda: call_model("deepseek-chat", [...])),
        ("analyze",  lambda: call_model("claude-opus-4-6", [...])),
        ("write",    lambda: call_model("gpt-4o", [...]))
    ]

    for step_name, step_func in steps:
        for attempt in range(3):
            try:
                cache[step_name] = await asyncio.wait_for(step_func(), timeout=60)
                break
            except asyncio.TimeoutError:
                print(f"⏰ {step_name} 超时，重试 {attempt + 1}/3")
            except Exception as e:
                if "429" in str(e):
                    wait = 2 ** attempt
                    print(f"🚫 {step_name} 限流，等 {wait}s")
                    await asyncio.sleep(wait)
                else:
                    raise
        else:
            raise RuntimeError(f"{step_name} 重试 3 次仍失败")

    return cache["write"]

这段代码跑起来确实稳了。但说实话工程量不小，而且每加一个模型供应商，就要多一套错误处理。

最后的解决方案：统一 API 网关

折腾两天后我开始反思：我到底是在写业务逻辑，还是在写 API 对接代码？

后来试了个思路——用一个支持多模型的 API 聚合服务统一接入：

# 所有模型走同一个 client
client = AsyncOpenAI(
    api_key="sk-xxx",
    base_url="https://api.ofox.ai/v1"
)

async def call_model(model: str, messages: list):
    response = await client.chat.completions.create(
        model=model,
        messages=messages
    )
    return response.choices[0].message.content

# 三个 Agent，一行代码切模型
research_result = await call_model("deepseek-chat", research_msgs)
analysis = await call_model("claude-opus-4-6", analyze_msgs)
final = await call_model("gpt-4o", write_msgs)

三个模型，一个 client，一套错误处理。 之前写的那堆 adapter 全删了。

并发问题也解决了——5 个并发请求不再 429。猜测原因是后端聚合了多个上游渠道（Anthropic、Bedrock、Vertex 都接了），单个渠道限流会自动切换。对我来说就是个黑盒，能用就行。

国内直连延迟也还行，走的阿里云节点，比裸连海外 API 快不少。

给在搞 Agent 开发的兄弟几个建议

  1. 别一上来就 5 个 Agent 协作。先单 Agent 跑通，再加节点。我见过太多人上来就画复杂架构图，连单个 Agent 都没调通
  2. 选模型看实际任务，别看跑分。GLM-5 跑分快追上 Claude 了，但实测复杂任务差距还是明显的。应试和干活是两回事
  3. 并发限制是 Agent 开发的隐形杀手。单请求感觉不到，一上多 Agent 立刻暴露。要么提前规划串行流程，要么找支持多渠道聚合的 API
  4. 统一 API 格式能省巨大工作量。自己维护 N 套 SDK 的成本，会随着模型数量指数增长
  5. 做好每一步的缓存和断点续传。多 Agent 流水线任何一步都可能失败，别让一个 429 毁掉整条链路

最后

多 Agent 协作确实是趋势，今天热榜这波讨论很有价值。但从"Demo 跑通"到"生产可用"，中间全是工程细节。

希望这些踩坑记录能帮到正在搞 AI Agent 开发的你。有问题评论区聊 👇

我是 ofox，一个在 AI 工程化路上反复踩坑的开发者。关注我，少走弯路。

avatar
文章
阅读
粉丝