最近一年里跟 Agent 打交道多了我最大的一个感受是模型本身的智商当然重要但真正决定一个 Agent 能干多少活的往往是它手里有没有趁手的家伙。很多同学搭 Agent 时把精力全扑在提示词和模型选型上结果一跑真实任务就露馅——要么回答不了实时信息要么算不对数要么扔过来一个 CSV 让它分析它只能干瞪眼。说白了缺的就是“工具箱”。这篇我就想认真拆一拆 Agent 最常用的三件套SearxNG、WolframAlpha 和代码解释器讲讲它们各自解决什么问题、怎么接进来、以及我实际用下来踩过的那些坑。不管你是刚接触 Agent 开发还是已经在做多智能体系统这篇应该都能给你一些可以照抄的参考。1. 为什么 Agent 需要工具箱从“嘴强王者”到“动手干活”1.1 大模型的三块短板咱们先捋清楚一个前提为什么 Agent 不能只靠模型本身活着我见过不少人有个误解觉得大模型什么都知道。实际上把模型当成一个“纯靠记忆说话的人”更准确它有三块特别明显的短板。第一块是实时信息缺失。模型训练有个截止时间之后发生的事它一概不知。比如你问它“今天热搜是什么”或者“某个包的最新版本号是多少”它只能靠猜甚至一本正经地编一个不存在的版本号给你。第二块是精确计算能力不足。语言模型本质上是在预测下一个词你让它算 123456789 乘以 987654321它大概率给你一个近似值而不是精确答案。至于微积分、矩阵运算、解方程这种符号推演更是容易翻车。第三块是无法操作外部环境。模型输出的只是文本它没法帮你查数据库、读文件、执行一段 Python 脚本、调用一个 API。如果需要这些能力就必须有“手”和“眼睛”伸出去把结果拿回来喂给它。这其实就是 Agent 这个词和普通 Chatbot 的根本区别。普通对话机器人是“你说一句它回一句”而 Agent 的核心在于自主决策、调用工具、完成任务。工具不是锦上添花是必需品。没有工具链的 Agent就像一个只有嘴、没有手的员工能侃侃而谈但真要干活就歇菜。1.2 工具调用的核心机制Function Calling你可能听说过一个词叫 Function Calling也有人叫 Tool Calling / Tool Use。它是目前把工具接到 Agent 上的主流方式。原理不复杂你在给模型的请求里额外声明一批“可用的函数”每个函数都有名字、描述、参数列表。模型在理解用户需求后不是直接输出最终答案而是先输出一个结构化的“调用意图”比如“我需要调用 search 这个函数参数是 xxx”。然后你作为开发者在自己的代码里真正执行这个函数比如真的去搜索或者真的去跑一段 Python拿到结果后再把结果“回填”给模型。模型结合函数返回的真实结果生成给用户的最终答复。你可以把整个循环理解为思考 → 选工具 → 执行 → 再看结果 → 再思考。这也是目前 Agent 架构里最核心、最常用的一套交互逻辑。在这个逻辑里工具自身的能力边界、返回数据的质量直接决定了 Agent 的最终表现。所以你会看到真正追求落地效果的人很少用那种“一键封装好的全能 Agent 框架”而是会自己仔细挑选和打磨每一个工具。1.3 三件套的分工定位我这次聊的三件套刚好覆盖了 Agent 最典型的三大类需求信息检索、精确计算、代码执行。SearxNG 解决的是“实时信息从哪来”的问题。它是一个自托管的元搜索引擎聚合了 Google、Bing 等多个上游搜索引擎的结果并且有干净的 JSON API特别适合让 Agent 去搜索网页、新闻、文档。你可以把它理解为给 Agent 装了一扇通向实时互联网的窗户。WolframAlpha 解决的是“精确知识计算”的问题。它是一个计算知识引擎擅长数学计算、单位换算、物理化学常量查询、数据对比等。你可以把它理解为一个“理科大脑”专门补足语言模型在符号推理和精确计算上的短板。代码解释器Code Interpreter / Code Sandbox解决的是“真正动手处理数据”的问题。它提供一个隔离的 Python 执行环境Agent 可以写代码计算、分析、绘图、处理文件。它补足的是 Agent 的“动手能力”相当于一个功能不限的计算机实验室。这三个工具加在一起Agent 基本就具备了一个完整“初级研究员”的能力能查资料、能算数、能写代码做验证。下面我挨个展开。2. SearxNG自托管元搜索引擎给 Agent 装上一双“眼睛”2.1 为什么选 SearxNG而不是直接调搜索引擎 API做 Agent 信息检索时你首先会面对一个选择是直接用某家搜索服务的官方 API还是自己搭一个聚合搜索直接用官方 API 确实省事但它有几个现实问题。第一是成本商业搜索 API 按千次请求计费开发阶段频繁调试会心疼。第二是配额很多免费额度每天只有几十次到几百次Agent 一旦跑起来一次多轮对话可能就要发起好多次搜索配额烧得飞快。第三是灵活度你想控制搜索地域、语言、时间范围、结果数量时官方 API 的参数往往有限。SearxNG 的好处恰好在于它是开源的、自托管的、无请求费用。你把它跑在一台低配的小服务器上它就变成一个完全属于你自己的搜索入口代理所有上游搜索引擎的请求最后汇总去重返回结果。对 Agent 来说这意味着一个稳定可控、成本几乎为零的检索接口。另外还有一层隐私考虑。SearxNG 默认不保存用户查询记录对于处理敏感数据或企业内部信息的 Agent 来说这比把查询直接发给第三方搜索服务更让人放心。虽然在 Agent 场景下隐私权重没那么高但“数据不出自家服务器”这一点在不少企业项目里是硬需求。2.2 快速部署Docker 一键启动SearxNG 部署非常简单官方提供了 Docker 镜像这也是我最推荐的方式。你不用关心 Python 依赖、系统配置这些破事一条命令就能跑起来。基本步骤如下# 拉取镜像 docker pull searxng/searxng # 创建数据目录存放配置文件 mkdir -p /opt/searxng cd /opt/searxng # 生成基础配置或用官方提供的 searxng.conf # 大致命令路径如下直接使用官方 git 仓库的配置文件也行如果你不想手工写配置我直接给你一个最小可用的searxng.conf参考片段use_default_settings: true server: secret_key: 换成你自己的随机字符串 limiter: false image_proxy: true search: safe_search: 0 autocomplete: google default_lang: zh-CN formats: - html - json search_engines: - name: google engine: google shortcut: g disabled: false - name: bing engine: bing shortcut: b disabled: false配置文件里重点说几个参数secret_key必填用于会话签名你可以用openssl rand -hex 32生成一个。limiter: false开发调试时建议先关掉限流不然高频请求会被拦截后面再按需打开。formats里必须包含json这是 Agent 调用时必须的接口格式。search_engines里你可以只保留一两个常用的引擎引擎太多反而会导致每次搜索都要等最慢的那个整体延迟变高。改完配置启动容器docker run -d \ --name searxng \ --restartunless-stopped \ -p 8888:8080 \ -v /opt/searxng:/etc/searxng \ searxng/searxng注意我把容器内部的 8080 端口映射到了宿主的 8888 端口这样只要访问http://你的服务器IP:8888就能打开搜索页面。测试一下页面能开、能搜出结果部署这步就算过了。如果你对 Docker 不熟悉直接把它当成“一个隔离的小环境”就好所有依赖都打包在里面不影响系统其他部分非常干净。2.3 JSON 接口Agent 最关心的调用方式Searxng 的页面模式是给人用的而 Agent 要用的是它的 JSON 接口。请求方式很简单就是对搜索端点加一个formatjson参数curl http://localhost:8888/search?qLangChainagenttoolcallformatjsonlanguagezh-CN返回的 JSON 结构里最核心的字段是results数组每个元素包含title、url、content这些字段。content一般是搜索结果摘要Agent 主要靠它快速判断这条结果值不值得点开。另外还有infoboxes知识卡片、suggestions搜索建议这些在特定场景下也很有用。我在代码里给 Agent 封装搜索函数时通常会做一层轻量处理把结果截断到前五条每条只保留标题、链接和摘要的前 200 个字符。为什么要截断因为大模型的上下文窗口虽然越来越大但塞进去太多垃圾信息会稀释注意力反而让回答质量下降。给模型“够用”的信息量比“海量”信息量更明智。import requests def searxng_search(query: str, max_results: int 5) - list[dict]: params { q: query, format: json, safesearch: 0, } resp requests.get(http://localhost:8888/search, paramsparams, timeout15) resp.raise_for_status() results resp.json().get(results, []) # 只保留关键字段截断长文本 cleaned [] for item in results[:max_results]: cleaned.append({ title: item.get(title, ), url: item.get(url, ), content: item.get(content, )[:200], }) return cleaned2.4 实例维护与常见注意点SearxNG 最大的好处是免费但它并不是零维护。我跑了几个月总结出三个需要注意的地方。第一是上游引擎的屏蔽问题。某些搜索服务对数据中心 IP 不太友好会弹验证码或者直接拒绝流量表现就是 SearxNG 页面能开但搜索一直转圈超时。解决办法是换一个对机房 IP 友好些的引擎配置或者调整请求间隔。没有万能的引擎组合只能实测调整。第二是请求频率。虽然 SearxNG 没有费用但你架不住它背后的上游引擎有风控。如果你的 Agent 同时发起太多并发搜索即使 SearxNG 收到请求上游的 Google 或 Bing 也会开始频繁报错。我后面会把工具调用改成串行或加一个简单的令牌桶限速效果会好很多。第三是结果质量参差。元搜索聚合了多个来源结果里偶尔会混入广告、低质内容。如果 Agent 对内容准确性要求高我建议在系统提示词里写一句“优先参考权威域名来源”同时在上层再加一道内容校验比如过滤掉明显是营销推广的标题关键词。注意SearxNG 默认返回的content字段是摘要截断不要把它当作完整网页内容。Agent 如果需要深入阅读某一篇网页后面还得接一个抓取正文的工具比如某种 HTML 解析器这是另一个话题但是信息链路里很重要的一环。3. WolframAlpha计算知识引擎补上 Agent 的“理科大脑”3.1 它能做什么不只算数更像一本可计算的百科全书WolframAlpha 从 2009 年上线到现在定位一直很特别。它既不是搜索引擎也不是普通的计算器而是一个“计算知识引擎”。你输入一个自然语言问题它先在语料库里理解问题意图再做查询和计算最后返回结构化结果。对 Agent 而言它补的是语言模型最难啃的一块需要精确计算和权威知识的场景。举个例子数学计算integrate x^2 * sin(x)这种符号积分模型可能给错WolframAlpha 直接给步骤和结果。单位换算120 miles in kilometers它精确返回 193.121 km。物理常量speed of light in m/s返回精确数值和量纲。日期计算days between 2023-01-01 and 2024-06-15精确到天。事实对比population of China vs India拉一整套逐年数据出来。我自己的体会是WolframAlpha 不是用来做开放域问答的它的知识覆盖偏向数学、物理、化学、统计、地理、金融等“可计算、可验证”的领域。如果你让 Agent 针对“今天热搜”这种开放问题去问它那纯属用错工具。但一旦遇到计算、验证、单位、常量这类需求它几乎没有替代品。3.2 API 接入申请密钥与发起请求WolframAlpha 接入要在它的开发者平台注册账号然后申请一个 App ID。免费额度有限每月 2000 次左右准确数字按官方最新政策个人开发和原型测试基本够用。如果你要商用或者跑大规模 Agent就得升级付费计划。拿到 App ID 后调用来之也很简单。它有两种 APISimple API返回图像或 JSON、Full Results API返回结构化 XML。对 Agent 来说用 Full Results API 拿结构化数据更合适因为解析出来的结果可以直接作为上下文交给模型。下面是 Python 示例import requests import xml.etree.ElementTree as ET APP_ID 你的AppID def wolfram_query(query: str) - str: params { appid: APP_ID, input: query, format: plaintext, output: json, # 新版API支持JSON输出 } resp requests.get( https://api.wolframalpha.com/v2/query, paramsparams, timeout20, ) resp.raise_for_status() data resp.json() # 抽取所有 plaintext 结果拼成一段文本 texts [] for pod in data.get(queryresult, {}).get(pods, []): for sub in pod.get(subpods, []): if plaintext in sub and sub[plaintext]: texts.append(sub[plaintext]) return \n.join(texts)上面的代码是最小可用版。实际项目中你还会想保留 pod 的标题字段比如 “Input interpretation” 和 “Result”因为模型看这些标签更容易理解结果含义。整体思路就是把 WolframAlpha 返回的结构化结果“拍平”成纯文本再喂给模型。3.3 返回结果的结构学会读“pods”要用好 WolframAlpha API必须知道它返回的数据结构。每个查询结果由若干pods可以理解为“面板”组成每个 pod 有标题title和若干subpods。常见的 pod 有Input interpretation你对问题的解读可以看作对查询语义的确认。Result最终计算结果这是最核心的。Step-by-step solution解题步骤需要额外参数podstate或替换stepbystepsolutiontrue才会返回。Plots图像Agent 一般不直接看图像但可以获取图表的元信息。Alternate form/Decimal approximation不同形式的结果。我第一次对接时犯过一个蠢错把 API 返回的整个 JSON 直接塞给模型。结果导致模型被无用的图像 URL 和 XML 元数据干扰回答反而变慢变差。后来我学乖了只做一层过滤把每个 pod 的title和plaintext字段拎出来拼成简短文本效果立刻提升。这也是我想反复强调的一点工具返回值要“精加工”再交给模型而不是把原生响应怼过去。3.4 什么时候该切到 WolframAlpha工具选择与路由策略Agent 不是遇到所有问题都应该调用 WolframAlpha调用得太多反而会拖慢响应。我常用的做法是在系统提示词里给模型写清楚“什么时候用这个工具”比如当用户的问题涉及精确数学计算、单位换算、科学常量、日期计算、统计比较时优先调用 wolfram_alpha 工具。如果只是开放域信息查询不要调用它。但完全靠模型自觉选工具并不总是可靠它在模糊问题下经常会选错。所以我在上层加了一道轻量规则先做一次关键词/模式匹配发现问题里包含“计算”“多少公里等于”“怎么积分”“太阳质量”之类的模式就直接强制走 WolframAlpha不走模型决策。这是一种非常朴素的“意图路由”但对提准确率很有效。我还想提一个注意点WolframAlpha 并不擅长中文自然语言。它理解英文查询的效果远好于中文。所以我在封装工具时会在调用前加一步“把用户问题翻译成英文”的处理最简单的做法就是用同一个大模型顺手翻译一下或者在系统提示词里要求“不要翻译”。别小看这个小细节它直接影响命中率实测能差出一大截。4. 代码解释器让 Agent 真正“动手算”而不只是“开口说”4.1 代码解释器到底解决什么问题搜索和计算能解决很多问题但还有一大类需求它们搞不定“处理你给我的数据”。比如用户上传一个 CSV 文件说“帮我统计每个月的销售额并画出趋势图”或者用户问“请用蒙特卡洛方法模拟一下中奖概率是 10% 的情况下连买 100 次至少中一次的概率是多少”。这种问题要真正给出可信答案唯一的路是真正去执行一段代码。代码解释器本质是一个受控的 Python 运行环境。Agent 自己写 Python 代码然后丢进这个环境里执行再把 stdout 的结果或生成的图片文件拿回来。说白了Agent 不在“脑内”推理了而是“脚踏实地”地写代码干活于是几乎所有数据任务它都能化为可计算的程序问题。这也是“嘴强王者”和“动手干事”的一道重要分水岭。没有代码解释器的 Agent遇到数值模拟只能硬编一个公式让模型“口算”有了代码解释器它可以写 20 行脚本跑一万次模拟直接拿到精确分布。4.2 三种集成方式本地执行、容器执行、托管沙箱实现代码解释器有几种路线从简单到靠谱我依次说下。方式一本地exec/subprocess执行这是最快上手的方案直接把模型生成的 Python 代码在当前进程里跑。开发调试时很方便模型写一个print(22)你用exec一执行就能拿到结果。但生产环境千万别这么干。原因很直接大模型生成的代码是不可信的。它可能无意中写一个死循环把你的服务 CPU 跑满更严重的它可能读到环境变量、删文件。本地执行等于把你的服务器完全暴露给模型。只建议在完全隔离的本地开发环境里玩玩。方式二容器执行Docker 单次沙箱这是我最推荐的生产级做法。每调用一次代码解释器就启动一个一次性 Docker 容器在容器里执行代码跑完即销毁。因为容器是隔离的模型代码无法触碰宿主机文件最多影响那个临时容器。实现方式可以用 Docker SDK。import docker import uuid client docker.from_env() def run_code(code: str, timeout: int 30) - str: container_name fsandbox-{uuid.uuid4().hex[:8]} try: container client.containers.run( python:3.11-slim, command[python, -c, code], detachTrue, mem_limit512m, pids_limit100, network_modenone, # 默认不给网络更安全 namecontainer_name, ) result container.wait(timeouttimeout) logs container.logs().decode(utf-8) return logs finally: try: client.containers.get(container_name).remove(forceTrue) except Exception: pass注意几个细节network_modenone断掉容器网络防止模型代码访问外部mem_limit和pids_limit限制资源防死循环和内存爆炸timeout超时报错兜底防挂起。这套方案每次执行约增加 1-2 秒启动开销但对稳定性来说是值得的。方式三托管沙箱服务如果你不想维护 Docker可以直接用云厂商的沙箱 API。比如某些模型厂商自带的代码解释器功能上传代码执行后返回文本和文件。好处是天然隔离、不用运维坏处是数据要出网且计费方式按调用次数或时长。对于内部数据敏感的 Agent还是自托管更放心。4.3 给模型定义代码解释器工具时的“说明书”模型写代码的技能再强也需要你明确告诉它能做什么、不能做什么、期望返回什么。工具描述写得越具体模型写出的代码越规范返工的概率越低。我的代码解释器工具描述通常会这么写功能执行 Python 代码并返回标准输出文本。 限制当前无网络连接只能使用预先安装的标准库及 numpy、pandas、matplotlib不要尝试读取本地文件代码必须能在 30 秒内运行完成。 输出格式返回运行结果的 stdout 内容。为什么强调“只能使用预装库”因为沙箱环境下没有网pip install是不度发挥作用的。你不可能让模型每次现装第三方包。我一般会在镜像里预装numpy、pandas、matplotlib、scipy这四件套覆盖了绝大多数数据分析场景。如果遇到不支持的库模型也会很自然地调整方案改用标准库实现。4.4 典型实战用代码解释器画图并返回给用户多数框架下代码解释器不仅能返回文本还能返回图片。比如用户说“帮我生成一条正弦曲线图”Agent 的完整流程是用户请求 → 模型决策要调用代码解释器模型生成代码用 matplotlib 绘制正弦曲线保存为 PNG沙箱执行代码 → 生成文件工具返回文件路径 → 模型引用“图片已经生成”前端展示图片Agent 同时给出一句简短介绍我在封装时会让容器把工作目录挂载到宿主机的共享目录或者用docker cp把生成产物导出再让主服务读取返回给用户。整个过程跑通后Agent 就具备了真正的“可视化输出”能力这对数据分析类 Agent 来说是刚需。注意代码解释器不是越复杂越好。有些开发者喜欢给模型塞一堆工具让模型自己挑但我后来发现工具数量太多会让模型决策变慢、变混乱。工具描述的简洁性和职责单一性比工具数量重要得多。5. 三个工具怎么协同从一个实际任务看 Agent 的工具编排5.1 一个综合示例三件套接力完成数据分析任务工具单个都好说真正见功夫的是怎么让它们配合起来。我带大家过一遍实际场景假设用户问“请帮我查一下过去一年某大宗商品的价格走势数据然后计算平均价格和最大回撤并画一张价格曲线图。”这个需求里其实包含三类子任务实时信息获取查价格数据、精确计算平均值和最大回撤、代码执行画图。一个合格的 Agent 工作流应该是用户发起请求 → 决策调用 SearxNG 搜索“XX商品 价格走势 历史价格数据” → 拿到若干网页结果Agent 筛选最可信的数据来源 → 决策调用代码解释器 → 代码解释器读取数据比如 CSV 或 API 数据计算均值、最大回撤绘图 → 生成 PNG 图片 → 决策如果需要验证某个数字的正确性或补充权威知识调用 WolframAlpha → 返回最终答案 图片这不是我拍脑袋设计的而是真实跑通过的一条链路。每个工具只负责自己最擅长的一段Agent 像流水线一样把结果串起来。5.2 工具编排的决策逻辑什么时候用哪个很多 Agent 框架用模型自动决策但纯靠模型“自由发挥”在一个复杂任务里经常跑偏。我更倾向于一个混合策略强制路由 模型决策结合。能被规则提前判断的需求比如“计算”“搜索”“绘图”关键词直接走固定工具模糊需求再交给模型判断。结果校验。工具返回结果后不是立刻给用户而是先让模型做一轮“结果与问题是否匹配”的检查。如果搜索不到有效内容模型应该主动承认“没有找到换一种方式”而不是硬编答案。这里我想说一个很多教程不会提的细节工具调用需要“重试策略”。搜索可能失败、WolframAlpha 可能超时、代码解释器容器可能起不来。Agent 至少要具备“失败后换个工具再试一次”的能力。我见过一个很典型的翻车案例Agent 调 WolframAlpha 计算一个积分失败就直接延用模型自己的“口算结果”回答了结果还是错的。正确做法是失败后先用代码解释器用 SymPy 算一遍。你看工具多了还有一个好处——可以互相兜底。5.3 系统提示词里如何描述工具工具描述写到什么程度直接决定模型用得顺不顺手。我常用的格式如下你有以下工具可用 1. searxng_search(query: str): 实时网络搜索适合获取最新信息、查找资料、寻找数据来源。返回标题、链接和摘要。 2. wolfram_alpha(query: str): 计算知识引擎适合数学计算、单位换算、科学常量查询、日期计算。查询请用英文表达。 3. code_interpreter(code: str): 执行 Python 代码适合数据计算、数据处理、绘图、模拟。环境中预装有 numpy/pandas/matplotlib/scipy无网络。 请根据用户需求选择合适的工具。一次只调用一个工具拿到结果后再决定下一步。最后那句“一次只调用一个工具”很重要。虽然现在很多框架支持并行工具调用但两个工具同时跑如果它们有依赖关系比如代码解释器需要搜索到的数据并行反而会乱。先串行、再优化这是稳妥的路径。5.4 模型与工具之间的“心跳”上下文记忆管理工具调用会带来一个容易忽略的问题上下文膨胀。每次搜索返回 5 条结果每条 200 字看起来不多但多轮对话里如果每次都塞原始结果上下文会越滚越大最后模型连自己刚说过什么都记不清了。我处理的办法是给工具返回值设置“有效期”。比如搜索结果的引用只在当前这一轮对话生效下一轮用户没问相关内容就直接丢弃代码解释器的输出如果只是数值就只保留最终结论和关键数字不保留完整日志。这本质上是一种轻量的记忆管理但做好它Agent 的多轮稳定性会显著提升。提示工具返回内容进上下文前先让一个小的“压缩器”模型或者同一个模型把结果提炼成三句话以内。这是对抗上下文膨胀非常有效的手段。6. 实测中踩过的坑与排查技巧实录6.1 SearxNG请求超时与结果为空现象Agent 偶尔报错“搜索超时”或者“搜索无结果”但用浏览器手动打开 SearxNG 页面又能搜出来。排查思路先确认 SearxNG 服务本身负载docker stats看 CPU 是不是被打满了。再检查是否有限流limiter: true时高并发请求会被拦报错码一般是 429。最后看上游引擎是否被墙或触发验证码换一个引擎试试。经验教训SearxNG 的搜索质量和你选的引擎高度相关。只开一个 Google 有时不稳定我后来开了三个引擎做冗余某些引擎失败时会自动 failover整体可用性从 80% 提到 99% 以上。6.2 WolframAlpha查询未命中与结果解析失败现象模型把查询问题翻译成英文后WolframAlpha 依然返回 “Wolfram|Alpha did not understand your input”。排查思路检查查询语句是不是太口语化。WolframAlpha 对自然语言的理解是有边界的calculate what is the meaning of life这种超出范围就要换问法。参考答案里的Input interpretationpod看看它把问题理解成什么了再换关键词重新组织语句。避免一次问多个子问题。把“计算 A 并比较 B”拆成两次查询命中率会提高很多。解析失败也很常见我遇到过 WolframAlpha 返回 JSON 里pods为空的场景。这时候可以在代码里加一个判断如果data[queryresult][success]为false直接向前端返回“该问题超出计算引擎范围”避免模型拿空结果硬编。6.3 代码解释器环境缺失与资源耗尽现象模型生成的代码引用了statsmodels但沙箱里没装或者代码里有个死循环把容器的 CPU 打满导致整个 Agent 卡住。处理办法预先在python:3.11-slim镜像里装好常用库制作成自定义镜像避免运行时依赖。pids_limit和mem_limit一定要设置这是防死循环和内存溢出的关键。给超时设置兜底比如container.wait(timeout30)超时后直接 kill并返回“代码执行超时”给模型让模型自己想办法改代码。这里有一个容易被忽略的坑模型生成的代码不会自己处理异常。比如 numpy 数组除零会产生警告而不是报错但结果可能是 inf。如果你直接把这个结果当有效输出Agent 就会给用户一个错误的结论。我后来会在系统提示词里加一句“你的代码必须对边界情况做防御性检查”并且在上层工具里对结果做一轮 NaN/inf 检测。6.4 工具之间的“互相打架”现象Agent 先搜了资料又调 WolframAlpha 算了一个不相关的数最后代码解释器又跑了一堆无关代码整个回答又慢又乱。原因多半是工具描述不够清晰模型不知道该在什么时候停下来。我最终的优化方案是把工具描述里的“使用条件”写得更明确。在系统提示词里增加“完成标志”当且仅当所有子问题得到回答或用户不再需要进一步工具调用时停止调用工具并给出最终答案。如果框架支持设置最大工具调用次数比如 5 次超限强制结束避免无限循环。我还留意到有些开源的 Agent 框架会默认给模型“自动摘要”的权限模型为了完成任务自己调了一个摘要工具反而把上下文内容缩短了弄丢了关键信息。这种“工具自杀”式调用排查起来很费劲唯一的方法就是每次工具调用前后打印日志盯紧上下文变化。6.5 一张实用速查表为了方便你排查问题我整理了一张常用排查表现象可能原因检查方法解决方案SearxNG 超时上游引擎被限流/验证码浏览器手动访问 SearxNG 页面增加备用引擎、调整请求间隔SearxNG 结果为空关键词太偏/引擎不支持返回 JSON 里查看unresponsive_engines换关键词、换引擎、增加搜索语言参数WolframAlpha 未命中英文表达不精确查看Input interpretationpod拆分子问题、改写问题表达WolframAlpha 返回慢请求过于复杂检查单次查询耗时限制每次只算一个主问题代码执行超时死循环或计算量过大docker stats看资源占用设置 pids_limit、timeout 兜底、提醒模型换算法代码缺库沙箱镜像包不全执行前pip list查看自建镜像预装常用库工具混乱调用工具描述不清记录每次工具调用日志优化工具描述、加最大调用次数这张表的价值在于当 Agent 表现不稳定时先别怀疑大模型能力先查工具层。很多“模型变笨了”的错觉其实是工具链出问题了比如一直搜到没用的结果、计算公式被错误翻译、代码环境缺库。把工具链调稳模型的表现自然就上来了。我个人在实际操作中的体会是Agent 开发到后期大部分时间不是在调模型而是在调工具。Search 结果的质量、WolframAlpha 的查询措辞、沙箱环境的依赖版本任何一个环节掉链子最终都会在用户那边放大成一个“AI 不靠谱”的整体印象。所以别嫌这些基础工具“太低级”越是底层的东西越值得反复打磨。最后再分享一个小技巧你可以给每个工具加上“返回状态码”字段比如搜索无结果返回 404计算未命中返回 422代码超时返回 508。这样模型看到状态码就能立刻知道发生了什么比自己从内容里猜准确得多也能减少一层提示词的负担。工具反馈越结构化Agent 的决策就越稳定。如果你正在搭自己的 Agent 工具箱不妨把这个细节直接加进去实测下来会很省心。