企业官网建设流程全解析

上个月面试一家做Agent平台的公司，技术面聊到一半，面试官突然抛出来一个问题：“一个 Agent 收到任务以后，是怎么一步步执行的？如果工具一直超时，模型不停重试怎么办？”说实话，我当时第一反应是这问题太“小儿科”了——Agent 不就是“大模型 + 工具调用 + 循环”吗？结果越往深聊越发现，这里面的坑比我预想的多得多。面试官追问的几个细节，比如“工具超时之后你把什么内容塞回给模型”“重试次数上限设多少、为什么”“怎么防止重试风暴拖垮下游”，我答得其实一般。这篇文章就把我事后梳理的完整思路写出来，既算给自己做个复盘，也希望能帮到正在搞 Agent 开发、或者准备 Agent 方向面试的朋友。

这不是一篇概念科普，而是实打实的工程经验。我会从 Agent 的执行链路拆解讲起，然后重点分析工具超时的成因和阈值设计，再讲模型不停重试的治理方案，最后聊聊面试官真正想考什么，附上我踩过的真实案例。全程都是可直接落地的思路和代码级别的细节，适合已经写过一两个 Agent demo、想往生产级方向走的人。

1. Agent 执行链路拆解：一个任务是怎么被一步步“消化”的

1.1 从“收到任务”到“第一轮推理”之间发生了什么

很多人以为 Agent 一收到任务就直接丢给大模型就完事了，这是对执行链路的误解。真实生产环境里，任务进来之后要先过一层“预处理管线”，至少在工程侧要做这几件事：

• 把原始用户输入标准化成内部消息格式，带上会话 ID、用户 ID、时间戳；
• 把系统提示词、工具 schema、历史上下文拼装成模型输入；
• 根据权限范围过滤掉该用户不该看到的工具；
• 做一次 KV 缓存命中检查，如果同样的前置条件出现过，可以直接复用中间结果。

这一步的目标，是为模型创造一个“可推理”的最小上下文。系统提示词里会写明 Agent 的定位、可用工具的说明、输出格式要求，工具 schema 会告诉模型有哪些函数、参数是什么、返回值长什么样。有些团队还会在提示词里强调“工具调用失败时，不要反复重试同一个工具”，这句话在后面应对重试风暴的时候特别有用，属于成本极低的提示词护栏。

预处理完成之后，模型才开始第一轮推理。很多 Agent 框架使用的是 ReAct 模式，也就是“推理 - 行动 - 观察”循环：模型先思考当前该做什么，输出一个行动（通常是一段标准化的 function call），然后系统去执行工具，把结果作为观察回填给模型，模型再基于观察继续思考，直到产出最终答案或者达到终止条件。

1.2 核心循环：观察、思考、行动、反馈

我用一个生活化的类比来解释这个循环。假设你是老板，让一个新来的实习生去调研竞品信息。实习生不会一次性干完所有事，他的工作方式是：先看任务（目标拆解），然后想第一步该干嘛（查资料），接着真的去数据库里查（工具调用），查到结果之后看一眼结果（观察），发现数据不全，再思考下一步是换一个数据源还是换关键词（下一轮行动），直到最终整理成一份报告交给你（最终回答）。Agent 干活的逻辑完全一样。

具体到技术实现上，一次标准循环是这样的：

1. 模型收到拼接好的输入，输出一个结构化的 function call，通常是 JSON 格式，包含工具名和参数；
2. 运行时校验参数格式，把工具调用转发给执行器；
3. 执行器调用真实工具，把原始返回结果经过截断、清洗、格式化成模型能理解的内容；
4. 将“工具返回结果”作为一条 assistant 消息追加到上下文，再次发给模型。

这个循环什么时候结束？一般有三个终止条件：模型输出了最终答案（final answer）、到达最大迭代次数（max steps）、用户主动打断。需要注意的是，这里的最大迭代次数一定要有，否则模型可能陷入无限循环，会话成本直接失控。我自己常用的初始值是 8 到 12 轮，复杂任务再往上调，但一般不建议超过 20 轮，因为上下文会越来越长，延迟和成本都会指数级上升。

