1. 项目概述：为什么需要子智能体？

在构建复杂AI应用时，我们常常会遇到一个核心矛盾：单一智能体（Agent）的能力边界。想象一下，你有一个非常能干的“全能型”助手，他既要负责理解你的复杂指令，又要去查询数据库、调用外部API、进行复杂的逻辑推理，最后还要生成格式完美的报告。这个助手很容易因为任务过载而“大脑过载”，要么反应变慢，要么在某个不擅长的环节出错，比如在生成代码时忽略了数据查询的准确性。

这就是DeepAgents框架中引入SubAgent（子智能体）机制的根本原因。它不是LangChain生态中的一个孤立概念，而是对“智能体即工具”这一思想的深度实践和架构化封装。简单来说，子智能体机制的核心思想是**“专业的事交给专业的智能体去做”**。通过将一个庞大、复杂的任务分解成多个子任务，并委派给专门为这些子任务设计和优化的子智能体来执行，主智能体则扮演“项目经理”或“调度中心”的角色，负责任务分解、协调和结果汇总。

这种架构带来的好处是显而易见的。首先，它极大地提升了系统的模块化和可维护性。每个子智能体可以独立开发、测试和优化。比如，你可以专门训练一个擅长SQL生成的子智能体，另一个擅长文本总结的子智能体，它们之间互不干扰。其次，它增强了系统的鲁棒性。一个子智能体的失败（例如，调用某个暂时不可用的API）不会导致整个任务链的崩溃，主智能体可以选择重试、更换子智能体或采用备选方案。最后，也是最重要的，它实现了能力复用。一个精心调校的“代码审查子智能体”可以被公司内多个不同的主智能体项目调用，避免了重复造轮子。

在当前的AI应用开发热潮中，无论是Dify、Coze这类低代码平台，还是需要深度定制的企业级智能体工作流（如基于LangGraph构建的复杂流程），子智能体机制都是实现高效、可靠、可扩展系统的关键设计模式。它让开发者从试图打造一个“无所不能”的超级AI的幻想中回归现实，转而专注于构建一个由多个“专业精英”协同工作的AI团队。

2. DeepAgents子智能体机制核心设计解析

要理解DeepAgents的子智能体，不能把它简单看作一个函数调用。它是一个完整的、具备自治能力的智能体单元。我们可以从它的几个核心设计维度来深入剖析。

2.1 角色定义与能力边界

每个子智能体在诞生之初，就必须有清晰的角色定义（Role）。这是子智能体机制的基石。角色定义通常通过系统提示词（System Prompt）来精确刻画，它需要明确回答以下几个问题：

1. 我是谁？例如：“你是一个专业的Python代码审查助手。”
2. 我的职责是什么？例如：“你的职责是检查给定的Python代码片段，找出其中的语法错误、潜在的性能问题、不符合PEP 8规范的写法，并提出改进建议。”
3. 我的能力边界在哪里？例如：“你只处理Python代码，不提供关于算法逻辑重写的建议，也不评价业务逻辑的正确性。”
4. 我如何与外界交互？例如：“你将接收一个包含代码的JSON对象，你需要返回一个包含‘问题列表’和‘修改建议’的JSON对象。”

一个定义模糊的子智能体是危险的。例如，一个角色定义为“数据处理助手”的子智能体，如果没有明确说明它能处理CSV、JSON还是数据库连接，主智能体在调用时就会产生困惑，甚至传递错误格式的数据导致任务失败。因此，在DeepAgents中，定义子智能体角色的提示词需要像编写产品说明书一样严谨。

2.2 通信协议与消息流

子智能体与主智能体之间，以及子智能体相互之间，需要通过一套清晰的通信协议来交互。在DeepAgents框架中，这通常基于标准的对话消息格式（如OpenAI的Message格式）进行扩展。

一个典型的调用流程如下：

