AI子代理系统配置实战：基于LangChain与GPT构建智能体协作架构-尧图网络科技

如果你正在尝试将 Codex 与 GPT 模型结合，构建一个能处理复杂任务、调用外部工具的子代理系统，那么你很可能已经遇到了几个核心难题：如何让不同的 AI 模型协同工作？如何配置复杂的技能链（Skill）？如何管理上下文和权限，避免“失控”或“无效调用”？

最近，围绕“Codex 子代理配置 GPT Luna Max”的讨论和搜索热度很高，这背后反映的正是开发者对构建更强大、更可控的 AI 代理（Agent）工作流的迫切需求。很多人以为这只是简单的 API 调用拼接，但实际上，其核心在于对“子代理”（Sub-Agent）架构的深刻理解与精细化配置。一个配置不当的代理，要么无法完成任务，要么会产生不可预知的调用链，消耗大量 Token 却得不到有效结果。

本文不会停留在概念层面。我们将深入探讨如何基于 Codex（或类似代理框架）配置一个高效、可靠的子代理系统，并整合如 GPT-4 等大语言模型（文中以“GPT Luna Max”代指一类高性能模型）。你将了解到：

子代理架构的核心思想：为什么单纯的模型调用不够，需要引入“代理”和“技能”的概念。
从零开始的配置实战：包括环境搭建、核心配置文件解读、技能（Skill）定义与注册。
与 GPT 模型的深度集成技巧：如何让 Codex 主代理智能地调用 GPT 子代理处理特定任务，并管理上下文。
避坑指南与最佳实践：针对网络搜索中高频出现的错误（如配置失败、端点错误、上下文超限）提供解决方案。

无论你是想自动化代码生成、数据分析还是构建复杂的对话系统，理解并掌握这套配置逻辑，都将是你构建下一代 AI 应用的关键一步。

1. 这篇文章真正要解决的问题：从“模型调用”到“智能体协作”

在 AI 应用开发的早期，我们习惯于直接调用单个大语言模型（LLM）的 API，发送提示词（Prompt），然后等待回复。这种方式对于简单任务足够有效，但一旦任务变得复杂——例如需要联网搜索、执行代码、查询数据库、多步骤推理——单个模型就会显得力不从心。你需要手动编写复杂的逻辑来判断何时调用何种工具，这本质上是在用传统代码的“确定性”去驱动 AI 的“非确定性”，既繁琐又脆弱。

子代理（Sub-Agent）模式的出现，正是为了解决这个问题。它的核心思想是：创建一个“主代理”（Master Agent）作为大脑和调度中心，它理解用户意图，并将复杂任务分解为子任务。每个子任务由一个专门的“子代理”负责，子代理可以绑定特定的 LLM（如 GPT-4 用于创意写作，Code Llama 用于代码生成）和一套“技能”（Skills，如执行 Python 代码、调用搜索引擎 API、访问数据库）。

那么，“Codex 配置 GPT Luna Max”这个命题的真实场景是什么？我们可以这样理解：

Codex：在这里通常指一个代理框架或平台（可能是开源项目如LangChain、AutoGen的某种配置，或是特定产品的代称），它提供了创建、管理和编排代理的基础设施。
GPT Luna Max：可以理解为一种高性能的 LLM 服务（例如 OpenAI 的 GPT-4，或类似能力的模型）。它是子代理所依赖的“思考引擎”。
配置：关键在于定义主代理如何根据任务类型，选择并激活那个绑定了 GPT 模型的子代理，以及该子代理能使用哪些技能。

因此，本文要解决的真正问题是：如何在一个代理框架中，结构化地定义技能、配置不同能力的子代理，并让它们协同工作，以完成单个模型无法处理的复杂任务。这不仅仅是写一个 API 调用，而是设计一个微型的、自治的 AI 系统架构。

2. 基础概念与核心原理

在深入配置之前，必须厘清几个关键概念。混淆它们会导致配置时方向错误。