这里插一个很多人忽略的细节：工具返回结果不能原样塞回上下文。真实工具返回的数据可能非常大，比如一个数据库查询返回几万行，或者一个搜索接口返回几十个网页正文，如果你不加处理直接丢给模型，上下文窗口很快就满了，而且还会把模型的注意力带偏。生产环境里，工具结果一定要做一轮 post-processing，常见做法包括截断、抽取摘要、只保留关键字段、把结构化数据转成简洁的文本描述。这个处理环节做得好的系统，和做得差的系统，在同样的模型能力下，效果差距非常明显。

1.3 单 Agent 与多 Agent 编排的区别

面试官如果继续追问，大概率会问你“这是一个 Agent 在执行，还是多个 Agent 协作”。我在工程里建议把这两件事分开理解：单个 Agent 的执行循环是基础，多 Agent 编排是上层建筑。多 Agent 系统里，每个子 Agent 都有自己的完整循环，父 Agent 负责调度和汇总，子 Agent 之间通过消息传递结果。但这个话题展开就太大了，面试时候你首先要把单 Agent 的循环讲清楚，再往上层带。

之所以要先强调单 Agent 的执行循环，是因为面试官后面问超时和重试的问题，都是建立在这个循环之上的。如果循环本身你没讲明白，后面全是空中楼阁。

2. 工具超时：不是所有“慢”都该归模型管

2.1 超时的三种典型成因与分类

工具超时是 Agent 生产环境里最频繁出现的异常，没有之一。我在公司里跑过的 Agent 系统，线上告警里超过一半跟工具调用超时有关。要治理超时，你先得知道超时到底是怎么发生的。以我的经验，超时大概率逃不出下面三类：

第一类是网络层超时。Agent 服务要调的工具通常分布在不同的服务器上，跨网络调用就有连接超时、TLS 握手超时、读超时、写超时这些细分场景。尤其是现在很多 Agent 走 HTTPS 调用外部 API，DNS 解析慢、TLS 握手慢、网络抖动，都会直接表现为工具调用迟迟不返回。

第二类是工具服务端处理慢。工具本身可能要做大量计算，比如调用一个图片生成模型、跑一次大规模数据聚合、或者查询一个慢 SQL，这些操作本身的耗时就可能超过客户端设置的超时时间。我在一个项目里遇到过调用第三方地图服务，正常情况 200ms 返回，高峰期能扛到 8 秒，这种情况你不能简单怪网络，而是工具服务端的响应能力问题。

第三类是工具自身缺陷导致卡死。工具进程 hang 住、数据库连接池耗尽、依赖的下游服务没设置超时导致级联阻塞，这些都会让工具调用“永远不返回”。这种最隐蔽，因为它不是慢，而是卡住——你等 30 秒和等 3 分钟结果可能一样，都是超时。

所以超时绝对不是“设置一个数字”那么简单。我建议把所有工具调用按场景统一分类，至少分成外部 API、内部服务、本地工具三类，每一类的超时策略都单独配置，不要一把梭用一个全局超时时间。

2.2 超时阈值怎么设置才不算“拍脑袋”

很多同学问我超时时间到底设多少合适。我的经验是：不要给一个单一的超时值，而是做分层超时。连接超时、读超时、总超时分开设置，分别控制不同环节。

接超时（connect timeout）建议设置在 3 到 5 秒。一个正常的内部服务，TCP 连接应该很快建立，超过 5 秒还没连上，大概率是网络不通或者服务已经挂了，等再久也没意义。

读超时（read timeout）要看工具类型。外部 API 建议 10 秒以内，内部服务建议 8 秒，本地工具可以放宽到 30 秒。比如你调一个本地 Python 脚本做文件处理，它要处理大文件，3 秒肯定不够，但 30 秒也足够它给出结果了。这个值不要设置得太长，因为对 Agent 系统来说，工具调用时间越长，整个会话的延迟就越高，用户体验就越差。

总超时（total timeout）是对整个工具调用过程的兜底，建议控制在 30 秒。不管哪一层出了问题，总超时一到，立即终止调用并返回错误。

这三层超时之间的关系是：总超时 > 读超时 > 连接超时，每一层都有明确的失败条件。设置完之后，还要配合健康检查机制。我在生产环境里会给每个工具加一个心跳检测，每 30 秒探测一次工具是否存活，如果连续 3 次探测失败，就把工具标记为不可用，直接从可用工具列表里摘掉。这样做能大幅降低线上工具超时的概率，因为很多故障在用户请求进来之前就已经被发现了。