1. 任务委派：主智能体生成一个“委派指令”。这个指令不仅包含原始任务描述，还会附加上下文（Context），例如用户的历史对话、之前步骤的执行结果等。指令会被格式化为一个标准的消息，发送给指定的子智能体。
2. 子智能体执行：子智能体接收到消息后，结合自身的系统提示词（角色定义）和收到的指令，进行内部推理和工具调用，最终生成执行结果。
3. 结果返回：子智能体将执行结果格式化为一个响应消息，返回给主智能体。这个结果应该是结构化的，便于主智能体解析。例如，一个“网络搜索子智能体”返回的结果可能包含[{"title": "...", "url": "...", "snippet": "..."}, ...]这样的列表。

关键在于，消息流可以是同步的，也可以是异步的。对于简单的、线性的任务链，同步调用足够。但对于需要多个子智能体并行执行（例如，同时查询天气、新闻和股票信息），或者某个子智能体执行时间很长（例如，训练一个机器学习模型）的场景，就需要引入异步通信和回调机制。DeepAgents的底层通常会利用像LangGraph这样的工作流引擎来管理这种复杂的、带有状态的消息流图。

2.3 状态管理与生命周期

子智能体是有“状态”的。这里的“状态”可能包括：

• 会话历史：与当前主任务相关的对话历史。
• 工具调用记录：本次执行中调用过哪些工具及其结果。
• 内部推理链：其思考过程（如果启用了Chain-of-Thought）。
• 资源句柄：例如，它可能打开了一个数据库连接或一个文件句柄。

主智能体需要管理子智能体的生命周期。这包括：

• 初始化：根据任务需要，实例化一个子智能体，并加载其配置（模型、提示词、工具列表）。
• 激活/执行：向子智能体发送消息，触发其执行。
• 状态重置/销毁：在子任务完成后，及时清理子智能体的状态，释放资源（尤其是如数据库连接、GPU内存等昂贵资源），以防止内存泄漏或状态污染影响到下一个任务。对于需要长期保持状态的子智能体（如一个记住用户偏好的对话助手），则需要有持久化状态的机制。

注意：在实践中，一个常见的误区是让子智能体无限期地保持状态，这会导致系统随着运行时间增长而变得不稳定。一个最佳实践是设计“无状态”或“轻状态”的子智能体，其所需的所有上下文都由主智能体在调用时显式提供。这样，子智能体实例就可以被安全地池化、复用和销毁。

3. 实操：从零构建一个子智能体系统

理论讲得再多，不如动手实现一遍。下面我们将基于LangChain和DeepAgents的设计思想，一步步构建一个简易但完整的子智能体系统。我们的场景是：一个“旅游规划主智能体”，它需要调用“天气查询子智能体”和“地点推荐子智能体”来为用户生成一份旅行建议。

3.1 环境准备与框架选型

首先，我们需要搭建基础环境。这里我们选择LangChain作为智能体框架的基础，因为它提供了构建智能体所需的核心抽象（如Agent、Tool、Chain）。虽然DeepAgents可能提供了更上层的封装，但理解底层原理至关重要。

# 创建虚拟环境（可选但推荐） python -m venv venv source venv/bin/activate # Linux/Mac # venv\Scripts\activate # Windows # 安装核心依赖 pip install langchain langchain-openai

对于模型，我们使用OpenAI的GPT-4系列，因为它对工具调用和复杂指令遵循表现出色。你需要在环境变量中设置你的OPENAI_API_KEY。

import os from langchain_openai import ChatOpenAI os.environ["OPENAI_API_KEY"] = "your-api-key-here" # 初始化LLM，温度调低以获得更确定性的输出 llm = ChatOpenAI(model="gpt-4-turbo-preview", temperature=0.1)

3.2 定义并实现子智能体

我们将创建两个子智能体。在真实场景中，它们可能会封装对真实API的调用，但这里我们用模拟工具来演示。

1. 天气查询子智能体 (WeatherSubAgent)这个子智能体的角色是：根据城市名和日期，返回模拟的天气信息。