概念	通俗解释	在本文场景中的角色	常见误区
代理 (Agent)	一个能够感知环境、做出决策并执行动作的AI实体。它通常由LLM（大脑）、记忆（Memory）和工具/技能（Tools/Skills）组成。	Codex 框架中运行的核心单元。可以是主代理，也可以是子代理。	认为代理就是聊天机器人。实际上，它是具备目标导向行动能力的AI程序。
子代理 (Sub-Agent)	一个专门负责某类特定任务的代理。它从主代理接收明确的子任务指令，完成后将结果返回。	专门配置了 GPT 模型和特定技能集（如写作、分析）的代理。是任务的具体执行者。	认为子代理是物理上分离的服务。它更常是一个逻辑概念，在同一框架内通过不同配置实现。
技能/工具 (Skill/Tool)	代理可以调用的具体功能。例如：“执行Python代码”、“谷歌搜索”、“读取文件”。技能扩展了代理的能力边界。	GPT 子代理所配备的“武器”。例如，一个数据分析子代理可能配备`pandas_analyze`技能。	将技能与模型本身的能力混淆。模型提供理解与生成，技能提供与外界交互的“手和脚”。
编排 (Orchestration)	主代理根据任务描述，决定调用哪个子代理、传递什么参数、如何整合结果的过程。这是系统的“指挥棒”。	Codex 框架的核心调度逻辑。通常通过提示词工程和路由规则实现。	认为编排需要复杂的硬编码。现代框架倾向于用LLM本身（主代理）来做动态路由。
上下文 (Context)	在对话或任务执行过程中，需要被LLM记住的历史信息。包括之前的对话、工具调用结果等。	连接主代理和子代理、串联多次技能调用的“信息流”。管理不当会导致任务失败。	忽视上下文长度限制，导致历史信息被截断，任务断链。

核心工作流程：

用户向主代理提出一个复杂请求（如：“分析最近三天的销售数据，写一份总结报告，并预测下月趋势”）。
主代理（大脑）分析请求，将其分解为子任务：[获取销售数据] -> [分析数据] -> [撰写报告] -> [预测趋势]。
主代理根据子任务类型，路由到对应的子代理。例如，将[分析数据]路由到“数据分析子代理”，将[撰写报告]路由到“文案写作子代理”。
子代理接收到具体指令后，结合自身绑定的LLM（如GPT）和可用的技能（如query_database，generate_text）来执行任务。
子代理将执行结果返回给主代理。
主代理整合所有子代理的结果，形成最终回复给用户。

这个流程中，“配置”的关键就在于定义步骤3中的路由规则，以及步骤4中每个子代理的LLM和技能绑定。

3. 环境准备与前置条件

为了进行实战演示，我们需要一个具体的代理框架。由于“Codex”可能指代不同项目，本文将选用一个当前最流行、概念最接近的开源框架LangChain作为示例。它的Agent和Tool概念与上文描述完全吻合，且社区活跃，资料丰富。

基础环境要求：

操作系统：Windows 10/11, macOS, 或 Linux (Ubuntu 20.04+)。本文命令以 Linux/macOS 为例，Windows 用户可在 PowerShell 或 WSL 中操作。
Python：版本 3.8 至 3.11。推荐使用 3.10 以获得最佳兼容性。
包管理工具：pip(Python 自带) 或conda(如使用 Anaconda)。
代码编辑器：VS Code, PyCharm 等任选。

关键依赖安装：我们将创建一个新的虚拟环境来管理依赖，这是避免包冲突的最佳实践。

# 1. 创建并激活虚拟环境 (可选，但强烈推荐) python -m venv codex_agent_env source codex_agent_env/bin/activate # Windows: codex_agent_env\Scripts\activate # 2. 升级pip pip install --upgrade pip # 3. 安装核心框架 LangChain 和 OpenAI 库 (用于调用GPT) pip install langchain langchain-openai # 4. 安装一些可能用到的社区工具包和工具 pip install langchain-community # 社区贡献的各种工具和集成 pip install wikipedia # 示例：维基百科查询工具 pip install arxiv # 示例：Arxiv论文查询工具 # 注意：实际工具根据你的需求安装，如 requests, sqlalchemy 等。

获取 API 密钥：要集成 GPT 模型，你需要一个 OpenAI API 密钥（或其他兼容 OpenAI API 的模型服务商密钥）。

访问 OpenAI 平台注册并登录。
在 API Keys 页面，点击 “Create new secret key”。
复制生成的密钥，并妥善保存。它只显示一次。

环境变量设置：永远不要将 API 密钥硬编码在代码中。使用环境变量管理。

# 在终端中设置环境变量 (临时，重启后失效) export OPENAI_API_KEY="你的-api-key-here" # Windows: set OPENAI_API_KEY=你的-api-key-here # 更推荐的做法是创建 .env 文件 echo "OPENAI_API_KEY=你的-api-key-here" > .env