这里有一个我踩过的坑：不要只用一套超时配置跑所有环境。开发环境、测试环境、生产环境的网络状况完全不同，你在本地 500ms 能调通的接口，生产环境可能因为防火墙策略、跨机房延迟变成 3 秒。最稳妥的做法是把超时配置做成可动态调整的，每个环境单独维护一套配置，线上变更通过配置中心下发，而不是改代码发版本。

2.3 工具超时之后，把什么内容塞回给模型

工具超时之后，Agent 系统要做两件事：一是终止这次工具调用，二是把超时信息改写成模型能理解的反馈。第二件事很多人做不好。

如果你直接把一个裸的 TimeoutException 塞给模型，或者只说一句“工具调用超时”，模型大概率会认为“这次是我没调用好，我再试一次就能成功”，于是立刻发起重试。这恰恰是面试题里“模型不停重试”的根源。正确的做法是：把超时改写成结构化的错误信息，明确告诉模型发生了什么、这是不是可恢复的错误、接下来该怎么做。

我实际用的错误反馈结构长这样：

{ "success": false, "error": { "code": "TIMEOUT", "stage": "connect", "tool": "weather_api", "message": "连接天气服务超时，耗时超过 5 秒", "retryable": true, "suggestion": "可以尝试备用天气数据源，或等待 2 秒后重试，最多重试 1 次" } }

把这段 JSON转成文本后追加到上下文，模型看到的是“retryable: true + suggestion: 等待 2 秒后重试，最多 1 次”，它就不会盲目地连环重试了。这个思路本质上是把人类的“故障沟通技巧”教给了模型——你不是只说“坏了”，而是说“哪里坏了、严不严重、下一步怎么办”。

另外要注意，超时错误信息里不要附带太多诊断细节。有些运维习惯把堆栈、IP、耗时曲线全都塞进去，这些对模型推理没有帮助，反而会污染上下文。给模型的内容，要精简到“发生了什么、是否可重试、建议怎么做”这三个维度就够了。

2.4 降级策略：工具不可用时，Agent 不是只能干等

工具超时之后，除了让模型“知道了然后重试”，你还可以在运行时层面提供降级路径。我总结下来有三类降级手段，可以在不同场景下兜底。

第一类是备用工具。同一个功能，提前准备两个或三个不同提供方的 API，比如天气查询有 A 厂和 B 厂的接口，搜索有搜索一和搜索二。主工具超时后，运行时直接尝试备用工具，或者把备用工具的信息给到模型，让它自动切换。这个方案的成本是可观测性变复杂，你需要记录每一次工具切换的原因和链路。

第二类是缓存兜底。不是所有工具调用都需要实时结果。对于天气、汇率、新闻、股票这类更新频率不高的数据，可以在内存或者 Redis 里缓存最近一次成功结果，工具超时时直接返回缓存数据，并标注“该数据可能是 30 分钟前的”。对很多任务来说，一个稍旧的数据远比“拿不到数据”强。

第三类是把超时转成对模型可解释的降级结果。意思是，如果工具超时了，你返回的不是“错误”，而是一个“降级后的结果”。比如查订单状态的工具超时了，你可以返回“无法实时获取订单状态，当前已降级为快照数据，展示用户上一笔成功交易的订单记录”，模型看到这个信息后，能更自然地调整自己的回答策略，而不是陷入“反复调同一个工具”的死循环。

这三类降级策略可以组合使用，但一定要记住：降级结果必须在反馈给模型的内容里明确标注“这是降级数据”，不能伪装成实时数据，否则 Agent 会把过期数据当作事实告诉用户，这就不是成本问题而是准确性事故了。

3. 模型不停重试：如何止住重试风暴

3.1 模型为什么会“执着地”重试

面试官问“模型不停重试怎么办”，本质上是在考你对模型行为的理解。模型为什么会在工具超时后反复重试？我的理解是，模型在做基于概率的序列生成，它在每一步都选择“最像正确答案”的下一步。当工具调用失败时，模型从训练数据里学到的模式是：如果我看到了失败，那么下一步最有可能是换个方式再试一次。尤其在多步推理任务里，模型已经把“获取工具结果”作为当前目标的前置条件了，它没有轻易放弃的机制。