from langchain.agents import AgentExecutor, create_tool_calling_agent from langchain_core.prompts import ChatPromptTemplate, MessagesPlaceholder from langchain.tools import tool # 1. 定义子智能体的工具 @tool def get_weather(city: str, date: str) -> str: """ 根据城市和日期查询天气。 参数: city: 城市名称，例如“北京”、“上海”。 date: 日期，格式为‘YYYY-MM-DD’。 返回: 模拟的天气描述字符串。 """ # 模拟一个简单的天气查询逻辑 weather_map = { "北京": {"sunny": "晴朗，气温15-25度，微风"}, "上海": {"rainy": "多云转小雨，气温18-22度，东南风3级"}, "广州": {"cloudy": "多云，气温22-30度，湿度较高"}, } default_weather = "天气数据暂不可用。" # 这里简化处理，忽略日期，仅根据城市返回 city_info = weather_map.get(city, {}) # 取第一个天气状态作为模拟结果 weather_desc = list(city_info.values())[0] if city_info else default_weather return f"{city}在{date}的天气情况：{weather_desc}" # 2. 定义子智能体的提示词（角色定义） weather_agent_prompt = ChatPromptTemplate.from_messages([ ("system", """你是一个专业的天气查询助手。你的唯一职责是响应用户关于天气的询问。 用户会提供城市和日期。你必须使用`get_weather`工具来获取信息，并直接、清晰地返回结果。 不要回答与天气无关的问题。如果用户的问题不包含明确的城市或日期，请要求用户补充。 """), MessagesPlaceholder(variable_name="messages"), # 用于接收主智能体传来的消息历史 MessagesPlaceholder(variable_name="agent_scratchpad"), ]) # 3. 装配子智能体 weather_tools = [get_weather] weather_agent = create_tool_calling_agent(llm=llm, tools=weather_tools, prompt=weather_agent_prompt) weather_agent_executor = AgentExecutor(agent=weather_agent, tools=weather_tools, verbose=False) # 生产环境建议关闭verbose

2. 地点推荐子智能体 (RecommendationSubAgent)这个子智能体的角色是：根据城市和兴趣标签，推荐旅游景点。

@tool def recommend_attractions(city: str, interest: str) -> str: """ 根据城市和兴趣推荐旅游景点。 参数: city: 城市名称。 interest: 兴趣标签，如‘历史’、‘美食’、‘自然’。 返回: 推荐的景点列表和简介。 """ attraction_db = { "北京": { "历史": "1. 故宫：明清两代的皇家宫殿，世界文化遗产。\n2. 颐和园：清代皇家园林，以昆明湖、万寿山为基。", "美食": "1. 全聚德（前门店）：品尝正宗北京烤鸭。\n2. 护国寺小吃街：体验豆汁、焦圈等京味小吃。" }, "上海": { "现代": "1. 外滩：欣赏万国建筑博览群和陆家嘴天际线。\n2. 上海迪士尼乐园：家庭游乐胜地。", "美食": "1. 城隍庙：品尝南翔小笼包、五香豆。\n2. 本帮菜馆（如上海老饭店）：体验红烧鮰鱼、油爆虾。" } } recommendations = attraction_db.get(city, {}).get(interest, "暂无针对此城市和兴趣的推荐信息。") return f"在{city}，对于‘{interest}’兴趣，推荐如下：\n{recommendations}" recommendation_agent_prompt = ChatPromptTemplate.from_messages([ ("system", """你是一个专业的旅游景点推荐助手。你的职责是根据用户提供的城市和兴趣标签，推荐合适的景点。 你必须使用`recommend_attractions`工具来获取推荐列表，并以友好的方式呈现给用户。 如果缺少城市或兴趣信息，请主动询问。 """), MessagesPlaceholder(variable_name="messages"), MessagesPlaceholder(variable_name="agent_scratchpad"), ]) recommendation_tools = [recommend_attractions] recommendation_agent = create_tool_calling_agent(llm=llm, tools=recommendation_tools, prompt=recommendation_agent_prompt) recommendation_agent_executor = AgentExecutor(agent=recommendation_agent, tools=recommendation_tools, verbose=False)

