人工智能代理的失败方式与传统软件不同——它们不会因堆栈跟踪而崩溃。它们会悄然失效：返回不完整的答案、因缓慢的 API 而卡住，或反复调用同一工具而浪费大量令牌。表面上看，代理似乎仍在运行，但其输出却是错误的、延迟的，或成本高昂的。
本系列文章涵盖了三种最常见的失败模式，并提供了经研究验证的解决方案。每种技术都附带一个可运行的演示，用于衡量改进前后的差异。
可运行代码： github.com/aws-samples/sample-why-agents-fail
这些演示使用了 Strands 代理 和 OpenAI（GPT-4o-mini）。所介绍的模式与框架无关——适用于 LangGraph、AutoGen、CrewAI，或任何支持工具调用和生命周期钩子的框架。
本系列：三项关键修复措施
- 上下文窗口溢出 —— 针对大数据的内存指针模式
- 永不响应的 MCP 工具 —— 针对缓慢外部 API 的异步 handleId 模式
- 人工智能代理推理循环 —— 使用防抖钩子（DebounceHook）并清空工具状态，以阻止重复调用
当工具输出超出上下文窗口时会发生什么？
当某个工具返回的数据量超过大语言模型（LLM）可处理的范围时，就会发生上下文窗口溢出——例如服务器日志、数据库查询结果或文件内容超出了令牌限制。此时，代理不会抛出错误而崩溃，而是悄然退化：截断数据、丢失上下文，或生成不完整的答案。
IBM 的研究量化了这一问题：一个材料科学工作流消耗了2000 万令牌却失败了；而采用内存指针模式的相同工作流仅使用了1,234 个令牌并成功完成。
解决方案——内存指针模式： 将大数据存储在 agent.state 中，并向上下文返回一个简短的指针。下一个工具通过解析该指针来访问完整数据：
from strands import tool, ToolContext
@tool(context=True)
def fetch_application_logs(app_name: str, tool_context: ToolContext):
# 假设此处获取了大量日志数据
logs = get_logs_from_server(app_name)
# 将大数据存入 agent 状态
pointer_id = tool_context.store_in_state(logs)
# 返回一个简短指针而非完整数据
return f"日志已存储，指针 ID: {pointer_id}"
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
