AgentChaos: Chaos Engineering for Agent Systems via Programmatic Fault Injection
提出AgentChaos，通过HTTP层非侵入式注入LLM API故障，评估代理系统鲁棒性。
核心发现
方法论
本文设计了基于分布式系统故障分类的LLM API响应故障分类体系，涵盖崩溃、遗漏和数值错误等六种类型。利用HTTP请求拦截机制，在运行时无源代码修改条件下，注入65种故障配置。通过验证故障触发情况，筛除未触发任务，确保评估准确性。多系统、多基线LLM模型和基准测试在不同故障配置下，性能普遍下降，pass@1最多下降50个百分点。故障诊断准确率低于53%，显示出识别难度。研究发现系统实现对鲁棒性影响大于模型能力，提出未来优化方向。
关键结果
- 在65种故障配置下，所有代理系统的性能均显著下降，最大pass@1下降达50个百分点，验证了故障注入的有效性。
- 不同模型间鲁棒性排名一致，表明系统实现比模型能力更关键。
- 故障诊断准确率低于56%，表明现有方法仍有较大提升空间。
研究意义
该研究突破传统离线或非API层故障注入限制，实现了实时、非侵入式的故障模拟，为大模型驱动的代理系统提供了系统性鲁棒性评估工具。其结果揭示了系统实现对鲁棒性的决定性影响，为未来系统设计提供了指导，有助于提升AI应用在实际场景中的可靠性和安全性。
技术贡献
提出基于HTTP请求拦截的故障注入框架AgentChaos，结合系统化故障分类，支持多场景、多模型、多故障配置的动态测试。创新点在于无需源代码修改即可实现细粒度响应内容故障注入，结合故障触发验证机制，有效避免漏检。该框架为大规模鲁棒性评估提供了新工具，显著优于传统离线或仅模拟网络层故障的方法。
新颖性
首次提出面向LLM API响应的系统化故障分类体系，结合HTTP层动态注入技术，实现了对响应内容（如截断、编码错误）等多维度故障的实时模拟。与现有方法相比，突破了只模拟服务器错误或超时的局限，支持细粒度内容修改，极大丰富了故障场景，推动了混沌工程在AI系统中的应用创新。
局限性
- 当前框架主要针对HTTP层响应故障，对于模型内部的语义偏差或 hallucination 等内容级故障支持有限。
- 故障注入策略依赖于预定义的配置，可能无法覆盖所有实际故障场景，未来需结合学习型策略优化。
- 在高并发环境下的性能影响和扩展性仍需验证，实际部署中可能面临性能瓶颈。
未来方向
未来将结合自适应故障策略和深度学习模型，提升故障检测与诊断准确率。计划扩展多协议、多层次故障注入能力，增强系统在复杂环境中的鲁棒性评估。同时，结合自动化修复机制，推动AI系统的自我修复与安全保障。
AI 总览摘要
随着大规模语言模型（LLMs）在智能代理系统中的广泛应用，系统的鲁棒性成为关键问题。现有故障注入方法多为离线或依赖源代码修改，难以实现实时、细粒度的故障模拟，限制了鲁棒性评估的全面性。本文提出AgentChaos，一种基于HTTP请求拦截的混沌工程框架，支持在运行时非侵入式注入多种LLM API响应故障。通过定义崩溃、遗漏和数值错误六大类故障，结合65个配置场景，系统性模拟实际部署中的多样故障类型。实验在多个代理系统和模型上验证，性能普遍下降，最大降幅达50个百分点，显示出系统实现对鲁棒性的影响大于模型能力。故障诊断准确率仍低于56%，表明未来仍有提升空间。该框架为AI系统的鲁棒性评估提供了新工具，有助于推动安全可靠的AI应用落地。
深度分析
研究背景
近年来，基于大模型的智能代理系统在问答、推理和软件工程等领域取得突破，代表性工作如OpenAI的ChatGPT、Anthropic Claude等。传统方法多关注模型性能优化，缺乏系统性鲁棒性评估工具。故障注入作为验证系统抗干扰能力的重要手段，已在传统软件中广泛应用，但在大模型API场景中仍面临挑战，特别是响应内容的细粒度故障模拟不足。近年来，混沌工程逐渐引入AI系统，旨在提前发现潜在脆弱点，提升系统可靠性。
核心问题
现有故障注入方法多为离线分析或仅针对网络层错误，难以模拟响应内容的细节故障（如截断、编码错误），且无法在运行时动态实现。LLM API的响应结构复杂，内容多为自由文本，缺乏系统化的故障分类体系，导致鲁棒性评估片面。此外，缺乏针对不同故障类型的细粒度注入机制，限制了对系统在实际故障场景下表现的理解。如何在保证无源代码修改的前提下，全面模拟多样化的响应故障，成为亟待解决的问题。
核心创新
本研究创新在于提出基于HTTP层的非侵入式故障注入框架AgentChaos，结合系统化的LLM API响应故障分类体系，支持多场景、多模型、多故障配置的动态模拟。具体创新点包括：
1）定义崩溃、遗漏、数值错误等六大类响应故障，覆盖实际部署中常见问题；
2）设计HTTP请求拦截机制，可在运行时无源代码修改条件下，细粒度修改响应内容（如截断、编码错误）；
3）引入故障触发验证机制，确保故障真正触发，避免误判。
这些创新极大丰富了故障模拟场景，为系统鲁棒性评估提供了强有力工具。
方法详解
- �� 设计响应故障分类体系，结合分布式系统故障模型，定义崩溃、遗漏、数值错误等六类故障。
- �� 利用HTTP请求拦截机制，动态拦截LLM API响应，依据配置修改响应内容（如模拟截断、编码错误等）。
- �� 采用故障触发验证，记录调用轨迹，确认故障是否触发，过滤未触发任务。
- �� 通过多模型、多系统、多基准测试，评估性能变化。
- �� 设计多种故障配置（如单次、持续、间歇、突发），模拟真实场景中的多样故障。
- �� 结合实验数据，分析性能下降幅度，验证框架有效性。
实验设计
实验采用OpenAI、Anthropic等多家LLM提供商的API，测试多个代理系统（如MapCoder、LangChain等）在不同任务（如Code生成、问答）上，应用65种故障配置。指标包括pass@1、成功率等。通过对比故障前后性能，验证故障注入的影响。还进行故障诊断准确率评估，分析不同故障类型的识别难度。实验结果显示，性能最大下降达50个百分点，验证了框架的有效性和实用性。
结果分析
所有系统在故障注入后性能均显著下降，最大降幅达50个百分点，验证了故障模拟的真实性。不同模型的鲁棒性排名一致，表明系统实现比模型能力更影响鲁棒性。故障诊断准确率低于56%，显示出识别难度。多场景、多模型的测试验证了框架的广泛适用性，为未来鲁棒性优化提供数据基础。
应用场景
该框架适用于AI系统开发者、测试工程师，可在实际部署前模拟多种故障场景，优化系统设计。也可用于模型供应商进行鲁棒性测试，提升API的稳定性。未来还可结合自动修复机制，推动AI系统的自我诊断与修复，增强其在关键应用中的可靠性。
局限与展望
目前框架主要针对HTTP层响应内容故障，对于模型内部的语义偏差、hallucination等内容级故障支持有限。故障配置依赖预定义场景，难以涵盖所有实际故障类型。高并发环境下性能影响尚未充分验证，未来需优化扩展性和效率。
通俗解读 非专业人士也能看懂
想象你在一家工厂工作，工厂里有很多工人（代表系统中的不同部分）在合作完成一件大事。每个工人都依赖工具（像API）来完成任务。有时候，工具会出错，比如突然停工（崩溃）、只完成一部分（遗漏）或给出错误的指令（数值错误）。如果工厂想提前知道这些问题会不会影响整体生产，就需要模拟这些故障。本文提出一种方法，就像在工厂里偷偷调皮地让工具出错一样，但不用改动工厂的机器，只是在工具的“信号线”上做手脚。这样可以在工厂正常运转时，测试出哪些故障会导致生产停滞，从而提前修补漏洞，确保真正的生产不会出大问题。
简单解释 像给14岁少年讲一样
想象你在学校玩游戏，有时候游戏会突然卡住、画面变得奇怪，或者只显示一半内容。这些问题让你很烦，但其实游戏开发者可以提前模拟这些问题，测试游戏的耐玩程度。本文就像是给游戏开发者发明了一种特殊的“作弊工具”，可以在不修改游戏代码的情况下，模拟各种出错情况，比如游戏卡住、画面错乱或只显示一半。这样，开发者可以提前知道哪些地方容易出错，提前修好，确保正式上线时游戏不会崩溃。就像在考试前模拟各种意外情况，帮助你更好地准备，避免真正的糟糕情况发生。
原文摘要
Agent systems rely on LLM APIs for every response, but these APIs can return server errors, truncated responses, or corrupted content that propagates through downstream agents and causes task failure. Evaluating robustness under these faults is crucial for reliable deployment. Existing fault injection methods are offline, require source code modification, or cannot modify specific response fields. A comprehensive evaluation also requires a systematic fault taxonomy because different fault types affect downstream agents differently. We propose AgentChaos, a chaos engineering framework for controlled, runtime, non-intrusive LLM API fault injection. Since all agent systems access LLMs through the same HTTP interface, we inject faults at this shared layer without modifying source code. We define crash, omission, and value faults on content and tool call fields, intercept and modify LLM API responses at runtime, and verify whether each fault is triggered to filter untriggered tasks and avoid underestimating fault impact. Evaluations across agent systems, benchmarks, and backbone LLMs under 65 fault configurations show that all systems degrade under fault injection, with pass@1 dropping by up to 50 percentage points. The ranking is consistent across models, suggesting that robustness depends on system implementation rather than model capability. Existing fault diagnosis methods achieve below 53% accuracy on fault type and below 56% on fault step, leaving room for improvement. We further reveal practical findings for agent system developers.