3.3 构建主智能体与调度逻辑

主智能体是大脑，它不直接处理具体任务，而是分析用户需求，拆解任务，并调度子智能体。

from langchain_core.messages import HumanMessage, SystemMessage, AIMessage import json class TravelPlannerAgent: def __init__(self, weather_agent_executor, recommendation_agent_executor): self.weather_agent = weather_agent_executor self.recommendation_agent = recommendation_agent_executor # 主智能体自身的LLM，用于理解用户意图和规划任务 self.llm = llm def plan_trip(self, user_query: str) -> str: """ 主规划流程 1. 意图识别与任务分解 2. 并行或串行调用子智能体 3. 汇总结果并生成最终回复 """ print(f"[主智能体] 收到用户查询: {user_query}") # 步骤1：意图识别与任务分解 # 这里简化处理，实际应用中可以用更复杂的Chain或另一个LLM调用来做规划 # 我们假设用户查询格式为：“我想去[城市]旅游，对[兴趣]感兴趣，[日期]的天气怎么样？” # 使用一个简单的LLM调用提取关键信息 extraction_prompt = f""" 请从以下用户查询中提取关键信息，并以JSON格式返回。 需要提取的字段：city（城市）， interest（兴趣，如历史、美食等）， date（日期，格式YYYY-MM-DD）。 如果某个字段不存在，请将其值设为null。 用户查询：{user_query} 只返回JSON，不要有其他文字。 """ extraction_response = self.llm.invoke([HumanMessage(content=extraction_prompt)]) try: info = json.loads(extraction_response.content) city = info.get('city') interest = info.get('interest') date = info.get('date') print(f"[主智能体] 解析出信息 - 城市: {city}, 兴趣: {interest}, 日期: {date}") except json.JSONDecodeError: return "抱歉，我无法理解您的旅行需求。请提供更清晰的信息，例如‘我想去北京旅游，对历史感兴趣，下周二的天气怎么样？’" # 步骤2：调度子智能体 results = {} # 如果提供了日期和城市，则查询天气 if date and city: print(f"[主智能体] 调度天气查询子智能体...") weather_task = f"查询{city}在{date}的天气。" weather_result = self.weather_agent.invoke({"input": weather_task, "messages": []}) results['weather'] = weather_result.get('output', '天气查询失败。') print(f"[天气子智能体] 返回: {results['weather'][:50]}...") # 如果提供了城市和兴趣，则获取推荐 if city and interest: print(f"[主智能体] 调度景点推荐子智能体...") recommendation_task = f"为对{interest}感兴趣的游客推荐{city}的景点。" recommendation_result = self.recommendation_agent.invoke({"input": recommendation_task, "messages": []}) results['recommendation'] = recommendation_result.get('output', '景点推荐失败。') print(f"[推荐子智能体] 返回: {results['recommendation'][:50]}...") # 步骤3：汇总与生成最终回复 if not results: return "未能提取到有效的旅行规划信息（城市、兴趣或日期）。请重新描述您的需求。" final_report = f"""# 为您生成的旅行规划报告 **目的地：** {city if city else '未指定'} """ if 'weather' in results: final_report += f"**天气信息：**\n{results['weather']}\n\n" if 'recommendation' in results: final_report += f"**景点推荐：**\n{results['recommendation']}\n\n" final_report += "祝您旅途愉快！" return final_report # 初始化并运行主智能体 planner = TravelPlannerAgent(weather_agent_executor, recommendation_agent_executor) user_query = "我下周五想去上海玩，对美食比较感兴趣，那天天气如何？" final_answer = planner.plan_trip(user_query) print("\n" + "="*50) print("最终回复：") print(final_answer)

运行上述代码，你将看到主智能体如何解析用户输入，识别出“上海”、“下周五”、“美食”等关键信息，然后并行或按需调度两个子智能体，最后将结果整合成一份完整的旅行报告。这个简单的例子清晰地展示了子智能体机制的工作流程：解耦、专精、协同。