更深层的原因是：模型并不知道它重试的行为会导致什么后果。它没有成本感知，不知道每次重试都在消耗 token、增加延迟，对下游工具造成压力。它也没有时间感知，网络超时对它来说只是“一个反馈”，它无法判断“这个工具已经挂了 10 分钟了”和“这个工具刚才只是抖动了一下”有什么区别。

所以治理模型重试，不能只靠“在提示词里跟模型说不要重试”，要从系统架构层面给模型提供“放手”的依据和能力。我自己总结了一套三层治理框架：退避、上限、熔断。这套框架的参考思路其实脱胎于分布式系统的重试治理，但 Agent 场景有其特殊性，需要结合模型的行为特点来设计。

3.2 第一层：指数退避与抖动，让重试不变成风暴

第一层治理是控制重试的频率。模型发起重试请求后，系统层面要拦截这个重试，强制加入退避等待时间，而不是立刻放行。

退避算法我用的是指数退避加抖动。核心思路是：每次重试的等待时间随着重试次数指数增长，同时加入一个随机抖动来避免多个请求同时重试造成“惊群效应”。

import random import time base_delay = 1 # 基础等待，单位秒 max_delay = 30 # 最大等待，单位秒 jitter = 0.3 # 抖动比例 def retry_delay(attempt: int) -> float: exp_delay = min(max_delay, base_delay * (2 ** attempt)) # jitter 让等待时间在一个区间内随机，避免多请求同时重试 actual_delay = exp_delay * (1 + random.uniform(0, jitter)) return actual_delay # 使用：第 0 次失败后等待约 1s，第 1 次失败后等待约 2s，第 2 次失败后等待约 4s time.sleep(retry_delay(attempt))

这个公式里的关键参数是 base、cap 和 jitter。base 我一般设 1 秒，不太长也不太短；cap 设 30 秒，防止等待时间无限膨胀；jitter 设 0.3 到 0.5 之间，太小起不到分散作用，太大又会让用户等太久。这个方案的优点是：短时间的工具抖动不会造成高频重试，长时间的工具故障又不会让系统一直烧钱。

但注意，退避等待是发生在系统层面的，不是让模型“sleep”然后继续。你要做的是在运行时拦截模型的重复工具调用请求，判断是否命中重试场景，命中则直接注入“等待 X 秒”的等待状态，或者返回到巡检循环。不要指望模型自己会等待。

3.3 第二层：最大重试次数，超了就必须换路径

第二层治理是设置重试次数的上限。这个数值不能拍脑袋定，需要结合两个因素来看：一是工具的可靠程度，二是业务对延迟的容忍度。

对于外部 API，比如天气、地图、搜索这类，我一般允许最多重试 2 次；对于内部服务，允许最多重试 3 次；对于本地工具，最多重试 1 次。这些数值不是固定的，你需要线上跑一段时间后，根据工具的成功率来调。比如某个工具平时成功率 99%，那你可以设 2 次重试；如果某个工具成功率只有 90%，那与其重试不如直接换方案。

重试次数耗尽之后怎么办？不能就这么让 Agent“卡死”，你要设置一条强制改道规则。我之前是这样做的：当同一工具在同一轮任务中连续失败达到 N 次，系统不是继续让模型思考，而是强制推进到下一个动作——要么切换到备用工具，要么让模型基于已有信息直接作答，要么标记任务失败并让用户介入。这相当于在模型层之上，加了一层确定性的控制器，防止模型进入“无尽重试”的状态。

这里还要强调幂等性设计。工具重试有一个隐含风险：如果工具不是幂等的，比如创建订单、转账这类有副作用的操作，重试可能导致重复下单、重复扣款。所以面向 Agent 的每个工具调用，都要带上一个 request_id，工具执行方记录已处理过的 request_id，重复请求直接返回“该请求已处理过”的结果。这在生成式 Agent 系统里不是可选项，是必选项。

3.4 第三层：熔断与语境管理，让 Agent 学会“放手”

熔断是第三层治理。原理类似于股票交易里的熔断机制：当某个工具在一段时间内连续失败达到阈值，系统直接打开熔断开关，短时间内对该工具的全部调用快速失败，不再真正发起请求。这样可以保护下游工具，防止重试风暴把工具彻底打挂。

