上周二晚上，我正准备睡觉，手机突然响了。是运维同事打来的，说线上的自主Agent系统出问题了，用户反馈Agent一直在重复执行同一个操作，停不下来，已经产生了大量异常数据。

我赶紧打开电脑，连上线上环境，开始排查。这一排就是一夜，直到第二天早上才找到原因并修复。这篇文章，我想记录一下这次排查的完整过程，以及从中得到的经验和教训。

自主Agent系统和传统的软件系统不一样，它有一定的自主性，会根据环境和目标自己决定下一步做什么。这种自主性带来了灵活性，但也带来了调试的难度。出了问题，你不能简单地看代码逻辑，还要理解Agent的决策过程。

问题发现

那天晚上九点多，运维同事接到用户反馈，说我们的自主Agent在执行任务的时候，一直在重复调用同一个工具，好像陷入了死循环。用户手动停止了好几次，但Agent重新启动后又会重复同样的操作。

我们的自主Agent是一个多步骤任务执行系统，用户给一个目标，Agent会自己拆解任务、调用工具、根据结果决定下一步。正常情况下，Agent会一步步完成任务然后停止。但那天晚上，有几个任务的Agent一直在重复调用"搜索信息"这个工具，每次搜索的关键词还都一样，完全停不下来。

我先是看了监控面板，发现Agent的调用量确实异常，比平时高了好几倍。而且都是同一个工具的调用，参数也几乎一样。这说明Agent确实陷入了某种循环，没有正常推进任务。

我赶紧把出问题的几个任务暂停了，避免继续产生异常数据。然后开始排查原因。

初步排查

第一步，我看了Agent的执行日志。我们的Agent系统会记录每一步的决策过程，包括思考过程、调用的工具、工具的返回结果、下一步的决定。

看了日志之后，我发现了一个奇怪的现象：Agent每次调用搜索工具之后，都会得到一个结果，然后Agent会思考下一步该做什么。但每次思考的结论都是"信息不足，需要继续搜索"，然后又用同样的关键词搜索一次。

也就是说，Agent觉得搜索结果没有提供足够的信息，所以想继续搜索。但它没有换关键词，也没有换工具，而是用同样的方式重复搜索，结果当然还是一样的。这样就形成了死循环。

为什么Agent会觉得信息不足呢？我看了搜索工具的返回结果，发现结果其实是有内容的，而且内容和任务相关。按理说，Agent应该能从这些结果中提取信息，然后继续下一步。但Agent似乎没有正确理解搜索结果，或者说没有把搜索结果和任务联系起来。

我一开始以为是搜索工具出问题了，返回的结果格式不对，导致Agent解析不了。但检查了搜索工具的代码和返回结果，格式是正确的，和平时一样。那问题出在哪里呢？

深入排查

第二步，我对比了正常任务和异常任务的日志。发现正常任务的Agent，在搜索之后会正确分析结果，然后决定下一步。而异常任务的Agent，在搜索之后总是说信息不足。

我仔细对比了两者的区别，发现异常任务有一个共同点：它们的任务描述都比较复杂，涉及多个步骤和多个信息点。而正常任务的描述相对简单。

这让我怀疑，是不是任务描述太复杂，导致Agent的上下文不够用了？我们的Agent用的是大模型，上下文窗口是有限的。如果任务描述加上历史对话加上工具返回结果，超过了上下文窗口，模型可能就会丢失一些信息，导致决策出错。

我检查了异常任务的上下文长度，发现确实都比较长，接近上下文窗口的上限。而正常任务的上下文长度都在安全范围内。

但这还不能完全解释问题。因为如果上下文溢出，模型应该会报错或者表现出其他异常，而不是专门重复搜索。我继续深入排查。

第三步，我看了Agent的提示词。我们的Agent有一套系统提示词，告诉它如何拆解任务、如何调用工具、如何判断任务是否完成。我发现提示词里有一条规则："如果当前信息不足以完成下一步，就继续搜索相关信息。"

这条规则本身没问题，但问题在于，提示词里没有告诉Agent，如果多次搜索同样的内容都没有得到新信息，应该怎么办。也没有限制搜索的次数。所以当Agent觉得信息不足的时候，它就会一直搜索，而不会换一种方式或者放弃。

这就解释了为什么Agent会陷入死循环：它觉得信息不足，按照规则应该继续搜索，但搜索同样的内容不会得到新信息，所以它还是觉得信息不足，继续搜索。形成了一个自我强化的循环。

但为什么只有复杂任务会出现这个问题呢？因为复杂任务需要的信息更多，Agent更容易觉得信息不足。而且复杂任务的上下文更长，模型的决策质量会下降，更容易做出重复搜索的决定。

找到根本原因

第四步，我做了一个实验。我把一个异常任务的上下文复制出来，在测试环境里重新运行，果然复现了问题。然后我逐步减少上下文长度，发现当上下文缩短到一定程度之后，Agent就能正常工作了。