4. 高级模式与架构演进

基础的单主多子架构只是起点。在实际生产环境中，子智能体机制会演变得更加复杂和强大。

4.1 动态子智能体创建与注册

在更复杂的系统中，子智能体可能不是预先静态定义好的，而是根据任务需求动态创建和注册的。这需要一个子智能体注册中心（Registry）。

class SubAgentRegistry: def __init__(self): self._agents = {} # name -> agent_executor 的映射 def register_agent(self, name: str, description: str, agent_executor): """向注册中心注册一个子智能体""" self._agents[name] = { 'executor': agent_executor, 'description': description } print(f"[注册中心] 已注册子智能体: {name} - {description}") def get_agent(self, name: str): """根据名称获取子智能体""" return self._agents.get(name) def list_agents(self): """列出所有可用的子智能体及其描述""" return {name: info['description'] for name, info in self._agents.items()} # 主智能体可以通过查询注册中心，动态决定调用哪个子智能体 registry = SubAgentRegistry() registry.register_agent("weather_checker", "查询指定城市和日期的天气", weather_agent_executor) registry.register_agent("attraction_recommender", "根据城市和兴趣推荐景点", recommendation_agent_executor) # 主智能体规划时，可以这样动态选择： def dynamic_dispatch(task_description): # 主智能体分析任务，决定需要哪些能力 required_capabilities = ["需要查询天气", "需要景点推荐"] # 这里简化，实际应由LLM判断 for cap in required_capabilities: # 这里应该有一个更智能的匹配逻辑，比如基于描述进行向量相似度搜索 if "天气" in cap: agent_info = registry.get_agent("weather_checker") if agent_info: # 调用该子智能体 pass

4.2 子智能体间的协作与通信

有时，子智能体之间也需要直接通信，而不是全部通过主智能体中转。例如，“行程规划子智能体”可能需要向“地图API子智能体”询问两个景点之间的距离，以优化路线。这就引入了子智能体间通信（Inter-Agent Communication）。

实现这种通信有两种主要模式：

1. 通过主智能体路由：子智能体A将请求发送给主智能体，主智能体识别出该请求应由子智能体B处理，然后转发请求并返回结果。这种方式逻辑集中，但主智能体可能成为瓶颈。
2. 直接通信：在注册中心的支持下，子智能体A可以直接查询并调用子智能体B的接口。这需要一套服务发现和调用协议，类似于微服务间的RPC调用。这种方式效率更高，但架构更复杂，需要处理服务发现、负载均衡、错误处理等问题。

在LangChain生态中，LangGraph是管理这种复杂工作流的绝佳工具。你可以将每个子智能体定义为一个“节点”（Node），主智能体的调度逻辑和子智能体间的依赖关系用“边”（Edge）来连接，形成一个有向图。LangGraph会负责状态传递、节点执行顺序（并行/串行）和条件分支，完美契合了子智能体协作的需求。

4.3 错误处理与熔断机制

在分布式系统中，任何一个服务都可能失败，子智能体也不例外。一个健壮的子智能体系统必须具备完善的错误处理机制。

• 重试策略：对于暂时性失败（如网络超时、API限流），主智能体应能对子智能体的调用进行有限次数的重试。
• 降级方案：当某个核心子智能体（如支付网关验证）完全失败时，系统应能切换到备选方案（如使用缓存的结果、提供一个简化流程、或明确告知用户服务暂时不可用）。
• 熔断器模式：如果某个子智能体在短时间内频繁失败，主智能体应能暂时“熔断”对该子智能体的调用，直接返回失败或使用降级方案，避免持续的失败调用拖垮整个系统。经过一段冷却时间后，再尝试恢复调用。
• 超时控制：必须为每个子智能体的调用设置合理的超时时间，防止因某个子智能体“卡住”而导致整个用户请求被挂起。

在代码中，这通常意味着在主智能体的调度逻辑里，对每个agent_executor.invoke()的调用进行try-except包装，并集成重试库（如tenacity）和熔断器库（如pybreaker）。