我的熔断配置举例：10 秒内连续失败 5 次，触发熔断 60 秒。这个 60 秒期间，所有对这个工具的调用直接返回“当前工具不可用，请稍后再试或使用替代方案”。熔断结束之后，放行一部分试探请求，如果成功则逐渐恢复流量，如果继续失败则再次熔断。实现上可以用一个简单的滑动窗口计数器，也可以用现成的熔断器库，这类方案在 Go、Python、Java 生态里都很成熟。

除了系统层面的熔断，还要做“让模型学会放手”的语境管理。模型在重试过程中，上下文里会堆积大量重复的失败日志，比如下面这个循环：

“调用工具A超时 -> 再次调用工具A超时 -> 继续调用工具A超时”

这些重复的失败记录会把模型的注意力完全吸住，让它越来越倾向重试。解决方法是：在把工具结果追加到上下文之前做压缩处理。如果同一工具已经连续失败多次，从第二轮失败开始，你不再追加完整的错误信息，而是追加一条简洁的汇总信息：“该工具在过去两轮调用中连续失败，错误均为超时，建议停止调用该工具，考虑切换方案。”模型看到这个汇总后，放弃重试的概率会大大提高。

同时，可以在系统提示词里加入“工具失败时的行为准则”。我自己用的一段话是：“如果工具调用失败，先从错误信息中的 suggestion 字段判断下一步行动。如果错误标记为不可重试，立即停止尝试该工具，切换备用方案或如实告知用户。不要无指导地重复尝试同一工具。”这段话放在系统提示词里，比每次临时拼接错误信息要稳定得多。

还有一个实际经验：给每个工具调用记录一个 attempt 计数器和总耗时，将这两个数字也反馈给模型。比如“第 2 次尝试，累计耗时 47 秒”，模型看到累计耗时之后，会产生“这太久了，不该继续下去”的判断，这也符合人类在真实协作中的行为模式。

4. 面试官真正想考什么：Agent 工程的系统化思维

4.1 这个问题背后的三层考察点

面试聊完之后我复盘了一下，那位面试官的问题看着是考“执行流程”，其实暗含了三层考察点，每一层都对应着不同的能力维度。

第一层是底层理解。你能不能把 Agent 的执行循环讲清楚，不是背概念，而是能说明每一步的输入输出、终止条件、异常分支。这一层考察的是你对 ReAct 循环、function calling、上下文管理的真实理解。

第二层是异常工程意识。工具超时、重试风暴这类问题，普通开发者写 demo 的时候根本不会碰到，只有搞过生产级系统的人才会考虑。面试官抛出这个场景，就是在试探你有没有把 Agent 当“工程系统”来设计，而不是只当“提示词 + API 调用”的玩具。

第三层是成本与风险权衡。无限重试的背后是 token 成本、下游系统压力、用户等待时间三者的博弈。你能不能说出“为什么不能无限重试”的工程理由，以及如何用退避、限流、熔断机制来平衡，这考察的是系统设计能力。生产级 Agent 和 demo 的分水岭，就在这里。

4.2 参考答案框架：三步回答法

如果让我重新回答一次这个问题，我会用一个三步框架来讲，既清晰又不容易被追问打乱。

第一步讲正常执行路径。任务是先解析意图，然后进入 ReAct 循环，模型思考后通过 function calling 调用工具，工具结果回填上下文，直到模型输出最终答案或达到最大迭代次数。

第二步讲异常路径。工具调用可能超时，三层超时分别控制，超时后返回结构化错误，错误信息里包含是否可重试和建议动作，同时系统侧有降级策略（备用工具、缓存兜底等）。

第三步讲治理方案。对于模型不停重试，采用“退避 + 上限 + 熔断”三层治理，匹配幂等设计和上下文压缩，在模型层之上加确定的规则护栏，让模型既能利用工具的灵活性，又不至于失控。

这个框架的好处是：先讲正常再讲异常，先讲模型再讲系统，层级分明。面试官追问任何一点，你都有内容可以往下展开。