然后在 Python 代码中使用python-dotenv加载：

pip install python-dotenv

4. 核心流程拆解：构建你的第一个子代理系统

现在，我们开始用 LangChain 构建一个包含主代理和 GPT 子代理的简单系统。我们的目标是：创建一个主代理，它能理解用户问题，并决定是调用一个“通用问答子代理”（用 GPT-3.5）还是一个“深度分析子代理”（用 GPT-4）。

4.1 步骤一：初始化 LLM 与工具（技能）

首先，我们创建两个 LLM 实例，分别代表不同能力的“大脑”。

# 文件：agent_system.py import os from dotenv import load_dotenv from langchain_openai import ChatOpenAI from langchain.agents import Tool, AgentExecutor, create_react_agent from langchain.memory import ConversationBufferMemory from langchain import hub # 用于拉取预设的提示词 # 加载环境变量 load_dotenv() # 1. 初始化两个 LLM，模拟不同能力的子代理 # 通用子代理使用 GPT-3.5-turbo（成本较低，响应快） general_llm = ChatOpenAI(model="gpt-3.5-turbo", temperature=0.1, api_key=os.getenv("OPENAI_API_KEY")) # 深度分析子代理使用 GPT-4（能力更强，适合复杂任务） analysis_llm = ChatOpenAI(model="gpt-4", temperature=0.1, api_key=os.getenv("OPENAI_API_KEY")) print("LLM 初始化成功。")

接下来，定义一些工具（技能）。工具是代理与外界交互的桥梁。

# 2. 定义一些工具（Skills） # 工具一：一个简单的计算器工具（模拟一个技能） from langchain.tools import tool import math @tool def calculator(query: str) -> str: """用于执行数学计算。输入应为一个数学表达式字符串，如 '3的平方加5' 或 'sin(45度)'。""" try: # 这是一个非常简单的示例，实际应用中可能需要更复杂的自然语言转表达式逻辑 # 这里为了演示，只处理非常简单的表达式 query = query.replace("的平方", "**2").replace("度", "") # 警告：使用 eval 有安全风险，仅用于演示。生产环境必须使用安全的表达式求值库（如 ast.literal_eval, numexpr）。 result = eval(query, {"__builtins__": None}, {"sin": math.sin, "cos": math.cos, "sqrt": math.sqrt}) return f"计算结果为: {result}" except Exception as e: return f"计算失败: {e}" # 工具二：一个模拟的数据库查询工具 @tool def query_user_database(user_id: str) -> str: """根据用户ID查询用户基本信息。""" # 模拟一个数据库 mock_db = { "001": "用户: 张三, 角色: 管理员, 注册时间: 2023-01-01", "002": "用户: 李四, 角色: 开发者, 注册时间: 2023-06-15", } return mock_db.get(user_id, f"未找到用户ID为 {user_id} 的记录。") # 工具三：获取当前时间的工具 from datetime import datetime @tool def get_current_time(placeholder: str = "") -> str: # 工具需要参数，这里加一个占位符 """返回当前的系统日期和时间。""" return f"当前时间是: {datetime.now().strftime('%Y-%m-%d %H:%M:%S')}" # 将工具包装成列表 tools = [calculator, query_user_database, get_current_time] print(f"已定义 {len(tools)} 个工具。")

4.2 步骤二：创建子代理

在 LangChain 中，一个“代理”由LLM+Tools+AgentType(或提示词) 定义。我们创建两个具备不同工具集的子代理。

# 3. 创建子代理 from langchain.agents import initialize_agent, AgentType # 子代理 A：通用助手，使用 GPT-3.5，拥有所有基础工具 general_agent = initialize_agent( tools, general_llm, agent=AgentType.CHAT_CONVERSATIONAL_REACT_DESCRIPTION, # 适合对话的代理类型 memory=ConversationBufferMemory(memory_key="chat_history", return_messages=True), verbose=True, # 打印详细执行过程，便于调试 handle_parsing_errors=True # 优雅处理解析错误 ) # 子代理 B：深度分析代理，使用 GPT-4，但只赋予它计算器和查询工具（假设它专注于数据分析） analysis_tools = [calculator, query_user_database] # 不包含获取时间工具 analysis_agent = initialize_agent( analysis_tools, analysis_llm, agent=AgentType.CHAT_CONVERSATIONAL_REACT_DESCRIPTION, memory=ConversationBufferMemory(memory_key="chat_history", return_messages=True), verbose=True, handle_parsing_errors=True ) print("子代理创建成功。")