import tenacity from tenacity import retry, stop_after_attempt, wait_exponential @retry(stop=stop_after_attempt(3), wait=wait_exponential(multiplier=1, min=4, max=10)) def call_agent_with_retry(agent_executor, input_data): """带有指数退避重试的子智能体调用""" try: # 可以在这里设置超时 result = agent_executor.invoke(input_data) return result['output'] except Exception as e: print(f"调用子智能体失败: {e}") raise # 重试装饰器会捕获异常并重试

5. 性能优化与最佳实践

当子智能体数量增多、调用频繁时，性能就成为必须考虑的问题。

5.1 子智能体池化

频繁创建和销毁子智能体实例（尤其是那些加载了大型模型的智能体）开销巨大。对象池化是常见的优化手段。你可以维护一个子智能体实例池，当需要调用时从池中借用一个实例，用完后归还，而不是每次都新建。

from queue import Queue import threading class SubAgentPool: def __init__(self, agent_factory, max_size=5): self._pool = Queue(maxsize=max_size) self._agent_factory = agent_factory self._lock = threading.Lock() for _ in range(max_size): self._pool.put(agent_factory()) # 预创建实例 def get_agent(self): """从池中获取一个智能体实例""" try: return self._pool.get_nowait() except: # 如果池为空且未达到最大大小，可以动态创建（需考虑线程安全） with self._lock: # 再次检查并创建 pass # 简单起见，这里等待 return self._pool.get() def return_agent(self, agent): """将智能体实例归还到池中""" self._pool.put(agent) # 使用池 weather_agent_pool = SubAgentPool(lambda: weather_agent_executor, max_size=3) agent_instance = weather_agent_pool.get_agent() try: result = agent_instance.invoke(...) finally: weather_agent_pool.return_agent(agent_instance) # 确保归还

5.2 异步调用与并行执行

如果多个子智能体之间没有依赖关系，那么并行调用可以大幅缩短总响应时间。Python的asyncio库是处理此类问题的标准工具。

import asyncio async def parallel_invoke_agents(user_query_info): tasks = [] if user_query_info.get('date') and user_query_info.get('city'): # 创建异步任务，注意：LangChain的AgentExecutor默认是同步的 # 需要将其放在线程池中运行以避免阻塞事件循环 task1 = asyncio.to_thread(weather_agent_executor.invoke, { "input": f"查询{user_query_info['city']}在{user_query_info['date']}的天气。", "messages": [] }) tasks.append(task1) if user_query_info.get('city') and user_query_info.get('interest'): task2 = asyncio.to_thread(recommendation_agent_executor.invoke, { "input": f"为对{user_query_info['interest']}感兴趣的游客推荐{user_query_info['city']}的景点。", "messages": [] }) tasks.append(task2) # 并行等待所有任务完成 results = await asyncio.gather(*tasks, return_exceptions=True) # 处理结果... return results

5.3 上下文管理与信息传递

如何在不同子智能体之间高效、准确地传递上下文信息，是一个挑战。一股脑地将所有历史对话都塞给每个子智能体会导致提示词臃肿、成本增加且可能引入无关干扰。

最佳实践是“按需传递”：

1. 主智能体做信息过滤：主智能体在向子智能体分派任务时，只传递与该子任务强相关的上下文片段。例如，给“代码生成子智能体”传递需求描述和API文档；给“代码审查子智能体”传递刚生成的代码和编码规范。
2. 使用共享状态存储：对于复杂的多步骤任务，可以建立一个共享的、结构化的状态存储（如一个字典或数据库）。每个子智能体读取和写入自己负责的部分。主智能体负责维护这个状态的整体一致性和版本。
3. 设计清晰的输入输出规范：强制要求每个子智能体的输出必须是结构化的（如JSON）。这样主智能体可以轻松地解析、提取和组合信息，再传递给下一个子智能体。非结构化的文本输出会给自动化流程带来巨大的解析负担。

6. 常见陷阱与调试技巧

