1. Agent 是什么为什么要多Agent智能体—— 能自主规划、调用工具、执行任务的 AI。跟普通的 LLM 调用不一样Agent 不只是你问我答它能自己决定下一步做什么。打个比方普通的 LLM 调用像客服热线你问一句它答一句Agent 更像你雇的助理——你说帮我调研竞品它会自己拆解任务、上网搜索、整理结果。两者的区别可以用一张表说清楚普通 LLM 调用Agent交互方式一问一答每次独立多轮自主决策外部工具需要人写代码串联自己决定调用哪个工具任务复杂度单步任务多步任务决策权人决定每一步AI 自己决定下一步那为什么要多 Agent原因有两个。一是专业化分工。把所有工具塞给一个 Agent就像让一个人同时当搜索工程师、数据分析师和报告撰写人。它哪个都能凑合但哪个都不精。拆成多个专门的 Agent每个只关注自己的领域Prompt 更短、工具更少、输出更稳定。二是并行效率。多个 Agent 可以同时干活。比如竞品调研搜索 5 个竞品的信息——一个 Agent 串行搜要五次五个 Agent 并行搜只要一次的时间。什么时候该用多 Agent一个简单的判断标准任务能拆成 2 个以上独立的子任务 → 考虑多 Agent子任务之间不需要频繁交换中间状态 → 适合多 Agent任务简单、步骤少、一个 Prompt 就能搞定 → 单 Agent 足够所有子任务必须共享同一份上下文 → 不适合多 Agent还有一个概念提一下MCPModel Context Protocol—— AI 与外部工具连接的开放标准。你可以理解为REST 是 Web API 的通用语言MCP 就是 AI 工具集成的通用语言。你只需要知道Agent 能自己调工具的 AI。当任务需要多种专业能力协作或者能拆成独立子任务并行处理时多 Agent 就有价值。代价是 Token 消耗会大幅增加。2. 从单 Agent 开始先搞定单 Agent理解它的运行机制。ReActAgent 的工作循环ReAct 模式Reasoning Acting—— Agent 的核心工作方式一个推理→执行→观察的循环。用做饭来类比看菜谱推理→ 切菜执行→ 尝味道观察→ 觉得淡了再加盐推理→ 加盐执行→ 再尝观察。Agent 的工作方式一模一样。写你的第一个 Agent完整代码import anthropic import json client anthropic.Anthropic() # 定义工具让 Agent 能搜索网页 tools [ { name: web_search, description: 搜索互联网获取实时信息。输入搜索关键词返回搜索结果摘要。, input_schema: { type: object, properties: { query: { type: string, description: 搜索关键词 } }, required: [query] } } ] def execute_tool(name: str, params: dict) - str: 工具执行入口——目前是模拟数据替换为 Tavily/SerpAPI 即可接入真实搜索 if name web_search: return f搜索{params[query]}的结果这里是模拟的搜索结果... return 未知工具 def run_agent(task: str) - str: 运行单 Agent 的 ReAct 循环 messages [{role: user, content: task}] while True: response client.messages.create( modelclaude-sonnet-4-20250514, max_tokens4096, toolstools, messagesmessages, ) # Agent 决定任务完成返回结果 if response.stop_reason end_turn: for block in response.content: if hasattr(block, text): return block.text # 安全兜底max_tokens 截止时也返回已有内容 if response.stop_reason max_tokens: for block in response.content: if hasattr(block, text): return block.text return Agent 输出被截断请增大 max_tokens # Agent 要求调用工具 tool_results [] for block in response.content: if block.type tool_use: result execute_tool(block.name, block.input) tool_results.append({ type: tool_result, tool_use_id: block.id, content: result, }) # 把 Agent 的回复和工具结果都加到对话历史 messages.append({role: assistant, content: response.content}) messages.append({role: user, content: tool_results}) # 试一下 result run_agent(搜索一下 2026 年最流行的 Python Web 框架有哪些) print(result)这段代码的核心是定义工具——ReAct 循环——对话历史——PromptAgent 自动规划搜索顺序——你不需要告诉它先搜 FastAPI 再搜 Django。3. 升级到多 Agent搞定了单 Agent。但当任务涉及多个领域——比如既要搜索信息、又要分析数据、还要生成报告——一个 Agent 的 Prompt 就得又长又复杂。每加一个工具它对每个工具的理解都会被稀释一点。这时候多 Agent 就有意义了。编排器-子 Agent 架构多 Agent 系统的核心架构叫Orchestrator-Subagent编排器-子 Agent。编排器Orchestrator—— 负责任务分配和协调的主 Agent。像项目经理不亲自干活负责拆解任务、分配给合适的人、汇总结果。子 AgentSubagent—— 执行具体任务的专门 Agent。每个只管自己的领域。上下文隔离为什么要分开这里有个关键设计上下文隔离Context Isolation—— 每个 Agent 有独立的对话历史互不干扰。上下文隔离就像分会议室开会——每个人先在自己的小会议室研究自己的部分最后只向项目经理汇报结论。不需要知道其他人搜了什么、看了哪些资料。在技术层面上下文隔离带来两个好处每个 Agent 的上下文窗口只包含自己需要的信息不会被其他任务的内容稀释子 Agent 只返回压缩后的结论给编排器不是把搜索中的所有中间结果都传回去代码实现import anthropic import json import re from concurrent.futures import ThreadPoolExecutor client anthropic.Anthropic() def create_subagent(system_prompt: str, task: str, tools: list None) - str: 创建并运行一个独立的子 Agent # 关键每个子 Agent 都有全新的 messages这就是上下文隔离 messages [{role: user, content: task}] while True: kwargs { model: claude-sonnet-4-20250514, max_tokens: 4096, system: system_prompt, messages: messages, } if tools: kwargs[tools] tools response client.messages.create(**kwargs) if response.stop_reason in (end_turn, max_tokens): for block in response.content: if hasattr(block, text): return block.text tool_results [] for block in response.content: if block.type tool_use: result execute_tool(block.name, block.input) tool_results.append({ type: tool_result, tool_use_id: block.id, content: result, }) messages.append({role: assistant, content: response.content}) messages.append({role: user, content: tool_results}) def extract_json(text: str) - dict: 从 LLM 输出中提取 JSON——处理 markdown 代码块包裹的情况 # 先尝试直接解析 try: return json.loads(text) except json.JSONDecodeError: pass # 尝试提取 json ... 中的内容 match re.search(r(?:json)?\s*([\s\S]*?), text) if match: try: return json.loads(match.group(1).strip()) except json.JSONDecodeError: pass # 尝试提取第一个 { ... } 块 match re.search(r\{[\s\S]*\}, text) if match: try: return json.loads(match.group(0)) except json.JSONDecodeError: pass raise ValueError(f无法从 LLM 输出中提取 JSON: {text[:200]}) def run_orchestrator(task: str) - str: 编排器拆解任务 → 并行分配 → 汇总结果 # 第一步让编排器分析任务拆成子任务 plan_response client.messages.create( modelclaude-sonnet-4-20250514, max_tokens2048, system你是一个任务编排器。分析用户任务拆解成可并行的子任务。 用 JSON 格式输出格式如下 {subtasks: [{name: 任务名, prompt: 子Agent的角色描述, task: 具体任务}]}, messages[{role: user, content: task}], ) plan extract_json(plan_response.content[0].text) # 第二步并行启动子 Agent results {} with ThreadPoolExecutor(max_workers5) as executor: futures {} for subtask in plan[subtasks]: future executor.submit( create_subagent, system_promptsubtask[prompt], tasksubtask[task], ) futures[subtask[name]] future for name, future in futures.items(): results[name] future.result() # 第三步汇总 summary create_subagent( system_prompt你是信息汇总专家。把多个研究结果整合成结构清晰的报告。, taskf以下是各子任务的结果请综合整理\n{json.dumps(results, ensure_asciiFalse, indent2)}, ) return summary代码结构分两部分create_subagent—— 创建独立的子 Agent。每次调用都是全新的messages这就是上下文隔离。注意stop_reason同时处理了end_turn和max_tokens。run_orchestrator—— 编排器分三步走分析任务 → 并行执行 → 汇总结果。你只需要知道多 Agent 系统的核心是编排器 子 Agent。编排器负责拆解和分配子 Agent 各自在独立的上下文中执行。用ThreadPoolExecutor可以让子 Agent 并行运行。4. 避坑指南搭多 Agent 系统的框架不复杂但从 demo 到稳定运行有几个坑需要提前知道。坑 1Token 消耗失控Token令牌—— AI 处理文本的基本单位也是计费单位。一个中文字大约 1-2 个 Token。具体消耗取决于任务复杂度、子 Agent 数量和工具调用轮次。上面的倍数是 Anthropic 在研究系统中的平均值。怎么控制子 Agent 只返回精简摘要不要把完整搜索结果传给编排器用max_tokens限制每个 Agent 的输出长度简单任务别用多 Agent——杀鸡别用牛刀坑 2上下文污染如果你不小心让多个 Agent 共享了同一个messages列表它们的对话历史会互相污染。A Agent 搜索的结果跑到 B Agent 的上下文里B Agent 就可能产出莫名其妙的回答。解法每个子 Agent 都用全新的messages列表。回头看第 3 章的create_subagent函数——每次调用都messages [{role: user, content: task}]这就是上下文隔离。坑 3工具描述太模糊工具的描述决定了 Agent 能不能正确使用它。描述写得模糊Agent 就不知道什么时候该用、怎么用。工具设计三条规则描述写清楚说明输入什么、返回什么、什么场景下用功能要专一一个工具做一件事别搞万能工具参数要约束用 JSON Schema 的required和类型限制坑 4调试困难多 Agent 系统最大的问题不是搭建而是出了 bug 很难定位。多个 Agent 并行运行某个给了奇怪的结果——你怎么知道是哪个 Agent 的问题我的经验是三个方法最管用打日志: 记录每个 Agent 的输入和输出出问题时能回溯。开发时关掉并行: 让 Agent 一个个跑方便定位。上线后再开并行。设置temperature0: 让结果尽量可复现。坑 5Prompt 越堆越长随着系统变复杂你可能会不断给 Agent 加指令。Prompt 越来越长Agent 反而越来越笨——因为注意力被分散了。解法把复杂指令拆到多个专门的 Agent 里而不是全塞到一个 Prompt。这也是多 Agent 架构的核心价值之一通过分工降低单个 Agent 的认知负担。你只需要知道多 Agent 的主要成本是 Token。保持上下文隔离、写好工具描述、打好日志能避开大部分坑。5. 想想可以做什么到这里你已经掌握了多 Agent 系统的核心ReAct 循环让 Agent 能自主推理和行动编排器-子 Agent 架构让多个 Agent 分工协作上下文隔离保证了每个 Agent 的工作质量Token 消耗和调试是实际落地时要重点关注的如果你想继续深入可以看看这几个方向接入真实搜索 API把模拟搜索换成 Tavily 或 SerpAPI让系统能真正上网搜信息MCP 协议标准化的 AI 工具集成方案。CNCF 在 KubeCon 2026 首次设立了 Agentics Day云原生和 Agent 系统正在快速融合Anthropic Agent SDK官方的 Agent 开发工具包封装了本文手写的很多逻辑适合生产环境生产级部署认证管理、速率限制、错误重试、成本监控——从 demo 到生产还有不少路要走