4.3 步骤三：构建主代理与路由逻辑

这是最核心的一步。我们需要一个“主代理”来理解用户意图，并决定将任务派发给哪个子代理。这里我们实现一个简单的基于规则的路由器。

# 4. 主代理路由逻辑 class MasterAgent: def __init__(self, general_agent, analysis_agent): self.general_agent = general_agent self.analysis_agent = analysis_agent def route_and_execute(self, user_input: str) -> str: """ 简单的主代理路由逻辑。 根据输入内容的关键词决定使用哪个子代理。 """ user_input_lower = user_input.lower() # 路由规则定义 analysis_keywords = ["分析", "预测", "趋势", "统计", "计算", "复杂", "深入"] general_keywords = ["你好", "时间", "介绍", "简单", "查询用户"] # 判断逻辑（实际项目应更复杂，可能使用一个LLM来判断） is_analysis_task = any(keyword in user_input_lower for keyword in analysis_keywords) is_general_task = any(keyword in user_input_lower for keyword in general_keywords) print(f"[主代理] 收到请求: {user_input}") print(f"[主代理] 分析任务? {is_analysis_task}, 通用任务? {is_general_task}") try: if is_analysis_task: print("[主代理] 路由至深度分析子代理...") response = self.analysis_agent.run(user_input) return f"[深度分析结果] {response}" else: # 默认或通用任务交给通用助手 print("[主代理] 路由至通用助手子代理...") response = self.general_agent.run(user_input) return f"[通用助手回复] {response}" except Exception as e: return f"[主代理] 执行出错: {e}" # 初始化主代理 master = MasterAgent(general_agent, analysis_agent) print("主代理初始化成功，系统准备就绪。\n" + "="*50)

5. 完整示例与代码实现

将以上所有步骤整合到一个可运行的脚本中，并添加一个简单的交互循环。

# 文件：main.py import os import sys sys.path.append('.') # 假设 agent_system.py 在同一目录 from agent_system import master # 从上面创建的模块导入主代理 def main(): print("=== Codex 风格子代理系统演示 ===") print("系统已启动。输入您的问题，或输入 'quit' 退出。") print("提示：尝试包含‘分析’、‘计算’等词触发深度分析代理。\n") while True: try: user_input = input("\n您: ") if user_input.lower() in ['quit', 'exit', '退出']: print("再见！") break if not user_input.strip(): continue # 主代理处理请求 response = master.route_and_execute(user_input) print(f"\n系统: {response}") except KeyboardInterrupt: print("\n\n程序被中断。") break except Exception as e: print(f"\n系统发生未知错误: {e}") if __name__ == "__main__": main()

关键逻辑解释：

模块化：将代理系统的创建放在agent_system.py，主程序放在main.py，结构清晰。
路由规则：MasterAgent.route_and_execute方法包含了简单的关键词路由逻辑。这是整个系统的“调度中心”。在实际复杂应用中，这个路由逻辑本身可以用一个 LLM 来实现，实现更智能的任务分解和分配。
代理类型：我们使用了CHAT_CONVERSATIONAL_REACT_DESCRIPTION代理类型，它适合多轮对话，并能使用 ReAct 框架（思考-行动-观察）来调用工具。
记忆：每个子代理都有自己的ConversationBufferMemory，用于维护与当前用户的对话上下文。主代理目前是无状态的，更高级的实现中主代理也需要记忆来跟踪整体任务进度。

6. 运行结果与效果验证

现在，让我们运行这个系统，看看主代理如何根据输入内容路由任务。

运行程序：

# 确保在虚拟环境中，且 OPENAI_API_KEY 已设置 python main.py

预期交互示例：