在实际开发中，我踩过不少坑，也总结了一些调试子智能体系统的有效方法。

6.1 陷阱一：模糊的角色定义

这是最常见的问题。一个角色定义为“帮助用户”的子智能体，最终可能做出任何事，导致行为不可预测。

• 症状：子智能体经常执行超出预期的操作，或拒绝执行本应属于其职责的任务。
• 排查：仔细检查系统提示词。确保它包含了明确的职责范围、输入输出格式和行为约束。可以使用“你必须...”、“你只能...”、“禁止...”等强指令性词语。
• 技巧：在提示词末尾加上一个“如果用户请求超出上述范围，你应明确拒绝并说明原因”的指令，这能有效防止智能体“越界”。

6.2 陷阱二：无限循环或递归调用

当主智能体和子智能体，或多个子智能体之间形成循环依赖时，系统可能陷入死循环。

• 症状：系统长时间无响应，或LLM调用次数激增，账单飞涨。
• 排查：
  1. 设置硬性限制：在主智能体的调度逻辑中，强制规定最大调用深度或最大子智能体调用次数。
  2. 记录调用链：在每次调用时，打印或记录当前的任务栈。当发现某个子智能体被重复调用且上下文相似时，很可能出现了循环。
  3. 设计防循环逻辑：例如，给每个任务分配一个唯一ID，并在状态中记录已执行的任务ID。如果发现当前任务ID已存在，则跳过或报错。
• 技巧：在使用LangGraph时，可以利用其内置的循环检测和中断机制。对于自定义调度，一个简单的“已访问节点”集合就能解决大部分问题。

6.3 陷阱三：上下文窗口溢出

子智能体在长时间对话或多轮协作中，积累的上下文可能超过LLM的令牌限制。

• 症状：LLM返回错误，提示上下文过长，或者开始遗忘对话早期的关键信息。
• 排查：
  1. 定期总结：设计一个“总结子智能体”，在上下文变得过长时，让它将历史对话压缩成一段简洁的摘要，然后用摘要替换掉冗长的历史。
  2. 选择性记忆：不要传递全部历史。只传递与当前子任务最相关的几条消息。这需要主智能体具备一定的信息检索和筛选能力。
  3. 使用支持长上下文的模型：虽然成本更高，但像GPT-4 Turbo（128K上下文）这类模型可以缓解此问题。
• 技巧：在开发阶段，始终在日志中输出发送给LLM的上下文长度，以便监控和预警。

6.4 调试技巧实录

1. 启用详细日志：将每个子智能体调用前（输入）和调用后（输出）的信息，以及主智能体的决策过程，都打印到日志中。这是最直接的调试方式。
2. 可视化工作流：如果使用LangGraph，务必利用其可视化功能，将整个智能体工作流画出来。这能帮助你一眼看清任务流向和潜在的循环点。
3. 单元测试子智能体：像测试普通函数一样测试每个子智能体。准备一系列标准输入，验证其输出是否符合预期。这能确保每个“零件”本身是可靠的。
4. 使用“模拟”或“存根”：在测试主智能体的调度逻辑时，不要调用真实的、可能慢或不可靠的子智能体（如真实天气API）。使用一个模拟对象（Mock）来返回预定结果，这样可以快速测试主逻辑的正确性。
5. 成本监控：在日志中记录每次LLM调用的模型、令牌使用量。这不仅能帮你控制预算，还能发现异常。例如，某个子智能体突然消耗了异常多的令牌，可能意味着提示词出了问题或陷入了循环生成。

构建一个稳健的子智能体系统，就像组建和管理一个高效的团队。你需要清晰定义每个成员（子智能体）的职责，建立顺畅的沟通机制（消息协议），制定应急预案（错误处理），并不断优化协作流程（性能调优）。这个过程充满挑战，但一旦系统运转起来，其解决复杂问题的能力和可扩展性，将远超任何一个单体智能体。从简单的串行调用开始，逐步向动态注册、并行协作、容错处理演进，你会深刻体会到模块化设计带来的强大力量。