1. 从一次真实踩坑说起为什么单 Agent 撑不住复杂任务我试过把「写代码 查安全 改文档」全塞进一个提示词里结果模型顾此失彼安全漏洞没查出来文档还写跑偏了。后来翻到 Anthropic 那篇讲 Agent 常见工作流的博客才意识到问题不在模型能力而在任务编排方式。Agent 模式本质上就是「怎么把一个大任务拆给一个或多个模型调用去完成」拆得好准确率和速度都上来拆得不好Token 翻倍、延迟爆炸、结果还互相打架。这篇聚焦三种最常用的模式Sequential 串行、Parallel 并行、Evaluator-Optimizer 评估优化。它们分别解决「步骤有依赖」「子任务独立」「首稿质量不够」三类问题。我会用 TaoToken 的统一 Key 和 API 通道把三种模式都跑一遍给出可复制的配置片段和验证动作你能直接照着构造请求、观察输出差异、记录耗时和质量。适合谁看正在用 Claude Code、Cline、Codex 这类工具做 Agent 编排的开发者想把单次对话升级成多步骤工作流的人以及被「一个 Agent 干所有事」坑过、想搞清楚什么时候该拆、什么时候不该拆的人。核心检索词就三个Agent 串行模式、Agent 并行模式、Evaluator-Optimizer 评估优化循环下面逐个拆。先说结论性的判断标准省得你读完才发现选错模式。任务步骤之间有明确的数据依赖B 必须等 A 的输出用 Sequential子任务彼此独立、只是逐个跑太慢用 Parallel首稿质量稳定不达标、且有可衡量的质量标准用 Evaluator-Optimizer。反过来如果单 Agent 把步骤写进提示词就能达标那就别拆——Anthropic 博客里那句 Pro tip 说得很直白先试单 Agent够用就别加复杂度。这句话我踩过坑之后才真正理解多步骤工作流不是越复杂越好每多一个环节就多一份延迟和 Token 成本。TaoToken 在这里的角色是统一通道三种模式都要发多次模型请求如果每个请求都去配不同的 Key、不同的 Base URL调试成本会很高。用一套 Key 走同一个 API 端点切换模型、对比输出都方便。下面先把它接上再逐个模式跑通。2. TaoToken 前置准备统一 Key 与 API 通道怎么配TaoToken 是一个模型 API 聚合通道你可以把它理解成「一个 Base URL 一个 Key就能调用多种模型」的入口。对跑 Agent 模式来说这点很关键Sequential 链里可能前一步用便宜模型做草稿、后一步用强模型做润色Parallel 分支里可能同时调多个模型做多视角评估Evaluator-Optimizer 里生成器和评估器甚至可以用不同模型。如果每个模型都要单独申请 Key、单独配端点光是环境变量就够乱的。统一通道把这些收敛成一个base_url和一个api_key模型差异只体现在model字段上。先拿 Key。打开 https://taotoken.net/api-keys 登录后创建一个 API Key复制出来。注意这个 Key 只在创建时完整显示一次丢了就重新建一个。拿到之后记下两个东西Base URL 是https://taotoken.net/apiKey 是sk-开头的那串。接下来是配置。不同工具的配置文件路径不一样我按最常见的三种给你。如果你用 Claude Code配置在~/.claude/settings.json如果用 Cline配置在 VS Code 的settings.json里对应 Cline 的字段如果用 Codex配置在~/.codex/auth.json和~/.codex/config.toml。三件套永远是 Base URL、Key、Model ID缺一不可。先看 Claude Code 的settings.json这是最常被问的{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_AUTH_TOKEN: sk-你的Key, ANTHROPIC_MODEL: claude-sonnet-4-20250514 } }注意ANTHROPIC_BASE_URL后面不要加/v1TaoToken 的端点已经处理好了路径。Model ID 要写完整别只写claude-sonnet否则会报模型不存在。再看 Codex 的~/.codex/auth.json{ OPENAI_API_KEY: sk-你的Key }配套的~/.codex/config.tomlmodel_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key OPENAI_API_KEYCline 的话在设置界面里选「OpenAI Compatible」Base URL 填https://taotoken.net/apiAPI Key 填你的 KeyModel ID 填你要用的模型。Cline 的 MCP 配置如果也要走 TaoToken同样在这三件套里对齐。配完之后最直接的验证是发一个最小请求。用 curl 试curl https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer sk-你的Key \ -H Content-Type: application/json \ -d { model: claude-sonnet-4-20250514, messages: [{role: user, content: 回复 OK 两个字母}], max_tokens: 10 }返回里能看到choices[0].message.content是OK就说明通道通了。如果返回 401先检查 Key 有没有复制全、有没有多余空格如果返回local proxy failed检查 Base URL 是不是写成了https://taotoken.net/api/v1多了/v1会出问题如果返回reading choices相关错误多半是响应体不是标准 JSON检查请求头Content-Type有没有带上。这一步过了三种模式的实验环境就齐了。下面每个模式我都用同一套 Key只改请求体里的messages和model方便你对比。3. Sequential 串行模式可复制的依赖链配置与最小请求Sequential 模式的核心是「上一步的输出是下一步的输入」。典型场景是「草稿 → 审核 → 润色」这种流水线或者数据转换管道里每一阶段给下一阶段加值。它的代价是延迟叠加三步串行总耗时约等于三步之和。收益是每个 Agent 只专注一件事准确率通常比一个 Agent 兼顾所有事要高。什么时候该用任务能自然分解成有明确依赖的阶段时。什么时候不该用步骤之间没有依赖、可以并行时——那用 Parallel 更快。Anthropic 博客里那句建议我再强调一遍先试单 Agent把所有步骤写进一个提示词够用就别拆。只有当单 Agent 无法可靠处理时才拆成多步骤。下面构造一个最小串行链第一步生成一段产品描述草稿第二步基于草稿做事实核查第三步基于核查结果润色。三步用同一个模型但你可以换成不同模型。先写一个 Python 脚本把三步串起来import requests import time API_URL https://taotoken.net/api/v1/chat/completions API_KEY sk-你的Key HEADERS { Authorization: fBearer {API_KEY}, Content-Type: application/json } def call_model(prompt, modelclaude-sonnet-4-20250514): payload { model: model, messages: [{role: user, content: prompt}], max_tokens: 500 } resp requests.post(API_URL, headersHEADERS, jsonpayload, timeout60) resp.raise_for_status() return resp.json()[choices][0][message][content] # 第一步生成草稿 draft call_model(写一段 100 字的产品描述产品是一款智能水杯能提醒喝水并记录饮水量。) print(草稿, draft) # 第二步事实核查输入是草稿 fact_check call_model(f检查下面这段描述里有没有不实或夸大的表述逐条列出\n{draft}) print(核查, fact_check) # 第三步润色输入是草稿和核查结果 final call_model(f根据核查意见润色下面这段描述保持 100 字左右\n草稿{draft}\n核查意见{fact_check}) print(终稿, final)跑之前先记下开始时间跑完记结束时间这样能拿到串行链的总耗时。实测下来三步串行大概在 8 到 15 秒之间取决于模型和网络。如果你把三步合并成一个提示词让单 Agent 做耗时可能只有 3 到 5 秒但输出质量不一定稳定——这就是串行的权衡用延迟换准确率。关键点在于第二步和第三步的输入都依赖前一步的输出这就是「依赖关系」的体现。你不能把第二步和第一步并行因为核查需要草稿也不能把第三步和第二步并行因为润色需要核查意见。这种依赖链就是 Sequential 的适用边界。如果你想在 Claude Code 里跑这个串行链可以把三步写成三个 slash command或者用一个脚本调用。Cline 里可以用 MCP 把三步串成工具调用链。不管哪种方式Base URL、Key、Model ID 三件套保持一致就行。再给一个更贴近工程的例子代码生成流水线。第一步根据需求生成函数骨架第二步补全实现第三步写单元测试。三步串行每步的输出都是下一步的输入。这种场景下串行的收益很明显每步只做一件事模型不容易跑偏。代价是三步的 Token 都要花而且延迟叠加。如果你的需求很简单单 Agent 一次就能生成完整代码加测试那就别拆。串行模式还有一个容易忽略的点错误传播。如果第一步的输出有错后面两步会基于错误继续放大。所以串行链里最好在关键步骤加校验比如第二步核查发现草稿有严重问题时直接中断而不是继续润色。这个「中断条件」是串行链设计的一部分别省略。4. Parallel 并行模式多分支独立请求与聚合策略Parallel 模式解决的是「子任务独立、逐个跑太慢」的问题。典型场景是多维度评估、代码审查、大规模文档分析。它的代价是成本更高——多个并发 API 调用而且需要设计聚合策略。收益是速度快而且能实现关注点分离一个 Agent 只负责一个维度比一个 Agent 兼顾所有维度更准。什么时候该用任务能拆成独立子任务或者需要对同一个问题有多个视角时。什么时候不该用Agent 需要累积上下文、需要建立在彼此工作之上时资源受限或 API 并发效率低时没有明确策略处理矛盾返回时聚合结果过于复杂反而降低输出质量时。这四条「不该用」很实用我踩过第三条的坑两个分支给出矛盾结论我没设计好怎么合并最后输出自相矛盾。下面构造一个最小并行链同一段代码三个分支分别检查安全性、性能、可读性然后聚合三份意见。用 Python 的concurrent.futures并发发请求import requests from concurrent.futures import ThreadPoolExecutor import time API_URL https://taotoken.net/api/v1/chat/completions API_KEY sk-你的Key HEADERS { Authorization: fBearer {API_KEY}, Content-Type: application/json } CODE_SNIPPET def get_user(db, user_id): query SELECT * FROM users WHERE id user_id return db.execute(query) def review(dimension, code): prompt f从{dimension}角度审查下面这段代码列出问题\n{code} payload { model: claude-sonnet-4-20250514, messages: [{role: user, content: prompt}], max_tokens: 400 } resp requests.post(API_URL, headersHEADERS, jsonpayload, timeout60) resp.raise_for_status() return dimension, resp.json()[choices][0][message][content] dimensions [安全性, 性能, 可读性] start time.time() with ThreadPoolExecutor(max_workers3) as executor: results list(executor.map(lambda d: review(d, CODE_SNIPPET), dimensions)) elapsed time.time() - start for dim, result in results: print(f {dim} ) print(result) print(f并行总耗时{elapsed:.2f} 秒)三个分支同时发出总耗时约等于最慢那个分支的耗时而不是三者之和。实测下来三个分支并行大概 4 到 6 秒如果串行跑就是 12 到 18 秒。这就是并行的速度收益。但并行不是免费的。三个分支各花一份 Token总 Token 是单次的三倍。而且聚合策略要设计好如果安全性分支说「有 SQL 注入」性能分支说「查询没加索引」可读性分支说「变量名太短」这三条意见怎么合并成一份可执行的修改建议我的做法是让一个「聚合 Agent」读三份意见输出一份去重、排序后的修改清单。这个聚合步骤本身也是一次模型调用别忘了算进成本。聚合策略有几种常见做法。投票模式多个分支对同一问题给判断取多数。分段模式每个分支负责不同方面聚合时按方面罗列。加权模式不同维度给不同权重聚合时按权重排序。选哪种取决于你的场景。代码审查适合分段模式多维度评估适合加权模式内容审核适合投票模式。并行模式还有一个坑并发数别开太大。TaoToken 通道对并发有合理限制你开几十个并发可能触发限流。一般 3 到 5 个分支比较稳。如果分支更多分批并发。另外每个分支的max_tokens要设合理别让某个分支输出过长拖慢整体。什么时候不该用并行如果三个分支的结论需要互相参考才能得出那就不是独立子任务应该用串行。如果聚合逻辑复杂到需要再写一个 Agent 来合并而合并质量还不如单 Agent 一次做完那就退回单 Agent。Anthropic 博客里那句「聚合结果过于复杂降低输出质量」说的就是这个。5. Evaluator-Optimizer 评估优化迭代循环配置与停止条件Evaluator-Optimizer 模式把两个 Agent 配对成迭代循环一个生成内容另一个按标准评估生成器根据反馈优化直到达到质量阈值或最大迭代次数。核心洞察是「生成和评估是两种不同的认知任务」分开让各自专精——生成器专注产出评估器专注应用一致的质量标准。什么时候该用有明确且可衡量的质量标准且首稿和终稿差异足够大、能弥补 Token 消耗时。典型场景有具体要求的代码生成安全标准、性能基准、风格指南、专业沟通语气和精准度重要、任何首稿质量持续不达标的情形。什么时候不该用首稿已达标时别用否则白白迭代实时应用别用基础分类等简单任务别用评估标准过于主观、AI 评估器无法保持一致判断时别用有确定性工具如 Linter时优先用工具预算限制超过质量收益时别用。下面构造一个最小评估优化循环生成器写一个 SQL 查询评估器检查效率和安全性不达标就反馈给生成器重写最多迭代 3 次。用 Python 写import requests API_URL https://taotoken.net/api/v1/chat/completions API_KEY sk-你的Key HEADERS { Authorization: fBearer {API_KEY}, Content-Type: application/json } def call_model(prompt, modelclaude-sonnet-4-20250514): payload { model: model, messages: [{role: user, content: prompt}], max_tokens: 500 } resp requests.post(API_URL, headersHEADERS, jsonpayload, timeout60) resp.raise_for_status() return resp.json()[choices][0][message][content] REQUIREMENT 查询最近 30 天内下单超过 3 次的用户邮箱按订单数降序 MAX_ITER 3 QUALITY_THRESHOLD PASS draft call_model(f写一个 SQL 查询满足需求{REQUIREMENT}) print(首稿, draft) for i in range(MAX_ITER): evaluation call_model( f评估下面这个 SQL 查询是否满足需求{REQUIREMENT}\n f查询{draft}\n f检查效率和安全性。如果达标第一行输出 PASS否则第一行输出 FAIL并列出具体问题。 ) print(f第 {i1} 轮评估, evaluation) if evaluation.strip().startswith(QUALITY_THRESHOLD): print(达标停止迭代) break draft call_model( f根据评估意见重写 SQL 查询\n原查询{draft}\n评估意见{evaluation}\n需求{REQUIREMENT} ) print(f第 {i1} 轮重写, draft)这个循环里有两个「护栏」最大迭代次数MAX_ITER和质量阈值QUALITY_THRESHOLD。没有护栏评估器可能一直挑剔微小瑕疵生成器一直微调但输出质量早就进入平台期了Token 白花。Anthropic 博客里那句「要懂得什么时候够好就行」说的就是这个。实测下来这个 SQL 例子通常 1 到 2 轮就达标。首稿可能用了SELECT *或者没加索引提示评估器指出后重写版会改成具体字段并加LIMIT。如果 3 轮还没达标说明要么需求本身模糊要么评估标准太严这时候应该停下来检查标准而不是继续加迭代。评估器的提示词设计很关键。要让评估器输出结构化结果比如第一行固定PASS或FAIL后面跟具体问题。这样程序能自动判断是否停止。如果评估器输出自由文本程序没法可靠判断循环就失控了。另外评估标准要具体别写「检查质量」这种模糊要求要写「检查是否有 SQL 注入、是否用了 SELECT *、是否有索引提示」。什么时候该用这个模式首稿质量稳定不达标时。如果首稿已经能用跳过这个模式直接输出。如果评估标准可以用 Linter 这种确定性工具检查优先用工具别用模型评估——工具更快更便宜更一致。如果场景需要即时响应比如用户等待的实时对话这个模式的迭代延迟不可接受。6. 三种模式常见报错与排查对照跑这三种模式时报错集中在几个地方。我按真实遇到的错误逐个说。401 Unauthorized。最常见的原因是 Key 没复制全、有多余空格、或者用了过期的 Key。检查Authorization头是不是Bearer sk-xxx格式中间有空格。如果 Key 是对的还报 401检查是不是把 Key 写进了错误的字段比如 Claude Code 里应该用ANTHROPIC_AUTH_TOKEN不是ANTHROPIC_API_KEY。local proxy failed。这个错误通常和 Base URL 有关。检查是不是写成了https://taotoken.net/api/v1多了/v1会导致路径拼接错误。正确的 Base URL 是https://taotoken.net/api请求路径由 SDK 或工具自己拼。另外检查网络能不能通到taotoken.net用 curl 直接试一下。reading choices 相关错误。这个多半是响应体不是标准 JSON或者choices字段不存在。检查请求头Content-Type: application/json有没有带请求体是不是合法 JSON。如果用了流式输出响应格式不一样要按流式解析。还有一种情况是模型返回了错误信息而不是正常响应比如模型 ID 写错了这时候响应里没有choices要先打印完整响应体看错误信息。OAuth 相关错误。如果你用 Claude Code 且之前登录过官方账号可能会走 OAuth 流程而不是 API Key。检查settings.json里有没有残留的 OAuth 配置确保ANTHROPIC_AUTH_TOKEN生效。Codex 的auth.json里如果同时有 OAuth token 和 API Key可能冲突清掉 OAuth 部分。模型不存在。Model ID 写错或写简写会报这个。Claude 系列要写完整日期版本比如claude-sonnet-4-20250514。不同模型的 ID 不一样去 TaoToken 的文档页查准确的 Model ID。并发限流。Parallel 模式开太多并发会触发。把max_workers降到 3 到 5或者分批并发。如果必须高并发加退避重试。迭代不停止。Evaluator-Optimizer 里评估器一直输出 FAIL循环跑满最大次数。检查评估标准是不是太严或者生成器是不是没理解反馈。把评估器的输出格式固定成第一行 PASS/FAIL程序才能可靠判断。Token 超限。串行链或迭代循环里上下文越积越长可能超过模型上限。每步只传必要信息别把全部历史都塞进去。评估优化循环里重写时只传原查询和评估意见别传之前所有轮次。这些报错里401 和 local proxy failed 占了大多数。配好三件套Base URL、Key、Model ID能解决八成问题。剩下两成是提示词和聚合逻辑的问题需要按场景调。7. 选型建议与下一步从单 Agent 到多模式的演进路径三种模式不是互斥的实际项目里经常组合。比如一个代码审查 Agent外层是 Parallel 三个分支查安全、性能、可读性每个分支内部如果是复杂检查可以用 Sequential 串行链最后聚合时如果质量不够加一层 Evaluator-Optimizer 迭代。但组合越多成本和延迟越高别一上来就上全套。演进路径建议这样走。第一步单 Agent 把所有步骤写进提示词跑通看质量。第二步如果单 Agent 不稳定拆成 Sequential 串行链每步专注一件事。第三步如果串行链里有独立子任务拖慢速度把那部分改成 Parallel 并行。第四步如果某个环节首稿质量稳定不达标加 Evaluator-Optimizer 迭代。每一步都先验证收益大于成本再往下走。TaoToken 在这个演进过程里的价值是统一通道。你从单 Agent 走到多模式组合模型调用次数从 1 次变成 3 次、5 次甚至更多如果每次都要换 Key、换端点调试成本会指数上升。用一套 Key 走同一个 Base URL切换模型只改model字段对比不同模式的输出差异就方便很多。想验证模型对话效果可以去 https://taotoken.net/api 的模型对话页直接试想长期跑编码 AgentCoding Plan 更适合接入文档在 https://taotoken.net/api 的文档页有详细说明。最后给一个实用技巧记录每次实验的耗时和 Token 消耗。串行链记总耗时并行链记最慢分支耗时和总 Token评估优化循环记迭代轮数和总 Token。跑上十几次你就能对自己的场景形成直觉——什么任务值得拆、拆成哪种模式、成本大概多少。这个直觉比任何教程都值钱因为你的场景只有你自己最清楚。现在你可以拿上面的三段代码把sk-你的Key换成自己的先跑串行链再跑并行链最后跑评估优化循环对比三者的输出质量和耗时。跑完你就知道自己的任务该用哪种模式了。