另外，面试官特别爱追问的一个点是“max steps 设多少，为什么”。别背一个空泛的数字。你可以说：“初始值设 10，然后根据任务的工具调用平均次数来调整。如果大多数任务只需要 2 到 3 次工具调用，10 就已经很富裕了；如果任务复杂度高，比如多轮搜索加多源比对，我再放宽到 15。同时会在每轮循环前检查剩余步数，如果接近上限，模型会被提示必须在本次输出中给出结论。”这个回答既展示了数据分析意识，又展示了兜底设计。

4.3 实战踩坑实录：几个我真实遇到过的案例

光讲理论没用，我挑三个真实踩过的坑出来，都是“工具超时 + 模型重试”组合拳打出来的事故，你们看完应该能直观感受到这个问题的杀伤力。

第一个坑是天气工具引发的死循环。早期做的客服对话 Agent，接了一个第三方天气查询接口，某天对方服务波动，连续 5 分钟超时。我们的超时时间是 10 秒，超时后直接把带堆栈的异常塞给模型，结果模型以为“参数不对”，开始疯狂修改参数重新调用，每次还都等满 10 秒超时。用户问一句“明天天气怎么样”，Agent 后台跑了 8 分钟、调了 20 多次工具、烧了十几万 token，最后也没给出答案。之后我把超时错误改成了结构化信息，把堆栈去掉，加了 retryable 字段和 suggestion，同样这个场景，模型最多试 2 次就会说“天气服务暂时不可用，我换个数据源试试”，完全变了个样子。

第二个坑是数据库 Agent 的重试风暴。当时给一个内部知识库做查询 Agent，工具是查数据库的接口，某次数据库连接池被慢查询打爆，Agent 遇到超时后立刻重试，重试请求又把连接池拖得更死，形成正反馈循环。数据库直接连不上了。这个事故让我彻底明白了重试必须要在系统层面做退避和熔断，不能指望模型自己收敛。后面加上了 3 次上限和 30 秒熔断，同一场景下，数据库挂了最多少量请求失败，不会再被打爆。

第三个坑是本地工具的无响应卡死。这个更隐蔽。我们的工具里有个本地格式转换工具，某一次处理一个超大文件时进程死锁了，既不返回也不报错，调用它的 Agent 一直干等，直到总超时 30 秒才醒悟。但问题在于，这个进程占着资源不放，后续任务再调它照样卡死，我们的策略是给本地工具增加进程级看门狗，超时直接 kill 掉进程重新拉起。这个案例提醒我，工具超时不能只靠客户端设置，工具侧也要有超时自杀机制。

这三个坑做完之后，我们沉淀了一套通用的“工具调用错误处理规范”，包括错误码分类、重试策略表、降级路径梳理。从运维视角看，Agent 系统的稳定性，其实不是模型的稳定性，而是它依赖的工具生态的稳定性。模型本身不会“崩溃”，但工具会，重试会，超时也会，所有治理手段本质上都是在保护工具生态不被模型的无监督行为搞垮。

4.4 面试追问速查：遇到这些问题怎么答

我把面试官可能追问的问题整理成了一个小表，每一个都是在这次面试中被追问过的，或者我复盘后觉得大概率会被问到的：

这张表别死背，核心是把“系统侧兜底 + 模型侧引导”的思路理顺。面试官要的不是标准答案，是你遇到这类问题的解决框架。

另外补充一个我实测有效的面试答题技巧：遇到这种“怎么办”类问题，先别急着给结论，先快速把问题拆成“正常路径是什么 + 异常有哪些可能 + 每种异常怎么处理”三段。这样不仅显得思路清晰，你讲的时候也不容易漏点。那位面试官后来在反问环节说，他问这个问题是为了筛掉那些只会调 API、不会设计系统的候选人，因为 Agent 生产环境里，异常处理能力直接决定系统能不能上线。这句话我印象很深。

我个人在实际操作中最深的体会是：Agent 系统的稳定性建设，80% 的精力都花在工具调用这一层，而不是模型层。你把工具超时、重试治理、降级策略设计好了，整个系统自然就稳了。如果你正在准备 Agent 方向的面试，建议不只背概念，而是真的去跑一个会调用外部 API 的小项目，故意把接口调慢、调挂，亲手观察模型的重试行为，再针对性地加上退避和熔断，这个经验比看十篇文章都管用。