=== Codex 风格子代理系统演示 === 系统已启动。输入您的问题，或输入 'quit' 退出。 提示：尝试包含‘分析’、‘计算’等词触发深度分析代理。 您: 你好，现在几点了？ [主代理] 收到请求: 你好，现在几点了？ [主代理] 分析任务? False, 通用任务? True [主代理] 路由至通用助手子代理... > Entering new AgentExecutor chain... Thought: 用户问好并询问时间。我有一个工具可以获取当前时间。 Action: get_current_time Action Input: {} Observation: 当前时间是: 2024-05-27 10:30:15 Thought: 我已经获取了当前时间，可以回答用户了。 Final Answer: 你好！当前时间是 2024年5月27日 10:30:15。 > Finished chain. 系统: [通用助手回复] 你好！当前时间是 2024年5月27日 10:30:15。 您: 请分析一下用户ID为001和002的用户的注册时间趋势。 [主代理] 收到请求: 请分析一下用户ID为001和002的用户的注册时间趋势。 [主代理] 分析任务? True, 通用任务? False [主代理] 路由至深度分析子代理... > Entering new AgentExecutor chain... Thought: 用户要求分析两个用户的注册时间趋势。我需要先查询这两个用户的信息。 Action: query_user_database Action Input: {"user_id": "001"} Observation: 用户: 张三, 角色: 管理员, 注册时间: 2023-01-01 Thought: 现在查询第二个用户。 Action: query_user_database Action Input: {"user_id": "002"} Observation: 用户: 李四, 角色: 开发者, 注册时间: 2023-06-15 Thought: 我拿到了两个用户的注册时间。现在需要分析趋势。注册时间“趋势”通常指时间先后和间隔。用户001注册于2023-01-01，用户002注册于2023-06-15。两者相差约5.5个月。可以计算一下具体天数。 Action: calculator Action Input: {"query": "(2023-06-15) - (2023-01-01)"} Observation: 计算失败: invalid syntax (<string>, line 1) # 我们的简单计算器处理不了日期减法 Thought: 我的计算器工具无法直接处理日期。我需要换一种方式分析。我可以描述这个时间差。 Final Answer: 根据查询结果，用户001（张三）注册于2023年1月1日，用户002（李四）注册于2023年6月15日。从注册时间来看，用户001比用户002早注册大约5个半月（约166天）。这显示出在2023年上半年，用户注册活动至少持续了半年，且早期注册的用户角色为管理员，后期注册的为开发者。可以推测系统在初期需要管理员搭建，后续吸引了开发者加入。如需更精确的趋势分析（如月度注册量），需要更全面的数据集。 > Finished chain. 系统: [深度分析结果] 根据查询结果，用户001（张三）注册于2023年1月1日，用户002（李四）注册于2023年6月15日。从注册时间来看，用户001比用户002早注册大约5个半月（约166天）。这显示出在2023年上半年，用户注册活动至少持续了半年，且早期注册的用户角色为管理员，后期注册的为开发者。可以推测系统在初期需要管理员搭建，后续吸引了开发者加入。如需更精确的趋势分析（如月度注册量），需要更全面的数据集。

效果验证点：

路由成功：当输入包含“分析”时，请求被正确路由到使用 GPT-4 的深度分析子代理；普通问候和查询时间则路由到 GPT-3.5 的通用助手。
工具调用：两个代理都成功调用了工具（get_current_time,query_user_database）。
上下文感知：代理在思考过程中能基于之前的观察（Observation）决定下一步动作。
错误处理：当计算器工具无法处理日期减法时，代理能调整策略，用描述性语言完成分析，体现了 LLM 的灵活性。

7. 常见问题与排查思路

在实际配置和运行此类系统时，你会遇到各种问题。以下是根据网络搜索中常见错误整理的排查清单。