这证实了我的猜测：上下文过长导致模型决策质量下降，加上提示词缺少退出循环的机制，共同导致了死循环。

但还有一个细节我没搞清楚：为什么Agent会觉得搜索结果信息不足？我看了搜索结果，内容是足够的。我把搜索结果单独拿出来问模型，模型能正确提取信息。但放在长上下文里，模型就提取不了了。

后来我才明白，这是大模型的"中间遗忘"问题。当上下文很长的时候，模型对中间部分的信息关注度会下降，容易忽略中间的内容。而搜索结果正好在上下文的中间位置，所以模型没有正确读取搜索结果，觉得信息不足。

这个问题在长上下文场景下很常见，但之前我们没有遇到过，因为之前的任务都比较简单，上下文不长。这次的复杂任务把上下文拉长了，就触发了这个问题。

所以根本原因是：复杂任务导致上下文过长，大模型出现中间遗忘，没有正确读取搜索结果，觉得信息不足，而提示词里没有限制重复搜索的机制，导致Agent陷入死循环。

修复方案

找到原因之后，我开始修复。修复从几个方面入手。

第一个修复是给Agent的工具调用加上次数限制。在提示词里明确规定，同一个工具用同样的参数最多调用两次，如果两次之后还是没有进展，就必须换一种方式或者向用户求助。这样即使模型觉得信息不足，也不会无限重复搜索。

第二个修复是优化上下文管理。我们实现了一个上下文压缩机制，当上下文超过一定长度的时候，自动把早期的工具返回结果压缩成摘要，只保留关键信息。这样可以有效控制上下文长度，避免中间遗忘问题。

第三个修复是改进提示词。在提示词里增加了对搜索结果的处理要求，告诉Agent每次搜索之后必须先总结搜索到的信息，然后再决定下一步。这样可以强迫模型关注搜索结果，而不是直接跳过。

第四个修复是增加监控和告警。我们给Agent系统加了异常检测，如果发现同一个工具被重复调用超过一定次数，就自动暂停任务并告警。这样即使出了问题，也能及时发现，不会等用户反馈才知道。

第五个修复是增加人工干预机制。当Agent遇到困难的时候，可以主动向用户求助，而不是自己死磕。这样既避免了死循环，也能让用户参与到任务执行中，提高任务的成功率。

这些修复上线之后，我把之前出问题的几个任务重新运行了一遍，都能正常完成了。又观察了几天，没有再出现类似的问题。

经验和教训

这次排查了一夜，虽然很辛苦，但也学到了很多。这里总结一下经验和教训。

第一，自主Agent系统一定要有退出循环的机制。Agent有自主性，但这种自主性需要有边界。如果没有限制，Agent可能会陷入各种死循环，消耗大量资源。在设计Agent的时候，要考虑到各种异常情况，给Agent的行为加上合理的限制。

第二，长上下文是大模型应用的常见坑。上下文越长，模型的决策质量越容易下降，还会出现中间遗忘等问题。不要以为上下文窗口大就可以随便塞内容，要做好上下文管理，该压缩的压缩，该丢弃的丢弃。

第三，提示词工程在Agent系统中至关重要。Agent的行为很大程度上是由提示词决定的，提示词里的一条规则，可能就会导致完全不同的行为。写提示词的时候要考虑各种边界情况，不能只考虑正常流程。

第四，监控和告警是必须的。自主Agent系统的行为比较复杂，出了问题可能不容易发现。一定要有完善的监控，能及时发现异常行为，比如重复调用、异常耗时、资源消耗过高等。不要等用户反馈了才知道出了问题。

第五，调试Agent系统要看决策过程。传统软件调试看代码和变量，Agent系统调试要看模型的决策过程。要记录Agent的思考过程、工具调用、结果反馈，这样出了问题才能追溯原因。没有完整的决策日志，Agent出了问题根本没法排查。

第六，测试要覆盖复杂场景。我们之前测试的都是简单任务，没有测过复杂的长任务，所以这个问题没有在测试阶段发现。以后测试Agent系统，一定要覆盖各种复杂场景，包括长任务、多步骤任务、异常输入等。

写在最后

这次线上故障排查了一夜，虽然很累，但也很有价值。它让我更深入地理解了自主Agent系统的特点和挑战，也让我们的系统更加健壮了。

自主Agent是一个很有前景的方向，但也是一个很新的领域，很多最佳实践还在探索中。我们在使用的过程中，会遇到各种各样的问题，每解决一个问题，就是一次成长。

如果你也在做自主Agent相关的开发，希望我的这次经历能给你一些参考。特别是上下文管理和循环控制这两个点，一定要重视，不然很容易踩坑。

最后用一句话来结束这篇文章："自主Agent的自主性是一把双刃剑，用好了能极大提升效率，用不好会制造各种麻烦。关键是给它装上合适的护栏。"

愿每一个做Agent开发的工程师，都能少踩坑，多产出。