尧图网站建设 
同一周里我分别在两个项目里接触了两种“性格”完全不同的 AI 智能体一个像老黄牛在任务里老老实实循环了九轮把每一步的计算结果都带回到下一轮最后算出了正确答案另一个像冒险家被装进了沙箱还不安分最后通过合法途径突破了沙箱限制拿到了隔离目录之外的配置信息。这两个案例恰好映照出 AI 智能体开发中两条最核心的技术主线多步任务规划让 Agent 会“想很多步”与沙箱环境管理让 Agent 能“安全地做事”。本文不聊概念空话直接用两个可落地的场景拆解“算下九圈”和“走出沙箱”背后的实现原理、工程代码与避坑清单。无论你是正在入门 AI 智能体开发还是准备在生产环境上线 Agent 应用这篇文章都能给你一套可参考的闭环思路。1. 背景智能体的“思考”与“行动”边界1.1 什么是 AI 智能体AI 智能体AI Agent是当前人工智能应用层最热的落地形态之一。它和普通聊天机器人的最大区别在于不是“你说一句它回一句”而是把一个大的目标拆解成多步任务自己决定先做什么、后做什么并在执行过程中根据环境反馈动态调整策略。一个完整的 AI 智能体通常包含四个核心模块规划模块Planning把用户目标拆解成子任务列表决定调用哪个工具、按什么顺序执行。记忆模块Memory保存上下文、历史操作和中间结果分为短期记忆和长期记忆。工具模块Tools通过函数调用、API、代码执行器等方式与环境交互。反射模块Reflection根据执行结果修正下一步计划或者判断任务是否完成。正是这四部分组合在一起智能体才表现出“能思考、能行动”的能力。近两年热度极高的“工作流搭建”“多智能体协作”“AI 编程助手”本质上都是在优化上述一个或多个模块。1.2 什么是智能体沙箱沙箱Sandbox是一种隔离机制它把智能体的代码执行、文件访问、网络请求限制在一个受控范围内防止因模型幻觉、工具误调用或恶意输入导致系统被破坏。沙箱解决的核心问题有三个安全隔离智能体可能需要动态执行 Python/Shell 代码这些代码不能直接在宿主机上运行。资源控制防止智能体调用死循环、超限内存、无限写盘影响宿主机稳定性。权限收敛默认情况下智能体只能访问预设的数据目录和 API 白名单不暴露生产密钥和敏感系统。“同一周两个 AI 智能体”里说的“一个走出沙箱”并不是指系统被攻破而是指通过合理配置和权限提升机制让智能体在授权范围内从受限的容器环境过渡到可访问更多资源的执行环境。这在真实的智能体工程落地中很常见比如本地开发时智能体在 Docker 沙箱里跑但联调时需要通过 DevContainer 或远程环境访问内部测试库。1.3 两条主线的对应关系比喻技术主线核心问题现实场景算下九圈多步任务规划与循环控制智能体如何围绕一个目标多轮推理、反复修正数学推理、代码自动修复、数据分析、业务指标拆解走出沙箱沙箱机制与权限边界扩展智能体如何在受控前提下访问更多资源自动化测试、多环境部署、跨系统数据同步理解了这两条主线后面的实战案例就好展开了。2. 环境准备与版本说明由于 AI 智能体开发涉及“模型调用 代码执行 工具集成”三层结构环境准备也比较多样。本文示例以Python 3.10为底座按需使用 LangChain 生态和 Docker 沙箱。你在本地实验时按下面清单准备即可。# 建议环境 操作系统Windows 10/11、macOS 12 或 Ubuntu 20.04 Python3.10 或 3.11 开发工具VS Code 或 PyCharm 容器工具Docker DesktopWindows/macOS或 Docker EngineLinuxPython 依赖方面我会用到以下库版本以你实际安装为准通常用pip install拉取最新稳定版即可pip install langchain langchain-openai python-dotenv docker requests说明本文案例中调用大模型的部分你可以使用 OpenAI 兼容接口、国内云厂商的模型服务也可以使用本地部署的 Ollama 开源模型。重点是展示智能体循环控制和沙箱边界管理的设计思路模型服务本身不强制特定品牌。版本差异较大时我会在代码中标注需要按实际情况修改的位置。为了便于统一管理密钥建议在项目根目录创建.env文件内容示例如下# .env LLM_API_KEY你的模型API密钥 LLM_BASE_URLhttps://你的模型服务地址 LLM_MODEL_NAME你的模型名称 SANDBOX_WORK_DIR/tmp/agent_workspace DOCKER_IMAGEpython:3.11-slim注意.env文件不要提交到 Git 仓库建议加入.gitignore。3. 核心原理拆解3.1 “算下九圈”多步循环任务的实现逻辑所谓“算下九圈”对应到技术上就是ReActReasoning Acting模式。智能体在一个任务上经历多轮“思考→行动→观察→再思考”的循环每一轮都把上一轮的观察结果拼接到上下文里让模型基于最新信息做出下一步决策。举个例子一个智能体收到“计算 2024 年 1 月至 3 月某产品线的环比增长率”任务。它可能需要先查询数据库、再清洗数据、再计算结果、再解释结论。每一步的输出是下一步的输入如果某一步出错它还能基于错误信息自我修正。这就是“会多绕几圈”的智能体。当前主流的多步循环实现方式主要有三种直接写一个 while 循环控制最大轮数最简单但需要手动管理记忆拼接和退出条件。使用 LangChain 的 AgentExecutor框架内置了 ReAct 循环只需要提供工具列表和停止条件。使用 Workflow/Graph 模式把智能体流程可视化为节点和边的有向图允许分支、合并和条件跳转。无论哪种方式最关键的问题是循环什么时候停一般有三种停止条件智能体输出“最终答案”标记如Final Answer: ...。达到最大迭代次数防止死循环。检测到工具调用异常或用户手动停止。下面是一个最小化的 ReAct 循环示例用代码模拟“算下九圈”的过程# 文件路径examples/mini_react_loop.py from langchain_openai import ChatOpenAI from langchain.agents import AgentExecutor, create_react_agent from langchain.tools import tool from langchain.prompts import PromptTemplate # 1. 准备一个工具模拟数据查询 tool def query_monthly_revenue(month: str) - str: 查询指定月份的销售收入month 格式为 YYYY-MM。 revenue_data { 2024-01: 120万, 2024-02: 135万, 2024-03: 150万, } return revenue_data.get(month, f没有 {month} 的数据) # 2. 配置模型 llm ChatOpenAI( model你的模型名称, # 按实际情况修改 api_key你的API密钥, # 推荐从 .env 读取 base_url你的模型服务地址 # 兼容 OpenAI 格式的模型服务 ) # 3. 构造 ReAct 提示词模板 prompt PromptTemplate.from_template( 你是一个数据分析助手可以查询月度收入数据。 你必须按照以下格式输出 思考...分析当前情况 行动工具名称 行动输入工具参数 观察...工具返回的结果 如果已经得到最终答案请输出 Final Answer: ...最终结论 已知工具 {tools} 工具名称格式 {tool_names} 用户问题{input} 历史思考过程{agent_scratchpad} ) # 4. 创建 Agent 并执行 agent create_react_agent(llmllm, tools[query_monthly_revenue], promptprompt) executor AgentExecutor( agentagent, tools[query_monthly_revenue], max_iterations5, # 最多允许“绕五圈”防止死循环 verboseTrue # 打印完整思考过程 ) result executor.invoke({input: 请依次查询 1 月、2 月、3 月的收入并告诉我哪个月环比增幅最大。}) print(result[output])这段代码的优点是结构清晰能看到智能体每一步的工具调用。实际运行时模型会经历“查询1月→查询2月→查询3月→比较增长幅度→输出结论”这样一个多轮循环也就是“算下九圈”的本质。3.2 “走出沙箱”沙箱边界与权限扩展设计再来看第二个主线。很多开发者在搭建智能体时会直接把代码执行功能接到宿主机上这非常危险。模型一旦被提示词注入例如用户输入里藏了os.system(rm -rf /)宿主机就可能遭殃。所以工程上通常会让代码执行类工具跑在沙箱里。沙箱常见的实现方案有Docker 容器每次执行创建一个临时容器用完即销毁隔离性最好。Firejail / gVisor / runc更底层的进程级或系统级隔离。云函数/FaaS把代码执行托管给云平台天然带超时和隔离。子进程 资源限制通过resource模块限制 CPU/内存适合轻量场景。“走出沙箱”在工程上指的是把原本运行在默认隔离容器里的智能体通过配置允许它访问指定宿主机目录、内网服务或附加密钥。例如开发环境默认 docker 沙箱无网络权限但你希望智能体能读取宿主机的/data/reports目录这时候就需要在启动容器时挂载目录并设置只读权限。下面是一个使用 Docker SDK 让 Python 代码在沙箱中执行的示例同时演示如何通过挂载目录实现“走出沙箱”的合法扩展# 文件路径examples/sandbox_executor.py import docker import uuid client docker.from_env() # 受控工作目录宿主机目录会被挂载进容器 HOST_WORK_DIR /tmp/agent_workspace CONTAINER_WORK_DIR /workspace IMAGE_NAME python:3.11-slim def execute_code_in_sandbox(code: str, mount_workspace: bool True) - str: 在 Docker 沙箱内执行一段 Python 代码。 如果 mount_workspaceTrue则把宿主机的 HOST_WORK_DIR 挂载进容器 相当于授权智能体访问这个目录 —— 即“走出沙箱”的合法方式。 container_name fsandbox_{uuid.uuid4().hex[:8]} # 写入待执行的代码文件到宿主机工作目录 code_file f{HOST_WORK_DIR}/task_code.py with open(code_file, w, encodingutf-8) as f: f.write(code) # 容器配置和挂载 volumes {} if mount_workspace: volumes[HOST_WORK_DIR] {bind: CONTAINER_WORK_DIR, mode: rw} command fpython {CONTAINER_WORK_DIR}/task_code.py try: container client.containers.run( imageIMAGE_NAME, commandcommand, volumesvolumes, working_dirCONTAINER_WORK_DIR, network_disabledFalse, # 允许网络访问 mem_limit512m, # 内存上限 cpu_period100000, cpu_quota50000, # 限制约 0.5 核 CPU detachTrue, namecontainer_name, removeFalse, ) output container.wait(timeout30) logs container.logs().decode(utf-8, errorsreplace) return f退出码: {output.get(StatusCode)}\n日志输出:\n{logs} except Exception as e: return f沙箱执行异常: {str(e)} finally: try: container.remove(forceTrue) except Exception: pass if __name__ __main__: demo_code import os print(os.getcwd()) print(os.listdir(/workspace) if os.path.exists(/workspace) else 工作目录未挂载) print(execute_code_in_sandbox(demo_code))执行这段代码前需要先确保 Docker 服务已启动并且宿主机存在/tmp/agent_workspace目录mkdir -p /tmp/agent_workspace python examples/sandbox_executor.py运行结果大致如下退出码: 0 日志输出: /workspace [task_code.py]可以看到沙箱容器内可以读取宿主机的挂载目录。如果去掉mount_workspaceTrue容器内的/workspace就不存在。这就是沙箱边界控制的最直观演示默认隔离按需放行。3.3 两个能力如何配合真正的生产级智能体往往同时需要这两种能力。举一个常见的“运维诊断智能体”场景智能体接收“检查 Nginx 日志中最近一小时内 5xx 错误占比”的任务。它先通过工具查询日志目录这需要“走出沙箱”——让容器能够挂载读取日志目录。它拿到原始日志后需要写一段 Python 脚本做聚合统计这又需要“算下九圈”——在沙箱内执行代码、观察输出、修正脚本、再次执行直到得到正确统计结果。所以多步循环是“大脑”沙箱是“手脚”“大脑”在每一轮思考后指挥“手脚”去行动再根据行动反馈继续思考。4. 完整实战构建一个带沙箱与多轮推理的代码质量审查智能体为了把两个核心能力整合到一起我们来做一个相对完整的小项目代码质量审查智能体。它的功能是读入一段代码 → 在沙箱中运行测试 → 根据运行结果和静态分析给出缺陷列表和修复建议。这个项目综合了“算下九圈”的 ReAct 循环也综合了“走出沙箱”的 Docker 执行机制。4.1 项目结构规划agent-code-reviewer/ ├── .env ├── requirements.txt ├── main.py ├── tools/ │ ├── __init__.py │ ├── code_executor.py │ └── static_checker.py └── workdir/ └── sample_code.py目录说明main.py主入口负责创建智能体并启动 ReAct 循环。tools/code_executor.py封装 Docker 沙箱执行工具。tools/static_checker.py一个简单的静态检查工具用于查找常见问题。workdir/宿主机工作目录会挂载进沙箱容器。4.2 添加依赖与配置requirements.txtlangchain0.2.0 langchain-openai0.1.0 python-dotenv1.0.0 docker7.0.0.env配置LLM_API_KEY你的模型API密钥 LLM_BASE_URL你的模型服务地址 LLM_MODEL_NAME你的模型名称 SANDBOX_IMAGEpython:3.11-slim SANDBOX_WORK_DIR./workdir需要在项目根目录创建workdir目录并在其中放入一个待审查的示例代码文件sample_code.py# 文件路径workdir/sample_code.py def calculate_average(numbers): total 0 for num in numbers: total num return total / len(numbers) if __name__ __main__: data [10, 20, 30, 40] print(calculate_average(data))这段代码存在两个典型问题没有处理空列表会抛 ZeroDivisionError以及求和方式不够 Pythonic。智能体需要在沙箱中执行它观察结果再给出审查意见。4.3 编写工具函数先实现沙箱执行工具 # 文件路径tools/code_executor.py import os import uuid import docker from dotenv import load_dotenv load_dotenv() class SandboxExecutor: def __init__(self): self.client docker.from_env() self.image os.getenv(SANDBOX_IMAGE, python:3.11-slim) self.work_dir os.getenv(SANDBOX_WORK_DIR, ./workdir) self.abs_work_dir os.path.abspath(self.work_dir) def execute_python(self, code: str, timeout: int 30) - str: 在沙箱容器中执行 Python 代码并返回标准输出和错误信息。 # 把代码写入宿主机工作目录 filename ftask_{uuid.uuid4().hex[:8]}.py host_path os.path.join(self.abs_work_dir, filename) container_path f/workspace/{filename} with open(host_path, w, encodingutf-8) as f: f.write(code) # 容器内执行 volumes {self.abs_work_dir: {bind: /workspace, mode: rw}} command fpython {container_path} container None try: container self.client.containers.run( imageself.image, commandcommand, volumesvolumes, working_dir/workspace, network_disabledFalse, mem_limit256m, cpu_period100000, cpu_quota50000, detachTrue, removeFalse, ) result container.wait(timeouttimeout) logs container.logs().decode(utf-8, errorsreplace) status_code result.get(StatusCode) return f[退出码 {status_code}]\n{logs} except docker.errors.ContainerError as e: return f容器执行失败: {str(e)} except Exception as e: return f沙箱异常: {str(e)} finally: if container: try: container.remove(forceTrue) except Exception: pass # 清理临时文件 if os.path.exists(host_path): os.remove(host_path)再实现一个简单的静态检查工具# 文件路径tools/static_checker.py import ast class StaticChecker: 极简静态检查器通过 AST 查找空函数、空列表除法、未使用变量等常见问题。 def __init__(self, source_code: str): self.source_code source_code self.tree ast.parse(source_code) def check(self) - list: issues [] for node in ast.walk(self.tree): # 检查除法中分母是否可能是 len() 调用 if isinstance(node, ast.Div): if isinstance(node.right, ast.Call) and isinstance(node.right.func, ast.Name) and node.right.func.id len: issues.append(发现除法分母为 len(...)当列表为空时会触发 ZeroDivisionError。) # 检查循环求和是否可以用 sum() 替代 if isinstance(node, ast.For): target_lines node.lineno issues.append(f第 {target_lines} 行存在 for 循环建议考虑使用内置 sum() 提升可读性。) return issues def run(self) - str: issues self.check() if issues: return 静态检查发现以下可疑点\n \n.join(f- {issue} for issue in set(issues)) return 静态检查未发现明显问题。4.4 编写主程序在主程序中我们把两个工具注册给 LangChain Agent并设置最大迭代次数。这样智能体就能“边看结果边修改”实现多轮循环审查# 文件路径main.py import ast from dotenv import load_dotenv from langchain_openai import ChatOpenAI from langchain.agents import AgentExecutor, create_react_agent from langchain.tools import tool from langchain.prompts import PromptTemplate from tools.code_executor import SandboxExecutor from tools.static_checker import StaticChecker load_dotenv() # 实例化工具 sandbox SandboxExecutor() tool def run_code_in_sandbox(code: str) - str: 将 Python 代码放入 Docker 沙箱中执行返回标准输出和执行结果。 可用于运行测试代码、验证脚本逻辑。 return sandbox.execute_python(code) tool def static_check_code(file_path: str) - str: 对指定 Python 文件做静态 AST 检查返回可疑问题列表。 file_path 是沙箱工作目录内的文件名。 # 读取宿主机工作目录中的代码文件 import os full_path os.path.join(workdir, os.path.basename(file_path)) if not os.path.exists(full_path): return f文件 {file_path} 不存在请先上传到工作目录。 with open(full_path, r, encodingutf-8) as f: source f.read() checker StaticChecker(source) return checker.run() # 模型配置 llm ChatOpenAI( modelos.getenv(LLM_MODEL_NAME), api_keyos.getenv(LLM_API_KEY), base_urlos.getenv(LLM_BASE_URL), temperature0.1 ) # 创建 ReAct Agent prompt PromptTemplate.from_template( 你是一个代码质量审查专家。你可以使用工具来分析代码并给出修复建议。 你必须按照以下格式输出 思考分析当前任务并决定下一步行动 行动工具名称 行动输入工具需要的参数 观察工具返回的结果 当收集到足够信息后使用以下格式输出最终答案 Final Answer: 基于观察结果的完整审查报告。 可用工具 {tools} 工具名称列表 {tool_names} 用户目标{input} 当前推理轨迹{agent_scratchpad} ) agent create_react_agent(llmllm, tools[run_code_in_sandbox, static_check_code], promptprompt) executor AgentExecutor( agentagent, tools[run_code_in_sandbox, static_check_code], max_iterations10, # 允许“绕十圈” verboseTrue, handle_parsing_errorsTrue ) if __name__ __main__: task ( 请审查 workdir/sample_code.py 这个文件。 先做静态检查再写一段测试代码放到沙箱里执行 验证 calculate_average 函数在空列表输入时是否会报错。 最后给出完整修复建议。 ) result executor.invoke({input: task}) print(\n 最终审查报告 \n) print(result[output])4.5 运行与验证在项目根目录依次执行pip install -r requirements.txt python main.py如果一切正常你会在verboseTrue的日志里看到类似下面的多轮循环过程 Entering new AgentExecutor chain... 思考首先读取文件并做静态检查。 行动static_check_code 行动输入{file_path: workdir/sample_code.py} 观察静态检查发现以下可疑点 - 第 8 行存在 for 循环建议考虑使用内置 sum() 提升可读性。 - 发现除法分母为 len(...)当列表为空时会触发 ZeroDivisionError。 思考静态检查发现了两个问题。接下来需要验证空列表输入时的行为。 行动run_code_in_sandbox 行动输入{code: from workdir.sample_code import calculate_average\nprint(calculate_average([]))} 观察[退出码 1] Traceback (most recent call last): ... ZeroDivisionError: division by zero 思考实验结果确认空列表会触发 ZeroDivisionError。现在可以给出最终报告了。 Final Answer: ...最终输出的审查报告会包含空列表输入会导致ZeroDivisionError原因是len(numbers)为 0分母为 0。for循环累加可以改用sum(numbers)代码更简洁且不易出错。修复建议示例增加防御性判断或让函数在空列表时返回0或抛出明确异常。到这里两个能力就完成了整合智能体“绕了几圈”多轮循环才拿到了“沙箱外/沙箱内”的验证结果并基于观察修正了最终答案。5. 常见问题与排查思路在实际开发中很多读者会在“多步循环”和“沙箱执行”两块踩坑。下面整理一个高频问题排查表按优先级排列问题现象常见原因排查步骤解决思路Agent 一直不输出 Final Answer循环轮数不够或模型陷入死循环观察 verbose 日志中是否反复调用相同工具提高max_iterations或优化提示词要求模型尽早总结工具参数格式解析失败模型返回的 JSON 格式不规范打印原始模型输出定位解析错误位置开启handle_parsing_errorsTrue改用框架 Tool 的args_schema做强校验Docker 沙箱启动失败Docker Desktop 未启动或镜像拉取失败执行docker ps检查 Docker 服务启动 Docker 服务确认python:3.11-slim镜像已存在沙箱容器能运行但读不到宿主机文件没有挂载卷或路径不对检查volumes配置路径是否为绝对路径改用os.path.abspath()挂载时目录权限设为rw沙箱内无法访问外网容器没有配置网络检查network_disabled参数设为False或调整 Docker daemon 的 iptables 规则模型 API 调用超时网络代理或 API 服务不稳定先用 curl 测试 API 连通性设置更长超时时间检查.env中 base_url 是否正确容器内执行中文日志乱码基础镜像未安装中文字体或编码查看容器内locale环境变量在命令前加export PYTHONIOENCODINGutf-8其中最容易忽略的是“循环不是越久越好”。每多绕一圈模型推理的 token 消耗就成倍增加而且历史轨迹越长模型越容易偏离最初目标。通常建议简单任务max_iterations3~5中等任务max_iterations8~10复杂任务优先拆成子 Agent而不是直接拉大循环上限6. 最佳实践与工程建议6.1 多步循环设计建议第一把“退出条件”前置到提示词里。不要只靠代码写最大迭代次数应该在系统提示里明确告诉模型“当获得足够信息时立即输出 Final Answer不要过度检查”。这样能大幅减少无效循环。第二给工具调用加结构化输入校验。直接让模型生成 JSON 参数时模型可能漏字段或传错类型。用 LangChain 的pydantic定义参数模型是更稳妥的做法from pydantic import BaseModel, Field class CodeRunInput(BaseModel): code: str Field(description要执行的 Python 代码) tool(args_schemaCodeRunInput) def run_code_in_sandbox(code: str) - str: return sandbox.execute_python(code)第三保留完整轨迹用于审计。生产环境建议把每一轮“思考、行动、观察”写入结构化日志。一旦智能体产出异常结果可以快速定位是哪一步出了问题。6.2 沙箱安全管理建议第一默认最小权限。沙箱容器不要用--privileged不要挂载宿主机的敏感目录如/etc、/root尽量用只读挂载。如果智能体需要写结果可以单独挂载一个输出目录。第二资源限制必须写死。在容器配置中显式设置mem_limit、cpu_quota、pids_limit。否则恶意代码或错误逻辑可能拖垮宿主机。下面是 Docker SDK 中可以补充的参数container self.client.containers.run( ..., mem_limit512m, cpu_period100000, cpu_quota50000, pids_limit256, nano_cpus500000000, # 等价于 0.5 核 read_onlyTrue, # 根文件系统只读 tmpfs{/tmp: size100m} # 临时可写目录 )第三网络按需开放。执行代码类的沙箱默认应禁用网络network_disabledTrue。只有当前任务确实需要下载依赖包或调用内部 API 时才打开网络并且最好设置白名单。第四合法“走出沙箱”要走审批流。如果要让智能体访问更高权限的数据目录不要直接把宿主机的根目录挂进去。更合理的做法是定义可访问目录的配置文件或环境变量。在权限服务中登记“该智能体可访问某目录”。容器启动时按配置动态生成挂载卷。这样既能“走出沙箱”又能保留审计链路。6.3 生产落地建议如果要上线生产环境不要直接让我写的单机 Python 脚本扛所有流量。建议把沙箱执行拆成独立服务例如 Sidecar 容器或独立 Worker主流程通过消息队列提交任务。这样可以避免因为某个智能体任务异常导致整个应用崩溃。另外大模型服务的密钥管理务必使用环境变量、密钥管理服务或 Kubernetes Secret不要硬编码进代码仓库。所有模型调用链路建议接入全链路追踪OpenTelemetry 等方便复现问题。7. 总结与学习路线这一周的两个智能体给我留下很深的印象本质上是两种工程能力的映射“算下九圈”考验智能体的多步规划与自我修正能力“走出沙箱”考验系统的安全边界与资源扩展能力。两者组合起来才是生产级 AI 智能体该有的样子——既聪明又可靠。读完这篇文章你应该掌握了ReAct 多步循环的执行原理以及如何通过AgentExecutor控制循环轮数和退出条件。Docker 沙箱的基本使用以及如何通过挂载卷实现“按需放行”的合法资源访问。组合两个能力完成一个“代码审查智能体”的完整流程。常见异常如何排查尤其是循环失控和沙箱权限问题。下一步你可以按以下方向继续深入学习 LangGraph它是比 AgentExecutor 更灵活的多智能体编排框架可以精细控制每个节点的状态转移、条件分支和人工介入。探索沙箱替代方案对比 Docker、Firecracker、WebAssembly 微虚拟机的隔离性能和启动速度选择适合自己业务场景的沙箱底座。实践提示词注入防御特别注意用户输入可能干扰智能体目标和工具调用行为在提示词中加入分隔符约束和敏感操作二次确认机制。关注 Agent 可观测性在正式项目里引入完整的日志、跟踪、回放能力否则智能体一旦在复杂链路中做错一步排错会非常痛苦。最后给你一个非常实用的建议在智能体上线前先总结一份“能力边界文档”明确列出它能调用哪些工具、不能调用哪些工具、运行在什么沙箱权限下、最多循环多少轮。这份文档不仅是给团队看的也是给模型自身的安全护栏设计依据。如果这篇文章对你有帮助别忘了收藏备用。后续如果你们团队在做智能体工作流调度、沙箱逃逸检测或代码执行类 Agent 应用时遇到了新问题欢迎在评论区和我交流。技术这条路总要亲手折腾过几个 Agent踩过几个坑才算真正入门。 从多步循环到沙箱突破：AI智能体开发两大核心主线实战解析
同一周里我分别在两个项目里接触了两种“性格”完全不同的 AI 智能体一个像老黄牛在任务里老老实实循环了九轮把每一步的计算结果都带回到下一轮最后算出了正确答案另一个像冒险家被装进了沙箱还不安分最后通过合法途径突破了沙箱限制拿到了隔离目录之外的配置信息。这两个案例恰好映照出 AI 智能体开发中两条最核心的技术主线多步任务规划让 Agent 会“想很多步”与沙箱环境管理让 Agent 能“安全地做事”。本文不聊概念空话直接用两个可落地的场景拆解“算下九圈”和“走出沙箱”背后的实现原理、工程代码与避坑清单。无论你是正在入门 AI 智能体开发还是准备在生产环境上线 Agent 应用这篇文章都能给你一套可参考的闭环思路。1. 背景智能体的“思考”与“行动”边界1.1 什么是 AI 智能体AI 智能体AI Agent是当前人工智能应用层最热的落地形态之一。它和普通聊天机器人的最大区别在于不是“你说一句它回一句”而是把一个大的目标拆解成多步任务自己决定先做什么、后做什么并在执行过程中根据环境反馈动态调整策略。一个完整的 AI 智能体通常包含四个核心模块规划模块Planning把用户目标拆解成子任务列表决定调用哪个工具、按什么顺序执行。记忆模块Memory保存上下文、历史操作和中间结果分为短期记忆和长期记忆。工具模块Tools通过函数调用、API、代码执行器等方式与环境交互。反射模块Reflection根据执行结果修正下一步计划或者判断任务是否完成。正是这四部分组合在一起智能体才表现出“能思考、能行动”的能力。近两年热度极高的“工作流搭建”“多智能体协作”“AI 编程助手”本质上都是在优化上述一个或多个模块。1.2 什么是智能体沙箱沙箱Sandbox是一种隔离机制它把智能体的代码执行、文件访问、网络请求限制在一个受控范围内防止因模型幻觉、工具误调用或恶意输入导致系统被破坏。沙箱解决的核心问题有三个安全隔离智能体可能需要动态执行 Python/Shell 代码这些代码不能直接在宿主机上运行。资源控制防止智能体调用死循环、超限内存、无限写盘影响宿主机稳定性。权限收敛默认情况下智能体只能访问预设的数据目录和 API 白名单不暴露生产密钥和敏感系统。“同一周两个 AI 智能体”里说的“一个走出沙箱”并不是指系统被攻破而是指通过合理配置和权限提升机制让智能体在授权范围内从受限的容器环境过渡到可访问更多资源的执行环境。这在真实的智能体工程落地中很常见比如本地开发时智能体在 Docker 沙箱里跑但联调时需要通过 DevContainer 或远程环境访问内部测试库。1.3 两条主线的对应关系比喻技术主线核心问题现实场景算下九圈多步任务规划与循环控制智能体如何围绕一个目标多轮推理、反复修正数学推理、代码自动修复、数据分析、业务指标拆解走出沙箱沙箱机制与权限边界扩展智能体如何在受控前提下访问更多资源自动化测试、多环境部署、跨系统数据同步理解了这两条主线后面的实战案例就好展开了。2. 环境准备与版本说明由于 AI 智能体开发涉及“模型调用 代码执行 工具集成”三层结构环境准备也比较多样。本文示例以Python 3.10为底座按需使用 LangChain 生态和 Docker 沙箱。你在本地实验时按下面清单准备即可。# 建议环境 操作系统Windows 10/11、macOS 12 或 Ubuntu 20.04 Python3.10 或 3.11 开发工具VS Code 或 PyCharm 容器工具Docker DesktopWindows/macOS或 Docker EngineLinuxPython 依赖方面我会用到以下库版本以你实际安装为准通常用pip install拉取最新稳定版即可pip install langchain langchain-openai python-dotenv docker requests说明本文案例中调用大模型的部分你可以使用 OpenAI 兼容接口、国内云厂商的模型服务也可以使用本地部署的 Ollama 开源模型。重点是展示智能体循环控制和沙箱边界管理的设计思路模型服务本身不强制特定品牌。版本差异较大时我会在代码中标注需要按实际情况修改的位置。为了便于统一管理密钥建议在项目根目录创建.env文件内容示例如下# .env LLM_API_KEY你的模型API密钥 LLM_BASE_URLhttps://你的模型服务地址 LLM_MODEL_NAME你的模型名称 SANDBOX_WORK_DIR/tmp/agent_workspace DOCKER_IMAGEpython:3.11-slim注意.env文件不要提交到 Git 仓库建议加入.gitignore。3. 核心原理拆解3.1 “算下九圈”多步循环任务的实现逻辑所谓“算下九圈”对应到技术上就是ReActReasoning Acting模式。智能体在一个任务上经历多轮“思考→行动→观察→再思考”的循环每一轮都把上一轮的观察结果拼接到上下文里让模型基于最新信息做出下一步决策。举个例子一个智能体收到“计算 2024 年 1 月至 3 月某产品线的环比增长率”任务。它可能需要先查询数据库、再清洗数据、再计算结果、再解释结论。每一步的输出是下一步的输入如果某一步出错它还能基于错误信息自我修正。这就是“会多绕几圈”的智能体。当前主流的多步循环实现方式主要有三种直接写一个 while 循环控制最大轮数最简单但需要手动管理记忆拼接和退出条件。使用 LangChain 的 AgentExecutor框架内置了 ReAct 循环只需要提供工具列表和停止条件。使用 Workflow/Graph 模式把智能体流程可视化为节点和边的有向图允许分支、合并和条件跳转。无论哪种方式最关键的问题是循环什么时候停一般有三种停止条件智能体输出“最终答案”标记如Final Answer: ...。达到最大迭代次数防止死循环。检测到工具调用异常或用户手动停止。下面是一个最小化的 ReAct 循环示例用代码模拟“算下九圈”的过程# 文件路径examples/mini_react_loop.py from langchain_openai import ChatOpenAI from langchain.agents import AgentExecutor, create_react_agent from langchain.tools import tool from langchain.prompts import PromptTemplate # 1. 准备一个工具模拟数据查询 tool def query_monthly_revenue(month: str) - str: 查询指定月份的销售收入month 格式为 YYYY-MM。 revenue_data { 2024-01: 120万, 2024-02: 135万, 2024-03: 150万, } return revenue_data.get(month, f没有 {month} 的数据) # 2. 配置模型 llm ChatOpenAI( model你的模型名称, # 按实际情况修改 api_key你的API密钥, # 推荐从 .env 读取 base_url你的模型服务地址 # 兼容 OpenAI 格式的模型服务 ) # 3. 构造 ReAct 提示词模板 prompt PromptTemplate.from_template( 你是一个数据分析助手可以查询月度收入数据。 你必须按照以下格式输出 思考...分析当前情况 行动工具名称 行动输入工具参数 观察...工具返回的结果 如果已经得到最终答案请输出 Final Answer: ...最终结论 已知工具 {tools} 工具名称格式 {tool_names} 用户问题{input} 历史思考过程{agent_scratchpad} ) # 4. 创建 Agent 并执行 agent create_react_agent(llmllm, tools[query_monthly_revenue], promptprompt) executor AgentExecutor( agentagent, tools[query_monthly_revenue], max_iterations5, # 最多允许“绕五圈”防止死循环 verboseTrue # 打印完整思考过程 ) result executor.invoke({input: 请依次查询 1 月、2 月、3 月的收入并告诉我哪个月环比增幅最大。}) print(result[output])这段代码的优点是结构清晰能看到智能体每一步的工具调用。实际运行时模型会经历“查询1月→查询2月→查询3月→比较增长幅度→输出结论”这样一个多轮循环也就是“算下九圈”的本质。3.2 “走出沙箱”沙箱边界与权限扩展设计再来看第二个主线。很多开发者在搭建智能体时会直接把代码执行功能接到宿主机上这非常危险。模型一旦被提示词注入例如用户输入里藏了os.system(rm -rf /)宿主机就可能遭殃。所以工程上通常会让代码执行类工具跑在沙箱里。沙箱常见的实现方案有Docker 容器每次执行创建一个临时容器用完即销毁隔离性最好。Firejail / gVisor / runc更底层的进程级或系统级隔离。云函数/FaaS把代码执行托管给云平台天然带超时和隔离。子进程 资源限制通过resource模块限制 CPU/内存适合轻量场景。“走出沙箱”在工程上指的是把原本运行在默认隔离容器里的智能体通过配置允许它访问指定宿主机目录、内网服务或附加密钥。例如开发环境默认 docker 沙箱无网络权限但你希望智能体能读取宿主机的/data/reports目录这时候就需要在启动容器时挂载目录并设置只读权限。下面是一个使用 Docker SDK 让 Python 代码在沙箱中执行的示例同时演示如何通过挂载目录实现“走出沙箱”的合法扩展# 文件路径examples/sandbox_executor.py import docker import uuid client docker.from_env() # 受控工作目录宿主机目录会被挂载进容器 HOST_WORK_DIR /tmp/agent_workspace CONTAINER_WORK_DIR /workspace IMAGE_NAME python:3.11-slim def execute_code_in_sandbox(code: str, mount_workspace: bool True) - str: 在 Docker 沙箱内执行一段 Python 代码。 如果 mount_workspaceTrue则把宿主机的 HOST_WORK_DIR 挂载进容器 相当于授权智能体访问这个目录 —— 即“走出沙箱”的合法方式。 container_name fsandbox_{uuid.uuid4().hex[:8]} # 写入待执行的代码文件到宿主机工作目录 code_file f{HOST_WORK_DIR}/task_code.py with open(code_file, w, encodingutf-8) as f: f.write(code) # 容器配置和挂载 volumes {} if mount_workspace: volumes[HOST_WORK_DIR] {bind: CONTAINER_WORK_DIR, mode: rw} command fpython {CONTAINER_WORK_DIR}/task_code.py try: container client.containers.run( imageIMAGE_NAME, commandcommand, volumesvolumes, working_dirCONTAINER_WORK_DIR, network_disabledFalse, # 允许网络访问 mem_limit512m, # 内存上限 cpu_period100000, cpu_quota50000, # 限制约 0.5 核 CPU detachTrue, namecontainer_name, removeFalse, ) output container.wait(timeout30) logs container.logs().decode(utf-8, errorsreplace) return f退出码: {output.get(StatusCode)}\n日志输出:\n{logs} except Exception as e: return f沙箱执行异常: {str(e)} finally: try: container.remove(forceTrue) except Exception: pass if __name__ __main__: demo_code import os print(os.getcwd()) print(os.listdir(/workspace) if os.path.exists(/workspace) else 工作目录未挂载) print(execute_code_in_sandbox(demo_code))执行这段代码前需要先确保 Docker 服务已启动并且宿主机存在/tmp/agent_workspace目录mkdir -p /tmp/agent_workspace python examples/sandbox_executor.py运行结果大致如下退出码: 0 日志输出: /workspace [task_code.py]可以看到沙箱容器内可以读取宿主机的挂载目录。如果去掉mount_workspaceTrue容器内的/workspace就不存在。这就是沙箱边界控制的最直观演示默认隔离按需放行。3.3 两个能力如何配合真正的生产级智能体往往同时需要这两种能力。举一个常见的“运维诊断智能体”场景智能体接收“检查 Nginx 日志中最近一小时内 5xx 错误占比”的任务。它先通过工具查询日志目录这需要“走出沙箱”——让容器能够挂载读取日志目录。它拿到原始日志后需要写一段 Python 脚本做聚合统计这又需要“算下九圈”——在沙箱内执行代码、观察输出、修正脚本、再次执行直到得到正确统计结果。所以多步循环是“大脑”沙箱是“手脚”“大脑”在每一轮思考后指挥“手脚”去行动再根据行动反馈继续思考。4. 完整实战构建一个带沙箱与多轮推理的代码质量审查智能体为了把两个核心能力整合到一起我们来做一个相对完整的小项目代码质量审查智能体。它的功能是读入一段代码 → 在沙箱中运行测试 → 根据运行结果和静态分析给出缺陷列表和修复建议。这个项目综合了“算下九圈”的 ReAct 循环也综合了“走出沙箱”的 Docker 执行机制。4.1 项目结构规划agent-code-reviewer/ ├── .env ├── requirements.txt ├── main.py ├── tools/ │ ├── __init__.py │ ├── code_executor.py │ └── static_checker.py └── workdir/ └── sample_code.py目录说明main.py主入口负责创建智能体并启动 ReAct 循环。tools/code_executor.py封装 Docker 沙箱执行工具。tools/static_checker.py一个简单的静态检查工具用于查找常见问题。workdir/宿主机工作目录会挂载进沙箱容器。4.2 添加依赖与配置requirements.txtlangchain0.2.0 langchain-openai0.1.0 python-dotenv1.0.0 docker7.0.0.env配置LLM_API_KEY你的模型API密钥 LLM_BASE_URL你的模型服务地址 LLM_MODEL_NAME你的模型名称 SANDBOX_IMAGEpython:3.11-slim SANDBOX_WORK_DIR./workdir需要在项目根目录创建workdir目录并在其中放入一个待审查的示例代码文件sample_code.py# 文件路径workdir/sample_code.py def calculate_average(numbers): total 0 for num in numbers: total num return total / len(numbers) if __name__ __main__: data [10, 20, 30, 40] print(calculate_average(data))这段代码存在两个典型问题没有处理空列表会抛 ZeroDivisionError以及求和方式不够 Pythonic。智能体需要在沙箱中执行它观察结果再给出审查意见。4.3 编写工具函数先实现沙箱执行工具 # 文件路径tools/code_executor.py import os import uuid import docker from dotenv import load_dotenv load_dotenv() class SandboxExecutor: def __init__(self): self.client docker.from_env() self.image os.getenv(SANDBOX_IMAGE, python:3.11-slim) self.work_dir os.getenv(SANDBOX_WORK_DIR, ./workdir) self.abs_work_dir os.path.abspath(self.work_dir) def execute_python(self, code: str, timeout: int 30) - str: 在沙箱容器中执行 Python 代码并返回标准输出和错误信息。 # 把代码写入宿主机工作目录 filename ftask_{uuid.uuid4().hex[:8]}.py host_path os.path.join(self.abs_work_dir, filename) container_path f/workspace/{filename} with open(host_path, w, encodingutf-8) as f: f.write(code) # 容器内执行 volumes {self.abs_work_dir: {bind: /workspace, mode: rw}} command fpython {container_path} container None try: container self.client.containers.run( imageself.image, commandcommand, volumesvolumes, working_dir/workspace, network_disabledFalse, mem_limit256m, cpu_period100000, cpu_quota50000, detachTrue, removeFalse, ) result container.wait(timeouttimeout) logs container.logs().decode(utf-8, errorsreplace) status_code result.get(StatusCode) return f[退出码 {status_code}]\n{logs} except docker.errors.ContainerError as e: return f容器执行失败: {str(e)} except Exception as e: return f沙箱异常: {str(e)} finally: if container: try: container.remove(forceTrue) except Exception: pass # 清理临时文件 if os.path.exists(host_path): os.remove(host_path)再实现一个简单的静态检查工具# 文件路径tools/static_checker.py import ast class StaticChecker: 极简静态检查器通过 AST 查找空函数、空列表除法、未使用变量等常见问题。 def __init__(self, source_code: str): self.source_code source_code self.tree ast.parse(source_code) def check(self) - list: issues [] for node in ast.walk(self.tree): # 检查除法中分母是否可能是 len() 调用 if isinstance(node, ast.Div): if isinstance(node.right, ast.Call) and isinstance(node.right.func, ast.Name) and node.right.func.id len: issues.append(发现除法分母为 len(...)当列表为空时会触发 ZeroDivisionError。) # 检查循环求和是否可以用 sum() 替代 if isinstance(node, ast.For): target_lines node.lineno issues.append(f第 {target_lines} 行存在 for 循环建议考虑使用内置 sum() 提升可读性。) return issues def run(self) - str: issues self.check() if issues: return 静态检查发现以下可疑点\n \n.join(f- {issue} for issue in set(issues)) return 静态检查未发现明显问题。4.4 编写主程序在主程序中我们把两个工具注册给 LangChain Agent并设置最大迭代次数。这样智能体就能“边看结果边修改”实现多轮循环审查# 文件路径main.py import ast from dotenv import load_dotenv from langchain_openai import ChatOpenAI from langchain.agents import AgentExecutor, create_react_agent from langchain.tools import tool from langchain.prompts import PromptTemplate from tools.code_executor import SandboxExecutor from tools.static_checker import StaticChecker load_dotenv() # 实例化工具 sandbox SandboxExecutor() tool def run_code_in_sandbox(code: str) - str: 将 Python 代码放入 Docker 沙箱中执行返回标准输出和执行结果。 可用于运行测试代码、验证脚本逻辑。 return sandbox.execute_python(code) tool def static_check_code(file_path: str) - str: 对指定 Python 文件做静态 AST 检查返回可疑问题列表。 file_path 是沙箱工作目录内的文件名。 # 读取宿主机工作目录中的代码文件 import os full_path os.path.join(workdir, os.path.basename(file_path)) if not os.path.exists(full_path): return f文件 {file_path} 不存在请先上传到工作目录。 with open(full_path, r, encodingutf-8) as f: source f.read() checker StaticChecker(source) return checker.run() # 模型配置 llm ChatOpenAI( modelos.getenv(LLM_MODEL_NAME), api_keyos.getenv(LLM_API_KEY), base_urlos.getenv(LLM_BASE_URL), temperature0.1 ) # 创建 ReAct Agent prompt PromptTemplate.from_template( 你是一个代码质量审查专家。你可以使用工具来分析代码并给出修复建议。 你必须按照以下格式输出 思考分析当前任务并决定下一步行动 行动工具名称 行动输入工具需要的参数 观察工具返回的结果 当收集到足够信息后使用以下格式输出最终答案 Final Answer: 基于观察结果的完整审查报告。 可用工具 {tools} 工具名称列表 {tool_names} 用户目标{input} 当前推理轨迹{agent_scratchpad} ) agent create_react_agent(llmllm, tools[run_code_in_sandbox, static_check_code], promptprompt) executor AgentExecutor( agentagent, tools[run_code_in_sandbox, static_check_code], max_iterations10, # 允许“绕十圈” verboseTrue, handle_parsing_errorsTrue ) if __name__ __main__: task ( 请审查 workdir/sample_code.py 这个文件。 先做静态检查再写一段测试代码放到沙箱里执行 验证 calculate_average 函数在空列表输入时是否会报错。 最后给出完整修复建议。 ) result executor.invoke({input: task}) print(\n 最终审查报告 \n) print(result[output])4.5 运行与验证在项目根目录依次执行pip install -r requirements.txt python main.py如果一切正常你会在verboseTrue的日志里看到类似下面的多轮循环过程 Entering new AgentExecutor chain... 思考首先读取文件并做静态检查。 行动static_check_code 行动输入{file_path: workdir/sample_code.py} 观察静态检查发现以下可疑点 - 第 8 行存在 for 循环建议考虑使用内置 sum() 提升可读性。 - 发现除法分母为 len(...)当列表为空时会触发 ZeroDivisionError。 思考静态检查发现了两个问题。接下来需要验证空列表输入时的行为。 行动run_code_in_sandbox 行动输入{code: from workdir.sample_code import calculate_average\nprint(calculate_average([]))} 观察[退出码 1] Traceback (most recent call last): ... ZeroDivisionError: division by zero 思考实验结果确认空列表会触发 ZeroDivisionError。现在可以给出最终报告了。 Final Answer: ...最终输出的审查报告会包含空列表输入会导致ZeroDivisionError原因是len(numbers)为 0分母为 0。for循环累加可以改用sum(numbers)代码更简洁且不易出错。修复建议示例增加防御性判断或让函数在空列表时返回0或抛出明确异常。到这里两个能力就完成了整合智能体“绕了几圈”多轮循环才拿到了“沙箱外/沙箱内”的验证结果并基于观察修正了最终答案。5. 常见问题与排查思路在实际开发中很多读者会在“多步循环”和“沙箱执行”两块踩坑。下面整理一个高频问题排查表按优先级排列问题现象常见原因排查步骤解决思路Agent 一直不输出 Final Answer循环轮数不够或模型陷入死循环观察 verbose 日志中是否反复调用相同工具提高max_iterations或优化提示词要求模型尽早总结工具参数格式解析失败模型返回的 JSON 格式不规范打印原始模型输出定位解析错误位置开启handle_parsing_errorsTrue改用框架 Tool 的args_schema做强校验Docker 沙箱启动失败Docker Desktop 未启动或镜像拉取失败执行docker ps检查 Docker 服务启动 Docker 服务确认python:3.11-slim镜像已存在沙箱容器能运行但读不到宿主机文件没有挂载卷或路径不对检查volumes配置路径是否为绝对路径改用os.path.abspath()挂载时目录权限设为rw沙箱内无法访问外网容器没有配置网络检查network_disabled参数设为False或调整 Docker daemon 的 iptables 规则模型 API 调用超时网络代理或 API 服务不稳定先用 curl 测试 API 连通性设置更长超时时间检查.env中 base_url 是否正确容器内执行中文日志乱码基础镜像未安装中文字体或编码查看容器内locale环境变量在命令前加export PYTHONIOENCODINGutf-8其中最容易忽略的是“循环不是越久越好”。每多绕一圈模型推理的 token 消耗就成倍增加而且历史轨迹越长模型越容易偏离最初目标。通常建议简单任务max_iterations3~5中等任务max_iterations8~10复杂任务优先拆成子 Agent而不是直接拉大循环上限6. 最佳实践与工程建议6.1 多步循环设计建议第一把“退出条件”前置到提示词里。不要只靠代码写最大迭代次数应该在系统提示里明确告诉模型“当获得足够信息时立即输出 Final Answer不要过度检查”。这样能大幅减少无效循环。第二给工具调用加结构化输入校验。直接让模型生成 JSON 参数时模型可能漏字段或传错类型。用 LangChain 的pydantic定义参数模型是更稳妥的做法from pydantic import BaseModel, Field class CodeRunInput(BaseModel): code: str Field(description要执行的 Python 代码) tool(args_schemaCodeRunInput) def run_code_in_sandbox(code: str) - str: return sandbox.execute_python(code)第三保留完整轨迹用于审计。生产环境建议把每一轮“思考、行动、观察”写入结构化日志。一旦智能体产出异常结果可以快速定位是哪一步出了问题。6.2 沙箱安全管理建议第一默认最小权限。沙箱容器不要用--privileged不要挂载宿主机的敏感目录如/etc、/root尽量用只读挂载。如果智能体需要写结果可以单独挂载一个输出目录。第二资源限制必须写死。在容器配置中显式设置mem_limit、cpu_quota、pids_limit。否则恶意代码或错误逻辑可能拖垮宿主机。下面是 Docker SDK 中可以补充的参数container self.client.containers.run( ..., mem_limit512m, cpu_period100000, cpu_quota50000, pids_limit256, nano_cpus500000000, # 等价于 0.5 核 read_onlyTrue, # 根文件系统只读 tmpfs{/tmp: size100m} # 临时可写目录 )第三网络按需开放。执行代码类的沙箱默认应禁用网络network_disabledTrue。只有当前任务确实需要下载依赖包或调用内部 API 时才打开网络并且最好设置白名单。第四合法“走出沙箱”要走审批流。如果要让智能体访问更高权限的数据目录不要直接把宿主机的根目录挂进去。更合理的做法是定义可访问目录的配置文件或环境变量。在权限服务中登记“该智能体可访问某目录”。容器启动时按配置动态生成挂载卷。这样既能“走出沙箱”又能保留审计链路。6.3 生产落地建议如果要上线生产环境不要直接让我写的单机 Python 脚本扛所有流量。建议把沙箱执行拆成独立服务例如 Sidecar 容器或独立 Worker主流程通过消息队列提交任务。这样可以避免因为某个智能体任务异常导致整个应用崩溃。另外大模型服务的密钥管理务必使用环境变量、密钥管理服务或 Kubernetes Secret不要硬编码进代码仓库。所有模型调用链路建议接入全链路追踪OpenTelemetry 等方便复现问题。7. 总结与学习路线这一周的两个智能体给我留下很深的印象本质上是两种工程能力的映射“算下九圈”考验智能体的多步规划与自我修正能力“走出沙箱”考验系统的安全边界与资源扩展能力。两者组合起来才是生产级 AI 智能体该有的样子——既聪明又可靠。读完这篇文章你应该掌握了ReAct 多步循环的执行原理以及如何通过AgentExecutor控制循环轮数和退出条件。Docker 沙箱的基本使用以及如何通过挂载卷实现“按需放行”的合法资源访问。组合两个能力完成一个“代码审查智能体”的完整流程。常见异常如何排查尤其是循环失控和沙箱权限问题。下一步你可以按以下方向继续深入学习 LangGraph它是比 AgentExecutor 更灵活的多智能体编排框架可以精细控制每个节点的状态转移、条件分支和人工介入。探索沙箱替代方案对比 Docker、Firecracker、WebAssembly 微虚拟机的隔离性能和启动速度选择适合自己业务场景的沙箱底座。实践提示词注入防御特别注意用户输入可能干扰智能体目标和工具调用行为在提示词中加入分隔符约束和敏感操作二次确认机制。关注 Agent 可观测性在正式项目里引入完整的日志、跟踪、回放能力否则智能体一旦在复杂链路中做错一步排错会非常痛苦。最后给你一个非常实用的建议在智能体上线前先总结一份“能力边界文档”明确列出它能调用哪些工具、不能调用哪些工具、运行在什么沙箱权限下、最多循环多少轮。这份文档不仅是给团队看的也是给模型自身的安全护栏设计依据。如果这篇文章对你有帮助别忘了收藏备用。后续如果你们团队在做智能体工作流调度、沙箱逃逸检测或代码执行类 Agent 应用时遇到了新问题欢迎在评论区和我交流。技术这条路总要亲手折腾过几个 Agent踩过几个坑才算真正入门。