问题现象	可能原因	排查方式	解决方案
启动失败，提示`ModuleNotFoundError`	依赖包未安装或虚拟环境未激活。	1. 运行`pip list \| grep langchain`检查。 2. 确认终端前缀显示虚拟环境名。	1. 激活虚拟环境。 2. 使用`pip install -r requirements.txt`安装所有依赖。
运行时代理无响应或报错`OpenAI API`相关错误	API 密钥未设置或无效；网络问题；额度不足。	1. 检查`echo $OPENAI_API_KEY`(Linux/macOS) 或`echo %OPENAI_API_KEY%`(Windows)。 2. 访问 OpenAI 平台检查额度与状态。	1. 正确设置环境变量或`.env`文件。 2. 检查网络连接，特别是代理设置。 3. 确保账户有可用额度。
代理无法正确识别工具，或错误调用工具	1. 工具描述（`docstring`）不清晰。 2. 代理类型（`AgentType`）选择不当。 3. 提示词（Prompt）未优化。	1. 开启`verbose=True`查看代理的思考链（Chain of Thought）。 2. 检查工具的描述是否准确说明了功能和输入格式。	1. 为工具编写清晰、具体的描述。 2. 尝试不同的`AgentType`，如`ZERO_SHOT_REACT_DESCRIPTION`用于简单任务，`CONVERSATIONAL_REACT_DESCRIPTION`用于对话。 3. 自定义提示词，明确告诉代理可用的工具列表和调用格式。
遇到错误`“Could not parse LLM output...”`	LLM 的输出不符合代理解析器（Parser）预期的格式。	查看`verbose`输出中 LLM 返回的原始文本。	1. 设置`handle_parsing_errors=True`让代理尝试修复。 2. 使用更强大的模型（如 GPT-4）作为代理的 LLM。 3. 简化工具定义或使用更结构化的输出解析器（如`StructuredTool`）。
上下文超限错误 (`max tokens`,`request too large`)	对话历史或工具输出太长，超过了模型的最大上下文长度。	1. 检查`ConversationBufferMemory`是否积累了过多内容。 2. 检查单个工具返回的数据量是否过大。	1. 使用`ConversationSummaryMemory`或`ConversationBufferWindowMemory`来限制记忆长度。 2. 在工具函数中对返回结果进行摘要或截断。 3. 升级到支持更长上下文的模型（如 GPT-4 Turbo）。
路由逻辑不准确，任务派发错误	主代理的路由规则（如关键词匹配）过于简单或存在歧义。	打印路由决策的日志，分析哪些输入被错误分类。	1. 实现更复杂的路由逻辑，例如使用一个轻量级 LLM（如 GPT-3.5）作为路由决策器。 2. 结合意图识别（Intent Classification）模型。 3. 建立任务分类规则库。
子代理之间状态隔离问题	多个子代理错误地共享了同一个内存实例，导致对话混乱。	检查初始化代理时传入的`memory`参数是否为独立实例。	确保每个需要独立对话上下文的代理，都拥有自己独立的`memory`对象实例。
工具执行缓慢或超时	工具依赖的外部 API 或服务响应慢。	在工具函数内部添加超时机制和日志。	1. 为工具调用设置超时（`timeout`）。 2. 实现异步（Async）工具调用。 3. 考虑使用缓存（Cache）减少重复调用。

8. 最佳实践与工程建议

将子代理系统用于实际项目时，遵循以下最佳实践可以大幅提升稳定性、可维护性和性能。

8.1 设计层面

明确代理职责：为每个子代理定义清晰的职责边界（Single Responsibility）。例如，“数据提取代理”、“代码生成代理”、“文案润色代理”。避免创建功能臃肿的“全能代理”。
技能粒度适中：工具（技能）的粒度要合适。既不要过于庞大（如一个“处理数据”的工具），也不要过于琐碎。一个好的工具应完成一个明确的、可复用的原子操作。
实现优雅降级：在主代理路由逻辑中，设计备用路径。当首选子代理或工具失败时，能降级到备用方案，或给用户明确的错误提示，而不是让整个系统崩溃。

8.2 配置与开发

使用配置管理：不要将模型名称、API密钥、工具列表等硬编码在代码中。使用配置文件（如config.yaml）或环境变量来管理。这便于在不同环境（开发、测试、生产）间切换。
编写详尽的工具描述：LLM 完全依赖工具函数的docstring来决定是否以及如何调用它。描述应包含：功能、输入参数格式（最好有示例）、输出格式。
实施结构化输出：对于需要从 LLM 或工具获取结构化数据的场景，使用 LangChain 的PydanticOutputParser或StructuredOutputParser，这比解析自由文本稳定得多。

8.3 性能与安全

管理上下文长度：这是成本控制和避免错误的关键。积极使用各种记忆（Memory）管理策略，如缓冲窗口、摘要、向量存储检索，只保留最相关的历史信息。
设置调用预算与限流：为代理设置最大 Token 消耗或最大调用步数（max_iterations），防止在复杂或循环任务中产生天价账单或陷入死循环。
隔离与沙箱化：对于执行代码（如 Python 代码执行工具）、访问数据库或调用外部 API 的工具，必须在严格的沙箱环境中运行，并进行权限控制和输入验证，防止任意代码执行或数据泄露。
记录与监控：记录所有代理的决策过程、工具调用和 LLM 的输入输出。这对于调试、优化提示词、分析成本和理解代理行为至关重要。考虑集成像LangSmith这样的追踪平台。